Fixing and improving crossrefs

classes/aspects/mode/constraints.rst

@@ -1,31 +1,27 @@
 Constraints
 -----------
 
-**C1:** Every «Mode» must be (directly or indirectly) connected to an
-association end of at least one «characterization» relation.
+**C1:** Every «:ref:`mode`» must be (directly or indirectly) connected to an
+association end of at least one «:ref:`characterization`» relation.
 
 .. container:: figure
 
    |Mode application 1|
 
-**C2:** The multiplicity of the characterized end (opposite to the Mode)
+**C2:** The multiplicity of the characterized end (opposite to the «:ref:`mode`»)
 must be exactly one. Therefore, the following examples are forbidden.
 
 .. container:: figure
 
    |Mode forbidden 3|
 
-**C3:** Modes cannot have as ancestors the following types: «Kind»,
-«Quantiy», «Collective», «Subkind», «Role», «RoleMixin», «Phase»,
-«Relator», «Quality».
+**C3:** Modes cannot have as ancestors the following types: «:ref:`kind`», «:ref:`quantity`», «:ref:`collective`», «:ref:`subkind`», «:ref:`role`», «:ref:`rolemixin`», «:ref:`phase`», «:ref:`relator`», «:ref:`quality`».
 
 .. container:: figure
 
    |Mode forbidden 2|
 
-**C4:** Modes cannot have as descendants the following types: «Kind»,
-«Quantity», «Collective», «RoleMixin», «Category», «Mixin», «Relator»,
-«Quality».
+**C4:** Modes cannot have as descendants the following types: «:ref:`kind`», «:ref:`quantity`», «:ref:`collective`», «:ref:`rolemixin`», «:ref:`category`», «:ref:`mixin`», «:ref:`relator`», «:ref:`quality`».
 
 .. container:: figure
 

classes/aspects/mode/definition.rst

@@ -1,10 +1,10 @@
 Definition
 ----------
 
-A **«Mode»** is a particular type of intrinsic property that has no
-structured value. Like qualities, modes are also individuals that
-existentially depend on their bearers. Types stereotyped as «Mode» are
-also **rigid**. You can find some examples of modes below:
+A «:ref:`mode`» is a particular type of intrinsic property that has no
+structured value. Like :ref:`qualities <quality>`, modes are also individuals that
+:ref:`existentially depend <dependency>` on their **bearers**. Types stereotyped as «:ref:`mode`» are
+also :ref:`rigid <rigidity>`. You can find some examples of modes below:
 
 .. container:: figure
 

classes/aspects/quality/constraints.rst

@@ -1,7 +1,7 @@
 Constraints
 -----------
 
-**C1:** A Quality must always be connected, through a characterization
+**C1:** A «:ref:`quality`» must always be connected, through a «:ref:`characterization`»
 to another type.
 
 .. container:: figure
@@ -16,17 +16,13 @@ forbidden.
 
    |Quality forbidden 1|
 
-**C3:** Qualtities cannot have as ancestors the following types: «Kind»,
-«Quantiy», «Collective», «Subkind», «Role», «RoleMixin», «Phase»,
-«Relator», «Mode».
+**C3:** Qualtities cannot have as ancestors the following types: «:ref:`kind`», «:ref:`quantity`», «:ref:`collective`», «:ref:`subkind`», «:ref:`role`», «:ref:`rolemixin`», «:ref:`phase`», «:ref:`relator`», «:ref:`mode`».
 
 .. container:: figure
 
    |Quality forbidden 2|
 
-**C4:** Qualtities cannot have as descendants the following types:
-«Kind», «Quantiy», «Collective», «RoleMixin», «Category», «Mixin»,
-«Relator», «Mode».
+**C4:** Qualtities cannot have as descendants the following types: «:ref:`kind`», «:ref:`quantiy`», «:ref:`collective`», «:ref:`rolemixin`», «:ref:`category`», «:ref:`mixin`», «:ref:`relator`», «:ref:`mode`».
 
 .. container:: figure
 

classes/aspects/quality/definition.rst

@@ -1,11 +1,11 @@
 Definition
 ----------
 
-A **«Quality»** is a particular type of intrinsic property which has a
-structured value. Qualities are things that are existentially dependent
-on the things they characterize, called their bearers. Types stereotyped
-as «Quality» are also **rigid**. OntoUML differentiates between three
-types of qualities:
+A «:ref:`quality`» is a particular type of intrinsic property which has a
+structured value. Qualities are things that are :ref:`existentially dependent <dependency>`
+on the things they characterize, called their **bearers**. Types stereotyped
+as «:ref:`quality`» are also :ref:`rigid <rigidity>`. OntoUML differentiates
+between three types of qualities:
 
 -  **Perceivable**, which capture qualities that could be measured by an
    agent with the appropriate instrument, like weight, height, color and

classes/nonsortals/category/constraints.rst

@@ -1,31 +1,31 @@
 Constraints
 -----------
 
-**C1:** A «Category» is always abstract. Notice that abstract classes
+**C1:** A «:ref:`category`» is always abstract. Notice that abstract classes
 are represented with an *italic* label.
 
 .. container:: figure
 
    |Category application 1|
 
-**C2:** A «Category» aggregate individuals that follow different
-identity principles, therefore it may not have as ancestor the following
-constructs: «Kind», «Quantity», «Collective», «Subkind», «Role»,
-«Phase», «Relator», «Mode», «Quality».
+**C2:** A «:ref:`category`» aggregate individuals that follow :ref:`different
+identity principles <identity>`, therefore it may not have as ancestor the following
+constructs: «:ref:`kind`», «:ref:`quantity`», «:ref:`collective`», «:ref:`subkind`», «:ref:`role`»,
+«:ref:`phase`», «:ref:`relator`», «:ref:`mode`», «:ref:`quality`».
 
 .. container:: figure
 
    |Category forbidden 1|
 
-**C3:** A «Category» is a rigid construct, therefore it cannot have as
-ancestor an anti-rigid type, as: «Role», «RoleMixin», «Phase».
+**C3:** A «:ref:`category`» is a :ref:`rigid <rigidity>` construct, therefore it cannot have as
+ancestor an :ref:`anti-rigid <rigidity>` type, as: «:ref:`role`», «:ref:`rolemixin`», «:ref:`phase`».
 
 .. container:: figure
 
    |Category forbidden 2|
 
 **C4:** Categories cannot have as descendants the following types:
-«Mixin», «Role», «Phase».
+«:ref:`mixin`», «:ref:`role`», «:ref:`phase`».
 
 .. container:: figure
 

classes/nonsortals/category/definition.rst

@@ -1,9 +1,9 @@
 Definition
 ----------
 
-A **«Category»** is a **rigid** mixin that does not require a dependency
+A «:ref:`category`» is a :ref:`rigid <rigidity>` mixin that does not require a dependency
 to be specified. It is used to aggregate essential properties to
-individuals which following **different identity principles**. Let's see
+individuals which following :ref:`different identity principles <identity>`. Let's see
 some examples:
 
 .. container:: figure
@@ -13,7 +13,7 @@ some examples:
 Categories are usually used in a refactoring process. For example, let's
 suppose that you defined two classes in your model, Person and Animal.
 Now you want to state that either people and animals have a weight. You
-than create a «Category», which has weight, and generalize the existing
+than create a «:ref:`category`», which has weight, and generalize the existing
 classes into it.
 
 .. |Category examples| image:: _images/ontouml_category-examples.png

classes/nonsortals/mixin/constraints.rst

@@ -1,16 +1,15 @@
 Constraints
 -----------
 
-**C1:** A «Mixin» is always abstract. Note that abstract classes are
+**C1:** A «:ref:`mixin`» is always abstract. Note that abstract classes are
 represented with *italic* labels.
 
 .. container:: figure
 
    |Mixin application 2|
 
-**C2:** A «Mixin» is a semi-rigid construct and because of that, it
-cannot have as ancestor either a rigid or an anti-rigid type. Therefore,
-only mixins can be ancestor of other mixins.
+**C2:** A «:ref:`mixin`» is a :ref:`semi-rigid <rigidity>` construct and because of that, it
+cannot have as ancestor either a :ref:`rigid <rigidity>` or an :ref:`anti-rigid <rigidity>` type. Therefore, only mixins can be ancestor of other mixins.
 
 .. container:: figure
 

classes/nonsortals/mixin/definition.rst

@@ -1,27 +1,26 @@
 Definition
 ----------
 
-A **«Mixin»** is a semi-rigid type, i.e., it "behaves" as a rigid type
-for some individuals and as an anti-rigid one for others (it's the only
-stereotype with such feature in OntoUML). As the Category and the
-RoleMixin, the Mixin meta-class characterizes individuals that follow
-different identity principles. Here are some examples of types that
-could be classified as Mixin:
+A «:ref:`mixin`» is a semi-rigid type, i.e., it "behaves" as a :ref:`rigid <rigidity>` type
+for some individuals and as an :ref:`anti-rigid <rigidity>` one for others (it's the only
+stereotype with such feature in OntoUML). As the «:ref:`category`» and the
+«:ref:`rolemixin`», the «:ref:`mixin`» meta-class characterizes individuals that follow
+:ref:`different identity principles <identity>`. Here are some examples of types that
+could be classified as «:ref:`mixin`»:
 
 .. container:: figure
 
    |Mixin examples|
 
-As categories, mixins are commonly applied during a refactoring process,
+As :ref:`categories <category>`, mixins are commonly applied during a refactoring process,
 in particular when we want to state that some properties are applied to
-both rigid and anti-rigid types. For instance, let's consider that we
-defined the following types in our model, Car and Jewellery, a general
+both :ref:`rigid <rigidity>` and :ref:`anti-rigid <rigidity>` types. For instance, let's consider that we defined the following types in our model, Car and Jewellery, a general
 concept for Ring, Necklace, etc. Now we want to define the type Luxury
 Good. In our worldview, every jewellery is luxurious, but only cars that
 are worth more than 30k dollars are. Since the value of a car changes
 through the years, being a luxurious car is a temporary classification,
 whilst being a jewellery is a permanent one. The type Luxury Good,
-therefore, is semi-rigid or a Mixin.
+therefore, is :ref:`semi-rigid <rigidity>` or a «:ref:`mixin`».
 
 .. container:: figure
 

classes/nonsortals/rolemixin/constraints.rst

@@ -1,22 +1,20 @@
 Constraints
 -----------
 
-**C1:** A «RoleMixin» is always abstract. Notice that abstract classes
+**C1:** A «:ref:`rolemixin`» is always abstract. Notice that abstract classes
 are represented with an *italic* label.
 
 .. container:: figure
 
    |RoleMixin application 3|
 
-**C2:** A «RoleMixin» aggregate individuals that follow different
-identity principles, therefore it may not have as ancestor the following
-constructs: «Kind», «Quantity», «Collective», «Subkind», «Role»,
-«Phase», «Relator», «Mode», «Quality».
+**C2:** A «:ref:`rolemixin`» aggregate individuals that follow :ref:`different
+identity principles <identity>`, therefore it may not have as ancestor the following
+constructs: «:ref:`kind`», «:ref:`quantity`», «:ref:`collective`», «:ref:`subkind`», «:ref:`role`»,
+«:ref:`phase`», «:ref:`relator`», «:ref:`mode`», «:ref:`quality`».
 
-**C3:** A «RoleMixin» is a anti-rigid construct, therefore it cannot
-have as descendent any rigid or semi-rigid type, as: «Kind», «Quantity»,
-«Collective», «Subkind», «Category», «Mixin», «Relator», «Mode»,
-«Quality».
+**C3:** A «:ref:`rolemixin`» is a :ref:`anti-rigid <rigidity>` construct, therefore it cannot
+have as descendent any :ref:`rigid <rigidity>` or :ref:`semi-rigid <rigidity>` type, as: «:ref:`Kind`», «:ref:`Quantity`», «:ref:`Collective`», «:ref:`Subkind`», «:ref:`Category`», «:ref:`Mixin`», «:ref:`Relator`», «:ref:`Mode`», «:ref:`Quality`».
 
 .. container:: figure
 

classes/nonsortals/rolemixin/definition.rst

@@ -1,23 +1,23 @@
 Definition
 ----------
 
-A **«RoleMixin»** is the equivalent of «Role» for types that aggregate
-instances with **different identity principles**. A class stereotyped as
-«RoleMixin» is also an **anti-rigid** type whose instantiation depends
-on a **relational** property. Here are some examples:
+A «:ref:`rolemixin`» is the equivalent of «:ref:`role`» for types that aggregate
+instances with :ref:`different identity principles <identity>`. A class stereotyped as
+«:ref:`rolemixin`» is also an :ref:`anti-rigid <rigidity>` type whose instantiation :ref:`depends
+on a relational property <dependency>`. Here are some examples:
 
 .. container:: figure
 
    |RoleMixin examples|
 
 RoleMixins usually occur in one of the two patterns: **Pattern 1:**
-RoleMixin defined by roles
+«:ref:`rolemixin`» defined by roles
 
 .. container:: figure
 
    |RoleMixin application 1|
 
-**Pattern 2:** RoleMixin as a role of a Category
+**Pattern 2:** «:ref:`rolemixin`» as a role of a «:ref:`category`»
 
 .. container:: figure
 

classes/sortals/collective/constraints.rst

@@ -1,31 +1,29 @@
 Constraints
 -----------
 
-**C1:** A «Collective» cannot have an identity provider («Kind»,
-«Collective», «Quantity», «Relator», «Mode» and «Quantity») as its
+**C1:** A «:ref:`collective`» cannot have an :ref:`identity <identity>` provider («:ref:`kind`»,
+«:ref:`collective`», «:ref:`quantity`», «:ref:`relator`», «:ref:`mode`» and «:ref:`quantity`») as its
 direct or indirect super-type.
 
 .. container:: figure
 
    |Collective forbidden 1|
 
-**C2:** A «Collective» cannot have types that inherit identity
-(«Subkind», «Role» and «Phase») as its direct or indirect super-types.
+**C2:** A «:ref:`collective`» cannot have types that inherit :ref:`identity <identity>`
+(«:ref:`subkind`», «:ref:`role`» and «:ref:`phase`») as its direct or indirect super-types.
 
 .. container:: figure
 
    |Collective forbidden 2|
 
-**C3:** A «Collective» cannot have types that aggregate individuals with
-different identity principles («Category», «RoleMixin» and «Mixin») as
-its direct or indirect subtypes.
+**C3:** A «:ref:`collective`» cannot have types that aggregate individuals with
+:ref:`different identity principles <identity>` («:ref:`category`», «:ref:`rolemixin`» and «:ref:`mixin`») as its direct or indirect subtypes.
 
 .. container:: figure
 
    |Collective forbidden 3|
 
-**C4:** As a rigid type, a «Collective» cannot have any anti-rigid type
-(«Role», «RoleMixin» and «Phase») as its direct or indirect super-type.
+**C4:** As a :ref:`rigid <rigidity>` type, a «:ref:`collective`» cannot have any :ref:`anti-rigid <rigidity>` type («:ref:`role`», «:ref:`rolemixin`» and «:ref:`phase`») as its direct or indirect super-type.
 
 .. container:: figure
 

classes/sortals/collective/definition.rst

@@ -1,11 +1,11 @@
 Definition
 ----------
 
-The **«Collective»** construct is used to represent **rigid** concepts
-that provide an **identity principle** for their instances. The main
-characteristic of a «Collective» is that it has an homogenous internal
+The «:ref:`collective`» construct is used to represent :ref:`rigid <rigidity>` concepts
+that provide an :ref:`identity principle <identity>` for their instances. The main
+characteristic of a «:ref:`collective`» is that it has an homogenous internal
 structure, i.e., all parts are perceived in the same way by the whole
-(see the MemberOf relation for more details about members of
+(see the «:ref:`memberOf`» relation for more details about members of
 collections).
 
 .. container:: figure
@@ -29,9 +29,8 @@ would say that a family is a functional complex.
 
    |Family|
 
-As the other identity provider stereotypes (Kind, Quality, Relator and
-Mode), a Collective can be specialized by subkinds, phases and roles, as
-well as generalized by mixins and categories.
+As the other identity provider stereotypes («:ref:`kind`», «:ref:`quality`», «:ref:`relator`» and
+«:ref:`mode`»), a «:ref:`collective`» can be specialized by :ref:`subkinds <subkind>`, :ref:`phases <phase>` and :ref:`roles <role>`, as well as generalized by :ref:`mixins <mixin>` and :ref:`categories <category>`.
 
 .. container:: figure
 

classes/sortals/kind/constraints.rst

@@ -1,27 +1,23 @@
 Constraints
 -----------
 
-**C1:** A «Kind» cannot have an identity provider («Kind», «Collective»,
-«Quantity», «Relator», «Mode» and «Quantity») as its direct or indirect
-super-type.
+**C1:** A «:ref:`kind`» cannot have an :ref:`identity <identity>` provider («:ref:`kind`», «:ref:`collective`», «:ref:`quantity`», «:ref:`relator`», «:ref:`mode`» and «:ref:`quantity`») as its direct or indirect super-type.
 
 .. container:: figure
 
    |Kind forbidden 1|
 
-**C2:** A «Kind» cannot have types that inherit identity («Subkind»,
-«Role» and «Phase») as its direct or indirect super-type.
+**C2:** A «:ref:`kind`» cannot have types that inherit :ref:`identity <identity>` («:ref:`subkind`»,
+«:ref:`role`» and «:ref:`phase`») as its direct or indirect super-type.
 
 .. container:: figure
 
    |Kind forbidden 2|
 
-**C3:** A «Kind» cannot have types that aggregate individuals with
-different identity principles («Category», «RoleMixin» and «Mixin») as
-its direct or indirect subtypes.
+**C3:** A «:ref:`kind`» cannot have types that aggregate individuals with
+:ref:`different identity principles <identity>` («:ref:`category`», «:ref:`rolemixin`» and «:ref:`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.
+**C4:** As a :ref:`rigid <rigidity>` type, a «:ref:`Kind`» cannot have any :ref:`anti-rigid <rigidity>` type («:ref:`role`», «:ref:`rolemixin`» and «:ref:`phase`») as its direct or indirect super-type.
 
 
 .. |Kind forbidden 1| image:: _images/ontouml_kind-forbidden-1.png

classes/sortals/kind/definition.rst

@@ -1,10 +1,10 @@
 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
+A «:ref:`kind`» is construct you are going to use in most of your models.
+It is used to represent :ref:`rigid <rigidity>` concepts that provide an :ref:`identity
+principle <identity>` for their instances and do not require a :ref:`relational
+dependency <dependency>`. A «:ref:`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: