Re: Hydra metadata for non-RDF resources

Am 11.11.2015 23:30 schrieb Maik Riechert <m.riechert@reading.ac.uk>:
>
> Am 11.11.2015 um 20:59 schrieb Dietrich Schulten:
>>
>> What makes me wonder is that you are talking about hydra metadata all the time.
>
> You're right, I shouldn't call it metadata. I guess I was looking for a broader term like "hydra constructs".
>
>> Your case seems to be a classic example for content negotiation. A client requesting csv gets csv, json-ld gets the same resource, but as json-ld, same for turtle, pdf, plaintext, html, you name it :-)
>
> I guess my main concern is whether a "smart" client that fetches some non-RDF representation shall take a peek into one of the RDF representations to try to discover some "hydra constructs" that it then could use on the original mime type (CSV). That's the main point really, is that an expected behaviour?

The csv could come with a Link header marked with the alternate rel, which links to the same uri as the csv and  hints to the client that the mimetype of that uri may be json-ld. See the Web linking rfc 5988 for the type parameter of the link header syntax. In addition, another link header with the hydra apidoc rel [1] would hint that this server has a hydra API. Not exactly what you are looking for, but maybe that can be interpreted by a hydra-compliant client as "try this and accept ld+json, you might get hydra". Quite a big step, but it is the best we have so far, this is what you should do.

IMO it would be more correct to define a Hydra profile URI which could be used to enhance the type of the alternate rel with a mime-type parameter giving the exact information you are looking for: there is an alternate *hydra* representation for this resource.

Like this: (link rel alternate...) type=application/ld+json;profile=http://www.w3.org/ns/hydra/core

However, Markus has been reluctant to go that far, therefore I cannot outright recommend it. Your question might be a use case which supports my view that the apidoc rel and a Prefer header to request a hydra flavor of rdf are in fact not enough and we need a profile URL :)

> Does that even make sense? What if some representations on that resource don't support certain API functionalities that however are supported in the hydra-enabled RDF representation? 

It is not the representation that supports a HTTP method but the resource itself. I guess you aim at possible request mime-types, like "you can send me a csv or a json-ld here". It is pretty much consense that we need a "hydra:mimetype" property which can be used on operation descriptors, we just don't have it yet.

> Do the hydra constructs of a RDF representation apply to their own representation only or to others at the same resource (like CSV) as well?

See above: you change the resource state, not the representation. The hydra constructs say things about the resource, not the response.

HTH;
Dietrich

[1] http://www.w3.org/ns/hydra/core#apiDocumentation is the rel which says that a link retrieves apidoc.