- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Mon, 2 May 2005 11:03:07 +0200
- To: <public-esw-thes@w3.org>
- Cc: "tm-pubsubj" <tm-pubsubj@lists.oasis-open.org>
Hello Dean, and all > We have been looking into using the SKOS RDF vocabulary > (http://www.w3.org/2004/02/skos/core.rdf) with RDFS-enabled tools, and > have found some anomalies that make it difficult to understand how SKOS > is intended to be used. In particular, we have loaded the vocabulary > into SWOOP, Protege and RDF Gateway. When we first did this, we thought > we must have found bugs in these tools, because of the strange results > that we got. But when we looked into core.rdf, it seems that these > things are part of SKOS itself. Sure they are. I had not looked at SKOS in SWOOP before, I just did, and indeed some things look weird. > <rdfs:Class rdf:ID="Concept"> > <rdfs:label xml:lang="en">Concept</rdfs:label> > ... > <skos:subjectIndicator > rdf:resource="http://www.w3.org/2004/02/skos/core/spec/#Concept"/> > ... > </rdfs:Class> This recursive use of subjectIndicator is certainly not a good idea, neither for this element, nor other ones in the whole specification. The information carried is that the URI http://www.w3.org/2004/02/skos/core/spec/#Concept provides a definition of the resource it defines. At best, it is tautological. Seems to me that the property skos:subjectIndicator should not use as declared value the URI of its subject, that is any declaration. a:foo skos:subjectIndicator a:foo should be avoided Reminder : the intended use of subjectIndicator is providing documentation of vocabularies, such as a:foo skos:subjectIndicator b:bar Where b:bar can be dereferenced to provide a human-readable resource indicating the subject, according to http://www.oasis-open.org/committees/download.php/3050/pubsubj-pt1-1.02-cs.pdf (which BTW is the official OASIS Published Subjects recommendation, and should replace the reference to the older draft http://www.oasis-open.org/committees/tm-pubsubj/docs/recommendations/general.htm in the SKOS document) "A subject indicator is an information resource which provides some kind of compelling and unambiguous indication of the identity of a subject to humans. It may be a textual definition, description or name; it may be a visual, audio or other representation of the subject; or it may be some combination of these. A subject indicator is distinct from the subject that it indicates." Certainly http://www.w3.org/2004/02/skos/core/spec/#Concept is conformant to the above definition *if used from an external vocabulary*. myDomain:Concept skos:subjectIndicator skos:Concept Topic map reading of the latter being that myDomain:Concept and skos:Concept, or at least their URIs define/identify the same subject, so the difference with the following is very subtle: myDomain:Concept owl:equivalentClass skos:Concept or even worse: myDomain:Concept owl:sameAs skos:Concept since in topic map land, everything is a topic (read in OWL : everything is an individual) But clearly, the recursive declaration skos:Concept skos:subjectIndicator skos:Concept seems to be inconsistent with : "A subject indicator is distinct from the subject that it indicates". Moreover, in this triple, skos:Concept is implicitly understood when subject of the triple as an abstract resource (Concept as owl:Class), and when object of the triple, as the information resource describing this abstract resource for humans (the table in the spec document). Web identity crisis strikes again. See http://www.ontopia.net/topicmaps/materials/identitycrisis.html Adding to the logical mess is certainly the following skos:subjectIndicator rdfs:range foaf:Document ... since it entails, along with skos:Concept skos:subjectIndicator skos:Concept the following triple skos:Concept rdf:type foaf:Document ... which is indeed very bizarre Now the real issue is "who cares?". Seems unlikely that any (useful) inference will ever be done on the core vocabulary itself, except for the above academic exercise. Inference will be done inside and across vocabularies, for query of relevant indexed resources, vocabulary mapping, semantic extension/restriction of search etc ... At that level, will the above logical oddities be really a problem? Cheers Bernard ********************************************************************************** Bernard Vatant Senior Consultant Knowledge Engineering bernard.vatant@mondeca.com "Making Sense of Content" : http://www.mondeca.com "Everything is a Subject" : http://universimmedia.blogspot.com **********************************************************************************
Received on Monday, 2 May 2005 09:03:27 UTC