W3C home > Mailing lists > Public > public-esw-thes@w3.org > May 2005

Confused ... RE: Subject Indicators RE: Using SKOS RDF vocabulary in RDFS

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>
Message-ID: <GOEIKOOAMJONEFCANOKCKELNFPAA.bernard.vatant@mondeca.com>

Oops, in my previous message I have completely confused


... 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

IOW, the following topics should be merged by a topic map application

<topic id="foo-core">

<topic id="foo-spec">

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 ...


> -----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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:19 UTC