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

UMTHES and SKOS-XL

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 21 Oct 2009 11:30:25 +0200
Message-ID: <4ADED4B1.4030902@few.vu.nl>
To: SKOS <public-esw-thes@w3.org>
Hi everyone,

I'm putting here a discussion we started with Thomas Brandholtz on UMTHES [1] on the use of SKOS-XL there (see slides at [2]). A long mail, but it can be interesting for a wider audience, as UMTHES is one of the first SKOS-XL implementations!

===

Dear Thomas,

So let's go. The main issue I have is that xl:Label is used in a very "term-oriented" way in UMTHES.
More precisely, I feel that you are using labels to aggregate lexical entities which which indeed are belonging to the same "term". But these literals be introduced as labels in basic SKOS, I think. Trying to use a concrete example from your slides:

:4711 rdf:type skos:Concept;
    skosxl:prefLabel :wasteWater.

:wasteWater rdf:type skosxl:Label;
    skosxl:literalForm "waste water";
    ext:lexicalVariant "wastewater";
    ext:compoundFrom (:waste :water).

"wastewater" is introduced as a lexical variant of "waste water". Per se, this is of course ok.
But in basic SKOS, I would have modelled that "wastewater" as a skos:altLabel or a skos:hiddenLabel of :4711. As not attaching that string to an instance of xl:Label using xl:literalForm prevents you from benefitting from the useful property chains given in XL. So I would have represented "wastewater" as an instance of xl:Label.

Of course, you may object that you can declare yourself a property chain (or property chains) that would allow to infer that the literals that are objects of ext:lexicalVariant triples (or the ones involving sub-properties of ext:lexicalVariant) are also objects of skos:hiddenLabel (or skos:altLabel) statements attached to the skos:Concept to which your xl:Label is attached.

But then I'd be still uncomfortable with an xl:Label giving raise to several (SKOS-basic) labels.
Additionally, we actually introduced xl:labelRelation to handle cases like acronyms [1]. In your approach, acronym is a subproperty of lexicalVariant, which is clearly a different pattern from ours.

As I feel it, your choice may be prefectly grounded in terminology. Still, I'd be curious to hear whether this is a strong position of yours, or if you could accomodate a different pattern.

Maybe there can be indeed a solution accomodating both points of view (if I interpreted one correctly, of course). Namely, introducing "wastewater" as the literalForm of an xl:Label which is not connected to any concept; just connected (by an ext:lexicalVariant which would be then a sub-property of xl:labelRelation) to :wasteWater.

Of course you can say then that the distinction between "waste water" and "wastewater" is something very important for your UMTHES and the applications you envision with it, and that "wastewater" should never be used as a basic concept label, even a hidden one. Or not even interpreted as something that could be a label...

You can also argue that the xl:Label story is quite thin in the SKOS Reference anyway, and that you can use that class as a purely technical hook for any purpose. That's indeed not far from being the truth, and if all are rightfully motivated, well, I guess we can have several ways of handling a relation such as acronymy co-exist.
But well, having one of the first XL deployments departing from the meager guidelines we had put in the Reference would not be a great sign for us :-/


Apart from this issue of ext:literalVariant and its sub-properties, I found the rest really good, confirming my first enthusiastic reaction after your talk :-)

Two comments/questions, maybe:

1. Are you planning to add the language tag that seem to be missing on some slides (e.g. for the ext:inflection objects) in the real data?

2. Intuitively, I feel that the definition of :NonPreferredTerm (on slide 33) is too strong. I would have said that everything that is related via xl:altLabel to a concept cannot be a PreferredTerm. Otherwise there would be a conflict with the inferred basic SKOS labelling triples [2]. So the complementOf axiom would not be really needed. But again, it's late, and I prefer to send this mail rather than letting you wait more time for my answer... 

Cheers,

Antoine

[1] http://www.w3.org/2006/07/SWD/track/issues/215
[2] http://eea.eionet.europa.eu/Public/irc/envirowindows/jad/library?l=/ecoinformatics_indicator/ecoterm_5-6102009/ecoterm09-bandholtzppt/_EN_1.0_&a=d
Received on Wednesday, 21 October 2009 09:30:55 GMT

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