Re: Preferred terms

On Mon, Oct 13, 2008 at 10:34:29AM +0200, Antoine Isaac wrote:
>
> Hi Sean,
>
>> I note, however, that this is not explicitly stated in our user  
>> requirements
> Do you mean, in the SKOS use case and requirements document? If yes, we  
> can consider it to be hidden in R-CompatibilityWithISO2788 . Thesaurus  
> guidelines provided with the main motivation for the uniqueness of  
> prefLabels...
> But actually I would consider that the intuitive semantics of  
> "preferred" should be enough. If you use some sources which make you not  
> able to distinguish a specific label, then it is quite worthless to fake  
> having a "preference".

Yes, I agree, I think the intuitive semantics of "preferred" should be enough. 

Note that given the graph

<foo> skos:prefLabel "bar"@en, "baz"@en .

an application can determine that this graph is not consistent with
the SKOS data model. But what the application does next is entirely up
to the application. I.e. whether the application reports an error to
the user, does nothing, or collapses in a heap is not defined in the
SKOS Reference. Therefore I don't see how the constraint on
skos:prefLabel will "break" applications merging data in a
distributed, open world. Handling such scenarios is up to the
application.

SKOS will have a wide diversity of implementing applications, which
are designed to meet a variety of needs. I think the SKOS Reference
would be going too far if it attempted to define how all applications
should behave under certain circumstances. What the SKOS Reference
does is define the SKOS data model. Communities can use the SKOS data
model to define agreements and operating procedures that are
appropriate to their needs. For example, I would expect many
communities to use the notion of consistency with the SKOS data model
as a baseline for interoperability, and therefore to implement or use
tools which report inconsistencies with the SKOS data model. However,
as I said above, the SKOS Reference does not mandate that all
applications handling SKOS must do so. It does not mandate any
application behaviour at all.

Does that make sense?

Cheers,

Alistair.
 

>
> Note that maybe the cases mentioned by Al could be solved by appropriate  
> use of custom language tags to distinguish between different "flavors of  
> language" used by the different systems.
> Something like
> my:un skos:prefLabel "United Nations"@en-x-system1 ; skos:prefLabel  
> "UN"@en-x-system2
> That's tricky, but I believe the scenario Al mentions are also a bit  
> tricky, too.
>
> Antoine
>
> [1] http://www.w3.org/TR/skos-ucr#R-CompatibilityWithISO2788
>
>>
>>
>> ISSUE-179 raises a question about our definition of preferred and  
>> alternate terms (labels), in particular whether multiple preferred  
>> terms are allowed. I was under the impression that the convention in  
>> thesauri was that concepts had at most one preferred term, leading to  
>> the constraint. The notion of "preferred", to me at least suggests a  
>> singleton. I note, however, that this is not explicitly stated in our  
>> user requirements. Can anyone provide links to concrete rationale or  
>> existing standards where this is discussed?
>>
>> Thanks,
>>
>>     Sean
>>
>> -- 
>> Sean Bechhofer
>> School of Computer Science
>> University of Manchester
>> sean.bechhofer@manchester.ac.uk
>> http://www.cs.manchester.ac.uk/people/bechhofer
>>
>>
>>
>>
>>
>
>
>

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

Received on Tuesday, 14 October 2008 11:20:34 UTC