- From: Guus Schreiber <schreiber@cs.vu.nl>
- Date: Thu, 26 Jul 2007 13:15:42 +0200
- 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. 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:08 UTC