Kind

Kind

Overview

Provides Identity: Yes
Identity Principle: Single
Rigidity: Rigid
Dependency: Optional
Allowed Supertypes: «Category», «Mixin»
Allowed Subtypes: «Subkind», «Role», «Phase»
Forbidden Associations: «SubCollectionOf», «SubQuantityOf», «Derivation» and «Structuration»
**Abstract: Undefined (No by default)

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», «Quantity», «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):