- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Thu, 26 Jul 2007 09:04:46 +0200
- To: Daniel Rubin <dlrubin@stanford.edu>
- CC: Guus Schreiber <schreiber@cs.vu.nl>, SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>
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