- From: Norman Gray <norman@astro.gla.ac.uk>
- Date: Fri, 5 Nov 2010 17:27:55 +0000
- To: Hugh Glaser <hg@ecs.soton.ac.uk>
- Cc: "nathan@webr3.org" <nathan@webr3.org>, Mischa Tuffield <mmt04r@ecs.soton.ac.uk>, Linked Data community <public-lod@w3.org>
Hugh (and Nathan), hello. On 2010 Nov 5, at 17:11, Hugh Glaser wrote: > Later, if I ask for <http://example.com/about#bob>, and expiry etc. was > not set aggressively, then there is a distinct possibility that the page > will not be re-fetched, but just hand back the "version: of > <http://example.com/about> that the server chose to return in response to > the <http://example.com/about#alice> request. Unless I'm misunderstanding you, if the client is asked "find out about http://example.com/about#bob", then it retrives the URL <http://example.com/about> -- the fragment is _not_ part of the request, and these two URI identifiers _both_ result in the same document being retrieved. Therefore, that /about document must describe both #bob and #alice. Thus (Nathan), responding to > I don't follow why it's inferred here that if you use a fragment then all information must be in one document?? makes no sense. You can use exactly the same one article per document approach with frags ...the <http://www.w3.org/TR/cooluris/#hashuri> example of the <http://example.com/about#alice> identifier implies that the <http://example.com/about> document must contain information about both the #alice and #bob fragments, because there's no way that the server can tell the difference between the two (since it never sees the fragment), and so it must provide the same document in both cases. A variant of this is the one-identifier-per-document one that you're describing (if I understand you correctly). You certainly can use the pattern <http://example.com/about/alice#alice>, and here the per-identifier document <http://example.com/about/alice> is an IR and the identifiers <http://example.com/about/alice#alice> or <http://example.com/about/alice#i> are not. I can see the advantages of this latter "slash-hash-URI" scheme, but I'm fairly confident it's distinct from what Leo and Richard are describing as their "hash-URI" scheme. If their "hash-URI" scheme is intended to cover your scheme, too, then the cooluris document may need a little clarification. Best wishes, Norman -- Norman Gray : http://nxg.me.uk
Received on Friday, 5 November 2010 17:28:26 UTC