Re-tagged rules and sections, and fixed several typo in UML conventions.

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

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

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

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

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