- From: Nathan <nathan@webr3.org>
- Date: Fri, 05 Nov 2010 18:03:34 +0000
- To: Hugh Glaser <hg@ecs.soton.ac.uk>
- CC: Norman Gray <norman@astro.gla.ac.uk>, Mischa Tuffield <mmt04r@ecs.soton.ac.uk>, Linked Data community <public-lod@w3.org>
Hi Hugh :) I honestly believe (although hopefully Richard will clarify) that it was never the intent to indicate it's a good idea to put millions of resources in a single file - rather to illustrate how it is possible to put multiple resources in one file, if you so wish. However, no you couldn't dynamically produce a document with the right things in it this way because HTTP and the server never sees a fragment. You can always use SPARQL in that way of course though :) Best, Nathan Hugh Glaser wrote: > Thanks - I thought as much, I think, but I was unclear. > The issue I was pondering on was whether it was being suggested that a > server could avoid sending the Gigs of data in <http://example.com/about> > when asked for one of the many hash URIs in <http://example.com/about>, > such as <http://example.com/about#alice>, but just responding with the rdf > for <http://example.com/about#alice>. > I think that the hash is stripped off, as you say, long before the server > in any case; but even of it wasn't, then things would break because of > caching of <http://example.com/about>, etc.. > This was all in relation to whether hash URIs are a problem for big files, > but that has long gone in the stream of emails now, I guess :-) > Best > > On 05/11/2010 17:33, "Nathan" <nathan@webr3.org> wrote: > >> Hi Norman, >> >> Norman Gray wrote: >>>> 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. >> Hmm, I don't see a distinction between the patterns to be honest, >> Richard / Leo can verify if they are distinct, personally think it could >> be better clarified to use a few different uris, some where it's one >> resource per doc, some with more than one. >> >> <http://example.com/alice#me> >> <http://example.com/about#bob> >> <http://example.com/about#frank> >> >> for instance, or something even clearer. >> >> Best, >> >> Nathan > > >
Received on Friday, 5 November 2010 18:04:48 UTC