Re: altLabels in different langauges

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 :)

Cheers,

Al.

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
Chilton
Didcot
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