Alan Ruttenberg wrote:
On Nov 10, 2010, at 5:41 PM, Nathan <[email protected]> wrote:
Alan Ruttenberg wrote:
On Wed, Nov 10, 2010 at 5:04 PM, Nathan <[email protected]> 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!
