- From: Bernard Vatant <bernard.vatant@mondeca.com>
- Date: Mon, 2 May 2005 13:01:32 +0200
- To: <public-esw-thes@w3.org>
- Cc: "tm-pubsubj" <tm-pubsubj@lists.oasis-open.org>
Oops, in my previous message I have completely confused http://www.w3.org/2004/02/skos/core#Concept http://www.w3.org/2004/02/skos/core/spec/#Concept ... it figures 1. I should not start by such conceptual things on Monday morning 2. I should read more carefully 3. I should have followed more closely the recent debates over core and spec Anyway, starting now from those correct premises, all remarks about recursive use of subjectIndicator seem irrelevant at first glance, since URIs are distinct: core:foo skos:subjectIndicator spec:foo But in a topic map environment, it is likely to be interpreted as two URIs identifying the same subject anyway. The subject indicator at http://www.w3.org/2004/02/skos/core/spec/#foo says to use the URI http://www.w3.org/2004/02/skos/core#foo But if you read closely the Published Subjects recommendation, the URI of a subject indicator is considered as an identifier for the subject it indicates/identifies. So http://www.w3.org/2004/02/skos/core/spec/#foo is an identifier of http://www.w3.org/2004/02/skos/core#foo IOW, the following topics should be merged by a topic map application <topic id="foo-core"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.w3.org/2004/02/skos/core#foo"/> </subjectIdentity> </topic> <topic id="foo-spec"> <subjectIdentity> <subjectIndicatorRef xlink:href="http://www.w3.org/2004/02/skos/core/spec/#foo"/> </subjectIdentity> </topic> So the real issue is : why do we need different URIs, since http://www.w3.org/2004/02/skos/core#foo could directly point to the subject indicator ... Bernard > -----Message d'origine----- > De : public-esw-thes-request@w3.org > [mailto:public-esw-thes-request@w3.org]De la part de Bernard Vatant > Envoyé : lundi 2 mai 2005 11:03 > À : public-esw-thes@w3.org > Cc : tm-pubsubj > Objet : Subject Indicators RE: Using SKOS RDF vocabulary in RDFS > > > > > 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 11:01:52 UTC