W3C home > Mailing lists > Public > public-swd-wg@w3.org > July 2007

Re: some thoughts about ISSUE 35 ConceptSchemeContainment

From: Daniel Rubin <rubin@med.stanford.edu>
Date: Thu, 26 Jul 2007 11:40:13 -0700
Message-Id: <6.2.5.6.2.20070726113315.04b58368@med.stanford.edu>
To: Antoine Isaac <aisaac@few.vu.nl>,
Cc: Guus Schreiber <schreiber@cs.vu.nl>,SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>

Hi
See below:

At 12:04 AM 7/26/2007, Antoine Isaac wrote:

>Hello,
>
>I'm sorry for being picky once again, but I 
>disapprove of almost all this, mainly for useability reasons:
>
>1. using owl:ontology as a substitute for 
>skos:ConceptScheme is dangerous, because people 
>will confuse concepts with class even more than 
>what is now. We'll need to document this 
>extensively, possibly using the idea of ConceptScheme again, so I'm worried.

I must admit, I still find it confusing that skos 
differentiates concepts from classes, and I 
suspect others in the community share the 
confusion, or in the least, will use skos inconsistently in this regard.

Daniel

>Daniel Rubin a écrit :
>>
>>I second this
>>
>>At 12:59 PM 7/25/2007, Guus Schreiber wrote:
>>
>>>Issue description: http://www.w3.org/2006/07/SWD/track/issues/36
>>>
>>>Synopsis of the issue: SKOS provides a 
>>>mechanism to indicate that a concept is 
>>>contained in a concept scheme (the property 
>>>skos:inScheme), but it is nontrivial to define 
>>>such containment for relation between concepts (e.g. broader/narrower).
>>>
>>>The whole notion of containment in a thorny 
>>>one in a Semantic Web setting. Note that OWL 
>>>ontologies do not have a language construct 
>>>for this. It is understandable that some way 
>>>of saying that "these elements are part of my 
>>>vocabulary" is useful for vocabulary owners. 
>>>However, it is doubtful whether we can try to 
>>>solve this at the level of SKOS. The reasons 
>>>for wanting to define containment typically 
>>>have to do with issues such as trust and 
>>>rights. In my view such mechanisms should be 
>>>provided at the general RDF level. We 
>>>shouldn't try to solve this issue with a special-purpose construct in SKOS.
>>>
>>>I therefore propose to deprecate the property skos:inScheme.
>>>
>>>I suggest to include in our documents 
>>>guidelines for how to handle containment 
>>>issues, e.g. by making using of 
>>>rdf:isDefinedBy or by relying on through guidelines for querying.
>>>
>>>I could also go one step further and propose 
>>>to drop also the class skos:ConceptScheme and 
>>>the property skos:hasTopConcept. Instead of 
>>>skos:ConceptScheme SKOS users could just use 
>>>the OWL construct owl:Ontology, which also 
>>>provides an import construct (owl:import). 
>>>Finding the top concepts could just be handled 
>>>at the query level. However, 
>>>skos:ConceptScheme (and skos:hasTopCncept) 
>>>could be just viewed as a useful documentation vehicle.
>>>
>>>Guus
>>
>>
>
Received on Thursday, 26 July 2007 18:40:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:17:29 GMT