The ORM Foundation

Hi,
  
  Is there a way to add constraints, using the Fact Editor, to a FactType definition in a declarative manor?  Can an IUC be added as in: Person(name)is member of {at most one} Team(name); where the text in the curly brackets adds an IUC to enforce a rule?  If there is not now a way to do this with NORMA, is there a reason why it would be impossible or impractical to add this facility to NORMA's fact editor?

  I think it would make entering FactTypes easier if, at least common, constraints could be added in this manor.  Taken further, would the ablity to add any ORM diagramatic elements as text provide a useful seperation of the diagramatic and textual representations of an ORM model?  Granted, that entering all properties associacted with model elements would get very cumbersome.  If NORMA could (does?) have a mechanism to keep both these (complete in themselves), representations syncronized, the modeler would be able to choose (at any point), which form is most useful for the purpose at hand; and those choices would conform to personal style and preferences.

  Don't most ORM modelers use both representations, diagramatic and textual, in the process of creating and evaluating their models?  The concise representation of a diagram, and its method of visually conveying complex relationships between significant numbers of model elements make it ideal for high level assessment.  Using text, on the other hand, offers the advantages of familiar and exact expression of individual or small groups of FactType elements.

  If you have comments or another perspective to offer on this, please do.

  Thanks.  BRN..

Brian,

You want a FORML parser. It's a good idea for NORMA. It'd be nice
to just be able to type in to the verbalizations window.

It's a pity there isn't a better textual language for ORM, but
FORML isn't that hard to parse. In fact, it's on my list of
things to do right after I finish parsing NORMA files into my
representation, which should be another couple of days work. I
think it can even be done with regular expressions. I really
need it, as I don't plan to build a drawing tool for my ORM
mapper at this stage - I'm more interested in the applications
of a model than its creation.

Hi Clifford,

  I hope you'll provide a way for us to take a look at what you're working on, when you complete your project.  Sounds like your idea of applications for ORM models is, in a sense, another abstraction - the model can be created in whatever manor the modeler chooses; you're concern is that it is compliant with ORM theory, ready to be used.  Good luck.  BRN..

I expect to publish my work as open source. It's in Ruby, and
I want it to be useful within the Rails framework, but there
are many steps, some of significant magnitude, before I've
reached that stage. Then again, after some early work, I might
get some collaborators :-).

NORMA is limited in its appeal to the open source community by
needing VS2005 Pro - and Windows - to run. Most hard-core Rails
developers are working on Apples, and others wouldn't work in a
Microsoft product of more than base-line pricing in any case.

When we were making the second pass on the fact editor, some time was spent trying to enter constraints via the fact editor. At first glance, it isn't that hard, as Brian suggested: Person(name)is member of {at most one} Team(name). In fact, the notation we toyed with was Person(name) is member of .at most one. Team(name). When the leading "." was entered, it was to fire the intellisense/auto-completion list with a basic set of common constraints, such as "at most one" or "exactly one". One goal was to be able to copy and paste from verbalization output (from Visio, for example) and quickly create a model.

At the time (mid 2005), other features took priority and we put the fact editor ideas on the shelf. I'm not sure if the current team has looked into it at all since. I agree that it would be beneficial to have at least these simple constraints in the fact editor when entering forward readings:

1) at most one
2) exactly one
3) at least one

Scott

Hi Scott,

  Thanks for the insights.  When asking about this in an email concerning Visio EA, I was in Outlook, and  typed the sample using italics for the constraint portion - couldn't do that with the editor used here.  Using italics looked more natural than a delimiting character set.  I wouldn't know if a formating option, like italics, would be workable in this instance. Considering the constraints that would be most helpful, covering the IU set would take care the most common chores.  Having these would eliminate the need to switch from keyboard to mouse; and removing that physical interuption would remove an interuption to the thought process of entering FactTypes.

  Going beyond the set of constraint declarations that would make life easier, would be important only to create two complete representations of the model, diagramatic and textual.  I haven't thought through the implications for that (or how it might be implemented), but I get a sense that they would open up new utilization of the models, as well as giving the modeler the choice as to how best to enter and assess FactTypes.  [It may have import as a method to establish a dynamic linkage between conceptual ORM models and physical implementations - something I think would be huge].

  Just as draging and dropping all the drawing elements (ovals, rectangles, line segments, etc...), on to a work space to enter each fact would be a pain, so would having to enter every constraint and property using text.  Also, a text only representation of a large model would be very hard for a human to comprehend - this human, anyway.  Unless a person were limited by a disablity, I doubt if they would choose to do all model creation using either form excusively.  In order to switch and choose (ad hock), would require the two representations be kept in sync.

  As far as using Intellisense, I recall Matt C. mentioning that it's not a trivial task to implement.  Not knowing what it takes to make it work, I thought it might make sense (no pun intended), in several aspects of the tool UI.  Also, I'm guessing there are propriatory rights issues (the more so if NORMA became independant of VS).

BRN..

Yeah, implementing Intellisense was not at all trivial. I spent quite a few months on it when I was on the team at Neumont. Once you have it as part of a text editor (the fact editor in this case), it's quite easy to assign the "completion set" a new array of strings which is the list you see in the auto-complete list. This would be the reason to use a character, such as "." or "{", to signal the beginning of a constraint in the editor and appropriately fill the completion set with the common phrases (at most one, at least one, etc).

Hi Scott,

  If Intellisense is the way to go, and it requires a character or symbol, maybe a comma would be a better choice than a period.  Periods are used so much for namespace hierarchy, that it might be confussing.  Also, a comma is a better choice for natural language-like reading; text following a comma is often used to qualify or extend the text that preceds it, as does a constraint.  

Student(name) is enrolled in, at most one, School(name).  

Do you need the ending comma as a delimiter?  Any thoughts on how the character choice would effect the ablity to enter multiple constraints in a FactType declaration?  This would be important if the options go beyond the combination of mandatory and frequency.  If you need a delimiter character, how about an apostophy?  Otherwise, wouldn't the capitolization of a following Object work and be more natural?  If the use of commas in value list constraints is a problem, the next best choice might be a semi-colon.

Student(name) is enrolled in/enrolls; at most one School(name); or Student is intern 

- for a disjuctive mandatory constraint for the two FactTypes.  Is the role selection ambibuous? I added the reverese reading to raise the issue. If role selection and role sequence selection can be made clear by positioning, then multiple elementary FactTypes can be referenced by external constraints, without having to modify their individual (atomic), declaration form.  This is not important in the limited addition of a few constraint types to the text based UI, but would be very important to work toward the two complete representation mode scheme I mentioned earlier.  Already the last example I showed is getting to the point where the diagrammatic representation is preferable for human consumption, but programmatic parsing is another kettle of fish.

BRN..

Brian,

It has definitely been too long since I've seen the source code for the fact editor to allow me to speak intelligently about this much further. We did look into creating a grammar at one point for the fact editor but I'm not sure if that lasted much longer than I did on the project. :-)

Is there anyone on the project now that can tell us if the implementation for the fact editor has changed much since those early days?

Scott

Unfortunately the fact editor has had little done to it since Scott graduated from Neumont. 

We are currently focusing most of our efforts on rearchitecting the transformation process from ORM to allow live views of target structures (e.g. database schemas and class models) and to enable much better handling of data types and name generation. 

Once this is in place, we plan to dramatically improve the fact editor, and eventually support a parsable textual input language for ORM (so that one could could enter whole ORM models including fact types, constraints and derivation rules in textual form). We hope to use this textual language also for declaring additional, non-graphcial constraints as well as conceptual queries. But this will take a while.

Terry

Hi Terry,

  Thanks for taking the time to comment on the NORMA development road map, or if that has too much of a connotation of certainty, then the at least a fair assessment of the way forward.

  I imagine that the work you are doing toward the live views will help when the time comes for reworking the FactEditor - let's hope.

  Good luck with the tasks at hand.  If there are specific elements of the framework where our feedback would help, let us know.  BTW, whenever there are elements that are slated for rework or replacement, letting us know (as you, Matt and Kevin have on occasion), helps us too. BRN..

"eventually support a parsable textual input language for ORM"

Is this going to be a derivative of FORML? Or something with
more of a symbolic (programming language) feel, or both/and?

I was planning on trying a fairly simple approach to parsing
NORMA's verbalizations using regular expressions. If that works
ok, then I can add more pattern matching until I have a complete
language. It might not be as succinct as a designer would like,
but there's something to be said for using the same language for
input that you get as output. I've never seen a spec for FORML.
Does that exist somewhere public?

Beyond that, I have a few ideas to adapt from my ADL (Aspect
Definition Language) which could yield a much more compact
representation.

I'd be keen to see any early proposals for your textual language,
as I have no plan to produce a graphical tool and my textual
language must be highly usable.

Hi Clifford,

  Your point of having the input (FactType entry), and output (Verbalization), using the same syntax/grammar/lexicon makes sense - in the same way that binary facttypes can (should), make sense when read from either direction.  In the later case, the words and phrasing are different for each direction,to accommodate English usage, but the semantic symmetry is an important part and strength of ORM.  The other obvious advantages are in reducing the learning curve and the likelihood of errors.

  It would probably be a good idea to have have some non-English speaking, or true multilingual people kick around ideas for a new FORML, to limit language bias.  This isn't a political correctness issue, or even a globalization issue, but a way to keep the semantic integrity as clean as possible.  Honestly, I don't know if it is possible to completely separate a model's semantics from a single natural language.  My guess is that handling objects and well defined constraint types would be a lot easier than handling the predicates.  A rose by any other name..., is a rose; but distilling the essence of the rest of that often quoted FactType definition isn't so easy.

  Have you made any descriptions of your ADL concepts public yet?  They sound interesting. BRN..

I don't know that it's generally going to be possible to
parse foreign language verbalisations. I think it's worth
doing for English, but a more context-free language is
needed for international adoption.

ADL is a toy DDL really, I've never got the handling of
relationships (essentially facts) right, and certainly
haven't got the support for constraints that ORM has, but
in that it creates an extended-ER structure with less
mapping, it's more directly implementable as a DB.
Although it "looks" attribute based, the underlying ideas
are fact-oriented. It supports aspect orientation very
naturally, hence the name. I invented it back in 1983 and
haven't really revised the model to adapt ideas from ORM.
If I drop the relation syntax and inspect add simple syntax
for binary facts (perhaps using operators like >-, -<, and
>-<), then the existing support for annotations would
easily allow representation of most of ORM - only higher-
order facts and a few things like subset and frequency
constraints need to be added. The spec is on my site at
<http://polyplex.org/cjh/software/adl>.

In any case it gives a bit of a flavour of what I'd like
to see an ORM language look like.

Actually, there are two of us working on the Fact Editor right now. As you may imagine, the ramp up time on this project is pretty big. We have recognized a number of issues with the current editor and are working to resolve all of those as well as take care of some fundamental problems with the current implementation. It should be able to start behaving a little more predictably when it comes to editing already existing facts. I'm fairly new to the project and brand new to these forums, but I'll try and answer what I can about the Fact Editor, as it is the one thing I am directly working on at the moment.