W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2004

Re: What if two resources are the same subject?

From: Thomas B. Passin <tpassin@comcast.net>
Date: Tue, 13 Apr 2004 14:51:54 -0400
Message-ID: <407C36CA.9050509@comcast.net>
To: "www-rdf-interest@w3.org" <www-rdf-interest@w3.org>

Jan Algermissen wrote:

>>Well there is only one resource, but multiple URIs, 
> Ah, that I did not know. So resources may 'span across authorities', yes?
> A single resource can live on different hosts controlled by different
> authorities, yes?
> (I expect the REST camp to scream but if they agree, too, so much the better) 

You want to remember that the URI as used in an RDF statement is NOT 
being used as a REST-like GET-able representation.  It is purely an 
identifier.  What does it identify?  Ah, there's the rub.  IF it 
resolves to a retrievable resource, you could apply the convention that 
the resource "should" say cogent things about the thing identified by 
the URI.  In that case, the retrievable URL would be acting like a PSI. 
  However, this is only a convention.

There is no mandated way in which an RDF resource identified by 
"http://www.some.org/countries/canada>" can be established as (or as 
not) the same resource as the one identified by 
"http://another.org/public/countries/Canada ", other than by the OWL 
statement just posted by Nowack (and that is OWL, not RDF - i.e., a 
plain vanilla RDF processor would not know to do anythng special with 
such a statement).

You might be able to discover the equivalency of the resources by the 
various properties of the two resources, if they they were identifying 
(another OWL-but-not-RDF notion) properties (e.g., inverse functional).

Otherwise, it is like merging topics in a topic map.  If  two topics 
happen to match one of the rules for merging, you know they should 
merge, otherwise, you have to get clever and hope to pick up on the 
equivalency.  Except that, in RDF, there are no built-in rules about it.


Tom P
Received on Tuesday, 13 April 2004 14:48:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:49 UTC