RE: URN as namespace URI for RDF Schema (run away... run away... ;-)

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext 
> Richard Newman
> Sent: 07 October, 2004 01:33
> To: Stephen Rhoads
> Cc: RDF interest group
> Subject: Re: URN as namespace URI for RDF Schema (run away... run
> away... ;-)
> 
> 
> 
> Stephen,
>    This idea (a) hasn't been heavily thought-through (having 
> pretty much 
> just jumped into my head), and (b) might have already been suggested, 
> but I'll throw it in anyway.

This seems to sync pretty closely, if not perfectly, with
the comments I presented in

http://lists.w3.org/Archives/Public/www-rdf-interest/2004Oct/0075.html

(sorry, didn't see your post before I replied myself)

>    How about using redirects? The problem is the overloaded 
> use of one 
> URI for several things: the returned representation, and the concept 
> itself. 

I think it's better to say that overloading of URIs is
a potential problem, not a definite problem. By employing
good practices and having a general understanding of both
the principle of URI opacity and the separation of
resource from representation inherent in the web architecture,
such overloading need not be a widespread problem. 

Also, the overloading of a single URI to denote multiple
resources is not (necessarily) due to the choice of URI,
but to misunderstanding, carelessness, or even honest
error on the part of users because they (too often)
equate the resource denoted by a URI with what they GET
back in their browser.

That's an understandable mistake for a typical web user
to make, but less acceptable for a software engineer
building web applications, who should pay attention to
the specs and have a handle on the core principles
(which is why AWWW is so important and why it's crucial
that that document "get it right").

> In this case, it's actually for two representations 
> as well as 
> the concept. What we really want is to ask for a 
> representation of the 
> concept, and get back a suitable one, in such a way that each 'thing' 
> is distinctly identified.

Right.

And the HTTP spec already provides for this, in that, if the
entity returned in a response is not the same resource as
identified in the request, the server should provide a distinct
URI for the returned entity in the response header. 

Thus, it may be that in most cases, the facts are clear, but
users (or tools) just don't pay sufficient attention and
(re)use the URI of a previous request for a new request
when they should be using a distinct, different URI provided in 
the response to the previous request.

>    It strikes me that if I ask for <http://example.com/Stephen>, 
> accepting RDF (or with an MGET), then I should be redirected to 
> <http://example.com/Stephen/RDF>; 

Well, a URIQA implementation may utilize redirection, and even
content negotiation, when responding to an MGET request, but that 
is up to the implementation. The requesting agent should not presume
the use of either.

But yes, the description of the resource would be a distinct
resource in its own right and need to be denoted by a distinct
URI if one were to refer to it.

(and yes, that includes a description of a description of a ...)

> if I hit it with a standard GET, I 
> should be redirected to <http://example.com/Stephen/image.jpg>. These 
> are two separate, unambiguous resources; indeed, they could 
> be formally 
> related to the concept:
> 
> ex:Stephen ex:rdfRep <http://example.com/Stephen/RDF> ;
>             ex:hrRep <http://example.com/Stephen/image.jpg> .
> (or somesuch).

And that knowledge could be available in the descriptions
provided in response to URIQA request.

>    So statements about the concept point to one URI, statements about 
> the image use the image URL, and statements about the RDF graph point 
> to the RDF. 

Yep.

> The base URI isn't itself dereferenceable (by 
> which I mean 
> a representation is returned for that URI*), but conditionally 
> redirects to resources which are, in such a way that it is understood 
> by clients. 

I don't think it's fair to say that a URI which, when 
dereferenced results in a redirction, is not dereferencable
or has no representation. If a GET request per that URI
successfully results in the requesting client obtaining
a representation, albeit via a few redirections, then
that URI is dereferencable, and the representation obtained
is a representation of the resource denoted by the original
request URI.

> This last bit I see as a stumbling block - how do they 
> handle the fact that they've got back a different resource?

The requesting client is not getting back a resource. It
is getting back a representation. And a given representation
can serve as the representation of more than one resource.

A representation can also be the representation of itself. 

I.e. a representation is the atomic component of the web, and
corresponds to a octet stream returned in the response to a
request. If the request URI denotes a representation, then
the representation returned is a representation of that
representation (resource) denoted by the request URI, and
thus the representation of a representation is always a 
bit-equal copy of itself.

So, the representation of a chair may be an binary encoded
image of the chair, yet that image is also a resource, and 
its representation is itself. Thus, the same representation
is the representation of two resources: the chair, and the
image (itself) and thus two GET requests with distinct 
request URIs denoting distinct resources can both return
the very same representation.

And, insofar as the semantics of the web machinery is
concerned, even when one gets back a representation of
a representation (such that one could fairly conclude
that one has gotten back the actual resource) one has
not actually gotten back the resource, only its 
representation.   

(hope that doesn't make your head hurt ;-)

>    It's late, so apologies if this makes no sense at all!

It made perfect sense.

> * Though I suppose that the statements about the base URI could be 
> returned by an MGET... a difference between accepting 
> application/rdf+xml and MGET?

Well, to make a point I've made frequently, and which is
discussed in the URIQA spec, content negotation is not a
suitable mechanism for capturing the semantics of URIQA
requests. Have a look at http://swdev.nokia.com/uriqa/URIQA.html
and past threads on this list for details why.

Cheers,

Patrick


> -Richard
> 
> 
> On Oct 6, 2004, at 20:54, Stephen Rhoads wrote:
> > This brings to mind something which I have been struggling over ...
> >
> > If one uses MGET (or "Accept: application/rdf+xml") to 
> retrieve an RDF 
> > description of a URI for which there is also a representation 
> > available via GET (a URL), what is being described, the concept 
> > denoted by the URI, or the representation (such as an HTML page) 
> > returned when dereferencing the URI?
> >
> > If the former, how does one make statements about the 
> representation?  
> > If the latter, how does one make statements about the concept?
> >
> > Suppose I mint a URI to identify myself and put up an RDF 
> description 
> > which is returned to an MGET or when application/xml+rdf is 
> specified. 
> >  I then put up an image of myself which is returned to a 
> normal GET.  
> > How can I separately make statements about myself (type:Person, 
> > name:"Stephen") and about the image (type:Image, 
> aspectRatio:"16:9", 
> > mediaType:"image/jpeg")?
> >
> > --- Stephen
> 
> 
>

Received on Thursday, 7 October 2004 08:55:26 UTC