Hi Christophe, Johan, Leonard, and others,

"SKOS / ISO 25964 interchangeability" should be seen as a strategic target, as long as this will not *restrict* any future SKOS usage to the ISO patterns.

I really like Christophe's wording:

[Christophe:]
> 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.


So, let us leave SKOS as flexible as it is, but let us try to harmonize some recommended SKOS extension for ISO interoperability.

Johan obviously has drafted something like that some tome ago:

[Johan:]
> JDS-3: on an earlier version of SKOS-XL, I made an exercise some time ago to cover the BS8723
> (which was input for the ISO standard)
> JDS-3: note this exercise was never discussed on any forum yet


Johan, have you made this exercise public? It might be a good starting point.


I would like to contribute some of my own considerations about Label management here.

Coordination should be handled in a different thread, as (following Leonard in this regard) coordination might rather be about Concepts, not Labels.

[Leonard:]
> Coordination of concepts has previously been discussed during the development of SKOS
> but was not followed through because it was "too hard" to deal with within the time available, ...


Christophe may see this differently, but I will focus on some basic Label / Term patterns in the following.

Christophe has started this thread with one concise example:

[Christophe:]
> 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


To me this looks rather simple. These attributes may be mapped as follows:

iso:lexicalValue -> skosxl:literalForm
iso:identifier: -> URI of the Label resource
iso:created, modified, source -> dct:created, etc.
iso:status ->
might be expressed as a skos:editorialNote
iso:lang ->
RDF language tag attached to the literalForm.

Some of these mapping may be arguable, but I connot find any structural challenge in this example.

Looking at the ISO model provided by Leonard (thanks Leonard for this update!) as well as to the patterns of UMTHES, I find the most crucial difference between SKOS and ISO is about distinguishing preferred terms from-non preferred terms.

SKOS distinguishes xl:prefLabel from xl:altLabel relations, but the related xl:Label itself is unclassified in this regard.
 
Following the SKOS(XL) semantics, one and the same xl:Label may appear as prefLabel of one Concept and as altLabel of another.

SKOS only keeps you from using the same Label as pref and alt in the same Concept:

> SKOS S13: "skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties."


This make only one usage pattern unvalid:

# one concept with the same label as pref/alt
# not valid due to S13

<Love> skosxl:prefLabel <love> ;
    skosxl:altLabel <love> .


But the following should be compliant with the explicit SKOS semantics, as far as I see:

# two concepts with reverse pref/alt Labels
# valid in SKOS but unwanted by ISO

<A> skosxl:prefLabel <love>;
    skosxl:altLabel <adoration> .

<B> skosxl:prefLabel <adoration> ;
    skosxl:altLabel <love> .


SKOS pref/alt of a label only exists in the context of a given Concept, while ISO pref/nonPref is bound to a given label (~term).

Further more, SKOS(XL) does not contain any equivalence relation. One might see something similar when looking at a single Concept: the prefLabel of this Concept may be seen as equivalent to the altLabel of the same Concept.

But again, this is not a relation between the two Labels, it is just a usage pattern in the context of a single Concept, and the same two Labels may be used differently in the context of another Concept.

If we want to have something like ISO term specialization & equivalence in a SKOS extension I would draft this as follows:

First, define ext:prefTerm and ext:nonPrefTerm both as subclasses of skosxl:Label.

ext:prefTerm rdfs:subClassOf skosxl:Label .
ext:nonPrefTerm rdfs:subClassOf skosxl:Label .

Now make these two classes disjoint.

ext:prefTerm owl:disjointWith nonPrefTerm .

Declare a subProperty of skosxl:prefLabel with ext:prefTerm in its range (btw. this should be valid in OWL2).

ext:hasPrefTerm rdfs:subProperty skosxl:prefLabel;
    rdfs:range ext:prefTerm .

Declare another subProperty of skosxl:altLabel with ext:nonPrefTerm in its range.

ext:hasNonPrefTerm rdfs:subProperty skosxl:altLabel;
    rdfs:range ext:nonPrefTerm .

Now define use/usedFor both as subProperties of skosxl:labelRelation.

ext:usedFor rdfs:subPropertyOf skosxl:labelRelation;
    rdfs:domain ext:prefTerm;
    rdfs:range ext:nonPrefTerm;
    owl:inverseOf ext:use .


Now you can write:

<love> ext:usedFor <adoration> .

From this will be inferred:

<love> rdf:type ext:prefTerm .
<adoration>
rdf:type ext nonPrefTerm .

and

<adoration> ext:use <love> .

Note that all this leaves the existing SKOS semantics untouched, but it provides an extension with more strict semantics:

# not valid:
<A> ext:prefTerm <love>;
    ext:nonPrefTerm <adoration> .

<B> skosxl:prefLabel <adoration> ;
    skosxl:altLabel <love> .

As far as I see, this proposal conforms to the existing SKOS recommendation and (basically) allows expressing some more strict ISO patterns.

I would like to discuss and clarify this so far before moving on to the more complex "compound" and "split" patterns.

What do you think?

Kind regards,
Thomas
-- 
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