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

Re: clarification on the use of fragments

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Wed, 10 Nov 2010 18:57:00 -0500
Message-Id: <92F60383-C809-4903-97DB-5291A5737FEF@gmail.com>
To: "nathan@webr3.org" <nathan@webr3.org>
Cc: Linked Data community <public-lod@w3.org>

On Nov 10, 2010, at 5:41 PM, Nathan <nathan@webr3.org> wrote:

> 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??
>
Nope. I'm saying that if a client has an identifier the referent of  
which they know nothing about,  and they put it in a browser, and they  
get back a page about several things, then there is a (not unlikely)  
possibility that they will not know which thing that identifier refers  
to.

Many URI's refer to regular web pages, and in those cases, when you  
get a web page, you aren't surprised.


> 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.

You miss the point. If you have an identifier that is supposed to mean  
an iPhone, and you put it in a browser and get a page that shows an  
iPhone and a bunch of accessories, then you may think that the URI  
refers to an iPhone and a bunch of accessories rather than an iPhone.

You have to remember that the situation that has to be planned for is  
that the client knows *nothing* about the URI means before getting  
back the page.

The advise to use fragments often is not given along with the caveats.  
This leads to situations like the one I mention. And there are a lot  
of them.

Regards,
Alan

>
> 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.

The M refers to megabytes by the way. I guess 3 orders of magnitude  
fewer descriptions. Not that it matters but I wanted to set that  
straight.

>
> Best,
>
> Nathan
>
Received on Wednesday, 10 November 2010 23:57:44 UTC

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