Re: clarification on the use of fragments

Alan Ruttenberg wrote:
> 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.

true of HTML, not of RDF, and as for HTML+RDFa, see below:

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

But that ambiguity is in the presentational markup up of that particular 
page, not in the data, and outlines the challenges ahead for designers.

To further illustrate, if one creates an RDFa document which has a 3x3 
grid of products in the center of the page marked with non human 
friendly @id's which correspond to the @about's
   <div id="ab123" about="#ab123">
Then a user is simply going to see a grid of products, and not know 
which specific one was referred to.

This however, is a clear case of where RDFa tooling can clear that 
ambiguity up, by perhaps highlighting the linked-to product.

The point being, there is no ambiguity in the data, as the RDFa tooling 
example above clarifies.

Best,

Nathan

ps: cheers for clearing up the M = MB not M = Million thing!

Received on Thursday, 11 November 2010 00:11:36 UTC