On Terry's statement:
If two (or more) supertypes are mutually exclusive, then you will get a validation error if you make a single entity a direct or indirect subtype of both of the nodes. In this case, with the exclusion of the supertypes, any entity that is a subtype of both would be the empty set, which is indeed the intersection of the supertypes (which, being mutually exclusive, do not intersect). The notion of 'the union of disjoint subtypes' applies to the shared supertype, not the subtypes.
On the general modeling pattern:
In addition to the set information, subtypes also have an instance relationship which forms a one-to-one relationship between the subtype instance and supertype instance, with the subtype role mandatory. The readings on this relationship are 'is' in both directions. Considering the original assertion that 'Specimen is a subtype of Animal', you can see the three constraints if you expand the 'Fact Types/SpecimenIsASubtypeOfAnimal/Internal Constraints' node in the 'ORM Model Browser'. The three constraints verbalize as below (with comments added for your model):
-
Each Specimen is at most one Animal. (this is OK)
-
Each Animal is at most one Specimen. (suspect because you probably want to allow multiple specimens of the same type of animal, AnimalInstance 'Peter' is a specimen of Animal 'Human', AnimalInstance 'Matt' is a specimen of Animal 'Human')
-
Each Specimen is some Animal. (suspect because you also want to allow Vegetable and Mineral specimens)
So, of the three constraints on the subtype, two of them contradict what you want your model to represent. The distinction between the Animal type and AnimalInstance is also extremely important. A Specimen is an instance of an Animal type, it is not the animal itself. You want Specimen 'xInstance' is of type Animal 'x', not Specimen 'x' is Animal 'x'. The second 'is' reading is what you get with the subtype assertion, but I think the 'is of type' reading is what you actually want.
So, in your model, you want three FactTypes (Specimen is of type Animal, Specimen is of type Vegetable, Specimen is of type Mineral) with a uniqueness constraint on the Specimen side for all three FactTypes and an exclusive or constraint across the three Specimen roles. Alternately, you'll need a shared supertype for Animal/Vegetable/Mineral. However, even with the shared supertype, I do not think that making Specimen a subtype is the correct model because of the conceptual difference between 'is' and 'is of type'.
On the error hyperlink issue:
Many of the validation errors have actions associated with them to fix the error. For example, if a ValueType does not have a DataType specified then the action is to select the ValueType, activate the Properties Window, select the 'DataType' property, and open the dropdown. If an error has an action, then the action can be activated in several ways:
-
Double-click the error in the Error List (available on the View menu). This selects the element with the error and activates the action if one is available.
-
Select the error in the 'Validation Errors' submenu on the context menu for a selected shape
-
Double-click a shape with an error display. This activates the first error in the 'Validation Errors' list that has an associated action
-
Click the hyperlink on the error display in the Verbalization Browser. This has the same actions as 1, and can possible change your shape selection (if you have the element selected in the Model Browser, for example). However, an action is not always available for the error.
There is no automatic action to fix the error you're seeing, and you most likely already have a shape selected to see the verbalization, so it looks like it does nothing. You definitely bring up a good point, though, namely that we should provide information on how to fix an error if no default action is available, and integrated help system topics need to be provided across the NORMA plugin (we do install a help file, but there are no context-sensitive topics).
-Matt