In my first few glances at SKOS eXtension for Labels, I didn't quite get it. Recently, though, while looking at a client's requirements document at TopQuadrant, when I saw that they wanted to attach metadata to individual terms, I started modeling this in my head and then I realized I didn't need to: SKOS-XL already had.

"Any problem in Computer Science can be solved by another level of indirection."

First, why can't you attach metadata to specific terms with the base SKOS standard? Because although SKOS is an ontology for managing controlled vocabularies (and taxonomies, and thesauri), the basic unit of what it manages is not a term, which is what taxonomy management software always managed before. This is a Good Thing, because it makes internationalized vocabularies much easier to manage. I can have a single concept with a German preferred label of "Spirituosen", a British English preferred label of "spirits", an American English preferred label of "liquor", and an American alternative label of "booze", and they all refer to the same concept. The United Nations Food and Agriculture Organization's AGROVOC thesaurus is a good example of this practice, with dozens of preferred and alternate labels for some concepts.

SKOS's extensibility means that you can attach all the metadata you want to a particular concept, but not to one of the terms defined as labels for that concept. This is because, being labels, they're strings. (In spec talk, they're "lexical entities", which isn't quite the same thing, but close enough for our purposes.) SKOS is built on RDF, and in RDF triples strings can only be the objects of triples, not the subjects. So how can we assign metadata about the labels themselves, such as the name of the person who added a particular label, or the date it was last updated?

The Cambridge computer scientist David Wheeler, who in 1951 became the first person ever to complete a PhD in the field, once said "Any problem in Computer Science can be solved by adding another level of indirection". That's what SKOS-XL does: it defines variations on the SKOS skos:prefLabel and skos:altLabel properties called skosxl:prefLabel and skosxl:altLabel (assuming, as always, that these prefixes have been properly declared). Instead of having strings as their values, these extension properties point to members of the skosxl:Label class. Members of this class have a skosxl:literalForm property to identify a string that serves as a label for the concept, and it can have all the additional properties you want.

The following shows some Turtle syntax for a SKOS-XL representation of the concept described above, with extra :lastEdited and :myCustomProperty properties adding metadata to some of the labels:

@prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
@prefix skosxl: <http://www.w3.org/2008/05/skos-xl#> .
@prefix :       <http://www.example.com/demo#> .
@prefix rdf:    <http://www.w3.org/2000/01/rdf-schema#> . 
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .

:concept234 rdf:type skos:Concept ;
  skosxl:prefLabel :label1 ;
  skosxl:prefLabel :label2 ;
  skosxl:prefLabel :label3 ;
  skosxl:altLabel  :label4 .

:label1 rdf:type skosxl:Label ; 
  :lastEdited "2011-02-05T10:21:00"^^xsd:dateTime ;
  skosxl:literalForm "Spirituosen"@de .

:label2 rdf:type skosxl:Label ; 
  :lastEdited "2011-02-05T10:28:00"^^xsd:dateTime ;
  :myCustomProperty 2.71828 ;
  skosxl:literalForm "spirits"@en-GB .

:label3 rdf:type skosxl:Label ; 
  :lastEdited "2011-02-05T10:34:00"^^xsd:dateTime ;
  skosxl:literalForm "liquor"@en-US .

:label4 rdf:type skosxl:Label ; 
  :lastEdited "2011-02-05T10:42:00"^^xsd:dateTime ;
  :myCustomProperty 3.1415 ;
  skosxl:literalForm "booze"@en-US .

The general idea is pretty elegant, and having a standardized way to do it prevents me and others from developing our own variations that do the same thing. I'm glad I didn't take that model in my head too far.

How much use of SKOS-XL have people seen in the real world?