From 3d13cabe7c210972ef4f0cef7ff0ca0b2662c059 Mon Sep 17 00:00:00 2001
From: csnyulas <csongor.nyulas@gmail.com>
Date: Tue, 20 Jun 2023 15:10:15 +0300
Subject: [PATCH] Re-tagged rules and sections, and fixed several typo in UML
 conventions.

---
 .../ROOT/pages/uml/conv-attributes.adoc       | 12 +++----
 docs/modules/ROOT/pages/uml/conv-classes.adoc | 11 +++++-
 .../ROOT/pages/uml/conv-connectors.adoc       | 34 +++++++++----------
 .../ROOT/pages/uml/conv-datatypes.adoc        | 10 +++---
 .../ROOT/pages/uml/conv-enumerations.adoc     |  2 +-
 docs/modules/ROOT/pages/uml/conv-general.adoc | 27 +++++++++------
 .../ROOT/pages/uml/on-conventions.adoc        |  4 +--
 7 files changed, 57 insertions(+), 43 deletions(-)

diff --git a/docs/modules/ROOT/pages/uml/conv-attributes.adoc b/docs/modules/ROOT/pages/uml/conv-attributes.adoc
index ff4057e5..f99ce4ca 100644
--- a/docs/modules/ROOT/pages/uml/conv-attributes.adoc
+++ b/docs/modules/ROOT/pages/uml/conv-attributes.adoc
@@ -3,7 +3,7 @@
 [[sec:attributes]]
 === Conventional recommendations on Attributes
 
-[[sec:attributes-names-with-verb]]
+[[rule:attributes-names-with-verb]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Attribute names
@@ -25,7 +25,7 @@ It is recommended to avoid duplicate attribute names across multiple classes. Un
 
 // To avoid laborious mechanical work of adding the prefix, it is possible to rely on the convention that the attribute names starting with a capital letter must be read as having the "has-" prefix. It means that the transformation script will prepend the "has-" prefix to all attributes starting with a capital letter.
 
-[[sec:attributes-multiplicity]]
+[[rule:attributes-multiplicity]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Attribute multiplicity
@@ -46,7 +46,7 @@ In special cases, a list of custom default multiplicities is defined for the tra
 [[sec:attributes-class]]
 === uml:Class attributes
 
-[[sec:attributes-datatypes]]
+[[rule:attributes-datatypes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Attribute datatypes
@@ -60,13 +60,13 @@ uml:Attribute shall be defined with generally accepted primitive datatypes.
 
 *Description:*
 
-Each uml:Attribute must have a name and an attribute type. uml:Attribute is mostly transformed into owl:DataProperty and in some controlled cases into owl:ObjectProperty. High preference shall be given to using OWL 2 compliant XSD [xref:references.adoc#ref:xsd[xsd]] and RDF [xref:references.adoc#ref:rdf[rdf]] standard datatypes. [xref:uml/conv-datatypes.adoc#sec:primitive-datatypes[see Section on Primitive Data types]]
+Each uml:Attribute must have a name and an attribute type. uml:Attribute is mostly transformed into owl:DataProperty and in some controlled cases into owl:ObjectProperty. High preference shall be given to using OWL 2 compliant XSD [xref:references.adoc#ref:xsd[xsd]] and RDF [xref:references.adoc#ref:rdf[rdf]] standard datatypes. [xref:uml/conv-datatypes.adoc#rule:primitive-datatypes[see Section on Primitive Data types]]
 
 In cases when a property needs to be defined as ranging on an unknown controlled list or authority table constitute a special case. They can be expressed as uml:Attribute with the datatype `skos:Concept`. These attributes are transformed into owl:ObjectProperty in a manner similarly to uml:Association.
 
-An attribute may contain an alias, used as an alternative label. It can be specified via uml:Tags. [xref:uml/conv-general.adoc#sec:tags[See section on uml:Tags]]
+An attribute may contain an alias, used as an alternative label. It can be specified via uml:Tags. [xref:uml/conv-general.adoc#rule:gen-tags[See section on uml:Tags]]
 
-[[sec:attributes-reuse]]
+[[rule:attributes-reuse]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Attribute name reuse
diff --git a/docs/modules/ROOT/pages/uml/conv-classes.adoc b/docs/modules/ROOT/pages/uml/conv-classes.adoc
index bc6e0989..ba52a1a7 100644
--- a/docs/modules/ROOT/pages/uml/conv-classes.adoc
+++ b/docs/modules/ROOT/pages/uml/conv-classes.adoc
@@ -3,6 +3,7 @@
 [[sec:classes]]
 === Conventional recommendations on Classes
 
+[[rule:class-name-gen]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Naming of classes
@@ -19,6 +20,7 @@ Class names shall be simple nouns or noun phrases.
 When choosing class names, it is conventional to use simple nouns or noun phrases. In case the class refers to actions, states, relations or qualities, which are usually expressed in natural language by verbs or adjectives then they must be nominalised. We often form nouns from other parts of speech, most commonly from a verb or an adjective. We can then use the noun phrase instead of the verb or adjective to create a more formal style. This process is called nominalisation.
 
 
+[[rule:class-name-singular]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Use of singular class names
@@ -35,6 +37,7 @@ Class names shall be formulated in singular.
 A class name represents a collection of objects. For example, a class "Language" actually represents all languages. Therefore, it could be more natural for some model designers to call the class "Languages" rather than "Language". In practice, however, the singular is used more often for class names, while the plural for sets and collections [xref:references.adoc#ref:noy2001[noy2001]]. Therefore, it is required that the class names must always use the singular lexical form.
 
 
+[[rule:class-name-capital]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Capitalise class names
@@ -51,6 +54,7 @@ Class names shall be written in Pascal case.
 The local segment in the name of a uml:Class element must start with a capital letter, and multiple words must be combined based on the Pascal case rules.
 
 
+[[rule:class-name-subclass]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Subclass naming
@@ -66,6 +70,7 @@ Classes in a subclass hierarchy should be named consistently.
 
 When building the class hierarchy, names of direct subclasses of a class should consistently either all include or not include the name of the superclass. For example, if we create two subclasses of `Wine` to represent red and white wines, then the two subclass names should be either `Red Wine` and `White Wine` or `Red` and `White`, but not `Red Wine` and `White` [xref:references.adoc#ref:noy2001[noy2001]].
 
+[[rule:class-single-subclass]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Single subclass
@@ -81,6 +86,7 @@ Class specialisations with a single child shall be avoided.
 
 This means that there should be at least two sibling subclasses specified in the model. By default, the classes are not disjunctive, however, if required, the transformation script may generate disjunctive classes by default.
 
+[[rule:class-circular]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Circular inheritance
@@ -99,6 +105,7 @@ This means that if a class `B` specialises a class `A`, then `A` may not special
 [[sec:uml-class]]
 === Technical conventions on uml:Class elements
 
+[[rule:class-name-mandatory]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Mandatory class names
@@ -114,6 +121,7 @@ Each uml:Class must have a short URI name.
 
 uml:Class is transformed into an owl:Class. Each uml:Class must have a name.
 
+[[rule:class-descr]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Class description
@@ -133,6 +141,7 @@ Optionally, in case there is a technical possibility to distinguish between UML
 
 Richer and structured descriptions can be provided by using uml:Tag(s).
 
+[[rule:class-properties]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Class properties
@@ -148,7 +157,7 @@ uml:Class must have connectors, attributes, or both.
 
 It is recommended that a uml:Class has relations, attributes, or both. A class must not miss both, attributes and relations associated with it. It is mandatory to avoid using the same name in a class, attribute or a relation.
 
-[[sec:abstract-class]]
+[[rule:class-abstract]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Abstract Classes
diff --git a/docs/modules/ROOT/pages/uml/conv-connectors.adoc b/docs/modules/ROOT/pages/uml/conv-connectors.adoc
index 5a72f951..8d3f72f5 100644
--- a/docs/modules/ROOT/pages/uml/conv-connectors.adoc
+++ b/docs/modules/ROOT/pages/uml/conv-connectors.adoc
@@ -4,7 +4,7 @@
 === Conventional recommendations on Relations
 
 
-[[sec:connetors-names-with-verb]]
+[[rule:connetors-names-with-verb]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Connector names
@@ -23,7 +23,7 @@ When establishing relations between concepts it is conventional to use verbs of
 The verb phrase must be in present tense, if needed inflected as third person singular. If an additional level of specificity is needed a qualifying nominal phrase may be appended.
 
 
-[[sec:connetors-bidirectional]]
+[[rule:connetors-bidirectional]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Bi-directional relations
@@ -40,7 +40,7 @@ Relationships are usually bi-directional, and the name for both directions shoul
 Relationships are usually bi-directional and the inverse one should be provided where it makes sense. Adjust the verb phrases in the predicates as appropriate, usually, by employing the _active and passive voice_ in the term formulation brings the desired result. For example, "uses/isUsedBy" and "refersTo/isReferredToBy" or "offers/isOfferedBy" [xref:references.adoc#ref:d2.01-2017[d2.01-2017]].
 
 
-[[sec:connetors-inverse]]
+[[rule:connetors-inverse]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Inverse relation
@@ -56,10 +56,10 @@ Semantically inverse relationships should be represented as two distinct uml:Con
 
 The name of the inverse relation should not be semantically inverted verb, such as in case of "buys/sells" , "open/closes". The semantically inverted dichotomies must be modelled in separate connectors because they represent different relations. For example the dichotomy "buys/sells" should be modelled as two pairs: "buys/isBoughtBy" and "sells/isSoldBy".
 
-When the relation is of different nature, more like an attribute, then prefixing and suffixing techniques can be employed. For example, in the Organisation Ontology [xref:references.adoc#ref:org-ontology[org-ontology]], the concepts of an "Organisation" and a "Site" are defined along with two relationships that are the inverse of each other: "Organisation hasSite Site" and "Site siteOf Organisation" [xref:references.adoc#ref:d3.1-2015[d3.1-2015]].
+When the relation is of different nature, more like an attribute, then prefixing and suffixing techniques can be employed. For example, in the Organization Ontology [xref:references.adoc#ref:org-ontology[org-ontology]], the concepts of an "Organization" and a "Site" are defined along with two relationships that are the inverse of each other: "Organisation hasSite Site" and "Site siteOf Organisation" [xref:references.adoc#ref:d3.1-2015[d3.1-2015]].
 
 
-[[sec:connetors-inverse-def]]
+[[rule:connetors-inverse-def]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Definition of inverse relations
@@ -81,7 +81,7 @@ Models should define such inverse pairs for relationships although this does not
 [[sec:association]]
 === Technical conventions on uml:Association
 
-[[sec:association-btw-classes]]
+[[rule:association-btw-classes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Associations connect classes
@@ -98,7 +98,7 @@ uml:Association elements connect two uml:Classes.
 The uml:Association connectors represent relations between source and target classes. The association connector cannot be used between other kinds of UML elements.
 
 
-[[sec:association-target]]
+[[rule:association-target]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Association connector name
@@ -119,7 +119,7 @@ First, if a connector name is specified then no source or target roles can be pr
 The second, and recommended approach is if the connector has no name then the target role must be specified. Or the converse, if a target role is specified then no connector name can be specified. Optionally a source role may be provided. In this case the relation direction must be changed from "Source->Target" to "Bidirectional". Or conversely, if the connector direction is "Bidirectional" then source and target roles must be provided. No other directions are permitted.
 
 
-[[sec:association-multiplicity]]
+[[rule:association-multiplicity]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Association multiplicity
@@ -136,7 +136,7 @@ uml:Association connector elements shall have their target multiplicity specifie
 The target and source multiplicity must be specified accordingly indicating the minimum and maximum cardinality.
 
 
-[[sec:association-definition]]
+[[rule:association-definition]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Association definition
@@ -157,7 +157,7 @@ It is recommended that each association has a definition. The definition is then
 === Technical conventions on uml:Dependency
 
 
-[[sec:dependency-btw-class-and-enum]]
+[[rule:dependency-btw-class-and-enum]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Dependency connects classes to enumerations
@@ -174,7 +174,7 @@ uml:Dependency connectors connect a uml:Class element to a uml:Enumeration eleme
 The dependency connector may be used between uml:Class and uml:Enumeration boxes, oriented from the class towards the enumeration. It indicates the class has an owl:ObjectProperty whose range is a controlled vocabulary. The connector must have direction "Source->Target". No other directions are acceptable.
 
 
-[[sec:dependency-name]]
+[[rule:dependency-name]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Dependency connector name
@@ -191,7 +191,7 @@ uml:Dependency connector elements shall have a valid name.
 The connector must have a valid name and no source/target roles are acceptable.
 
 
-[[sec:dependency-multiplicity]]
+[[rule:dependency-multiplicity]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Dependency multiplicity
@@ -214,7 +214,7 @@ In the transformation process, for the reasoning purposes, the range of the prop
 === Technical conventions on uml:Generalization
 
 
-[[sec:generalization-btw-classes]]
+[[rule:generalization-btw-classes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Generalization connects classes and sub-classes
@@ -231,7 +231,7 @@ uml:Generalization connectors connect a uml:Class element to its superclass uml:
 The uml:Generalization connector signifies a class-subClass relation and is transformed into `rdfs:subClassOf` relation standing between source and target classes.
 
 
-[[sec:generalization-name]]
+[[rule:generalization-name]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* uml:Generalization connector with no name
@@ -248,7 +248,7 @@ uml:Generalization connector elements shall have no name or a target role specif
 The uml:Generalization connectors must have no name or source/target roles specified in the UML model.
 
 
-[[sec:proxy-classes]]
+[[rule:proxy-classes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Proxy classes
@@ -265,7 +265,7 @@ For classes defined in external models proxy uml:Class elements should be define
 In case a model class should inherit a class from an external model then proxies must be created for those classes. For example, if `Buyer` specialises an `org:Organization`, then a proxy for `org:Organization` must be created in the `org` package.
 
 
-[[sec:disjoint-subclasses]]
+[[rule:disjoint-subclasses]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Disjoint subclasses
@@ -283,7 +283,7 @@ In this specification, the subclasses are assumed disjoint by default, unless ot
 
 
 
-[[sec:equivalent-classes]]
+[[rule:equivalent-classes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Equivalent classes
diff --git a/docs/modules/ROOT/pages/uml/conv-datatypes.adoc b/docs/modules/ROOT/pages/uml/conv-datatypes.adoc
index 1ec81682..77884a48 100644
--- a/docs/modules/ROOT/pages/uml/conv-datatypes.adoc
+++ b/docs/modules/ROOT/pages/uml/conv-datatypes.adoc
@@ -2,7 +2,7 @@
 
 === Conventional recommendations on datatypes
 
-[[sec:composite-datatypes]]
+[[rule:composite-datatypes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Primitive vs. composite datatypes
@@ -22,7 +22,7 @@ This convention draws the distinction between primitive (or atomic) types (consi
 [[sec:uml-datatype]]
 === Technical conventions on uml:DataType elements
 
-[[sec:primitive-datatypes]]
+[[rule:primitive-datatypes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* XSD and RDF datatypes
@@ -66,7 +66,7 @@ The table above provides a simplified correspondence between UML and XSD datatyp
 * https://www.w3.org/TR/rdf11-concepts/#section-Datatypes[RDF 1.1 Datatypes section]
 * https://www.w3.org/TR/owl2-syntax/#Datatype_Maps[OWL 2 Datatype Maps]
 
-[[sec:owl2-datatypes]]
+[[rule:owl2-datatypes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* OWL 2 datatypes
@@ -82,7 +82,7 @@ Whenever possible, OWL 2 compliant XSD and RDF datatypes shall be used.
 
 We strongly recommended the use of OWL 2 compliant XSD and RDF standard datatypes, if possible. They might be useful also for indicating a specific datatype, which is impossible with the UML ones. For example, making a distinction between a general string (`xsd:string`) and a literal with a language tag (`rdf:langString`), or XML encoded ones such as `rdf:HTML` and `rdf:XMLLiteral`.
 
-[[sec:proxy-datatypes]]
+[[rule:proxy-datatypes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Proxy datatypes
@@ -99,7 +99,7 @@ For already existing datatypes proxy uml:DataType elements should be defined.
 For the model consistency, it is recommended that the proxy data types be defined in the model for the XSDfootnote:[https://www.w3.org/2011/rdf-wg/wiki/XSD_Datatypes] and RDF data typesfootnote:[https://www.w3.org/TR/rdf11-concepts/#section-Datatypes] used in the model. The proxies must follow the standard namespace convention using the `rdf:` and `xsd:` prefixes.
 
 
-[[sec:datatypes-references]]
+[[rule:datatypes-references]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Datatypes references
diff --git a/docs/modules/ROOT/pages/uml/conv-enumerations.adoc b/docs/modules/ROOT/pages/uml/conv-enumerations.adoc
index 33c1f1be..294e3203 100644
--- a/docs/modules/ROOT/pages/uml/conv-enumerations.adoc
+++ b/docs/modules/ROOT/pages/uml/conv-enumerations.adoc
@@ -6,7 +6,7 @@
 In UML the controlled lists, discussed in Section [xref:uml/conv-general.adoc#sec:controlled-list[Controlled List]] are represented as uml:Enumeration. They are transformed into instances of a SKOS model [xref:references.adoc#ref:skos-spec[skos-spec]].
 
 
-[[sec:enumeration-to-skos]]
+[[rule:enumeration-to-skos]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Interpretation of uml:Enumeration
diff --git a/docs/modules/ROOT/pages/uml/conv-general.adoc b/docs/modules/ROOT/pages/uml/conv-general.adoc
index ab806e8c..14750293 100644
--- a/docs/modules/ROOT/pages/uml/conv-general.adoc
+++ b/docs/modules/ROOT/pages/uml/conv-general.adoc
@@ -6,7 +6,7 @@ In this section we provide a number of general conventions whose fundamental nat
 [[sec:names]]
 === Naming Conventions
 
-Defining naming and structural conventions for concepts in an ontology and then strictly adhering to these conventions don’t only make the ontology easier to understand, but also helps avoid some common modelling mistakes.
+Defining naming and structural conventions for concepts in an ontology, and then strictly adhering to these conventions, don’t only make the ontology easier to understand, but also helps avoid some common modelling mistakes.
 
 UML is a language without formal semantics. Moreover, it is quite flexible and permissive with ways in which a concept can be expressed. Also, there are many alternatives in naming concepts. Often there is no particular reason to choose one or another alternative. However, we need to define a set of naming conventions for classes, relations, attributes, controlled lists and adhere to it [xref:references.adoc#ref:noy2001[noy2001]].
 
@@ -58,7 +58,7 @@ All prefixes used in the element names must refer to a valid namespace declarati
 |===
 *Description:*
 
-The names should also belong to and be organised by _namespaces_. They can be provided as a short prefix to the elements name, for example "org:Organisation", "epo:Notice" or "skos:Concept". Namespaces are addressed in detail in Section [xref:uml/conv-general.adoc#sec:namespaces[Namespaces]].
+The names should also belong to and be organised by _namespaces_. They can be provided as a short prefix to the elements name, for example "org:Organization", "epo:Notice" or "skos:Concept". Namespaces are addressed in detail in Section [xref:uml/conv-general.adoc#sec:namespaces[Namespaces]].
 
 *See also:* SEMIC Style Guide Rules [https://semiceu.github.io/style-guide/1.0.0/gc-general-conventions.html#sec:gc-r4[GC-R4]], [https://semiceu.github.io/style-guide/1.0.0/gc-semantic-conventions.html#sec:sc-r3[SC-R3]] and [https://semiceu.github.io/style-guide/1.0.0/gc-conceptual-model-conventions.html#sec:cmc-r6[CMC-R6]]
 
@@ -81,6 +81,7 @@ It is recommended to avoid abbreviations in concept names. Also, the words emplo
 // [[sec:casing]]
 //=== Case sensitivity
 
+[[rule:gen-names-case]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Case sensitivity
@@ -103,6 +104,7 @@ All the names are case-sensitive. This means that the class "Buyer" and the attr
 [[sec:delimitation]]
 //=== Delimitation
 
+[[rule:gen-names-multi]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Delimitation in multi-word names
@@ -126,6 +128,7 @@ Exceptionally, if the conceptual model authors must maintain high readability of
 [[sec:uniqueness]]
 //=== Name uniqueness
 
+[[rule:gen-names-unique]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Name uniqueness and reuse
@@ -145,12 +148,13 @@ This means that there cannot exist a class and an attribute with the same name (
 
 Names that reduce to the same identifier are considered the same. For example "Legal Entity" and "LegalEntity" are different labels, but they reduce to the same identifier "LegalEntity". In such cases the names are considered equal and the UML elements replicated.
 
-Although name uniqueness is a recommendation, sometimes it is useful to replicate a UML element. In such cases, when the names are reused, the assumption is that the two UML elements represent manifestations of the same meaning. This is especially important for relations, and is explained in Section [xref:#sec:relation-reusability[]].
+Although name uniqueness is a recommendation, sometimes it is useful to replicate a UML element. In such cases, when the names are reused, the assumption is that the two UML elements represent manifestations of the same meaning. This is especially important for relations, and is explained in Convention [xref:#rule:gen-relation-reuse[]].
 
 
-[[sec:relation-reusability]]
+//[[sec:relation-reusability]]
 //=== Relations reusability
 
+[[rule:gen-relation-reuse]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Reuse of relations
@@ -177,6 +181,7 @@ Optionally, the transformation process from the conceptual model to the formal o
 [[sec:suffix-prefix]]
 //=== Suffix and prefix
 
+[[rule:gen-names-suffix-prefix]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Use of suffixes and prefixes
@@ -257,7 +262,7 @@ The controlled list is a carefully selected list of words and phrases and is oft
 
 As a rule of thumb, but not always, the relationship between the controlled list as a whole and its comprising elements can be informally conceptualised as a class-instance, class-subclass, set-item, or part-whole.
 
-[[sec:gen-controlled-list]]
+[[rule:gen-controlled-list]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Representation of known controlled lists
@@ -279,7 +284,7 @@ The expectation is that the controlled lists are published in accordance with be
 
 Two use-cases can be identified in practice: (a) when the code list is known and is explicitly referred to as the range of a property, and (b) when a property is modelled but no code list reference is provided as its range.
 
-[[sec:gen-controlled-list-unknown]]
+[[rule:gen-controlled-list-unknown]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Representation of unknown controlled lists
@@ -297,7 +302,7 @@ When the controlled list is unknown, then it shall not be referred to, but inste
 
 When the authors of a conceptual model intend to omit which controlled list shall be used, then a class attribute with the range `skos:Concept` (in some cases `Code` is preferred, but we strongly recommend avoiding this) can be created to indicate that. This approach can be useful in situations when multiple (external) controlled lists can be used interchangeably. For example, the `adms:status` property of a `dcat:CatalogueRecord` shall be a `skos:Concept`, without specifying the controlled list.
 
-[[sec:gen-controlled-list-empty]]
+[[rule:gen-controlled-list-empty]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Controlled list values
@@ -337,7 +342,7 @@ In order to enable the reuse of names defined in other models and reuse of uniqu
 
 // Namespaces are commonly structured as hierarchies to allow reuse of names in different contexts [xref:references.adoc#ref:xml-namespaces[xml-namespaces]]. This mechanism can be implemented in UML through partitioning the model using packages, which are described in the [xref:uml/conv-packages.adoc#sec:uml-package[uml:Package]] Section.
 
-[[sec:known-namespaces]]
+[[rule:gen-known-namespaces]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Known namespaces
@@ -405,7 +410,7 @@ Encoded UTF-8 and UTF-16 names may be used [xref:references.adoc#ref:xml1-spec[x
 [[sec:stereotypes-tags]]
 === Stereotypes and Tags
 
-[[sec:stereotypes]]
+[[rule:gen-stereotypes]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Stereotypes
@@ -419,11 +424,11 @@ Stereotypes have no semantics and hence shall be avoided. Exceptionally, some se
 
 *Description:*
 
-The use of stereotypes is not recommended. There should be only a small set of stereotypes, with well-defined meaning and pre-established transformation rules that shall be used in the conceptual model. In this set of rules the `\<<Abstract>>` stereotype is adopted to mark abstract classes [xref:uml/conv-classes.adoc#sec:abstract-class[see section on Abstract Classes]].
+The use of stereotypes is not recommended. There should be only a small set of stereotypes, with well-defined meaning and pre-established transformation rules that shall be used in the conceptual model. In this set of rules the `\<<Abstract>>` stereotype is adopted to mark abstract classes [xref:uml/conv-classes.adoc#rule:class-abstract[see convention on Abstract Classes]].
 
 *See also:* SEMIC Style Guide Rule [https://semiceu.github.io/style-guide/1.0.0/gc-conceptual-model-conventions.html#sec:cmc-r17[CMC-R17]]
 
-[[sec:tags]]
+[[rule:gen-tags]]
 |===
 |{set:cellbgcolor: #a8c6f7}
  *Title:* Tags
diff --git a/docs/modules/ROOT/pages/uml/on-conventions.adoc b/docs/modules/ROOT/pages/uml/on-conventions.adoc
index 7c0cf554..796d6521 100644
--- a/docs/modules/ROOT/pages/uml/on-conventions.adoc
+++ b/docs/modules/ROOT/pages/uml/on-conventions.adoc
@@ -1,9 +1,9 @@
 [[sec:on-conventions]]
 == UML Model Conventions
 
-The current set of UML Model Conventions are meant to guide the semantic engineers and ontolgy editors on producing consistent, uniform and uniquely interpretable conceptual models. Also, it is meant to help the readers of the conceptual models tointerpret the meaning and eliminate any ambiguities. Finally, the conventions are  fit for implementation.
+The current set of UML Model Conventions are meant to guide the semantic engineers and ontolgy editors on producing consistent, uniform and uniquely interpretable conceptual models. Also, it is meant to help the readers of the conceptual models to interpret the meaning and eliminate any ambiguities. Finally, the conventions are  fit for implementation.
 
-This set of guidelines is aligned with the SEMIC style guide [xref:references.adoc#ref:semic-style-guide[semic-style-guide]] and constitutes an extension and further elaboration.
+This set of guidelines is aligned with the SEMIC style guide [xref:references.adoc#ref:semic-style-guide[semic-style-guide]] and constitutes an extension and further elaboration of it.
 
 [[sec:keywords]]
 == Key words for Requirement Statements