Am I wrong or is there some ambiguity concerning the term "Fact Type" in the documentation and implementation of NORMA? From my old InfoModeler Guide to FORML, I take it that a Fact Type is a complete fact - Object, predicate, Object (for a binary fact). The NORMA documentation often seems to indicate only the predicate portion when talking about Fact Types. Also, there's no way to select a (complete), Fact Type in the model, other than CNTRL selecting all the component parts (while you can select the predicate as a unit). One of the strengths of ORM is as a method of reducing ambiguity. I think it's best to be clear about what is a Fact Type, a Fact instance, A role, a predicate, etc.... BRN..
There could be some ambiguity. When I was writing the walk-through ("documentation"), I'd used Fact Type in some places and Fact in others. The understanding I came to in my discussions with Terry is that the Fact Type is the collection of objects linked by the predicate. "[Person] drives [Car]" would be an example of Fact Type. It becomes a Fact when the Fact Type is populated with instances of the Object Types. "[Tyler] drives [Jeep]" would a Fact in this example.
Having said all that, keep in mind that this was simply my understanding and should not be taken as gospel truth. I may have understood incorrectly.
Next, the walk-through's ambiguity.... In NORMA's code, the object model has a FactType class, which has predicate readings for a given sequence of roles, and so forth. The representation of a FactType object on the screen is the sequence of role boxes with the predicate text shown below. So I guess the confusion comes from "Fact Type" being the conceptual union of some Object Types with a predicate, and a C# "FactType" (no space) containing everything in a Fact Type, but having a single representation on the screen. I think in the documentation I kept referring to the FactType object's representation rather than a conceptual Fact Type.
After all that, the question is: What should the FactType object's representation be called? I can see where a complete Fact Type must have all the Object Types linked. On the other hand, I don't think we can just call it a "Predicate" because the predicate is just text without any role boxes. If anybody has a suggestion of what to call it, I'll be happy to go make a revision to the walk-through. Assuming I can ever get Acrobat running on my machine again. Ever since I graduated and my laptop got re-imaged things just haven't worked the same. But that's a separate thread. :-)
Brian, thanks for your useful feedback. I asked Tyler to quickly get some documentation up before he graduated, and in the time available I think he did a good job, even if some of the wording could have been more precise.
The documentation provided at this stage is not official, and is intended simply as a help to get you started. When we come up for air, we hope to provide extensive documentation that has been carefully worded to avoid confusion. In the meantime, here is a quick explanation.
In ORM 2, the term "fact type" has essentially the same meaning as in ORM 1, but we have extended the number of fact type readings that may be used. Each fact type may be referenced by one or more typed predicates (i.e. the combination of a predicate reading with the names of the object types listed in the order in which the roles are intended to be traversed).
ORM 2 allows multiple predicate readings to be declared for any given ordering of the roles in the predicate. For example, in ORM 1 the same fact type might be referenced by
(a) "Employee works for Department" or
(b) "Department includes Employee".
ORM 2 allows these readings, as well as any number of alias readings. For example, you may provide additional readings such as
(a') "Employee is employed by Department"
(b') "Departments employs Employee".
Thanks for the responses.
It helps to understand the environment within which the project is taking shape. This is, after all, a development process; so we all (I hope), understand, that the wrinkles will get ironed in time.
Thanks Tyler, also for pointing out that 'FactType' and 'Fact Type' are being used internally (in the project), to refer to seperate conceptual entities. For another name for the C# FactType, the important thing is that it be unambigous to you (as it will be hidden from the end user).
Terry, thanks for the insights into ORM 2 enhancements. What's the motivation for the multiple readings, XML schema definitions?
Tyler, I've been spending most of a week on IT stuff with my own system. I hate playing admin, as it keeps my mind from better things. Good luck sorting out your notebook. One suggestion, look into some form of virtualization, like VM-Ware, Virtual PC or Server, etc.... Looks like the best way to keep things seperate on a computer you use for more than one purpose. Very useful for development testbeds too.
Good luck. BRN..