It was asked to me today how I will keep track of a label source (and other management information) in SKOS...
Hopefully SKOS-XL reifies labels.

Looking at ISO 25964, I have:
Attributes of ThesaurusTerm:
LexicalValue String      1 The wording of the term
identifier   String      1 A unique identifier for the term
created      date     0..1 The date when the term was created
modified     date     0..1 The date when the term was last modified
source       String   0..1 The person(s) or document(s) from which the term was taken
Status       String   0..1 Indication of whether the term is candidate, approved, etc.
lang         language 0..1 A code showing the language of the term. This should be
                           included if the thesaurus supports more than one language

The subject may be touchy but one could like to see a standardized way to have SKOS / ISO 25964 interchangeability
(something like an SKOS/ISO application profile)

This would allow:
1) An ISO 25964 thesaurus editor could unload/reload using SKOS files without information losses.
2) Exchanges between different ISO 25964 thesauri could be done using the SKOS format.
3) SKOS aware applications could support ISO 25964 "extensions" without parameterization to indicate which RDF attributes contains the supplementary ISO data.
4) SKOS would benefit from the insights of ISO 25964 design team.

There is a rather striking difference between SKOS flexibility and extendability (opening ways to unstandardized horizons) and ISO willingness to build upon the past within a stricter frame.

What I am suggesting is to check (and to normalize somewhat) how the complete data model of ISO can be mapped in SKOS(-XL).

By the way, labels reification opens the way to write labels which are written from multiple coordinated concepts.
A reified label of a coordination concept could include an rdf:Seq.
This rdf:Seq would contain strings and/or refers to (reified) labels from the different coordinated concepts and/or refers to coordination operators (conjunctions).
This could generate a dynamic literalForm based on the labels of the differeent coordinated concepts.

Have a nice evening,


Johan De Smedt a écrit :
Hi Thomas,
Please find in-line and prefixed with ">>JDS-2:" clarifications on your added questions.
In the examples, "ev:" stands for the EUROVOC schema prefix.

kr, Johan De Smedt.


From: Thomas Bandholtz [mailto:thomas.bandholtz@innoq.com]
Sent: Sunday, 25 October, 2009 20:13
To: Johan De Smedt
Cc: 'SKOS'; 'Antoine Isaac'
Subject: Re: UMTHES and SKOS-XL

Hi Johan,

some considerations inline:

I see SKOS primarily as an exchange format not as a maintenance format.

This is a very important issue. I used to see SKOS purely as an exchange format either, but since LOD I understand skosified reference vocabularies as an important building block at runtime. This does not constrain maintenance to anything else than the vocabulary has to be serializable in SKOS so that it will meet the expectations of a SKOS aware application.

Users of the EUROVOC thesaurus maintenance system manage permuted literals as properties of preferred or alternate xl:Labels.
- the genuine managed labels are ok to have a URI that can later be used in an LOD or SPARQL service interface
- permuted literal forms do not have this quality
However, when making a SKOS compliant publication, the hidden label has relevance (as search value)
Hence EUROVOC publishes for a skos:Concept :C
- :C xl:prefLabel :ptC; xl:altLabel :nptC; skos:hiddenLabel "permuted literal form of C" .
- :ptC xl:literalForm "PT of C" .
- :nptC xl:literalForm "nPT of C" .
I think this is compliant with SKOS(XL) - comment is welcome.

I don't see any reason why this should not be compliant with SKOS. But it may not express your semantics:  
>>JDS-2: indeed, not all semantics are expressed that is what I try to explain below..
 You provide prefLabel and altLabel with XL, but hiddenLabel in plain SKOS, so how will you express that some permuted literal form refers to one of the labels? A Concept by itself has no literal form, so i do not understand how it may have a permuted literal form. Is there exactly one permuted literal form per Concept or per Label?
Could you give an example?
 >>JDS-2: example:
C stands for the concept with preferred term "child abuse"
:C xl:prefLabel :childAbuse
:childAbuse xl:literalForm "child abuse"@en .
:childAbuse ev:permutedLiteralForm "abuse, child"@en .
For this, the EUROVOC publishing service generating SKOS will generate in addition
:C skos:prefLabel "child abuse"@en .
:C skos:hiddenLabel "abuse, child"@en
This is based on the following two (informally noted) rules that go with the EUROVOC schema
- A chain xl:prefLabel([Concept][Term]) o ev:permutedLiteralForm([Term][literal]) → skos:hiddenLabel([Concept][literal]) .
- A chain xl:altLabel([Concept][Term]) o ev:permutedLiteralForm([Term][literal]) → skos:hiddenLabel([Concept][literal]) .

The details of why
- :nptC is an an alt label
- "permuted literal form of C" is a permuted label
can be found in the equivalence relationships (simple or compound) or in the permuted literal forms of either :ptC or :nptC.
This is expressed in the EUROVOC specific SKOS extension (and thus requires knowledge of the owl schema beyond
the formal OWL expressions - i.e. the documentation that goes with the schema).

I understand that "ptC" stands for "preferred term of a Concept" and "nptC" for "non-preferred term of a Concept", right?  >>JDS-2: yes. 
The basic ISO equivalence relationship is "preferredTerm USED FOR non-preferredTerm" with inverse "non-preferredTerm USE preferredTerm".
There is no such construct in SKOS. A SKOSXL Label cannot be preferred or not by itself, it only depends on how it is linked to a Concept (pref/altLabel).
(see an example below ...)
Guess that is the reason why you have a EUROVOC specific SKOS extension (which we don't know so far).
I wonder how you express "permuted literal forms of either :ptC or :nptC", when the permuted literal form is a rdf:Literal? 
>>JDS-2: an xl:Label may have an arbitrary number of ev:permutedLiteralForm.  This is a data property (like xl:literalForm).
>>JDS-2: in contrast though, ev:permutedLiteralForm has no cardinality constraints.
>>JDS-2: further, for any xlLabel :L, its property xl:literalForm and all its ev:permutedLiteralForm must have the same language. 
This might be a special case, but xs:labelRelation is intended to point to a xl:Label instance, not to a Literal.

The selection of something being a PT or an nPT or a permuted label is up to the thesaurus maintenance/management.
It is not always obvious if either an acronym ("OWL") or the full name ("Web Ontology Language") will be used as PT
in a real world thesaurus.  (Like considerations apply for other label relations)
However, once a name is selected as the PT, the related labels are likely (mandatory?) candidates for nPT or hidden labels.
As there currently is no SKOS extension capturing such label relations, we now discuss on which approach to take.
I would advocate that for some of the work done on the ISO standardization, it may be worthwhile to do some RDF
standardization effort in the future.
Possible candidates are:
- Concept groups

What is the difference from a skos:Collection? 
>>JDS-2: group means any subset of concepts while collections where aimed to represent "node labels" and "facets".
>>JDS-2: I think Stella and Antoine are better placed to respond to this accurately. 

- Equivalence relationships (simple and compound)

SKOS only has altLabel prefLabel relations from a Concept to a Label.
>From this arises the question whether the same Label my be pref of one Concept and alt of another?
Would this be compliant? Yes (may be not intentionally).

S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties."
S14: "A resource has no more than one value of skos:prefLabel per language tag."

These only keep you from saying something like:

<Love> skos:prefLabel "love"@en ; skos:prefLabel "adoration"@en .


<Love> skos:prefLabel "love"@en ; skos:altLabel "love"@en .

But the following is compliant:

<A> skos:prefLabel "love"@en ; skos:altLabel "adoration"@en .
<b> skos:prefLabel "adoration"@en ; skos:altLabel "love"@en .

Or even more evident in XL:

<A> skosxl:prefLabel :love; skosxl:altLabel :adoration .
<B> skosxl:prefLabel :adoration ; skosxl:altLabel :love .
:love skosxl:literalForm "love"@en .
:adoration skosxl:literalForm "adoration"@en.

SKOS pref/alt of a label is only known in the context of a given Concept, while
ISO pref/nonPref is bound to a given label (~term).
>>JDS-2: I agree and this makes ISO Thesaurus semantics more strict than SKOS (as you demonstrate in the example below). 

If you want to have ISO equivalence in SKOS you may express something like:

prefTerm subClassOf xl:Label .
nonPrefTerm subclassOf xl:Label .
prefTerm disjointWith nonPrefTerm .

xl:prefLabel range prefTerm .
xl:altLabel range nonPrefTerm . 
>>JDS-2: I do not follow with these last 2 rules as they would redefine SKOS-XL.
>>JDS-2: Instead we define ev:EquivalenceRelation relating a prefTerm and a nonPrefTerm using properties ev:use and ev:uf respectively.
>>JDS-2: ev:use and ev:uf do have range prefTerm and nonPrefTerm respectively.
>>JDS-2: then we say that :C xl:altLabel :nptC is entailed by:
>>JDS-2: :C xl:prefLabel :ptC.
>>JDS-2: :eqr rdf:type ev:equivalenceRelation ; ev:use :ptC ; ev:uf :nptC. 

usedFor subPropertyOf xl:labelRelation;
    domain prefTerm;
    range nonPrefTerm;
    inverseOf use .

and then:

love  a prefTerm;
adoration a nonPrefTerm;
love usedFor adoration.

Obviously, the industry may find the schema provided in the ISO standard (UML/XML) sufficient.

? I do not really understand this. 
>>JDS-2: I mean the ISO standard went a long way:
>>JDS-2: The BS preparing it defined an XML schema for Thesauri. 
>>JDS-2: This covered more than SKOS (this statement is scoped to thesaurus).
>>JDS-2: In addition a model was defined using the Unified Modeling Language (UML).
>>JDS-2: Likewise this model has more specific thesaurus artifacts. 

Thomas Bandholtz, thomas.bandholtz@innoq.com, http://www.innoq.com 
innoQ Deutschland GmbH, Halskestr. 17, D-40880 Ratingen, Germany
Phone: +49 228 9288490 Mobile: +49 178 4049387 Fax: +49 228 9288491