Some KOS, for example classification systems such as the Universal Decimal Classification [UDC], use notations (or legends) as the primary means of access to the concepts they contain. Notations are symbols that are not normally recognized as words or word sequences in any natural language and therefore can be used independently of natural language contexts. They are usually composed of digits, supplemented by punctuation marks and other characters, as in the following example of UDC:
512.6 Special branches of algebra
SKOS allows notations to be represented in two ways, depending on the priorities of the conceptual scheme editor. The first preferred technique is to use the skos:notation property. This property allows attaching a concept to an RDF-typed literal, a literal with an explicit data type [RDF-PRIMER]. The data type of the literal specifies a syntax encoding scheme, which conforms to the use of notations in the KOS in question. The value of the literal is the notation itself (in this case the classification code itself):
ex:udc512 skos:prefLabel “Algebra”@en ;
skos:notation “512”^^ex:UDCNotation .
See below for details on how to handle data types. This approach can be especially useful if a KOS editor wants to provide users with processing rules that are specific to the KOS notation scheme. For example, many classification systems have specific syntax rules that allow complex notations to be decomposed, leading to the linking of the corresponding concept to simpler concepts. In addition, this pattern can help SKOS tool developers and KOS editors who want notations to be displayed in a specific way.
However, managing these data types can be cumbersome. In addition, the above pattern is not really necessary when editors consider the notations themselves to be simple language-independent tags. In such cases, it is possible to use a SKOS labeling property, e.g. skos:prefLabel, without any language label, as in
ex:udc512 skos:prefLabel “Algebra”@en ;
skos:notation “512”^^ex:UDCNotation ;
skos:prefLabel “512” .
Note that notations represented in this way are unlikely to benefit from notation-specific mechanisms (such as display procedures) in SKOS tools. By default, users should expect these notations to be treated, according to the SKOS model, as mere labels.
Notations, typed literals and data types
A typed literal is a UNICODE string combined with a data type URI.
Typed literals are commonly used to denote values such as integers, floating point numbers and dates, and there are a number of data types predefined by the XML Schema specification [XML-SCHEMA] such as xs:integer, xs:float and xs:date.
For other situations, new data types can be defined, which are often referred to as “user-defined data types” [SWBP-DATATATYPES].
By convention, the skos:notation property is only used with a typed literal in the object position of the triple, where the URI of the datatype denotes a user-defined datatype corresponding to a particular system of notations or classification codes.
For many situations it may be sufficient to simply coin a datatype URI for a particular notation system, and define the datatype informally through a document describing how notations are constructed and/or what lexical forms are allowed. Note, however, that it is also possible to define at least the lexical space of a data type more formally through the XML Schema language. Users should be aware that tools may vary in their support for data types. However, tools should at least treat lexically identical literals as equal.
There are no restrictions on the cardinality of the skos:notation property. A concept can have zero, 1 or more notations.
When a concept has more than one notation, these can be from the same or different notation systems. In the case where the notations are from different systems, different data types can be used to indicate this. It is not common practice to assign more than one notation from the same notation system (i.e., with the same data type URI).
Unique notations in concept schemes
By convention, no two concepts of the same concept schema are assigned the same notation. If they did, it would not be possible to use the notation to uniquely refer to a concept (i.e., the notation would become ambiguous).
Preferred notations and labels
There are no restrictions on the combined use of skos:notation and skos:prefLabel. In the following example, the same string is given as both a lexical form of a notation and as a lexical form of a preferred label.
Typed literals consist of a string and a data type URI. By convention, skos:notation is only used with typed literals in the object position of the triple.
Simple literals consist of a string and a language tag. By convention, skos:prefLabel (and skos:altLabel and skos:hiddenLabel) are only used with simple literals in the object position of the triple.
There is no such thing as an RDF literal with language label and data type URI, i.e., a typed literal has no language label, and a plain literal has no data type URI.
Domain of skos:notation
Note that no domain is given for skos:notation. Thus, the effective domain is the class of all resources (rdfs:Resource). Therefore, the use of skos:notation with any resource type is consistent with the SKOS data model.