Re: SKOS properties

On 27 Apr 2007, at 12:03, Bernard Vatant wrote:

>
> Hi Stella
>
> Stella Dextre Clarke a écrit :
>> Sue Ellen,
>> Yes, I can see that treating antonyms as synonyms would not suit a  
>> terminology application at all. And even for thesaurus  
>> applications, it only works for *some* antonyms in *some*  
>> contexts. (For example the black/white and war/peace cases that  
>> have been mentioned look most  unlikely candidates.)
> I chose "black" and "white" for sake of simplicity, knowing they  
> are unlikely to appear as concepts in a thesaurus. But we seem to  
> all agree that antonyms deserve a special treat. And that a pair of  
> antonyms should be represented in SKOS as two different instances  
> of skos:Concept, right?
>> For a thesaurus manager, however, it is nice to be able to apply  
>> this treatment in selected cases. Can/should  SKOS try to meet all  
>> needs of all user groups?
> Maybe SKOS (core at least) should not, but RDF can, as Jakob wrote  
> this need could be dealt with a specific subproperty of skos:related
>
> skos:antonym      rdfs:subPropertyOf      skos:related
>
> If it's not defined in SKOS namespace, nothing prevents to declare  
> it in a specific extension defined by those who have this need
>
> my-skos-extension:antonym      rdfs:subPropertyOf      skos:related
>
> I've been playing with medical terminologies lately, and there is  
> this notion of "excludes" in ICD10. See http://www.icd10.ch/
> This is also a form a antagonist relationship, which could be  
> defined as subproperty of skos:related, maybe specific to ICD,  
> maybe reusable by other vocabularies.
>
> There is no difficulty to specify subproperties of skos:related in  
> RDF. The real question is to know if those specifications are of  
> enough general use to be integrated in SKOS core, or defined in  
> SKOS extensions, or left to the community of users to specify in  
> their own namespace. For antonyms and exclusions, I'm leaning  
> towards the second solution.

Defining the common relationships is one half of the task -- the  
other is ensuring that the interpretation of those relationships is  
consistent (e.g. broader is a transitive relation). Allowing  
community users to define their own extensions places an onus on them  
to enforce consistent, adding it to the core allows the imposition of  
more "global" constraints, but as Guus points out, potentially raises  
the bar to adoption/implementation.

	Sean

--
Sean Bechhofer
School of Computer Science
University of Manchester
sean.bechhofer@manchester.ac.uk
http://www.cs.manchester.ac.uk/people/bechhofer