Re: some thoughts about ISSUE 35 ConceptSchemeContainment

Bernard Vatant wrote:
> 
> I second Antoine on this.
> 
> Although I have been wondering about the subtle differences between 
> using ConceptScheme vs subClassOf Concept, there is at least one feature 
> of ConceptScheme which I would not give up, it's hasTopConcept. 
> Actually, the inScheme declarations are useless/redundant if you 
> consider the narrower property to be internal to a ConceptScheme, in 
> which case the containment in a ConceptScheme can be entailed from the 
> hasTopConcept declaration(s). A ConceptScheme "contains" all its 
> declared top concepts and their descendants in the broader-narrower 
> hierarchy.

Bernard, Antoine,

My main point was about the problems with skos:inScheme,  I can live with skos:ConceptScheme an skos:hasTopConcept. 

Guus

> 
> Bernard
> 
> 
> Antoine Isaac a écrit :
>>
>> 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
>>>
>>>
>>>
>>
>>
>>
> 

-- 
Vrije Universiteit Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
T: +31 20 598 7739/7718; F: +31 84 712 1446 
Home page: http://www.cs.vu.nl/~guus/

Received on Thursday, 26 July 2007 11:16:11 UTC