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

Re: some thoughts about ISSUE 35 ConceptSchemeContainment

From: Guus Schreiber <schreiber@cs.vu.nl>
Date: Thu, 26 Jul 2007 13:15:42 +0200
Message-ID: <46A8825E.9080109@cs.vu.nl>
To: Bernard Vatant <bernard.vatant@mondeca.com>
CC: Antoine Isaac <aisaac@few.vu.nl>, SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>

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. 


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:44 UTC