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

Re: Mistaken identity?

From: Jon Hanna <jon@hackcraft.net>
Date: Thu, 24 Jun 2004 01:46:40 +0100
Message-ID: <1088038000.40da247051115@>
To: "www-rdf-interest@w3.org" <www-rdf-interest@w3.org>

Quoting "Thomas B. Passin" <tpassin@comcast.net>:

> Jon Hanna wrote:
> > I read that as good separation between specs.
> > 
> > 1. URIs provide a way to identify resources.
> > 2. HTTP provides a way to GET or PUT representations of resources, or POST
> > represetations into them.
> > 3. RDF provides a way to describe relationships between resources
> identified by
> > URIs, or between resources and literals.
> Well, 1) and 3) go together nicely.  It's just 2) that is the odd man 
> out.  A lot of people would like to have a retrievable URI denote the 
> thing that gets retrieved, or at least the resource of which the 
> retrieved thing is a representation.  Trouble is, it leads to so many 
> problems that no one has convinced many others that they know how to 
> make it work.
> For example, given a retrievable URI -
> A. Does it denote i) the URI string itself, ii) the resource whose 
> representation gets retrieved, or iii) one of the representations (and 
> if so, which one?)?


> B. If you picked ii) or iii), how do you talk about the URI string itself?

iii. It's a literal string, just as "hello world" is. <http://example.net/> is
the resource, "http://example.net/" is the URI.

> C. How do you know which URIs are supposed to be treated one way - as 
> denoting the resource they point to - and which the other, given that 
> actual sites go up and down, change, domains get bought and sold, etc.?

They're all identifiers identifying resources. That's why they're called
*Resource Identifiers*.

> D. If you picked A.ii or A.iii, what is supposed to happen when the 
> resource itself changes its state, which may mean gets completely 
> changed or replaced?

The representation should of course change to reflect that. Similarly RDF
documents describing the resource should change to reflect that.

> These are not trivial questions to answer.  Maybe we will eventually get 
> a convergence on a solid and reliable convention about the issue, but 
> until we do, what can we do except to go along with what the current RDF 
> Rec(s) say?

If you are using a URI with both RDF and HTTP then you need to answer it. Acting
in accordance my position seems to be the safest approach; either I will be
shown to be correct in time - and you really must have the same resource
represented and described, or you will - and it won't hurt to have the same
resource represented and described.

> &rdf;type and &rdfs;label seem like pretty good identifiers to me, and 
> they don't have to be retrievable - and if they were, they would not 
> denote the retrieved thing.

There is no fragment identifier within the document obtained from
http://www.w3.org/1999/02/22-rdf-syntax-ns, though I seem to remember that
rdf:ID was once used there (there were still issues in treating that as a
fragment identifier). Still at least dereferencing
http://www.w3.org/1999/02/22-rdf-syntax-ns will tell me that:

<rdf:type> <rdf:type> <rdf:Property> .
<rdf:type> <rdfs:isDefinedBy> <rdf:> .
<rdf:type> <rdfs:label> "type" .
<rdf:type> <rdfs:comment> "The subject is an instance of a class." .
<rdf:type> <rdfs:range> <rdfs:Class> .
<rdf:type> <rdfs:domain> <rdfs:Resource> .

And dereferencing http://www.w3.org/2000/01/rdf-schema will tell me that:

<rdfs:label> <rdf:type> <rdf:Property> .
<rdfs:label> <rdfs:isDefinedBy> <rdfs:> .
<rdfs:label> <rdfs:label> "label" .
<rdfs:label> <rdfs:comment> "A human-readable name for the subject." .
<rdfs:label> <rdfs:domain> <rdfs:Resource> .
<rdfs:label> <rdfs:range> <rdfs:Literal> .

So not perfect by my view of what should be done here (I would tend against
using # to end RDF namespaces anyway) but not bad either.

Jon Hanna
"…it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt
Received on Wednesday, 23 June 2004 20:46:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:51 UTC