Re: Naming

On Mon, 8 May 2000, Dan Connolly wrote:

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

In the RDF world, and on my reading of Web architecture, we   can think of
the entity body either as a literal chunk of data, or as a resource for
which we lack (knowledge of) a URI name. I'm inclined to think of it as a
resource, anonymous in the sense of being un-named in this context, but
possessing properties such as sizeInBytes, checksum etc.

So on this view: there are some resources that can provide representations
of themselves as other resources. The resource
http://www.w3.org/Icons/WWW/w3c_main and the resource it emits
[some-unnamed-entity-body] are related, and shouldn't be conflated. If we
want to exchange metadata about the latter, we either get used to talking
about it as a resource, or consider it a "literal", in the RDF sense.

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

Appreciated. That was my point really, that the resource we're discussing
here 'w3c_main' is not something we can know directly, only exchange
messages with over HTTP. And that the things we get back in such
transactions are themselves the sorts of thing/entity/resource that we
want to use metadata to describe.

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

Yep. 

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

(It would be good to have a mechanical representation of this assertion,
eg. for caching, disconnected use etc...)

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

It's not clear where we guarantee that. RDFS says that the model
corresponding to an RDF Schema shouldn't be changed, but is silent on
whether alternate syntactic representations might for eg become available
via content negotiation. This can of course be over-ridden by W3C
Publication Rules for specs. But I'm inlcined to agree: "it" shouldn't
change.


> 
> [...]
> 
> 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.

I disagree. The issue is confused already - the conceptual model of a
URI-identified Web-GETtable resource and it's various accessible
representations over time hasn't yet been accessibly documented in a way
that enough people understand. My use of 'resource' in this context will
doubtless be puzzling, but the alternative seems to be inventing yet
another synonym for 'thingy'...

RDF uses 'resource' in a very general way, and makes good use of this
generality by showing how we can use this general notion of a resource to
describe properties, relationships, attributes etc of Web content. When
we pick apart some of these scenarios (eg. image, in 3 formats, changed
over time etc etc) we find lots of different
things/entities/resources/objects that are easily
confused with one another. But just as RDF models the creator of the image
as a 'resource' (aka thing) with properties and relationships, RDF models
the different public representations of an image as 'resources'. While
these may (like people...) lack public URIs, the situation is not very
different from the general problem of 'anonymous resource mentions' we've
discussed here recently.

"the person who created the image/png representation of the W3C logo"
"the image/png representation of the W3C logo"
"the literal content/state of that logo"

At least the first two seem to me to be equally deserving of the label
'resource'.

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

I'm not sure where you got "all of altavista" from, nor why you're
assuming that the representation of something can't be a concise summary,
eg. front pages serving as table of contents. http://www.altavista.com/ is
just some thing known to the Web; you're alluding to it being the same
thing as Altavista Inc's huge web index.

" but being clear when you do so is quite a challenge."

Quite. This is one of my concerns with RDF. However squeaky clean the
model, unless  the Web has a clear conceptual model (here's how to identify a Web
_Page_, a Web _Service_ a Web _Site_ etc) the richness of the formal model
is wasted.


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

I can't see any other way to go without bloating the RDF model. If we
don't model these as 'resources' because we think the word is confusing,
what are we supposed to do instead?

If you accept that people will want to use metadata to talk about these
kinds of scenarios (images in different formats, versions etc -- pretty
mainstream problem in eg Digital Library community) we'll need some
way of using RDF without having a "pretty confusing" discussion. 


We've had this discussion before, eg. representing people. You've
previously  suggested that [dc:creator.PersonalEmail] and
[dc:creator.PersonalPhoneNumber]  properties might be used to relate a
document to details of its creator, without requiring an RDF resource
representing that person (aka as an 'anonymous node'). This strategy
doesn't work when multiple creators are involved, since the extra node in
the graph is needed to bind together their properties.

This leads to a strategy where you model the creator of a document as an
un-named resource, which serves to hook together properties such as
email/phone/age. As you've often pointed out, some of these properties
(eg. personalMailbox) can be uniquely identifying, a workaround for the
lack of URIs for people. 

I believe the same thing holds for entity bodies. We want metadata about
them (for all sorts of purposes, caching, searching, rights etc). We don't
usually have URIs for them. We don't (like people) usually think of them
as "Web" resources. But as far as RDF is concerned (and, I thought, Web
architecture generally) they are resources.
 
> > 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.

OK, fine, yep.

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

Thanks for the extra precision: this is exactly the problem I'm concerned
with. The mime type may differ from day to day and client to client, which
is a problem from an RDF perspective as we treat URI References as if they
made sense when lifted out of such contexts.

<rdf:Description about="http://www.w3.org/Icons/WWW/w3c_main#foo">
<s:size>1000</s:size>
</rdf:Description>

...is my concern. What does it mean to make such assertions against a URI
reference that includes the #foo, in the absense of some context such as a
particular HTTP transaction? The 'abstract' resource doesn't have a mime
type, but is associated with both image/gif and image/png representations.

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

[...]
> > 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

No, I don't believe I understand the issue overlaps well enough to
propose a question worth seeking a "consensus" answer on. 

I was testing the water hoping for an informal response to a
hard-to-formalise question.

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

Fair point. My attempt below  was a bit more concrete but needs tightening
up.

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

Asked slightly differently: how about if the latter was just some RDF
instance data, and didn't have the additional rules imposed through being
a representation of an RDF Schema.

Or: are URI references with fragement identifiers ever meaningful when
divorced from the context of some HTTP transaction? (and hence mimetype)
If so, can we specify to software the cases in which such fragment IDs
"make sense"? 

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

The problem:

I don't mind admitting that I find the problem hard to articulate. Here
are some of its component parts...

1. we want to have metadata about the mime-type specific
  representations of (for example) some image resource.

2. This metadata may need to make use of mime-type specific semantics for
  the # fragment/view component of a URI reference. eg. an image that was
  available in (say) SVG as one content-negotiable representation. If SVG
docs have fragement semantics (eg. allowing us to pick out some
sub-component of the image encoded in an entity body) we'll likely want to
exploit this in metadata descriptions.

3. Since there may be multiple mime-typed representations of any HTTP
GETtable resource, there can be no context-free interpretation of
URI references to these resources that use the '#foo' fragments.

Dan


--
mailto:danbri@w3.org

Received on Monday, 8 May 2000 13:59:41 UTC