W3C home > Mailing lists > Public > public-esw-thes@w3.org > November 2009

Re: Label management information in SKOS-XL (continuing from UMTHES and SKOS-XL)

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Mon, 09 Nov 2009 14:28:50 +0100
Message-ID: <4AF81912.2040302@few.vu.nl>
To: Johan De Smedt <Johan.De-smedt@tenforce.com>
CC: Thomas Bandholtz <thomas.bandholtz@innoq.com>, SKOS <public-esw-thes@w3.org>
Hi everyone,

I think it would be a very good idea to have this ISO/SKOS alignment/extension work done!
Even though I might have not much time these days to push it, unfortunately :-/

As a matter of fact, the pattern and axioms proposed by Thomas for pref and alt labels seem very sensible to me.

I'd just like to emphasize that introducing specific PrefTerm/NonPrefTerm and explicitly representing equivalence links at their level it does not correspond to a strict requirement in SKOS. 
As Thomas said, this can perfectly be derived from the prefLabel/altLabel statements with instances of xl:Label as objects, so there is redundancy. So no one using SKOS-XL should feel forced to use PrefTerm/NonPrefTerm classes and their associated machinery, if the only goal is to be compliant with SKOS-XL (this comments is especially aimed at Thomas, who was wondering about the validity of using that in his conversion of UMTHES).
But of course it does help materializing the alignment to ISO, so it is very much ok to use it, for those who are interested in that point.
(and even then, as far as I can understand Leonard's graph, the UF/USE relations are also redundant in ISO with the use of the isNonPreferredLabelFor/isPreferredLabelFor ones; but I won't discuss that here, and just assume that we should aim at mapping all relevant features in ISO)

A couple of minor (picky) comments:
- usual notations for classes and properties start with upper-case, so I'd expect, e.g, ext:PrefTerm and ext:NonPrefTerm instead of ext:prefTerm and ext:nonPrefTerm
- for a mapping to ISO, I'd recommend to stick to the ISO choice for labels (for classes or properties) rather than adhoc ones, whenever possible. So, ext:PreferredTerm instead of ext:PrefTerm, and so on. That's really a detail, but that can help future communication with ISO people...

Cheers,

Antoine





> Hi Thomas,
>  
> As stated,
> - the exercise dates back from end 2008
>   (I did update the imports as the SKOS core namespace issue was still 
> 2008/05).
> - I made it when reviewing the help my understanding in mapping it to SKOS
> - It was never discussed publicly and needs corrections
> - It has not been aligned with the recent ISO DIS that was circulated.
>  
> If it is useful, it can be the start of the exercise suggested by Thomas.
>  
> Johan.
> 
> ------------------------------------------------------------------------
> *From:* public-esw-thes-request@w3.org 
> [mailto:public-esw-thes-request@w3.org] *On Behalf Of *Thomas Bandholtz
> *Sent:* Thursday, 05 November, 2009 09:32
> *To:* SKOS
> *Subject:* RE: Label management information in SKOS-XL (continuing from 
> UMTHES and SKOS-XL)
> 
> 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
Received on Monday, 9 November 2009 13:29:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:39:05 GMT