Re: Are URI-References bound to resources?

Sorry if my response sounded heated.  I am a little put off by all of the 
times I've had RDF folks say that the definition of resource isn't sufficient
for semantic description, when they haven't even defined resource correctly
in the RDF spec.  It certainly doesn't help when others from XML land want
to define a new URI scheme that has all of the properties of any good URI,
except for an arbitrarily different syntax because they don't want
"something" to mistake it for being a URL.  There comes a point when I have
to conclude that the W3C no longer understands the Web architecture.

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

Ooops, missed that.  RFC 2396 treats those as two separate identifiers
within the same syntactical protocol element.  I could have sworn that was
in the spec.

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

The RDF spec refers to the representation as the resource -- in other words,
that the fragment itself is a resource.

> > > > 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
>   http://example.org/q#foo
>     and
>   http://example.org/q#bar
> 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.

The resource identifier is before the fragment.  The fragment identifies
a subset of the representation retrieved after a GET of the resource.
It isn't possible to "access" the fragment on its own, and hence it is
not itself a resource until someone provides another URI that that
has the semantics of mapping to that representation as a resource
(i.e., an indirect reference).

> >  At no time whatsoever is the resource transferred
> > across the network when doing a GET.
> 
> Quite; who/what suggested it was?

That's what the definition you quoted said when it referred to the fragment
as a resource.

> >  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
>   http://example.org/q#foo
> is bound to; and in particular, whether it's reasonable
> to say that it's bound to a resource.

Now you lost me.  What does "bound" mean?  I would say that the namespace
is bound according to the authority example.org.  Since example.org is never
given the opportunity to interpret #foo, that part of the URI reference
isn't within example.org's authority, and hence it is not 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?

"It is possible to address a portion of a resource."  That is wrong.
It is possible to reference a portion of a representation.  Besides that,
why does it use the term "addressable" in the first place?  Addressable
implies locator which defines URLs, not URI.  If it is going to refer to
the RFC 2396 definition, then it should use the RFC 2396 definition.

> >  So are the definitions used by RDF.
> 
> Really? How so? which text in the RDF spec conflicts
> with which text in RFC2396?

This text:

 Resources
    All things being described by RDF expressions are called resources.
    A resource may be an entire Web page; such as the HTML document
    "http://www.w3.org/Overview.html" for example. A resource may be a part
    of a Web page; e.g. a specific HTML or XML element within the document
    source. A resource may also be a whole collection of pages; e.g. an
    entire Web site. A resource may also be an object that is not directly
    accessible via the Web; e.g. a printed book. Resources are always named
    by URIs plus optional anchor ids (see [URI]). Anything can have a URI;
    the extensibility of URIs allows the introduction of identifiers for
    any entity imaginable.

and it later proceeds to be clueless about the semantic differences between
resources (mappings/bindings/names) and representations (the stuff you
might get as a response when accessing the resource).

> >  That's why they keep having semantic problems with the Web.
> 
> Who is "they"? What problems?

The folks on this list who have several times requested that "resource"
be redefined to be some subset of the Web's resources in order to solve
some logic problem in RDF.  You'll have to search the archives for the
specifics.

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

Not my problem -- it was on a public forum, representing the future of the
most important aspect of the Web architecture, and the fact that some folks
at the W3C didn't bother to keep apprised of the definition while they
were supposedly defining the uber-meta-model for describing resources
isn't something you should be defending.  W3C marketing claims it is
on top of this stuff.

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

Not in URI land, hopefully.  It doesn't mean that the old specifications
were right.  Tim's design documents still refer to resources as documents.
That was true prior to 1993, but not after 1993.  My goal was to update
the semantics so that they reflected what was actually working on the Web,
without losing the fundamental principles that Tim described to me at W3C.

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

No worries, I wasn't upset with you -- just me.

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

Yeah, but I worked out a definition of that "thing" during the HTTP/1.1
stuff.  I call it a representation.  Jeff Mogul didn't like that and insisted
on calling it an "instance".  That's why neither is defined in the spec.
Representation is, however, defined in my dissertation.

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

Right, and we abandoned it in 1995 because that definition caused
all sorts of ambiguities in the specs.  For example, how is access
control assigned to "things" on the Web.  By the resource.  Is it possible
to define separate access control to different fragments of the same
resource?  No.  Therefore, a fragment is not a resource until it is
bound as some other URI by a naming authority that can control access
to the fragments as separate, identifiable resources.  Because if we
decided the other way -- that a fragment was a resource too -- then we'd
have to define a new term for that subset of "old-style resources" that
were actually subject to the Web behavioral model.

The same logic applies to many other aspects of the Web design beyond
access control.  That's why I separated the definition of resource
and representation, and hence why REST is an acronym for representational
state transfer.  I needed to do that for HTTP/1.1 because the old model
just didn't fit things like CGI, Apache modules, and URN indirection.

....Roy

Received on Friday, 11 May 2001 19:17:53 UTC