Re: the necessity of describing responses in-band

Hi Ruben

> On October 6, 2015 at 6:02 PM Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
>
>
> Hi John,
>
> > For HTML would also be fair to say that much of the metadata is put in the
> > <head> element of the message body.
>
> …but all of the metadata a user is supposed to see, wil stil make it to they
> <body>.
> I rarely see really interesting metadata (only) in <head>.

However there is plenty of interesting stuff in <link> elements.

In the hyrda:Collection in the examples, how come you don't use hydra:member to
link the
collection to the members. Isn't this needed to inform the client that the items
are in 
the collection and not just three random/unrelated resources?

Another point I'd like to raise is the use of quads rather than triples.
As you are most likely aware there are no agreed formal semantics for RDF
datasets [1].

I can sure see the appeal of putting the metadata in a separate named graph.
But do you think that using quads would come at the risk of interoperability
issues?
What would happen if someone did a LOAD operation of one of these quads
documents into a store?
Would it make sense to state the metadata graph is a subgraph of the main graph?

I made a simple LD wrapper for BreweryDB a while back [2] and ran into similar
questions.
Here I had done things slightly different where a URI like
http://breweryld.semaku.com/beer/8GpObe
identifies the document (information resource) and URI like
http://breweryld.semaku.com/beer/8GpObe#id
identifies the thing described in the document.

In the JSON-LD context I'd originally aliased "data" key to "@graph" keyword so
the document is plain
triples, but a client handling it as JSON could still somehow separate the data
from the metadata.
In the end I mapped "data" to dc:subject which I think is also semantically
clear.

John

[1] http://www.w3.org/TR/rdf11-datasets/
[2] https://gist.github.com/jaw111/46209e853f83d041a6dd

Received on Wednesday, 7 October 2015 20:13:55 UTC