- From: Sean B. Palmer <sean@mysterylights.com>
- Date: Tue, 30 Oct 2001 18:25:35 -0000
- 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>
TimBL:- > 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 UTC