OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

	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

(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

	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

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?




Bernard Vatant
Senior Consultant
Knowledge Engineering

"Making Sense of Content" :  http://www.mondeca.com
"Everything is a Subject" :  http://universimmedia.blogspot.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]