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

Re: clarification on the use of fragments

From: Nathan <nathan@webr3.org>
Date: Wed, 10 Nov 2010 22:41:28 +0000
Message-ID: <4CDB1F98.4040404@webr3.org>
To: Alan Ruttenberg <alanruttenberg@gmail.com>
CC: Linked Data community <public-lod@w3.org>
Alan Ruttenberg wrote:
> On Wed, Nov 10, 2010 at 5:04 PM, Nathan <nathan@webr3.org> wrote:
>> Alan Ruttenberg wrote:
>>> In the interest of clarification, the reason that some of us advocate
>>> *not* putting several resources in one file using fragments is that it
>>> then becomes difficult to serve (standard web) pages that give only
>>> information about one resource, because the server doesn't see the
>>> fragment id.
>> Yes, if you want one thing described per file, then describe one thing per
>> file, if you want two things described per file, then don't be surprised
>> when that file describes two things, rather than one.
> 
> Not that we disagree, but I wanted to point out that it isn't "you"
> the author who we are concerned about surprising. It is the consumer -
> the person who goes to see what the resource means. To my mind,
> anything more than one resource described in a response will likely
> confuse someone you don't want to confuse (the customer).

Alan,

This is all very conflated, I'm quite sure you're not suggesting that 
virtually every ontology, every page of comments, every specification, 
every page of products, or search results, or indeed any page on the web 
which describes more than one thing (and uses fragments) confuses 
someone you don't want to confuse - or are you??

Perhaps then if we say, that smashing every single w3c spec in to one 
document is not a good idea, but having one spec which describes a few 
different concepts, is perfectly fine.

I personally have faith that people usually will have enough brain power 
to manage their data in some reasonable way, and not stick 200+M 
descriptions in a single file, or have 200+M files with 2 lines each.

Best,

Nathan
Received on Wednesday, 10 November 2010 22:42:29 UTC

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