Re: Naming

On Mon, 8 May 2000, Godfrey Rust wrote:

> At 09:35 AM 5/8/00 +0100, McBride, Brian wrote:
> >What resource does the URI name?
> >
> >Is it the namespace, the RDF Model, the XML serialization or some abstract
> >composition of all of them?
> Or the particular manifestation or format of one of them as it appears at
> this location?  

Great questions. Here's a meta-question:

Is this a question about the RDF schema namespace URI, about XML namespace
URIs generally, or about Web architecture and URI naming in the general
case? Unfortunately I don't think theres a clear answer, but I'm inclined
towards the latter.

Here's an analogy:

What resource is this? When I dereferenced it just now I got a resource
of type image/png. If I'd dereferenced in a different environment I might
have got the image/gif version; if I'd derferenced a year ago I might've
got a different version of either of those files.

So Godfrey's mention of the manifestation/format aspect is critical in the
general case of Web identifiers. People too often assume that a Web URL is
"http://"+ name of physical machine + "/" + path-to-some-file

In practice things are a lot more abstracted than this. For example, doesn't name some Unix server in Boston, but dereferences to
one of various IP addresses for mirrors of the W3C site scattered around
the planet. Not everyone knows that, nor should they need to.

Those servers understand to name
a content-negotiable resource, available in image/png and image/gif

Here's an HTTP session conducted by hand which makes that clear (what I
do is ask for the HTTP HEAD metadata on a resource and send an accept
header claiming that I only accept some fictional mime type. This prompts 
the server to tell us about the different manifestations/format
representations of 'w3c_main'):

[danbri]$ telnet 80
	Connected to
	Escape character is '^]'.
	HEAD /Icons/WWW/w3c_main HTTP/1.1
	Accept: application/x-fictional-format-that-wont-exist

	HTTP/1.1 406 Not Acceptable
	Date: Mon, 08 May 2000 11:24:16 GMT
	Server: Apache/1.3.6 (Unix) PHP/3.0.15
	Alternates: {"w3c_main.png" 0.7 {type image/png} {length 5904}},
	 0.5 {type image/gif} {length 5684}}
	Vary: negotiate, accept
	TCN: list
	Content-Type: text/html 

So one lesson here is that the resource
is itself not the thing that is transferred across the wire in an HTTP
session. It's the Web's name for _something_. What you get when you ask
the Web about that thing, that resource, might well vary according to
the kind of message you send it, the time of day, or other properties of
that resource. HTTP transports representations not the resources
themselves (although those representations might be considered
(anonymous?) resources too and have properties/attributes etc).

There are at least two other resources involved here: one is a thing that
has a mime type of image/gif and size-in-bytes of  5684, the other has a
mime type of image/png and a size-in-bytes of 5904. 
It happens that these other two resources also have Web URIs, ie.

So, back to the XML/RDF namespace URI thing.

From one perspective (bare XML namespaces with no additional conventions
layered on top), "" is simply a
string that can be used to compose URI references such as

Per the URI RFC, the URI reference is composed
of a URI proper, and a fragment or
view identifier, "Class". The interpretation of the latter is relative to
the mime type of the former. As I've shown above, in the general case a
resource may use the Web to explose multiple mime-typed representations of
a resource. Access control, personaliseation etc also affect the
representations that are available in different contexts.

As it happens, the W3C server is currently serving that particular name
with just the mime type of text/plain, and as that mime type doesn't
define (to my knowledge) any semantics for URI framents/views, we're in
uncharted Web territory. 

I'll send a separate message about XPointer's use of #foo identifiers in
an RDF context. If we serve that resource as text/xml that'll give us a
whole other set of issues to deal with.

So back to my original question: 

Do folks here think the issues around URIs and Resources, and around
identification of fragment identified views of representations of those
resources, deserve a general treatment, or should we try to figure out a
perspective for those cases where the resource is (in some sense) an RDF

In other words, do we expect there to be anything special about the
answers we give Brian and Godfrey for

versus for

My inclination is to say that the Web needs a fix for both cases, and that
attempting an RDF-specific clarification here would be unhelpful. Consider
this scenario:
represents the W3C logo. Currently available in image/png and
image/gif. How do we deal with
"" if for example an SVG
representation (XML vector image format) were to also be made available by
HTTP content negotiation. This (RDF-free) problem seems to me to be very
close to the issues we're coming up against in an RDF context.

If anyone can see a way to partition the problem and fix this for RDF
without having to wait for a general-case solution, do speak up now!



Received on Monday, 8 May 2000 08:13:35 UTC