in

The ORM Foundation

Get the facts!

Why incompatible types at subset contraints?

Last post 05-29-2014 21:48 by jacobvos. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • 05-27-2014 7:42

    • jacobvos
    • Top 25 Contributor
      Male
    • Joined on 01-21-2013
    • The Netherlands
    • Posts 24

    Why incompatible types at subset contraints?

    See the scheme below. Why do I get "Model Error: Constraint 'SubsetConstraint1' in model 'ORMModel1' has role players with incompatible types." for the two subset constraints to the left and to the right?

    When setting the sampe population for e.g. 'Quality Test is planned to be performed on Date' and for 'Performed Quality Test has been promised', for both I can select the sample population defined at 'Quality Test'. (For the latter one 'inherited' via 'Quality Test has been performed'.)

    - Jacob


    Filed under:
  • 05-27-2014 14:53 In reply to

    Re: Why incompatible types at subset contraints?

    Hi Jacob,

    The issue here is that the objectification of 'QualityTest has been performed' and QualityTest itself are different object types, so they are not directly compatible. The general way to approach this is as I show in the attached diagram, which is to pulled out the required link fact type (select the objectified fact type in the model browser, expand to find the implied fact types, and drag onto the diagram). You can then set up a two column uniqueness that verbalizes as follows:

    If some QualityTest is involved in some PerformedQualityTest then that QualityTest is involved in that PerformedQualityTest that has been promised.

    Unfortunately, there are a couple of tooling issues with this. First, I'm not automatically finding the join path over the first role sequence. Second is that the validation is giving a bogus error regarding intersection with a mandatory constraint (the constraint validation engine hasn't caught up to the nuances of join paths).

    Having said that, as I'm looking at the model I'm not sure that this is best solved with some modeling adjustments. For example, are the observations and performance date really roles of the QualityTest (a type of test) or PerformedQualityTest (an execution of, or instance, of that test). If you move the QualityTest role players for the two binary fact types to the objectified unary then you'll be in business.

    I also question why PerformedQualityTest objectifies a unary. This is implying that only one performance of each test can exist in your data. So, either each test can be performed one time only, or you must toss all historical data when a new test is started. I seems like letting PerformedQualityTest (better named as QualityTestPerformance because the performance object exists before, during, and after the actual execution of the test, so the past tense in the name is misleading). I think the best approach here is to make this a standalone object type (many-to-one with QualityTest) and move all of your unary and binary fact types to the performance, not the test itself. You'll then find it much easier to constrain.

    -Matt

    PS This should create an automatic join path, I'll look to see what the issue is. 


  • 05-27-2014 21:11 In reply to

    • jacobvos
    • Top 25 Contributor
      Male
    • Joined on 01-21-2013
    • The Netherlands
    • Posts 24

    Re: Why incompatible types at subset contraints?

    Hi Matt,

    There are two aspects in your answer: 1) behaviour of NORMA; 2) how I did the conceptual modelling. About the latter: this is the most interesting part for me and I appreciate your comments, but let's try in those posts to focus on the first one. (For your interest: I try to model the objective world and the intersubjective world as they are understood in theory behind the DEMO methodology.)

    A question about 'different object types'. When setting the sample population in NORMA, I defined for Quality Test the instance 'QT-1'. I selected that one also for (among others):

    - 'Quality Test has been performed'

    - 'Performed Quality Test has been requested'

    So why, if the objectification of 'Quality Test has been performed' is different from 'Quality Test' (as you stated), can I use 'QT-1' for the first one (and subsequently for 'Performed Quality Test has been requested')?

    Note: when selecting for 'Performed Quality Test has been requested' an instance in the Sample Population Editor of NORMA, I can select from the sample population of the objectification 'Quality Test has been performed' or from the sample population of 'Quality Test' (by which an item that is not defined yet as sample instance of 'Quality Test has been performed' automatically will be added to that sample population.

    - Jacob

  • 05-27-2014 23:35 In reply to

    Re: Why incompatible types at subset contraints?

    Hi Jacob,

    The sample population editor is designed to allow you to add objects without leaving the fact types that use them. Basically, the in-cell expansion offered in the PerformedQualityTest has been promised sample population editor layout is equivalent to a row in the QualityTest has been performed editor layout. If you look at the header captions you'll see PerformedQualityTest(QualityTest(.Code)) in one and QualityTest(.Code) in the other. These are different types.

    I'm not in a position to comment on the DEMO methodology. However, the expansion you're seeing for the link fact type is exactly what is happening under the covers. Unlike objectified binaries and n-aries, we actually keep both the unary role and the link fact type for mapping purposes. There is an implied equality constraint between the two PerformedQualityTest roles. As with any other constraint on a unary role, this one applies only when the unary is true. This is true condition on the equality constraint is why we need to keep both the link fact type and the separate unary role for full fidelity in the mapping.

    I believe the DEMO expansion of the objectified unary is basically the same, even though the motivation for creating it is likely much different. ORM does not treat an object the same type as its preferred identifier (I am not my name). Also, ORM does not treat an objectifying object type the same as the fact type it objectifies. Both the types (fact type and object type) and instances (fact and object) in an objectification are in 1-1 correspondence with each other, but they are not the same. If this is what DEMO is telling you to do with an ORM model then we can likely conclude that some of the DEMO design process guidelines is not advisable for the ORM methodology. Knowing why this is the case would be an interesting discussion.

    Cheers, 

    -Matt 

  • 05-28-2014 1:18 In reply to

    • jacobvos
    • Top 25 Contributor
      Male
    • Joined on 01-21-2013
    • The Netherlands
    • Posts 24

    Re: Why incompatible types at subset contraints?

    Hi Matt,

    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.

    I understand what you wrote about different types and preferred identifier. An example: the entity type 'Person' with reference mode .Name, and a unary 'Person is employed', and that unary is objectified as 'Employee' with reference mode .Code. Sample population: 'Jacob Vos' is (the name) a Person who is employed and his Employee code is '840983'.

    '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.

    Do I understand this well?

    A little bit off-topic: You wrote: "Unlike objectified binaries (...)". I think this is also done for objectified binaries and n-aries. For example I defined 'Person is working for Company' and objectified this as 'Employment'. Now an implied fact type (the 'link fact type' as I understood it) is created between 'Person' and 'Employment'. So NORMA keeps both the binary fact type and the link fact type. Please let me know if I misunderstood something.

    - Jacob

  • 05-28-2014 9:34 In reply to

    Re: Why incompatible types at subset contraints?

    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:

     

    1. 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.
    2. 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 

  • 05-29-2014 21:48 In reply to

    • jacobvos
    • Top 25 Contributor
      Male
    • Joined on 01-21-2013
    • The Netherlands
    • Posts 24

    Re: Why incompatible types at subset contraints?

    Hi Matt,

    Thank you for your extensive answer! My initial question is answered.

    However I still don't fully understand why - in my initial example - at defining the sample population for 'Performed Quality Test has been promised' I can select Quality Test 'QT-1'. 'Performed Quality Test' is namely a different identity, as you explained. You wrote about this selection in your second post: "The sample population editor is designed to allow you to add objects without leaving the fact types that use them. (...)"

    If you can explain this with some more / other words, it would be nice.

    Further, I see I have to dive deeper into the difference between an objectified unary fact type and a subtype - in ORM, so not strictly related to NORMA.

    - Jacob

Page 1 of 1 (7 items)
© 2008-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service