Kind
- Category
RigidSortal
- Provides identity
- Identity principle
- Rigidity
- Dependency
optional
- Allowed supertypes
- Allowed subtypes
- Forbidden associations
- Abstract
undefined
Definition
A «Kind» is construct you are going to use in most of your models. It is used to represent rigid concepts that provide an identity principle for their instances and do not require a relational dependency. A «Kind» represent a Functional Complex, i.e., a whole that has parts contributing in different ways for its functionality (see the ComponentOf relation for more details about functional parts). Let’s see some examples:
Constraints
C1: A «Kind» cannot have an identity provider («Kind», «Collective», «Quality», «Relator», «Mode» and «Quantity») as its direct or indirect super-type.
C2: A «Kind» cannot have types that inherit identity («Subkind», «Role» and «Phase») as its direct or indirect super-type.
C3: A «Kind» cannot have types that aggregate individuals with different identity principles («Category», «RoleMixin» and «Mixin») as its direct or indirect subtypes.
C4: As a rigid type, a «Kind» cannot have any anti-rigid type («Role», «RoleMixin» and «Phase») as its direct or indirect super-type.
Common questions
Q1: If a «Kind» is relationally independent, does that mean we cannot define relations for theses types?
A1: No! When we say that a «Kind» is relationally independent, we mean that it does not necessarily require a relation to be defined, like a «Role» does. Here is an example in which a «Kind» has a dependency.
This example was extracted from the Software Requirements Reference Ontology (SRRO). Click here to take a look at it.
Examples
EX1: Fragment from the Configuration Management Task Ontology (see more):
EX2: Fragment from the OntoUML Org Ontology (O3) (see more):
