W3C home > Mailing lists > Public > uri@w3.org > May 2001

Re: Are URI-References bound to resources?

From: Dan Connolly <connolly@w3.org>
Date: Fri, 11 May 2001 16:08:24 -0500
Message-ID: <3AFC54C8.E633D05A@w3.org>
To: "Roy T. Fielding" <fielding@ebuilt.com>
CC: Aaron Swartz <aswartz@upclink.com>, uri@w3.org
"Roy T. Fielding" wrote:
> > > This seems to imply that URI references (that is, URIs with fragment
> > > identifiers) are not bound to a resource themselves.
> >
> > Careful... it does not imply that URI references are
> > bound to resources; but nor does it imply that they are *not*
> > bound to resources. RFC2396 is silent on what
> > a URI reference is bound to.
> Eh?  It is a resource identifier. It identifies resources.

The question is about the term "URI reference". You're saying
that a URI reference identifies a resource? That's perhaps
consistent with the RFC, but I don't see it stated in
the RFC.

Leaving aside the fact that a relative URI reference needs
a bit of context (a base URI) to identify a resource,
I'm fine with this view of things; in fact, I think it's
the view used in the RDF spec; but you seem to think
otherwise; I'm confused...

> > > Instead, the only
> > > resource involved is that of the absolute URI itself.
> > >
> > > Is this interpretation correct?
> >
> > I don't think so; I think you're reading more into RFC2396
> > than is there. (you're certainly not the first, and
> > I don't expect you'll be the last.)
> No, that is correct.

The interpretation he's asking about says that
identify the same resource. Are you sure that's correct?
i.e. can you justify that from the text of RFC2396?
As far as I can tell, RFC2396 doesn't say what resource
either of them identifies; it only tells you that
yes, they identify the same resource after you remove
the #fragid. Duh.

>  At no time whatsoever is the resource transferred
> across the network when doing a GET.

Quite; who/what suggested it was?

>  Only a REPRESENTATION of that resource
> is transferred, and the fragment refers to a target within the representation
> and not within the resource.  That is why fragments are media-type specific.

Yes, but again, I don't see how that's directly relevant;
the question is what
is bound to; and in particular, whether it's reasonable
to say that it's bound to a resource.

> > > If so, it would have serious consequences
> > > for many RDF specifications.
> >
> > RDF isn't the only spec that extends the domain
> > of the URI->resource mapping; XLink does too--
> > er... it did in earlier drafts... I pointed
> > that out in a review comment... during last call,
> > I think; they seem to have changed their mind since then...
> >
> > [[[
> > The notion of resources is universal to the World Wide Web. [Definition:
> > As
> > discussed in [IETF RFC 2396], a resource is any addressable unit of
> > information or service.] Examples include files, images, documents,
> > programs, and query results. The means used for addressing a resource is
> > a URI (Uniform Resource Identifier) reference (described more in 5.4
> > Locator Attribute (href)). It is possible to address a portion of a
> > resource.
> > ]]]
> That definition is wrong.

Really? how so? It just says "the term resource in this
spec is imported from RFC2396". How could it be wrong?

>  So are the definitions used by RDF.

Really? How so? which text in the RDF spec conflicts
with which text in RFC2396?

>  That's
> why they keep having semantic problems with the Web.

Who is "they"? What problems?

> > Keep in mind that RDF 1.0 was finished Feb 1999,
> > just a few months after RFC2396 in Aug 1998. It would
> > seem perfectly reasonable to do an editorial revision
> > of RDF to make a new term for what RDF 1.0 calls 'resource',
> > and use 'resource' to mean just what RFC2396 defines
> > it to mean.
> Dude, I finished the definition of resource a long time before RFC 2396
> was published -- it was in the November 1997 draft.

You finished *your* definition of 'resource' a long time ago.
Getting that to be *the* definition took quite a while longer...
i.e. getting folks to read it, understand it, agree to it,

>  And even that was
> just a rewording of the "HTTP object model" (now called the REST architectural
> style) that I was working on back in 1995 during our whiteboard discussions
> at the W3C.

I agree; I don't think anything has changed in substance for
about 10 years.

> > TimBL went that way in some code he wrote recently;
> > he uses 'Thing' for the class of things that includes
> > resources *and* things denoted by absolute-uris-with-fragments:
> Just shoot me.  Its my fault for not sending you guys a copy of my
> dissertation when I was writing it.  I didn't realize that we had diverged
> so far from a common model.

Chill, Roy. Show me the text on which you're basing this
conclusion. I think you're being hasty. I don't see
divergence; I see two views:

I. The conservative view:

There's a mapping
	Absolute URI -> Resource
Since http://example.org/q#foo isn't an absolute
URI, RFC2396 doesn't say what it identifies; folks
should use some other term for what it identifies.
(This is the view used in TimBL's recent hack
with the Thing class, probably because folks were
uncomfortable with ...)

II. The original/liberal view

There's a mapping
	Absolute URI, with optional fragment identifier -> Resource
RFC2396 only explicitly talks about the part of that
mapping where the domain is an Absolute URI with no fragment
identifier, but RFC1630, among other specs, talks
about the whole mapping.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Friday, 11 May 2001 17:08:44 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:39 UTC