The ORM Foundation

Models get hard to read if you use subset constraints and equality constraints between roles. Sure there are good reasons to use them, but I found that you do not need special symbols and line styles to depict them. Suptyping and subset constraints are the same concept - one for object types, the other for (combinations of) roles. So why not just mark the subset and equality symbols as deprecated and use one visual method instead of using two distinct diagram notations for nearly the same?

In addition we get another way to depict duplicated object types in a model (the both-sided arrow is implied if you use the same name for two object types).

P.S: I added the third row with splitted arrows later.

Hi Jakob,

It is an interesting thought and there are certainly parallels between the notions of subtype and subset. However, there are some problems with this suggestion.

1. Subset and subtype are not the same conceptual notion. Subtype is primarily a meta- relationship that describes a relationship between types (A is a subtype of B). There is also an instance relationship implied by subtyping that is especially useful if the subtype has an alternate identification scheme. The instance reading is always of the form 'a1 is/is b1', with no mention of subtyping.
2. Putting a shape in the middle of the constraint connections allows the lines to bend. You would lose this with a subtype line.
3. There is additional information displayed with the constraint. Right now, you just get the deontic 'o' and color change. We may be adding more information in the future. For example, we're considering a check mark to indicate that there is a custom condition on the constraint that restricts when it applies.
4. The solid line of a subtype is much more invasive than the light dotted constraint connector. You can generally read through the constraint connector unless the placement is really bad. I don't think you can say the same for a subtype connector.
5. The bulk of the subtype connector drawing is on the ends. This is not a major issue for object type connections where there is a lot of edge real estate, but there is much less real estate availble around a role. If you put two of three of these on one or two roles, it would soon be indistinguishable as to which lines goes where, whether you're attached to a single role or many, etc. Also, mixing the bulky arrows in with the noise already around a fact type (readings, internal uniqueness constraints, simple mandatory dots, objectification border and object type names, role value constraints) would complete obscur many of the features.
6. Equality and subset are set comparators and need to look the same as Exclusion. There are other set comparators that are not in the main notation set (proper subset, overlap, proper overlap). The main reason these are not in (I had to ask Terry on this one) is that all ORM constraints are designed to be trivially satisfied in an empty model, and these cannot be. However, we're also considering graphical notations for derivation paths and other query conditions applied to an ORM model where this type of constraint is appropriate, and we would like to use the same notation.
7. Subtype lines don't split well to handle multiple targets.

So, basically, while there are certainly similarities between subset/equality and supertype, they are not conceptually equivalent, and subset/equality have signficantly more similarities with other constraint representations than with subtyping.

Having said all of that, some tool options to do things like hide constraints, z-order the lines better (behind readings, for example), and possibly adjust the shape size (I think the rings are two big, for example) could be considered to improve the user experience.

The double arrow notation for duplicated object types is an idea I think we should consider more, although I'd need to know more about the scenario(s) where you use this. Having additional tool options to collapse and expand object types and broader use of aliasing would also help this situation. However, federation scenarios frequently require that you keep the separate ObjectTypes. My gut feeling is that you would need the additional information provided in a 1-1 fact type for a clean mapping of the federation scenario.

-Matt

 In addition to Matt's comments, a single equality constraint may apply between many roles (n >= 2), and your suggested double-arrow notation for that would be more intrusive.

  Also set-comparison constraints may apply between role sequences, including ones projected from join paths, and the current notation seems betetr for that.

Cheers

Terry

Refering to Matt's points:

1. Sure subtyping and subset/equality constraint are not the same, but if you objectify two connected predicates, you get subtypes.
2. To connect more then two predicates, the arrows would need to split - I already do this for subtyping to avoid parallel lines (first model in the third row).
3. I am not sure about deontic constraints - how do you express deontic subtypes in the current ORM2 syntax?
4. This depends on the model. I feel that the subset/equality constraint symbol are two heavy in some places.
5. see 4
6. Interesting to hear about other constraints. Are there symbols for them?
7. see 2

I think it is a matter of taste but you are right that my suggestion is not always an improvement. z-ordering lines is a good idea I have not tried yet. So while I think that my suggestion could at most provide an alternative syntax for simple cases, what do you think of splitting arrows for normal subtyping and putting the subtype constraint symbol (if any) on top of the subtyping line?

jakob.voss:

Sure subtyping and subset/equality constraint are not the same, but if you objectify two connected predicates, you get subtypes.

Well, you get two entities that could potentially be subtypes, but that doesn't mean that the objectifying entity types of any two entities with compatible role players should be subtypes. You're also assuming that all roles in the fact type participate in the equality or subset constraint. I think you're taking this too far.

jakob.voss:

To connect more then two predicates, the arrows would need to split - I already do this for subtyping to avoid parallel lines (first model in the third row).

The central equality or subset constraint symbol tell you what the lines are about. The emphasis is on the 'constraint' nature, and singling out two constraints and using an alternate syntax is frankly forcing an issue into a syntax that doesn't have a problem.

jakob.voss:

I am not sure about deontic constraints - how do you express deontic subtypes in the current ORM2 syntax?

Select a constraint in NORMA and change the modality to deontic. You get a color change on the constraint, and a little 'o' inserted in the outline.

jakob.voss:

This depends on the model. I feel that the subset/equality constraint symbol are two heavy in some places.

But the places where they are heavy can be placed so as not to interfere, which is much harder to do with the heavier subtyping lines. And, again, you are only addressing the issue for a fraction of the possible constraints.

jakob.voss:

Interesting to hear about other constraints. Are there symbols for them?

Not yet, but the proper subset is obvious (lose the line under the sideways U). Haven't thought on overlap. Again, these would only be used for graphic query representations.

jakob.voss:

what do you think of splitting arrows for normal subtyping and putting the subtype constraint symbol (if any) on top of the subtyping line?

I believe joining the lines prior to their entry into the supertype has been done in other tools (I'm pretty sure it can be done in VisioModeler). Putting the constraint on the intersection could only be used in restricted cases because it will not always be the case that the complete set of supertypes falls under the main constraint, and constraints can apply to one or more direct subtypes combined with one or more indirect subtypes. You would not be able to represent these other constraint patterns using this UI paradigm.

Jakob, I appreciate what you're trying to accomplish here, but the current constraint syntax has been set up over many years to be flexible and consistent across multiple constraint types and constraint attach points (subtypes and roles). You have offered some suggestions that may work on basic scenarios, but I do not believe they significantly reduce overall clutter (given the heavier subtype lines and arrows, I think you'll actually use more ink with your suggestions than using the central constraint shapes), and mix too many metaphors (subtyping and subset/equality relationships are very close in some implementation mappings, but conceptually they are very different). ORM diagrams say a lot of very detailed things with a small number of pictures, and there will be some clutter. If there is too much clutter for you, create separate shapes for the same instances (two shapes with the same name always represent the same instance without any connecting lines) and apply the constraints in a cleaner space for clarity.

-Matt