Re: the necessity of describing responses in-band

Hi Melvin,

> One point is that putting triples in a document doesnt help you if you're doing a HEAD request.

That's true. Not much to see in there.
In general, the Web is pretty boring if we only do HEAD requests ;-)

> I think it's not unusual to see
> 
> <> predicate object
> 
> isnt it?  For example the personalProfileDocument pattern.  For meta data about a document.

Right, but that metadata is then mingled together with the data.
And not all metadata about a resource has that resource as a subject.
As a result, if we do not distinguish data and metadata with graphs,
clients cannot separate them in general.

Take for instance:

>> <> a hydra:Collection, hydra:PagedCollection;
>>    dc:title "Amazon results for 'Peppa Pig'";
>>    hydra:totalItems 30,862;
>>    hydra:itemsPerPage 16;
>>    hydra:firstPage </search/?q=peppa+pig&page=1>;
>>    hydra:nextPage </search/?q=peppa+pig&page=2>.
>> </#amazon> ex:paymentCondition [
>>   ex:condition [ ex:minimumTotal 35.00 ];
>>   ex:result [ ex:shippingCost 0.00 ]
>> ].
>> </items/45158567> a pto:Book;
>>   schema:name "Peppa Goes Swimming"@en.
>> </items/35235179> a pto:Toy;
>>   schema:name "Peppa Pig Regular Plush"@en.
>> </items/10268448> a pto:Dress;
>>   schema:name "Peppa Pig Long Sleeve Bicycle Gown"@en.

There's no way for the client to know that </#amazon>
is not part of the data.

> It seems to be a common point of debate as to whether to mandate meta data in a document or in a header (or both or either!).
> 
> Is there a clear understanding of when to put data in one or the other, or is it simply preference?  

The conservative answer is to put it in the header,
because poor clients might get confused if it is in the message.

The purpose of my blog post is to argue that
clients cannot get confused if you separate it properly using graphs,
and that everywhere else on the Web, metadata is put inside of the document.
Furthermore, I also argue that putting all metadata in the header
is not practical, because there can be a lot of it.

Hence, my conclusion is that putting metadata inside of the response
is both possible and desirable, and done everywhere else.

> One thing we do in rdflib.js is create a graph of all header responses for every document fetched and put it in a knowledge base.  Then later we can check both data points, do you think this is a good idea?

It's a good idea.
I would just recommend that servers put things inside of the response.
Then you could put the metadata graph inside of that knowledge base instead.
The end result is the same, except that a metadata graph can contain much more.
Nobody is going to put a multi-field hypermedia control in the headers.

> The idea of pagination is interesting, because could be viewed at the HTTP level or at the generic document level, so I can see why opinion may be split.

My opinion is easy: just see what the rest of the Web does.
Pagination is put inside of the message there.
I see no reason to do it differently just because it's RDF instead of HTML.

In an ideal situation, the headers (besides Content-Type) should be the same
regardless of the body. Putting things inside of the body for HTML,
but in the headers for RDF, just seems a clumsy and unnecessary workaround.

Best,

Ruben

Received on Tuesday, 6 October 2015 14:47:47 UTC