Fixed-length labels

§ 8.1 of the XKOS specification describes how to use SKOS labels in combination with `xkos:maxLength` to render fixed-length labels. Another example taken from the NAF rév. 2 (“Nomenclature d'activités française”) is given below:

Labels of different types

Official labels should always be represented by the `skos:prefLabel` property. For usual labels, `skos:altLabel` should be used, but only when they are different from the official ones, due to the SKOS integrity rules.

For example, the French “Nomenclature des professions et catégories socioprofessionnelles 2020” (PCS2020) distinguishes “official” and “usual” labels:

In the first example above, the official and usage labels are different, so `skos:altLabel` can be used to express the usage label. In the second example, the usage label is the same as the official one, so `skos:altLabel` cannot be used since `skos:prefLabel` and `skos:altLabel` are disjoint properties. `skos:prefLabel` represents both the official and usage labels.

If more than one type of “unofficial” labels exist, SKOS-XL constructs can be used, in the same way than for the fixed-length labels example. In this case, the `skos-xl:Label` can be qualified by a custom property listing the different types of labels. The current version of XKOS does not define this kind of property.

Translations

Classification publishers should always provide textual material (labels and notes) in their original language. Additionally, it is recommended to publish English versions of at least the official labels and if possible of other labels and of all notes.

RDF native support of multilingualism should always be used:

Note structure

As indicated in the XKOS specification, and as a prerequisite for the versioning and timestamping of notes, instances of `xkos:ExplanatoryNote` should be used as value for the SKOS and XKOS note properties, and not literal values.

The instances of `xkos:ExplanatoryNote` should at least follow the structure given in the table below, in addition to other properties described below, depending if the note is timestamped or versioned.

Versioning notes and timestamping notes

As indicated in the introductory paragraph about classification major revisions and versions, the notes are the information that have fine-grained versions between each major revision of a classification (any changes other than on the notes - moving a concept, renaming a concept, etc. - is supposed to happen in a new major revision, hence applies to a new Concept URI. See section Major versions of classifications).

We propose 2 different patterns of versioning for notes: versioning notes with a version number and a date range, and keeping the history of notes with a timestamp.

The first pattern to version notes implies that each new version of the note is given a version number and a date range. All notes, except `skos:changeNote` and `xkos:caseLaw` should follow this pattern: `skos:scopeNote`, `skos:definition`, `xkos:coreContentNote`, `xkos:additionalContentNote`, `xkos:exclusionNote`, `xkos:inclusionNote`. These notes should use the properties listed in the table below.

Given the versioning history of such notes, a client accessing a particular version of the classification might not be interested to know about the versioning history of all notes, and is only interested in the current state of each note.

The second pattern implies that the note is associated with a publication date, but no version number. This pattern applies to `skos:changeNote` and `xkos:caseLaw`. It will use the properties listed in the table below.

Given the versioning history of such a note, a client accessing a particular version of the classification might be interested to have the full history of each value of the note.

xkos:inclusionNote vs. xkos:caseLaw

When a framework classification is implemented it is generally accompanied by explanatory notes (represented using `skos:scopeNote` or its sub-properties). These explanatory notes can undergo some review procedures so that countries can provide feedback about their content. Once the new or updated/revised classification comes into force and for stability sake, the explanatory notes remain untouched until the classification is next revised or updated.

Questions about the explanatory notes are addressed to the custodians of the relevant classifications who then issue classification decisions after discussion with countries; these classification decisions are generally grouped under various names (e.g. "rulings", "classification decisions", "caselaws") and represented using the `xkos:caseLaw` property. When a framework classification is revised or updated theses caselaws are considered for inclusion in the official explanatory notes.

In other words, classification objects that were not explicitly described in the core content note nor in the additional content note are taken into account by adding a case law specifying the content not explained in the explanatory notes. As defined in Neuchâtel terminology model "case law refers to a ruling concerning the classification of certain statistical objects/units, which do not obviously fit into one category and are not clearly defined by explanatory notes".

Type the classification items of a given classification

A best practice is to declare a new subclass of `skos:Concept` as the type of the classification items for a given revision of a classification. For example the class “ex:NACE-R2_Item” could be declared as a subclass of `skos:Concept` to represent the set of all items in the 2nd revision of the NACE classification. Introducing this class allows to constrain the range of certain properties on this class.

This new subclass of skos:Concept shall be linked to the skos:ConceptScheme with either of these 2 modelling patterns:

1. an `rdfs:seeAlso` property, in both direction (from the `skos:ConceptScheme` to the new sub-class of `skos:Concept`, and from the new subclass of `skos:Concept` to the `skos:ConceptScheme`)
2. a formal OWL equivalence between the subclass of `skos:Concept` and a restriction on the property `skos:inScheme`, with an `owl:hasValue` equal to the `skos:ConceptScheme` URI. For example here is how one would declare the equivalence between a new subclass of skos:Concept "NACE-R2_Item" and the set of `skos:Concept` that have a `skos:inScheme` equal to the corresponding scheme URI:

   Class: ex:NACE-R2_Item
   
       EquivalentTo:
           skos:inScheme value ex:nace-r2
   
       SubClassOf:
       	skos:Concept
   						

While the first option is more direct and readable, the second one is more formal.

This new class is expected to be declared in the same file as the `skos:ConceptScheme` representing the classification.

Both these options are illustrated in the example below.

Note that items inside the classification are not expected to be explicitely typed with this new class; they should only be typed with `skos:Concept`. The declaration of this class is only useful so that it can be assigned as the range of some properties.

Type classification items according to their level

§6 of the XKOS specification describing classification levels states the following:

"In XKOS, a classification level is defined as a specialization of `skos:Collection` named `xkos:ClassificationLevel`. (...) Individual `skos:Concept` objects are related to the `xkos:ClassificationLevel` to which they belong by the usual `skos:member` property (going from the level to the classification item)."

In this best practice document we describe how to declare OWL classes that correspond to the set of items of the classification at each particular level. These classes are subclasses of the class that represent the set of all items of the classification, as described in previous section. The OWL classes link to their corresponding classification level with `rdfs:seeAlso`, and vice-versa : a classification level points to the corresponding class with the same predicate.

Declaring OWL classes corresponding to classification levels allows to refer to these classes in the signature (domain or range) of properties. A typical use-case is to indicate that a certain property can refer only to the items at one or more levels of a classification.

Following the example given above, the following levels of the NACE-R2 would each have a corresponding `owl:Class` declared as subclass of `ex:NACE-R2_Item`:

• ex:NACE-R2_Section / corresponding class : ex:NACE-R2_Section_Class
• ex:NACE-R2_Division / corresponding class : ex:NACE-R2_Division_Class
• ex:NACE-R2_Group / corresponding class : ex:NACE-R2_Group_Class
• ex:NACE-R2_Class / corresponding class : ex:NACE-R2_Class_Class

These classes would be declared as direct subclasses of `ex:NACE-R2_Item`, as the set of e.g. NACE sections is a subset of the set of all NACE items. However these classes would not be declared as subclasses of each other, as it is not true to state that e.g. the set of all NACE R2 divisions is a subset of all NACE R2 sections.

To capture the intent that instances of NACE R2 divisions are expected to be narrower concepts of instances NACE R2 sections, the classification levels are referenced in an ordered list by the `xkos:levels` property on the `skos:ConceptScheme`.

This is illustrated in the following example.

We note however one limitation to this approach : contrary to the class that represents the set of all items of the classification (`ex:NACE-R2_Item` in the example above), it is not easily possible to declare a formal OWL equivalence between the classes that represent the set of items of a level and the corresponding `xkos:ClassificationLevel`. This is due to the fact that the `skos:member` link is expressed on the classification level and refers to the classification items, contrary to `skos:inScheme` that is expressed on the items and points to the classification. For this to be possible, an inverse of `skos:member` should be declared.

Type classification items according to a branch or a subset of items

It is sometimes desirable to restrict the range of a property not to items of a particular classification, nor to items at a certain level in a certain classification, but either to a "branch" of the classification, or to a subset of the elements taken anywhere in the classification.

For the cases where it is known that the classification is "partitioned" in subsets that can be used independantly, the following modelling pattern can be applied : each "partition" is declared as a `skos:ConceptScheme`, linked to the main `skos:ConceptScheme` of the classification with a `dcterms:isPartOf`; and the `skos:Concept`s of the classification items have 2 `skos:inScheme` properties : one that refers to the main `skos:ConceptScheme`, and one that refers to the `skos:ConceptScheme` of their "partition". This pattern is typically applied for the modeling of micro-thesauri in large thesaurus.

The pattern described above of declaring an OWL class corresponding to the skos:ConceptScheme can be applied, this time with a skos:ConceptScheme corresponding to a "partition". This is illustrated in the example below:

Correspondences direction

By convention, the source Classification in a correspondence is the ‘former’ one, and the target Classification is the ‘new’ one. Or in other words, the source is the classification whose items compose the domain of the correspondence relation and the target is the classification whose items correspond to the range of this correspondence relation.

As an additionnal information, it is also possible to use properties given by the [[PROV-O]] vocabulary, for instance `prov:wasDerivedFrom` to convey the fact that one classification is based on a previous one and has with it a common content (see below).

Documenting correspondences

Works requiring classifications are numerous, and there may exist several correspondence tables between two given classifications, depending on the scope of the comparison, the used methodology, etc. Thus it is recommended to document the `xkos:Correspondence` with notes and other properties providing information concerning the creation context of these correspondence tables. The table below lists the mandatory and optional properties for this.

The above table is formally encoded in a set of [[SHACL]] constraints, documented in the appendix.

It is possible to have several correspondence tables based on the same source and target classifications that are created with different methodologies and thus give different views of the relation between the two classifications (e.g. if links are constructed automatically or if they are determined by expert judgement). It may therefore be necessary to store this information by associating with the mapping table a `prov:Activity` encompassing the creation steps followed.

Documenting concept associations

The following table lists the optional properties that can be expressed on a `xkos:ConceptAssociation`

The above table is formally encoded in a set of [[SHACL]] constraints, documented in the appendix.

It is possible to further describe concept associations with custom properties. INSEE for example uses `insee:differenceNote` and `insee:similarityNote` to capture respectively how the related items differs and how they are similar, as in the following example:

Examples of xkos:ConceptAssociation

Examples below are taken from the correspondence table between two successive versions of the french classification of occupations.

In the RDF snippet below, the two classifications pcsese1982 and pcsese2003 are typed as two `skos:ConceptScheme` and the correspondence table pcsese1982 - pcsese2003 is typed as a `xkos:Correspondence`.

Describing the correspondence table matrix

Among the numerous kind of work involving classifications, we may have to apply distribution coefficients between the items of the initial (source) classification and those of the final (target) classification, for instance when we have to make economical estimations between two revisions of a classification, spanning different temporal periods.

To cope with this use case, as well as the use-case of the n-to-m concept association described above, it is possible to link the correspondence table with a matrix, expressed with the RDF Data Cube vocabulary [[QB]], that associates some values to each pair of associated source-target concepts. These values could be a percentage, a price, or a boolean to indicate whether the concepts are actually linked or not. These values are actually the measures of the observations in the data cube.
Note that multiple values can be associated with a single observation in this data cube matrix, to give for exemple values both in terms of number of employees and in terms of revenues.

One could see this matrix as a redundancy with the correspondence table. It is actually a different, complimentary point of view: while the correspondence table gives a “documentary” view, and an easy way to traverse from the source concept to the target concept, the matrix provides the statistical point of view, with the numbers or weights associated to each pair of related source-target concepts.

It is suggested that a new property is introduced in XKOS to capture the link between a Correspondence table and its corresponding `qb:DataSet` that captures the weights. The suggested property is `xkos:weightedBy`, but it is not part of XKOS at the time of this writing. A more generic property like `dcterms:relation` can also be used by default.

The following example illustrates this suggested mechanism. Note how the correspondence table in this example, and the associated matrix, are defined only for a given `xkos:ClassificationLevel` in each of the compared classifications.

The following example illustrates a real example with a weighted correspondence table between NAF and NAFrev1 classifications.

Major versions of classifications

When a complete revision of a classification happens, a new major version of a classification is produced.

It is recommended that all concepts and levels are recreated with new URIs in the new revision. Only the changes of notes should be allowed in fine-grained versions between each major revision of a classification, as described in section Versioning notes and timestamping notes.

The relation between the classification items of the two revisions is given by a correspondence table as presented in the corresponding section of this document.

As for the classification themselves, the `skos:ConceptScheme` of the former revision should have the property `owl:deprecated` set to “true” and its end of validity period set in the `schema:endDate` property. Links between successive revisions can be asserted between the `skos:ConceptScheme`s by using `xkos:supersedes`; this property conveys the idea that the classification being referred to is deprecated.

Use of PROV-O

§5.1 of the XKOS Specification states

“Readers should also be aware that the Provenance Ontology, which was not available at the time of writing of this specification, introduces the related notion of "entity specialization" (`prov:specializationOf`). This can be an alternative approach for describing the versioning of classifications.”

The following table gives more details on how XKOS properties are related to [[PROV-O]]. The use of [[PROV-O]] properties in combination with XKOS properties is encouraged to promote wider interoperability of links between classifications.

Note that in the case of a `xkos:variant`, the corresponding [[PROV-O]] property is `prov:wasDerivedFrom` instead of `prov:wasRevisionOf`. The existence of a variant does not imply the original version is deprecated. There will be an overlap between the validity time period of the variant version and the reference one.

Note also that no mapping is made between `xkos:belongsTo` and `prov:specializationOf` since the PROV property implies the entities are of the same nature, whereas the classification is a `skos:Concept` and the level a `skos:ClassificationLevel`.

Example of statistical classification series

The figure below presents the succession of two revisions of the NAF classification. The temporal periods of validity of each revision are given through the `schema:startDate` and `schema:endDate` properties. A possibility to clearly identify that the NAFRev1 is the obsolete version is to use the `owl:deprecated` property set to `true`.

In the `xkos:ConceptAssociation` the `xkos:sourceConcept` makes a reference to a `skos:Concept` belonging to the `skos:ConceptScheme` of the former classification while the `xkos:targetConcept` references a `skos:Concept` belonging to the (`skos:ConceptScheme` of) the new revision of the classification.

Datasets of classifications

It is recommended to use DCAT V2 to describe and disseminate metadata associated with classifications.

Each revision of a classification should correspond to one `dcat:Dataset`. For instance, in the example below, the classification NAF Rev1 and NAF Rev2 are separated in distinct `dcat:Dataset`s with different version information. Each classification’s dataset belongs to a `dcat:Catalog`.

Each dataset should have downloadable files in the necessary formats for both human and machine agents. In particular, statistical classifications should be provided for download in an RDF file based on [[SKOS]] and [[XKOS]] vocabularies, containing the full content of the classification. In the example, CSV and RDF (SKOS) formats are provided. The `dcterms:conformsTo` property should be set to the URI of the [[XKOS]] vocabulary: http://rdf-vocabulary.ddialliance.org/xkos.

For practical reasons it is important to have direct access to the latest version of a classification for directly retrieving the updated notes. However, for reasons of nomenclature expertise it is also important to have access to changes in notes that have affected the nomenclature. It is therefore recommended to have access to the history of modifications of all notes within the revision of the classification included in a `dcat:Dataset`. These versions containing the history of all notes are considered as different distributions of the datasets. They should be described by specific properties. Here we use `rdfs:comment` for describing and discriminating the distributions, given a lack of other modeling alternatives in DCAT (as of september 2022; this was raised in this DCAT issue). Other information is given by the `dcterms:temporal` metadata that has a larger span for the distributions containing all the note changes.

Datasets of correspondences

Each correspondence table shall also be provided as a distinct Dataset in the catalog. This dataset can be linked with the dataset of the source classification and the dataset of the target classification with:

• A generic `dcterms:relation` property, that is expressed both from the source and target dataset to the correspondence table dataset, and from the correspondence dataset to its source and target.
• A `dcat:Relationship` that indicates more precisely the role of each dataset, either source or target in the correspondence table. The role of each dataset is captured by the `dcat:hasRole` property, with one of these 2 values:
  • `xkos:correspondenceFromRole`
  • `xkos:correspondenceToRole`
  The exact URIS for roles have been proposed to XKOS but are not part of the standard at the time of writing of this document, and so are subject to change.

The example below presents the correspondence between Naf rev2 and Naf rev1 classification.

Proposed URI pattern for classifications

Where:

• `{scheme}`: is the URI scheme, typically “http” or “https”.
• `{authority}`: the domain name of the authority attributing the URI to the resource. This guarantees the unicity of the URI at Web scale. Note that the domain name can be a dedicated subdomain of the more general domain name of the authority e.g. “data.acme.org” or “id.acme.org”.
• `{all_classifications}`: is a fixed component in the URI indicating that what follows pertains to the identification of an entity in the scope of a classification, as opposed to an entity in another domain, like statistical data, document metadata, etc. Typical examples are “codes”, “classifications”, etc.
• `{classification_naming_context}`: an identifier for the naming context that will contain the different components of this classification; This component typically is based on the classification id in one of its specific revisions. Examples are “nafr2”, “pcs1982”, etc.
• `{concept_scheme_id}`: an identifier for the concept scheme that represents a revision of the classification.

Proposed URI pattern for classification levels

Where:

• `{scheme}`, `{authority}`, `{all_classifications}` and `{classification_naming_context}` components have the same meaning as the in the URI pattern for the classification;
• `{level}`: an identifier for a level in this classification. Some implementations have chosen the plural forms, e.g. “sections”, “classes”, “divisions”, etc.

Proposed URI pattern for classification items (Concepts)

Where:

• `{scheme}`, `{authority}`, `{all_classifications}` and `{classification_naming_context}` components have the same meaning as in the URI pattern for the classification;
• `{level}`: an identifier for the level of the concept. It is key to understand that the level is an intrinsic part of the concept identity in statistical classifications. A concept cannot be moved in a given revision of a classification. Hence the level is part of the concept URI. Implementations have chosen to use the singular form of the level, thus a different stem from the URI of the corresponding level. Examples are “section”, “class”, “division”, etc.
• `{concept_id}`: an identifier for the specific concept within the classification; the format of the identifier varies depending on the classification and the level. Examples are “A”, “1963”, “10.73”, etc.

Proposed URI pattern for Labels

Where:

• `{concept_URI}`: the concept URI, as described above. The URI for the label is hierarchically below the URI of the concept having this label, since a label entity is attached to a single concept.
• `{label_id_length_language}`: a component identifying the label, typically composed with a fixed part, the label length and the languages. Examples are “label40fr” or “label65en”

Proposed URI pattern for Notes (versioned)

Where:

• `{concept_URI}`: the concept URI, as described above. The URI for the note is hierarchically below the URI of the concept having this note, since a note entity is attached to a single concept.
• `{type_of_note}`: An indication of type of the note according to XKOS note types, e.g. “noteExclusions”, “noteGenerale”, “noteContenuCentral”, “noteContenuLimite”, etc.
• `{note_version}`: the version of the note, e.g. “v1”, “v2”
• `{language}`: the language code of the note, e.g. “fr”

Proposed URI pattern for Notes (timestamped)

Where:

• `{concept_URI}`: the concept URI, as described above. The URI for the note is hierarchically below the URI of the concept having this note, since a note entity is attached to a single concept.
• `{type_of_note}`: An indication of type of the timestamped note according to XKOS note types, typically a “changeNote” (“noteChangement”)
• `{date}`: the date of the note, in an xsd:date format, e.g. “2021-09-22”
• `{language}`: the language code of the note, e.g. “fr”

Proposed URI pattern for Correspondences

Where:

• `{scheme}` and `{authority}` have the same meaning as in the URI pattern for classifications;
• `{all_correspondences}`: is a fixed component in the URI indicating that what follows pertains to the identification of an entity in the scope of a correspondence table. Typical examples are “correspondences”, “mappings”, etc.
• `{source_concept_scheme_id}-{target_concept_scheme_id}`: the identifiers for respectively the source and target concepts schemes mapped in this correspondence.

Proposed URI pattern for Concept associations

Where:

• `{correspondence_URI}` : the correspondence URI, as described above. The URI for an association is hierarchically below the URI of the correspondence in which this association is, since a concept association is attached to a single correspondence.
• `{all_associations}`: is a fixed component in the URI indicating that what follows identify a concept association. Typical example is "association".
• `{source_concept_id}-{target_concept_id}`: the identifiers for respectively the source and target concepts linked through this concept association.