Unify paragraphs

classes/aspects/mode/constraints.rst

@@ -1,15 +1,13 @@
 Constraints
 -----------
 
-**C1:** Every «:ref:`mode`» must be (directly or indirectly) connected to an
-association end of at least one «:ref:`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 «:ref:`mode`»)
-must be exactly one. Therefore, the following examples are forbidden.
+**C2:** The multiplicity of the characterized end (opposite to the «:ref:`mode`») must be exactly one. Therefore, the following examples are forbidden.
 
 .. container:: figure
 

classes/aspects/mode/definition.rst

@@ -1,10 +1,7 @@
 Definition
 ----------
 
-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:
+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/mode/examples.rst

@@ -1,15 +1,13 @@
 Examples
 --------
 
-**EX1:** Fragment from the Configuration Management Task Ontology (`see
-more <http://www.menthor.net/cmto.html>`__):
+**EX1:** Fragment from the Configuration Management Task Ontology (`see more <http://www.menthor.net/cmto.html>`__):
 
 .. container:: figure
 
    |Example CMT|
 
-**EX2:** Fragment from the OntoUML Org Ontology (O3) (`see
-more <http://www.menthor.net/o3.html>`__):
+**EX2:** Fragment from the OntoUML Org Ontology (O3) (`see more <http://www.menthor.net/o3.html>`__):
 
 .. container:: figure
 

classes/aspects/quality/constraints.rst

@@ -1,16 +1,13 @@
 Constraints
 -----------
 
-**C1:** A «:ref:`quality`» must always be connected, through a «:ref:`characterization`»
-to another type.
+**C1:** A «:ref:`quality`» must always be connected, through a «:ref:`characterization`» to another type.
 
 .. container:: figure
 
    |Quality application 1|
 
-**C2:** The multiplicity of the characterized end (opposite to the
-quality) must be exactly one. Therefore, the following examples are
-forbidden.
+**C2:** The multiplicity of the characterized end (opposite to the quality) must be exactly one. Therefore, the following examples are forbidden.
 
 .. container:: figure
 

classes/aspects/quality/faq.rst

@@ -1,14 +1,9 @@
 Common questions
 ----------------
 
-**Q1:** Can I represent the property "height" as an attribute instead of
-a Quality?
-**A1:** Yes. The decision to represent attributes or
-qualities is entirely up to you. It is useful to represent properties as
-qualities when you want to define different escales for the same
-characteristic. For instance, if you want to model that a Person has a
-"height" property, which can be measured in meters or centimeters you
-should explicitly represent the Height quality.
+**Q1:** Can I represent the property "height" as an attribute instead of a «:ref:`quality`»?
+
+**A1:** Yes. The decision to represent attributes or qualities is entirely up to you. It is useful to represent properties as qualities when you want to define different escales for the same characteristic. For instance, if you want to model that a Person has a "height" property, which can be measured in meters or centimeters you should explicitly represent the Height quality.
 
 .. container:: figure
 

classes/nonsortals/category/constraints.rst

@@ -1,31 +1,25 @@
 Constraints
 -----------
 
-**C1:** A «:ref:`category`» is always abstract. Notice that abstract classes
-are represented with an *italic* label.
+**C1:** A «:ref:`category`» is always abstract. Notice that abstract classes are represented with an *italic* label.
 
 .. container:: figure
 
    |Category application 1|
 
-**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`».
+**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 «: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`».
+**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:
-«:ref:`mixin`», «:ref:`role`», «:ref:`phase`».
+**C4:** Categories cannot have as descendants the following types: «:ref:`mixin`», «:ref:`role`», «:ref:`phase`».
 
 .. container:: figure
 

classes/nonsortals/category/definition.rst

@@ -1,19 +1,12 @@
 Definition
 ----------
 
-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 :ref:`different identity principles <identity>`. Let's see
-some examples:
+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 :ref:`different identity principles <identity>`. Let's see some examples:
 
 .. container:: figure
 
    |Category 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 «:ref:`category`», which has weight, and generalize the existing
-classes into it.
+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 «:ref:`category`», which has weight, and generalize the existing classes into it.
 
 .. |Category examples| image:: _images/ontouml_category-examples.png

classes/nonsortals/category/examples.rst

@@ -1,15 +1,13 @@
 Examples
 --------
 
-**EX1:** Fragment from the ECG Ontology (`see
-more <http://www.menthor.net/ecg.html>`__):
+**EX1:** Fragment from the ECG Ontology (`see more <http://www.menthor.net/ecg.html>`__):
 
 .. container:: figure
 
    |Example ECG|
 
-**EX2:** Fragment from UFO-S, a commitment-based service ontology (`see
-more <http://www.menthor.net/ufo-s.html>`__):
+**EX2:** Fragment from UFO-S, a commitment-based service ontology (`see more <http://www.menthor.net/ufo-s.html>`__):
 
 .. container:: figure
 

classes/nonsortals/mixin/constraints.rst

@@ -1,15 +1,13 @@
 Constraints
 -----------
 
-**C1:** A «:ref:`mixin`» is always abstract. Note that abstract classes are
-represented with *italic* labels.
+**C1:** A «:ref:`mixin`» is always abstract. Note that abstract classes are represented with *italic* labels.
 
 .. container:: figure
 
    |Mixin application 2|
 
-**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.
+**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,26 +1,13 @@
 Definition
 ----------
 
-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`»:
+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 :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 :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 :ref:`semi-rigid <rigidity>` or a «:ref:`mixin`».
+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 :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 :ref:`semi-rigid <rigidity>` or a «:ref:`mixin`».
 
 .. container:: figure
 

classes/nonsortals/mixin/examples.rst

@@ -1,16 +1,13 @@
 Examples
 --------
 
-**EX1:** Conceptual model based on the Music Ontology (`see
-more <http://www.menthor.net/music-ontology.html>`__):
+**EX1:** Conceptual model based on the Music Ontology (`see more <http://www.menthor.net/music-ontology.html>`__):
 
 .. container:: figure
 
    |Example Music|
 
-**EX2:** Fragments extracted from the OntoUML Org Ontology (O3), a model
-about the active structure of organisations (`see
-more <http://www.menthor.net/o3.html>`__):
+**EX2:** Fragments extracted from the OntoUML Org Ontology (O3), a model about the active structure of organisations (`see more <http://www.menthor.net/o3.html>`__):
 
 .. container:: figure
 

classes/nonsortals/rolemixin/constraints.rst

@@ -8,13 +8,9 @@ are represented with an *italic* label.
 
    |RoleMixin application 3|
 
-**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`».
+**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 «: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`».
+**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,30 +1,27 @@
 Definition
 ----------
 
-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:
+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:**
-«:ref:`rolemixin`» defined by roles
+RoleMixins usually occur in one of the two patterns:
+
+- **Pattern 1:** «:ref:`rolemixin`» defined by roles
 
 .. container:: figure
 
    |RoleMixin application 1|
 
-**Pattern 2:** «:ref:`rolemixin`» as a role of a «:ref:`category`»
+- **Pattern 2:** «:ref:`rolemixin`» as a role of a «:ref:`category`»
 
 .. container:: figure
 
    |RoleMixin application 2|
 
-The second pattern is a more concise form of the first. They are
-semantically equivalent.
+The second pattern is a more concise form of the first. They are semantically equivalent.
 
 .. |RoleMixin examples| image:: _images/ontouml_rolemixin-examples.png
 .. |RoleMixin application 1| image:: _images/ontouml_rolemixin-application-1.png

classes/nonsortals/rolemixin/examples.rst

@@ -1,15 +1,13 @@
 Examples
 --------
 
-**EX1:** Fragment of the OntoUML Org Ontology (O3) (`see
-more <http://www.menthor.net/o3.html>`__):
+**EX1:** Fragment of the OntoUML Org Ontology (O3) (`see more <http://www.menthor.net/o3.html>`__):
 
 .. container:: figure
 
    |Example O3|
 
-**EX2:** Fragment of a conceptual model about Brazilian Public Tenders
-(`see more <http://www.menthor.net/public-tenders.html>`__):
+**EX2:** Fragment of a conceptual model about Brazilian Public Tenders (`see more <http://www.menthor.net/public-tenders.html>`__):
 
 .. container:: figure
 

classes/sortals/collective/constraints.rst

@@ -1,23 +1,19 @@
 Constraints
 -----------
 
-**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.
+**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 «:ref:`collective`» cannot have types that inherit :ref:`identity <identity>`
-(«:ref:`subkind`», «:ref:`role`» and «:ref:`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 «: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.
+**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
 

classes/sortals/collective/definition.rst

@@ -1,36 +1,19 @@
 Definition
 ----------
 
-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 «:ref:`memberOf`» relation for more details about members of
-collections).
+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 «:ref:`memberOf`» relation for more details about members of collections).
 
 .. container:: figure
 
    |Collective examples|
 
-To decide whether or not to classify a concept as a collective, think
-about the relation between it has towards its parts (or members). Do all
-members are "equally perceived" by the whole (the collective)? In other
-words, do all members contribute in the same way to the functionality of
-the whole? If the answers are yes, you have a collective. It is
-important to keep in mind that some concepts, like Family or Fleet could
-be classified as both collectives and functional complexes. For
-instance, if we understand a family as a group of people with equal
-roles and responsibilities towards the family, we would say it is a
-collective. However, if we distinguish a person as the head of the
-family, and another as being responsible for the family's income, we
-would say that a family is a functional complex.
+To decide whether or not to classify a concept as a collective, think about the relation between it has towards its parts (or members). Do all members are "equally perceived" by the whole (the collective)? In other words, do all members contribute in the same way to the functionality of the whole? If the answers are yes, you have a collective. It is important to keep in mind that some concepts, like Family or Fleet could be classified as both collectives and functional complexes. For instance, if we understand a family as a group of people with equal roles and responsibilities towards the family, we would say it is a collective. However, if we distinguish a person as the head of the family, and another as being responsible for the family's income, we would say that a family is a functional complex.
 
 .. container:: figure
 
    |Family|
 
-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>`.
+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