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

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

From: Miles, AJ \(Alistair\) <A.J.Miles@rl.ac.uk>
Date: Tue, 3 May 2005 14:10:01 +0100
Message-ID: <F5839D944C66C049BDB45F4C1E3DF89D18DCB4@exchange31.fed.cclrc.ac.uk>
To: <public-esw-thes@w3.org>

Hiya,

I propose to remove all statements involving the skos:subjectIndicator property *as predicate* from the SKOS Core Vocabulary itself for now, until we understand this issue better.

Cheers,

Al.

---
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440



> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Bernard Vatant
> Sent: 02 May 2005 12:02
> To: public-esw-thes@w3.org
> Cc: tm-pubsubj
> Subject: Confused ... RE: Subject Indicators RE: Using SKOS RDF
> vocabulary in RDFS
> 
> 
> 
> 
> 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/recommend
> ations/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 Tuesday, 3 May 2005 13:10:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:53 GMT