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