Re: some thoughts about ISSUE 35 ConceptSchemeContainment

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 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
>>
>>
>>
>
>
>

-- 

*Bernard Vatant
*Knowledge Engineering
----------------------------------------------------
*Mondeca**
*3, cité Nollez 75018 Paris France
Web:    www.mondeca.com <http://www.mondeca.com>
----------------------------------------------------
Tel:       +33 (0) 871 488 459
Mail:     bernard.vatant@mondeca.com <mailto:bernard.vatant@mondeca.com>
Blog:    Leçons de Choses <http://mondeca.wordpress.com/>

Received on Thursday, 26 July 2007 10:41:38 UTC