Hi Jacob,
Good discussion.
jacobvos:First of all: Don't learn from my posts that DEMO tells what to do with an ORM model. I try to capture my interpretation of DEMO in an ORM model. That might be wrong.
Please note that I put a big If at the beginning of my sentence regarding application of the DEMO process to an ORM model. Although I've seen it demonstrated, I'm not intimately familiar with nuances of the process, so I can't tell if you've interpreted it correctly or not. I just thought it was a question that needed to be asked.
jacobvos: Sample population: 'Jacob Vos' is (the name) a Person who is employed and his Employee code is '840983'
This actually reveals quite a bit, especially regarding your treatment of identification. There are two issues here:
- The use of is in 'Jacob Vos' is a Person. The parenthetical (the name) indicates what should be obvious, namely that a name and a person are not the same thing. ORM would say the Person identified by the name 'Jacob Vos' or the Person with name 'Jacob Vos'. The difference may be subtle, but the first phrase is claiming that a name is a person, whereas the other is not claiming this at all. You are not your name.
- An objectification of Person is employed would generally be called Employment instead of Employee. If you want an Employee to be a Person then use a subtype relationship to indicate a shared identity. With a subtype you can correctly use is to indicate a shared instance (that person is an employee, that employee is a person with name1). The choice between a subtype and unary fact type depends on what else you need to say. If the subtype plays no additional roles in the model, then a unary fact type is sufficient. However, if you need additional data that applies only to the subtype--such as a context-dependent reference scheme like an Employee code--then the subtype lets you do it naturally.
You can see more of these structural issues in the verbalization of your sample population. For example, you say Person who is employed, but you do not directly refer back to that employment. Instead, his refers back to Person, completely skipping the employment. You haven't actually related the objectification of Person is employed and Employee has EmployeeCode at all in your sentence, although I believe you meant to imply it. Why is the sentence structure not on par with the intent? Because the instance that objectifies a unary fact is not an instance of the objectified role player in normal communication patterns. This relationship between the objectifying object and a played role is represented in ORM by the link fact type. So, if you use the natural name for the objectification (Employment, not Employee), then you can same The Person with name 'Jacob Vos' is involved in the Employment with code '840983'. You can see how saying Person is involved in Employee would be odd--a Person is an Employee, indicating a much stronger (identity) relationship than is involved in.
If you use subtyping for Employee instead of the objectified unary then your sentence uses is one time to indicate identity over the subtyping, resulting in The Person with name 'Jacob Vos' is the Employee with code '840983'. I find this a much more natural communication act than your original sentence.
jacobvos: 'Person' and 'Employee' are different types. But they can have the same reference scheme (not in my example). If they have the same reference schem it might seem that an instance of a 'Person' and an instance of 'Employee' are the same. However that isn't correct.
Just because the reference schemes can be reduce to the same value doesn't mean that the reference schemes are the same. The objectified unary is identified by the entity that plays the unary role (Person in this suggested model, QualityTest in the early model). The entity (Person, QualityTest) is then identified by a value (name, code). ORM does not treat identification the same as identity, so an entity is not its identifying value any more than an objectifying object of a unary fact is its objectified role player.
I acknowledge that you can name objects to imply some sort of relationship here, but any formal interpretation of a model must rely on the structure presented. The names give meaning to the modeler, not the tool. Structurally, what you're doing with Person is employeed objectified as Employee is equivalent to Person is dead objectified as Death. Clearly, I can't say that the death of a person is that person. Contrast this to a subtyping relationship, where I can always say that an instance of a subtype is an instance of the supertype, regardless of the names you plug in for the subtype and supertype.
jacobvos: So NORMA keeps both the binary fact type and the link fact type
Yes, NORMA always defines the link fact types. The difference between unary and binary/n-ary is very subtle. An objectification always implies an equality constraint implied between the mirror roles in the link fact type(s) (meaning the link fact type roles attached to the role players of the objectified fact type) and the mirrored roles in the objectified fact type. For a unary fact type, this equality constraint is conditional on the unary actually being true (instead of false or null). For a binary or n-ary fact type the implied equality constraint is not conditioned in any way.
What this means for a logical or physical mapping of the system is that the objectified fact type can be completely eliminated from the system and represented with fully fidelity by its link fact types. This isn't true with the unary case because of the conditional nature of the equality constraint. Note that NORMA currently maps all unaries as open world with negation because the RMAP doesn't handle conditional cases at all, so this distinction would be more visible with a full RMAP. Technically, an open world interpretation of the unary (True or null) would have an unconditional equality constraint.
I did not mean to imply that the link fact types are created for unary cases only, just that the mapping is slightly different. The in-memory models as also slightly different (the mirror role for the binary/n-ary case is called a RoleProxy, which references a Role but is not a full Role (you can attach readings to it, but not a role player, role name, constraint, etc.). The mirror role in an objectified unary is occupied by an ObjectifiedUnaryRole, which both references the mirrored Role and is a Role unto itself.) Again, these distinctions are very subtle will be completely invisible if you're just using the tool. U apologize if this muddied the waters of the main conversation.
Cheers,
-Matt