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

Hi all,

I wrote this up a while ago but didn't send it out because it seemed half baked, and I presumed the RDFTM task force would get to it anyway, and I also didn't think I should send something like this out without having read all the RDFTM documents which I haven't had time to do yet ...

... but it seems relevant to current discussion, so here it is in half baked form fwiw:

---
Modelling Published Subjects in RDF

Let's say I want to refer unambiguously to the eiffel tower.  To do this via the published subjects methodology, I would first create a document that describes the eiffel tower, perhaps with some prose, some pictures and so forth.  Then, I publish this document on the world wide web.  In published subjects terminology, the eiffel tower is the subject of this document, and, because it describes one and only one subject, the document is a subject indicator.

I can now use the URL (sic) of this document to refer unambiguously (via a layer of indirection) to the subject in question (i.e. the eiffel tower).  In other words, I can now point to 'the thing indicated by the document with URL x'.  In published subjects terminology, this layer of indirection is hidden by allowing you to point to 'the thing with subject identifier x'.    

To model the above system in RDF, we must describe two distinct resources: (1) the eiffel tower itself, and (2) a document describing the eiffel tower.  We can then assert a single RDF statement describing the relationship between the two resources, for which purpose we require an RDF predicate (property) that captures the essence of the relationship between a subject indicator and its subject.  

Let us assume that such a predicate has been defined, and is called 'http://www.example.org/predicates#subjectIndicator'.  Let us also assume that (2) has the URI 'http://www.example.org/theEiffelTower'.  

Then, an RDF/XML serialisation of this single statement could be written as:

---
<rdf:RDF 
	xmlns:rdf="" 
	xmlns:ex="http://www.example.org/predicates#">

	<rdf:Description>
		<ex:subjectIndicator rdf:resource="http://www.example.org/theEiffelTower"/>
	</rdf:Description>

</rdf:RDF>
---

A notation 3 serialisation of this same statement is:

---
@prefix rdf: <> .
@prefix ex: <http://www.example.org/predicates#> .

[] ex:subjectIndicator <http://www.example.org/theEiffelTower> .
---

Note that the resource (1) is modelled as a blank node (bnode) in the RDF graph. 

Because a subject indicator describes one and only one subject, the predicate used in the above example can be declared to be an inverse functional property (IFP).  If this has been declared, then if any two nodes in an RDF graph have the same value for this property, they are inferred to be the same resource.

For example, given the trivial graph corresponding to the following serialisation, the blank node A is inferred to be identical to the blank node B:

---
<rdf:RDF 
	xmlns:rdf="" 
	xmlns:ex="http://www.example.org/predicates#">

	<rdf:Description rdf:nodeID="A">
		<ex:subjectIndicator rdf:resource="http://www.example.org/theEiffelTower"/>
	</rdf:Description>

	<rdf:Description rdf:nodeID="B">
		<ex:subjectIndicator rdf:resource="http://www.example.org/theEiffelTower"/>
	</rdf:Description>

</rdf:RDF>
---

In fact, just such a predicate has already been defined, as part of the SKOS Core Vocabulary (see http://www.w3.org/2004/02/skos/core/guide/#secpsi).

This analysis has a bearing on the use of HTTP URIs as subject identifiers.  In the pubsub methodology HTTP URIs are only ever allocated to subject indicator documents.  The notion of a subject identifier hides a layer of indirection, as has been described above.  Therefore, you are quite free to use a slash HTTP URI as a subject identifier without questioning the principle that such URIs necessarily denote information objects.  I.e. hash vs. slash does not apply.

This analysis also has a bearing on the proper mapping of knowledge representation structures between Topic Maps and RDF.
 
The XML Topic Maps (XTM) specification allows topics to be merged based on the following principles:

(i) If the subject of a topic (i.e. the thing that topic represents) is an information resource, then the identity of two topics may be established via the URL (sic) of that information resource.  

(ii) If the subject of the topic is not an information resource, then the identity of two topics may be established via the URL (sic) of a subject indicator document.

However, there is a problem to consider when mapping from RDF to topic maps.  To illustrate this problem, and to avoid any confusion surrounding existing URI schemes, let us assume that there exists some URI scheme called 'foo:'.  Ownership of parts of this URI space may be obtained by simply applying in writing to the Foo organisation, which then gives you (free of charge) a part of this space corresponding to a unique number.  For example, I applied to Foo inc. and got ownership of the URI space foo:00789:.  So now I am free to coin URIs like foo:00789:bar foo:00789:bar/blah etc. and allocate them to whatever I want.  I have a pet hamster called Gerald, whom I would especially like to be able to make RDF statements about, so I allocate the URI foo:00789:gerald-the-hamster to him.  This scenario is completely consistent with the webarch as I understand it.

So, then, how would I translate the following RDF graph:

<rdf:RDF>

	<ex:Hamster rdf:about="foo:001789:gerald-the-hamster">
		<foaf:name>Gerald</foaf:name>
	</ex:Hamster>

</rdf:RDF>        

... into an XML topic map?  The URI 'foo:001789:gerald-the-hamster' certainly doesn't 'locate' Gerald, so I can't use the xtm:subjectLocator element.  Niether does this URI correspond to a published subject indicator document, so I can't use the xtm:subjectIndicator element.

So isn't it correct to say that Subject identity in topic maps is restricted to the subset of URI space that is URL space, because it depends on subjects being either 'locatable' in themselves, or having a 'locatable' subject indicator document?

RDF does not require that a resource be either 'locatable', or have a 'locatable' subject indicator document.  Resources may be directly identified via any type of URI, which obviously includes non-URL URIs.  This does not affect TM -> RDF mapping (because URL space is a subset of URI space), but presents problems for RDF -> TM mapping.  The identity of resources with non-URL URIs, or with no URI but whose identity is normally established in RDF via an IFP (such as a foaf:Person), cannot currently be translated into topic maps.

Recently I had the idea that the relationship between a subject indicator document and its subject should be modelled in TM as an *association* between two topics, which is somehow an inverse-functional association.  I'll try and draw this idea in a diagram soon, it's hard to explain in prose ... that'll have to do for now (sorry).

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:30:50 UTC