Re: Naming

Dan Brickley wrote:
> On Mon, 8 May 2000, Godfrey Rust wrote:
> 
> > At 09:35 AM 5/8/00 +0100, McBride, Brian wrote:
> > >What resource does the URI http://www.w3.org/2000/01/rdf-schema# name?
> > >
> > >Is it the namespace, the RDF Model, the XML serialization or some abstract
> > >composition of all of them?

It identifies
	the empty-fragment ("") view of
	the resource accessable by (among other mechanisms, such
		as proxies, caches, and phoning your neighbor to
		ask him to ask him what's available there just now)
		HTTP to a host called www.w3.org
		using the path /2000/02/rdf-schema


The term "resource" is pretty much opaque, like the term "point" in
geometry. Consider:

	What point does (10, 15) identify?

except that URI-space is very much non-euclidean ;-)

From a less formal perspective, you can consider URIs as noun phrases;
they identify a "person, place, or thing".

> > 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:
> 
>         http://www.w3.org/Icons/WWW/w3c_main
> 
> What resource is this? When I dereferenced it just now I got a resource
> of type image/png.

Careful; you got an *entity body* of type image/png, not a resource.
The resource identified by http://www.w3.org/Icons/WWW/w3c_main
has state that's subject to change by the W3C webmaster, and
you didn't get all that; you cannot, for example, locally simulate
its behaviour indefinitely.

What you get back from a GET request to a resource is not, in general, a
resource identified by any URI that you can discover; you get back some
content;
an 'entity body' in the HTTP spec terminology.
	http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.3

An entity body is directly observable:
you can compare it, locally, for identity with another entity
body. In general, a resource is not directly observable;
you can only observe it by bouncing messages off it and
seeing how it responds.

In specific cases, a publisher can say "this resource *is*
a particular piece of content; it has no other state than
what's in this entity body: ...". For example, the W3C
says this about
	http://www.w3.org/TR/1999/REC-xml-names-19990114/Overview.html

Once you have successfully done a GET on that resource,
you can completely simulate its behaviour locally.


Hmm... I think we also guarantee that
	http://www.w3.org/2000/01/rdf-schema
doesn't change over time, though we don't guarantee that it's
doesn't vary by MIME type.

[...]

You make the same point below:

> So one lesson here is that the resource http://www.w3.org/Icons/WWW/w3c_main
> is itself not the thing that is transferred across the wire in an HTTP
> session.

but in somewhat misleading terminology, I think.

You can speak of the content returned from an HTTP GET as a resource,
since you can refer to it with a noun phrase, and you can issue a URI
to correspond to any natural language noun phrase. (There are even
interesting design issues around naming request, responses,
and their content ; for example, adding
a Message-ID header to POST requests and responses, or using
a Content-ID: header on a GET reply) But to do so just confuses
the issue, in most cases.

> 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

'representations' is clear in most cases, but not all: what
you get back from a GET to http://www.altavista.com/ is
hardly a representation of all of altavista. You could say
it's a representation of the particular service interface
or something, but being clear when you do so is quite a challenge.

Using 'entity body' per the HTTP spec is fiarly straightfoward
and usually clear. [hmm... checking my sources, I see
that 'representation' is HTTP standard terminology too.]

> (although those representations might be considered
> (anonymous?) resources too and have properties/attributes etc).

Yes, but as I say, that discussion is usually pretty confusing.


> 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.
> http://www.w3.org/Icons/WWW/w3c_main.gif
> http://www.w3.org/Icons/WWW/w3c_main.png

Nope... we don't use http://www.w3.org/Icons/WWW/w3c_main.gif
to name a particular stateless piece of content. We use it
to name the image/gif variant of http://www.w3.org/Icons/WWW/w3c_main ,
whatever that may be at the time.

> So, back to the XML/RDF namespace URI thing.
> 
> From one perspective (bare XML namespaces with no additional conventions
> layered on top), "http://www.w3.org/2000/01/rdf-schema#" is simply a
> string that can be used to compose URI references such as
> http://www.w3.org/2000/01/rdf-schema#Class
> 
> Per the URI RFC, the URI reference
> http://www.w3.org/2000/01/rdf-schema#Class is composed
> of a URI proper, http://www.w3.org/2000/01/rdf-schema and a fragment or
> view identifier, "Class". The interpretation of the latter is relative to
> the mime type of the former.

careful... 'the MIME type of a URI' is, in general, an ill-formed
definite description: what's *the* MIME type
of http://www.w3.org/Icons/WWW/w3c_main ?

cf http://www.w3.org/Architecture/Terms#definite-description

rephrased carefully: the interpretation of a fragment identifier w.r.t.
an entity body received in response to a GET request to a resource is
relative to the MIME type of the entity body.

> 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,

odd... I would have expected text/xml.

> and as that mime type doesn't
> define (to my knowledge) any semantics for URI framents/views, we're in
> uncharted Web territory.

Quite!

> 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
> model?

I hope you're not trying to reach consensus on that question. That's
a question about how to organize the most effective book on the subject
or something.

I recommend you persue questions that have black-and-white answers,
testable by software.

> In other words, do we expect there to be anything special about the
> answers we give Brian and Godfrey for
> 
> http://www.w3.org/Icons/WWW/w3c_main#foobar
> 
> versus for
> 
> http://www.w3.org/2000/01/rdf-schema#foobar

Asked exactly that way, yes, I expect a different answer, because
W3C has said that RDF Schemas don't change; i.e. if you use a URI
in the syntactic role of RDF schema, you promise not to change
its content over time. So W3C has promised that
http://www.w3.org/2000/01/rdf-schema doesn't vary over time.

> My inclination is to say that the Web needs a fix for both cases,

A fix? I don't see any problem that you have identified.

> and that
> attempting an RDF-specific clarification here would be unhelpful. Consider
> this scenario:
> 
> http://www.w3.org/Icons/WWW/w3c_main
> represents the W3C logo. Currently available in image/png and
> image/gif. How do we deal with
> "http://www.w3.org/Icons/WWW/w3c_main#foobar" 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.

Problem? I don't see any problem in this scenario.

> 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!
> 
> Dan
> 

By the way... relevant writings on this subject include:

	Web Architecture: Generic Resources
	http://www.w3.org/DesignIssues/Generic

	Web Architecture: Protocols for State Distribution
	http://www.w3.org/Architecture/state


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 8 May 2000 10:31:03 UTC