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?

4 Comments

By fps on February 8, 2011 5:09 PM

Hmm… nothing states that we can deduce the statements involving the standard skos props?

“All problems in computer science can be solved by another level of indirection… Except for the problem of too many layers of indirection.” - or too many indirections to deal with.

So, couldn’t we have a global mechanism that would work for any property whose range is rdfs:Literal ? Something around :

exlit:ExtendedLiteral a rdfs:Class.

exlit:extendedLiteral
a rdfs:Property;
rdfs:range ExtendedLiteral.
dc:comment “from a statement using this property, one can deduce the statement whose subject is this statement’s subject , whose predicate is this statement’s object’s exlit:property value, and whose object is statement’s object’s exlit:value .”

exlit:property a rdfs:Property;
rdfs:domain exlit:ExtendedLiteral;
rdfs:range rdfs:Property;
dc:comment “the ’literal property’"@en.

exlit:value a rdfs:Property;
rdfs:domain exlit:ExtendedLiteral;
rdfs:range rdfs:Literal;
dc:comment “the literal value”@en.\

So, from:
ex:Me extendedLiteral ex:MyGivenName.
ex:MyGivenName a ExtendedLiteral;
exlit:property foaf:givenName;
exlit:value “François-Paul”;
dc:comment “My parents first thought of calling me François, like one if my grand fathers, but they resolved to add Paul like the other one, for having them both happy”.

You could deduce ex:me foaf:givenName “François-Paul”.

Does it make sense ?

Best

By Bob on February 8, 2011 9:43 PM

Sure, I guess. I’m just happy that a way to address this client’s needs didn’t require new modeling and non-standardized extensions, like I originally thought it would.

By masaka on February 8, 2011 10:08 PM

Hi,

NDLSH (National Diet Library Subject Heading) uses SKOS-XL heavily to give ‘yomi’ (transcription) to each label. See for example,

http://id.ndl.go.jp/auth/ndlsh/00574798.ttl\

By Bob on February 9, 2011 8:55 AM

Thanks Masaka, those are very interesting.