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

Re: Excess URI schemes considered harmful

From: Sean B. Palmer <sean@mysterylights.com>
Date: Tue, 30 Oct 2001 18:25:35 -0000
Message-ID: <01b401c16170$48544c00$dadd93c3@y0r1d9>
To: "Tim Berners-Lee" <timbl@w3.org>, "Roy T. Fielding" <fielding@eBuilt.com>, "Harald Alvestrand" <harald@alvestrand.no>
Cc: "Al Gilman" <asgilman@iamdigex.net>, "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>, "'Rob Lanphier'" <robla@real.com>, <uri@w3.org>, "Dan Connolly" <connolly@w3.org>, "Larry Masinter" <LMM@acm.org>, "Dan Zigmond" <djz@corp.webtv.net>, "Rich Petke" <rpetke@wcom.net>
> Having an http:  URI doens't mean you *have* to retrieve
> a page every time the URI is encountered.

This simple fact, if recognized by more people, could also clear up the
discussions (well, arguments) pertaining to what Fragment IDs identify, and
whether or not they are bound to the MIME type of an object that is being
dereferenced. The fact is that the user of the URI-reference gets to choose
the access mechanism, which could for example include looking up the URI in
some local Semantic Web KB. It seems quite likely that if I have added some
information to my KB, and that I have flagged it so that I trust it
implicitly, then if a triple is found thus:-

   <http://example.org/#blargh> rdfs:label "Blargh" .

Then I trust that information. I have in effect derived the meaning of an
HTTP URI-ref using methods other than HTTP, and other than some catalogue
of HTTP documents. The recent advances in P2P also offer an alternative
resolution mechanism that I could discuss further, but I shall just note it
as an alternative at this point.

Another fact that comes into play is that persistence across FragID space
should also [1] be maintained. When we derference a URI in one browser, we
expect the dereferenced result to be similar in functionality to the same
URI having been dereferenced in another browser. We tend to get upset when
it isn't, as the anguish generated over msn.com proves (msn.com telling
some browsers that they must upgrade to IE, without offering an alternative
to view the page as-is). This is similar to the fact that if we have
different ACCEPT headers in our HTTP requests, we still expect resources
that are similar in functionality, and I suggest that that functionality
extends to FragIDs representing more or less the same "thing",
notwithstanding the fact that the interpretation of a FragID depends upon
the amount of information available, and that this clearly depends upon the
method of derferencing, and the context.

So IMO Fragment ID's are not broken bits of Web architecture, contrary to
what DanBri et al. have expressed at point in the past (cf. [2]), simply
because they do the job of reaching further into a resource after it has
been derferenced, and they do so properly. Just as I can define URIs and
URI-views in many ways, people can interpret them how they wish - that's
the beauty of URIs, and it's how the Web works.

N.B. The discussion about URIs for content types needs a little more work,
and I may re-visit that... there is a certain amount of tension between
what we would like to do w.r.t. identifying syntactic or semantic aspects
of a resource before (or as) we dereference it, and how and whether or not
this can be (effectively and consistently) implemented.

[1] Also, as in "Cool URI *References* Don't Change".
[2] http://lists.w3.org/Archives/Public/www-rdf-interest/2000Mar/0028

Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Tuesday, 30 October 2001 13:25:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:29 GMT