I checked to see if adding prefixs and suffixes to FactTypes was allowed in NORMA (as it was in IM). I hadn't used them in IM, and am not sure how useful they are. My assumption is that they are used only to add clarity to the reading of a FactType, and have no effect on the model or how the model is mapped through OIAL, or further along the line; is this true?
Anyway, NORMA does accept something like: owned DOG(name) has Personality(type)
Here, owned is an adjective of Dog indicating that a dog that has an owner, but not where THAT fact is important enough to record - it just helps to qualify the statement.
First, is this use of a prefix (where it has no functional effect), a good idea? By implying introduced facts (that some dogs have owners, and only owned dogs have personalities), does that make the model more clear and correct, or less so?
Second, should a prefix or suffix have some function in a model? Can it have a function and exist without the restrictions imposed on the other elements of a FactType, and not compromise the model?
Finaly, even if just used as an aid to readablity, the current verbalization of a FactType that contains a prefix is not good: Owned each Dog has at most one Personality.
Thanks for your comments. BRN..
I think you're referring to is known as hyphen-binding. In a reading, you put a hyphen after the word you want to use as a prefix. There's a suffix syntax too, and I think it's just prepending a hyphen to the suffix word. For an example, let's say "Person has Grandfather". If you wanted to break that out into two fact types you would enter, "Person has paternal- Grandfather" and "Person has maternal- Grandfather". Then verbalizations would be something like, "Each Person has at most one paternal Grandfather."
You're incorrect in assuming that it doesn't affect the model or its mappings. In this case you're breaking apart the fact type with the frequency constraint ("Each Person has at most two Grandfather"). It's a common optimization technique for reducing the number of many-to-many fact types that get mapped to separate tables. For this example, instead of a "Person" and a "PersonHasGrandfather" table being generated, you'd have a "Person" table with "maternalGrandfather" and "paternalGrandfather". (This example assumes Grandfather plays no other role and gets absorbed.)
I remember it being in the verbalization specs, and for some reason I have a memory of seeing it working in the NORMA verbalization browser. It doesn't seem to be working in the version I'm running right now, but I keep putting hyphen bindings into my models anticipating the day that it will magically work.
For your model, you'd put a subset constraint on "owned- Dog is owned by Person" and "Dog has Personality" so that "For every owned Dog that has Personality, that owned Dog is owned by some Person." The readings could be finessed, but I think that covers the basic idea.
-- Tyler Young
Running the CustomTool on a model with just the one FactType: owned Dog(name) has Personality(type), generates no files that include the word "owned"
Though there may be, as yet not implemented, Prefix/Suffix hyphenation functionality that you mentioned, it looks more like the manor in which I entered the FactType, NORMA accepted "owned" as an out of place predicate phrase (as if it were a ternary FactType, with a missing first ObjectType). It doesn't raise an error, but doesn't effect the mapping of the model either. Other than the notation of the FactType in the model display and its verbalization, I can't see any other effect that it has.
I like the functionality you suggested, though. You should add that as a request item. BRN..
Hyphen binding currently affects verbalization only. The pattern is that both 'hyphen space' binds to the nears object name replacement to the right, and 'space hyphen' does the same thing in reverse so "final- Exam is taken by Student" gives a spanning uniqueness constraint of "It is possible that more than one final Exam is taken by the same Student and that the same final Exam is taken by more than one Student.", while "Exam that is -final is taken by Student" verbalizes the same sentence as "It is possible that more than one Exam that is final is taken by the same Student and that the same Exam that is final is taken by more than one Student."
At the moment we're grouping the bound text with the object name when it is quantified, but we're colorizing it as part of the normal predicate text. Terry had some objections to this and it is likely to be modified to better visually group the bound modifiers with the role player name.
We're also looking at better rules for generating default role names off of the reading text as part of enforcing that far role names are unique (we don't do this yet). When this is done you'll see more parts of the predicate text pieces appear in the generated code.
I actually looked the the prefix/suffix options after seeing the hyphenation mentioned in the pdf file included in the document package released last week - BTW, did you do the PPTs?
I tried to enter us the hyphen in the FactEditor, but it just treated as a litteral in the predicate. I looked through an old IM manual and saw the prefix/sufix reference; there it seemed to be only a reading aid.
When you said "...you'd put a subset constraint on..." did you mean that the tool would add that constraint, if the prefix/suffix functionality where in place; but I'd need to do this manually until then?
I'll try carring this through and see if the mapping is as you suggest. I can see how looking ahead to avoid the m:m tables is an advantage, as long as it doesn't distort the conceptual model: in your grandparent example, it seems to enhance it. BTW, the canine example was just the first thing that came to mind for a test FactType; doesn't mean my modeling ambitions are going to the dogs. BRN..