Re: UMTHES and SKOS-XL

Ah yes. We discovered a similar problem during work on BS 8723. It was 
about whether to introduce a specialisation of USE/UF to cater for 
abbreviations/acronyms and their expansions, for which you might use 
tags such as AB/FT. A problem arises when the abbreviation is short for 
another non-preferred term rather than the preferred term.
(For example, the preferred term "Information and communication 
technology" can have non-preferred terms "Information technology", "IT" 
and "ICT")
It becomes apparent that the proposed specialisation is not really a 
type of USE/UF. It is an inter-term relationship that can sometimes 
apply between non-preferred terms. Obviously it is possible to find a 
way of representing this accurately, but at the expense of making the 
whole model more complicated and the tagging conventions more cumbersome.

My personal view on this is that if you try to add more value in the 
shape of lexical/terminological information, you lose the virtue of 
simplicity. To put it another way, if you have mixed objectives (trying 
to achieve  terminological objectives as well as enabling information 
retrieval) these tend to detract from each other.

Cheers
Stella

*****************************************************
Stella Dextre Clarke
Information Consultant
Luke House, West Hendred, Wantage, OX12 8RR, UK
Tel: 01235-833-298
Fax: 01235-863-298
stella@lukehouse.org
*****************************************************


Antoine Isaac wrote:
> 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 10:17:16 UTC