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" <[email protected]> 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





Reply via email to