W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2006

Re: altLabels in different langauges

From: Alistair Miles <a.j.miles@rl.ac.uk>
Date: Tue, 30 May 2006 16:19:32 +0100
Message-ID: <447C6284.3060805@rl.ac.uk>
To: public-esw-thes@w3.org

Hi all,

Food for thought ...

My current favourite solution to this problem is to go back to the 
idea of modelling types of note as classes. A single property (e.g. 
"skos:annotation") then links concepts to notes, and another single 
property (e.g. "skos:annotatesLiteral") can link a note to literals 
that are labels for some concept. E.g. ...

@prefix eg: <http://www.example.com/vocab#>.
@prefix skos: <http://www.w3.org/2004/02/skos/core#>.

eg:A a skos:Concept;
   skos:prefLabel "grinding house"@en;
   skos:altLabel "grinding mill"@en;
   skos:annotation _:aaa.

eg:B a skos:Concept;
   skos:prefLabel "grindery"@en;
   skos:altLabel "grinding mill"@en;
   skos:annotation _:aaa.

_:aaa a skos:ScopeNote;
   rdf:value "Use 'grinding house' for a place material is crushed and 
'grindery' for a place where metal objects are sharpened."@en;
   skos:annotatesLiteral "grinding mill"@en.

I also would favour dropping the use of rdf:value, and have different 
properties for alternate media type values of the annotation content, 
e.g. "skos:noteContentText" "skos:noteContentXHTML" 
"skos:noteContentMathML" "skos:noteContentSSML" etc.

This framework is then flexible enough to allow extension by 
refinement to achieve the translation and abbreviation requirements. 
E.g. a third party could declare ...

@prefix x: <http://www.example.com/skos-extensions#>.

x:TranslationNote a rdfs:Class;
   rdfs:subClassOf skos:Documentation.

x:translationSource a rdf:Property;
   rdfs:subPropertyOf skos:annotatesLiteral;
   rdfs:domain x:TranslationNote.

x:translationTarget a rdf:Property;
   rdfs:subPropertyOf skos:annotatesLiteral;
   rdfs:domain x:TranslationNote.

.. and use them as in e.g. ...

eg:C a skos:Concept;
   skos:prefLabel "peace"@en, "rust"@nl.
   skos:altLabel "repose"@en, "serenity"@en, "rusten"@nl, "sereniteit"@nl;
   skos:annotation [
     a x:TranslationNote;
     x:translationSource "repose"@en;
     x:translationTarget "rusten"@nl;
   skos:annotation [
     a x:TranslationNote;
     x:translationSource "serenity"@en;
     x:translationTarget "sereniteit"@nl;

A similar extension pattern could be used to capture abbreviation and 
acronym relationships.

Like I said, food for thought :)



Mark van Assem wrote:
> Hi Ron, Sue,
>> Thanks for a very nicely and succinctly worded summary of the issue in 
>> your previous message.
> :-)
>> alt-labels for a single concept in the first place.) So you are really 
>> no further ahead.
> You are probably right that in general my proposal is senseless. But on 
> a technical level this *is* a way out to be able to keep the assumption 
> that the different labels are translations of each other. It would only 
> work for thesauri one has under own control. It is not my *preferred* 
> solution (see below).
>> I agree with Susan's comment. There are things we should expect SKOS 
>> to do well (e.g. interoperability with Semantic Web applications), and 
>> there are things we should not expect SKOS to do (e.g. lossless 
>> transfer of multilingual thesaurus data as in Paul's case). Wisdom may 
>> consist of 
> That is why I would like to hear your views on the Change Proposal I 
> made [1]. I still do not understand what is against adding a class Term 
> and a property between skos:Concepts and skos:Terms to the schema so 
> that we are able to represent a bit more of the original thesaurus data. 
> For example, I understand that the people at FAO are developing a new 
> OWL model for AGROVOC in which they want to be able to relate terms to 
> each other. So they will probably end up with their own OWL schema next 
> to their port to SKOS. This does not seem to be the way we should be 
> headed.
> I acknowledge that the addition makes the model a bit more difficult, 
> but I am still in the dark as to why the trade-off should be in favour 
> of the more simple model with labels attached to skos:Concept.
>  > Wisdom may consist of knowing what you want to do and what tools you
>  > need to do it.
> I totally agree. But it would be unwise to *not* have a model that would 
> be able to handle more of the thesaurus data without much additional cost.
> I am not saying we should change SKOS now, but I am saying that we need 
> to explore this issue more deeply before the "definitive" SKOS is put 
> out into the world. Maybe some more experience with the current model 
> can help us finding out how the trade-off really lies.
> Cheers,
> Mark.
> [1]http://lists.w3.org/Archives/Public/public-esw-thes/2006May/0009

Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Oxfordshire OX11 0QX
United Kingdom
Web: http://purl.org/net/aliman
Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440
Received on Tuesday, 30 May 2006 15:20:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:30 UTC