in

The ORM Foundation

Get the facts!

Objectification in the latest NORMA update

Last post Sun, Apr 19 2015 2:00 by Matthew Curland. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • Sat, Mar 22 2014 15:09

    Objectification in the latest NORMA update

    Recently I updated to the latest version of NORMA. Soon after I noticed in my older models that NORMA signals error - with regard to objectifications - in places that for sure were error-free before the last update.

    To reproduce the error, I have created

    - one entity named Item, and 

    - one fact type: 'Item directly precedes Item', in such a way that:

    - For each Item, at most one Item directly precedes that Item.

    - This association with Item provides the preferred identification scheme for ItemDirectlyPrecedesItem.

    - It is possible that some Item directly precedes more than one Item.

    Everyting was fine till that moment. Next I've tried to objectify the above fact type and here is what I've got:

    Model Error: Model 'ORMModel1' contains multiple readings with an expanded reading signature of 'item is involved in item directly precedes item'. Each reading must be unique in the model.

    Model Error: Model 'ORMModel1' contains multiple readings with an expanded reading signature of 'item directly precedes item involves item'. Each reading must be unique in the model.

    Could you please explain the meaning of that error message? Is it a bug or incorrect modeling? If so, how to avoid it?

    Best regards,

    Piotr Pikielny

    Filed under:
  • Sat, Mar 22 2014 21:20 In reply to

    Re: Objectification in the latest NORMA update

    Hello Piotr,

    Starting with this release NORMA actually verifies that each expanded reading in your model correspond to exactly one fact type. By an expanded reading, I mean a reading with a normalized form (object type names are broken into pieces over camel casing, hyphens are removed, etc.). I called this expanded form a reading signature, and validate that it is unique in the model.

    So, how does this related to objectifications? When you explicitly objectify a fact type, NORMA automatically create a link fact types for each role in the objectified fact type. These link fact types establish the relationship between the objectifying entity type and each of the objectified role players, and are given default readings of <ObjectifyingEntityType> involves/is involved in <RolePlayer>. In the case where you objectify a ring fact type, you get multiple fact types with the same readings, which triggers this error.

    As with most errors, you can jump to the place to fix the error one of three ways (double-click the error in the Error List toolwindow, select the error in the Error Validation list of the highlighted object, or just double-click the shape the error is displayed on). In this case, error activation will select a role in the fact type and jump you to the Implied Fact Type Readings branch in the ORM Reading Editor tool window, which shows you the readings for the link fact type associated with the selected role. You can editor your link fact type readings here. Although the error will clear, I recommend selecting the other ring role as well and providing non-default readings. For example, in this case, you could change the readings for the first role to ItemDirectlyPrecedesItem involves preceding- Item and preceding- Item is involved in ItemDirectlyPrecedesItem and use 'following' instead of 'preceding' with the other role.

    I know this is a bit of a hassle now, but these objectified rings occur relatively rarely and do not take long to fix. The benefit of not having repeated readings in the model has long been considered an ORM metarule, but NORMA had never enforced it. The other nice benefit of this change is that you can get a shape for an existing fact type on a new diagram by typing a matching reading (with the role players, of course) into the fact editor. Previously, this created a duplicate fact type.

    -Matt 

    PS This is discussed in the first readme item (Duplicate Reading Signature Validation) for the December 2013 NORMA CTP. After installation, you can find the readme in the Documentation directory of your NORMA installation under C:\Program Files\ORM Solutions (use C:\Program Files(x86)\ORM Solutions for a 64-bit OS). I strongly advise a quick scan through the readme items when you upgrade NORMA. I've made some minor usability upgrades to this file by putting previous releases in collapsible blocks, so there is not as much noise at the top of the file.

    PPS NORMA actually does implied objectification for binary fact types with spanning uniqueness constraints and for all n-ary fact types. The structure is identical to explicit objectification, and you can see the implied fact types in the reading editor by selecting the individual roles. Although this error is actually tracked in this case, it is classified as hidden, so it does not display or serialize. It was just too invasive (and Terry complained loudly in the intermediate drop where it happened). 

  • Sun, Mar 23 2014 4:52 In reply to

    Re: Objectification in the latest NORMA update

     Matt,

    Thank you for fast response.

    I should have read the last update's documentation first before writing to you.

    Piotr 

     

  • Thu, Apr 24 2014 11:29 In reply to

    • Gordon Everest
    • Top 50 Contributor
      Male
    • Joined on Wed, Mar 26 2008
    • Minneapolis, Minnesota USA
    • Posts 9

    Re: Objectification in the latest NORMA update

    Matt,

      As you can see from the posts below (to my class forum) students are still having trouble with this problem and how to correct it.  Can you give a little more guidance?

    Postings on H6 Forum, Party Time!   2014s

    Objectified ternary error

    by Michael Schnaser - Wednesday, April 23, 2014, 9:42 PM 

    I think this is related to the quadranary question earlier. Basically, I wanted to objectify a ternary fact about a Guest introducing a Guest to another Guest and call it an Observation.. That is, there are three boxes in the fact type all leading to my Guest. When I do that, I get this error:

    Model 'ORMModel1' contains multiple readings with an expanded reading signature of 'guest is involved in guest introduces guest to guest'. Each reading must be unique in the model.

    I guess I could do it with a quadranary, but I'm curious as to what this means anyway.

    Re: Objectified ternary error

    by Guy Gaskin - Thursday, April 24, 2014, 1:34 AM 

    I saw this error message in office hours today also.

    I removed the strings specific to your model and searched on "Model contains multiple readings with an expanded reading signature of. Each reading must be unique in the model."  (pretty typical - how would search engines know about your solution-specific names after all?)  

    Found http://www.ormfoundation.org/forums/t/1129.aspx , which is pretty recent (see attached).  

    Haven't confirmed yet that this would resolve issues in HW6, but, it looks applicable.. 

    Re: Objectified ternary error

    by Michael Schnaser - Thursday, April 24, 2014, 11:52 AM

    I saw that post, but I don't know what to do with it. More specifically, here is an excerpt: 

    In this case, error activation will select a role in the fact type and jump you to the Implied Fact Type Readings branch in the ORM Reading Editor tool window, which shows you the readings for the link fact type associated with the selected role. You can editor your link fact type readings here. ......

    I don't know what to change to make the error go away - this person just says "Edit it". 

     

  • Thu, Apr 24 2014 14:26 In reply to

    Re: Objectification in the latest NORMA update

    Hi Gordon,

    I'll try a further explanation, both on the background and the implementation.

    When a fact type is objectified in ORM an implicit relationship is created for that objectification between each of the role players of the objectified fact type and the objectifying entity type. NORMA automatically creates these fact types (known as link fact types) behind the scenes when you objectify a fact type, and assigns default readings to the each of the fact types following the pattern ObjectifyingEntityType involves/is involved in RolePlayerOfObjectifiedFactType. For the ternary fact type Guest introduced Guest to Guest, this produces three link fact types, one for each role, using the default generated object type for the objectifying entity type. Each of the three link fact types has the default readings (forward and reverse) GuestIntroducedGuestToGuest involves/is involved in Guest. The result is 3 new fact types with 2 readings each where each of the readings look the same.

    Jumping to a different aspect of ORM theory, it is a requirement that each typed reading be unique, where a  typed reading means the reading text with the role player names inserted for the player holds. So, if Person has PersonName and Book has Title are both in the same model, the reading text ('has') is shared, but the typed reading text is unique. The reasons for this are farely obvious: it makes it extremely difficult to navigate a model when two fact types appear to be the same but are not.

    NORMA takes the reading requirements one step further and normalizes the reading text to get a reading signature (a NORMA term, not an ORM term). This is done by stripping hyphen binding, expanding camelCased and PascalCased combined names, and standardizing casing where possible. This is done because different generation targets use different forms of these names, and we want the generated systems to be robust. Therefore, we want object type names of 'PersonName', 'person name', and 'Person name' to all be treated as different similarly when we verify the reading signatures. Therefore, NORMA normalizes GuestIntroducedGuestToGuest involves Guest to get a signature of guest introduced guest to guest involves guest, which is the text you'll see in the error message for overlapping names.

    For objectifications you'll see this error only when the same role player is used more than one role in the objectified fact type. These readings can be edited using the reading editor window by selecting a role in the objectified fact type and opening the Implied Fact Type Readings branch, where you'll see the is involved in and involves link fact types. To edit one of these readings just click the reading, wait for the editor to activate, then change the reading text (the role players are locked in this editor). If you see this error, you can navigate to the correct point in the reading editor by activating the error, which is done using any of four different gestures in the tool (double-click the shape with the error display, right click the shape and select the error in the Validation Errors submenu, click the error text in the ORM Verbalization Browser, or double-click the error in the Error List tool window).

    To fix this error, I recommend changing the reading text for each reading (forward and reverse on each role). For example, with the triple-Guest fact type, you can change the readings by putting in hyphen bound names. If we rename the objectified form of the fact type to Introduction, you can change the readings to (do the first two by selecting the first role, then the next two on the second role, then clean up the third role as well).

    introducing- Guest is involved in Introduction, Introduction involves introducing- Guest

    introduced- Guest is involved in Introduction, Introduction involves introduced- Guest

    introduced- to Guest is involved in Introduction, Introduction involves introduced- to Guest

    This will both clear up this error and give you a much better default name in the relational mapping. Prior to this edit, the Introduction table would get columns guest1, guest2, guest3. With this in place, you'll get introducingGuest, introducedGuest, introducedToGuest, which is much more readable. Note that the link fact types exist for all n-ary fact types and binary fact types with spanning uniqueness constraint even if they are not objectified, and you can clean up your column names using this technique instead of throwing role names all over the diagram. The only difference with these implicit objectifications is that you won't see the error, as you do when you explicitly objectify the fact type.

    Note that you can also individually select the link fact types in the model browser (right click the fact type, choose Select in Model Browser, expand the fact type node, then expand the Implied Fact Types node to see each one). From here you can even drag them onto your diagram and see what they look like. [Warning: there is a bug in the December 2013 release preventing the link fact type for a role with a single-column uniqueness constrant from drawing without asserting. This will be fixed in the next public drop, or pull the latest intermediate release from http://ORMSolutions.com/NORMAPreview.]

    Gordon, let me know if you have other questions. I knew there would be some pain on this fairly recent change, but I think it is much better than allowing duplicate fact type readings, which was easily done before and could cause a lot of confusion. I also improved other things related to this (reentering an existing fact type in the fact editor adds a shape for the existing fact type, and activation of link fact types selects the role and reading editor instead of the link fact type in the model browser and the fact editor). I'm hoping once modelers are used to this that it will become a normal part of the process. If there are too many students asking about it, maybe you can take a couple of minutes to demonstrate how to handle it during class?

    -Matt

  • Sun, Apr 19 2015 0:35 In reply to

    • Gordon Everest
    • Top 50 Contributor
      Male
    • Joined on Wed, Mar 26 2008
    • Minneapolis, Minnesota USA
    • Posts 9

    Re: Objectification in the latest NORMA update

    I think I finally understand the problem and why this solution is necessary.

    The basic idea is that with an objectified predicate you now have two objects, hence there is an implied fact sentence between them.  However, for the objectified predicate there is an (implied) fact type, actually a separate one for each role in the predicate as it is involved with the other object.

     Here is how I have rewritten about this for my NORMA Usage Notes:

    Objectified predicate:  Right click existing predicate > 'Objectify Fact Type.' If new, select from Toolbox.

    You probably will want to change the default objectified object name.  => Properties > name.

    If any two roles are on the same object, that generates an error: "contains multiple (same) readings…"

    Now there are two objects involved, but for the objectified predicate, it is the roles which are involved.

    Hence, the system generates implied fact types between the common object and each of the roles in the objectified predicate.

    Select a role in the predicate and the system displays the implied fact types in the readings editor.

    Resolve the error by changing the common object names in the implied fact type(s) to reflect the role.

    For example, if the objectified fact type is 'Person loves Person' and the object name is changed to "Love," the role of the first person could be 'Lover' and the second would be 'loved one' or simply 'lovee.'  To correct the error, change the implied fact type for the first role to: "LoverPerson is involved in Love" and change the inverse reading correspondingly.  Since the two readings are now different, changing the second role of 'Lovee' is optional, but recommended for clarity. 

    Have I got it?  Does that make it clear and succinct?  

  • Sun, Apr 19 2015 2:00 In reply to

    Re: Objectification in the latest NORMA update

    Hi Gordon,

    Good to hear from you. 

    A couple of comments:

    1. (minor) You can change the name of the objectifying entity type on the shape as well. Just click the name shape above the fact type. There are other uses for this shape as well. For example, if you want to use the fact editor to create a fact type with the objectifying entity type as a role player then you would select the name shape, not the fact type.
    2. If you want to restore the default name--which automatically tracks the highest priority reading on the fact type--then delete the name in the Properties Window or inline editor. Simply modifying the text will not turn tracking back on.
    3. Double-clicking a fact type with this error will take you to the correct position in the reading editor to fix the problem. The error will go away after you modify the forward and reverse readings for the first role, but you should make a corresponding edit on the second.
    4. When you're constructing your readings I would recommend using the hyphen binding syntax instead of attaching text directly beside the object type name. So, you want 'lover- Person is involved in Love' and 'lovee- Person is involved in Love' instead of LoverPerson and LoveePerson.
    5. Note that all binaries with a spanning uniqueness and all n-ary fact types are implicitly objectified and also have link fact types. However, it was too confusing to display the error in these cases. The naming error for implicit objectification of ring fact types is ignored. Nevertheless, for optimal relational generation I recommend doing the same process on these fact types. The readings are in the same place, namely in the reading editor branch for implied fact type readings available when a role is selected.
    -Matt

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