W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

From: Nathan <nathan@webr3.org>
Date: Fri, 05 Nov 2010 18:03:34 +0000
Message-ID: <4CD446F6.7030402@webr3.org>
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 :)



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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC