Subkind

Subkind

Overview

Provides Identity: No
Identity Principle: Single
Rigidity: Rigid
Dependency: Optional
Allowed Supertypes: «Kind», «SubKind», «Quantity», «Collective», «Relator», «Quality», «Mode», «Category», «Mixin»
Allowed Subtypes: «SubKind», «Role», «Phase»
Forbidden Associations: «Structuration»
Abstract: No restriction (default: false)

Definition

A «Subkind» is a construct used to represent rigid specializations of identity providers («Kind», «Collective», «Quantity», «Relator», «Mode» and «Quantity»). By default, its usage do not require a relational dependency.

Let's see some examples:

Usage constraints

R1: A «Subkind» must always have exactly one identity provider («Kind», «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:

R2: 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:

R3: 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:

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

Usage Examples

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

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

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