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