A «Subkind» is a construct used to represent rigid specializations of identity providersKind», «Collective», «Quantity», «Relator», «Mode» and «Quantity»). By default, its usage do not require a relational dependency. Let’s see some examples:



C1: A «Subkind» must always have exactly one identity providerKind», «Collective», «Quantity», «Relator», «Mode», «Quantity») as an ancestor (a direct or indirect super-type). Therefore, our examples in the first figure should be modelled as:

Subkind application 1

C2: Because it is a rigid type, a «Subkind» cannot have an anti-rigid type («Role», «Phase», «RoleMixin») as an ancestor. Therefore, the following fragments would not be allowed:

Subkind forbidden 1

C3: Since every instance of a «Subkind» follows the same identity principle, a «Subkind» cannot have an mixin type («Category», «Mixin», «RoleMixin») as a descendant, i.e., a direct or indirect subtype. Fragments like the ones below are not allowed:

Subkind forbidden 2

Common questions

Q1: Are subkinds only used to specialize kinds?

A1: No! Even though the name might be a little misleading, a «Subkind» may be used to specialize any identity provider, which includes «Collective», «Quantity» and «Relator».


EX1: Usually, subkinds come in groups, like in the examples below:

Subkind application 2

EX2: Fragment from the Normative Acts Ontology (see more):

Example NAO

EX3: Fragment of a conceptual model about Brazilian Universities (see more):

Example University