Re: some thoughts about ISSUE 35 ConceptSchemeContainment

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.

2. owl:imports defines importing on an ontology basis: if you want to 
import just some concepts and/or if you want to change the links between 
them to have your own view on the domain, you're going into a mess

3. as I already mentioned discussing with Alistair on using complex 
algorithms to handle his solution for concept grouping, I disapprove of 
all that could make one user's life a hell. And I think relying on 
querying (vs. explicit representation) for accessing all kind of needed 
information harms the use of the model. Take the example of the RDFS 
query engines that have implemented a predicate like "directSubClassOf" 
to access direct link between classes (which you can do by making your 
query just a little bit more comple) : there must be a reason...

4. finally I'm sceptical about the use of namespaces or RDF-based 
solutions for provenance/trust (like quadruples or named graphs) to 
handle concept scheme information. To me these are based on knowledge 
source (that we trust or not, etc.) and I think there is no bijection 
between a knowledge source and a concept scheme: a same source could 
provide information about several concept schemes and different 
(trusted) sources could contribute to define a same scheme. I don't say 
that's impossible, I just want to warn that this call for thinking about 
different cases and solutions, as well as writing pages of guidelines 
that we might not have the time for.

Also, I think this mail shall definitevely forwarded to the SKOS mailing 
list, which could give us very interesting comments on this idea of 
dropping concept scheme information

Antoine

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 07:04:49 UTC