- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Tue, 6 Oct 2015 13:57:26 +0200
- To: Asbjørn Ulsberg <asbjorn@ulsberg.no>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Hydra <public-hydra@w3.org>
> Right. Good point. We can make recommendations, though? In RFC 2119
> parlez, people SHOULD offer their Hydra-enabled APIs in
> application/ld+json.
I'd prefer:
Hydra-enabled APIs SHOULD offer at least a JSON-LD representation of their resources.
This does not exclude other representations.
>> For instance,
>> $ curl -H "Accept: application/ld+json" http://fragments.dbpedia.org/2015/en
>> does give you JSON-LD, but not (yet) the kind you want I guess.
>
> I'm not sure how else the above can look and still be JSON-LD
> compatible?
With a different@ context, it would be much more accessible.
The current structure needs to be navigated as:
response["@graph"][0]["@graph"][0]["hydra:property"]
which throws away of the main advantage of JSON-LD,
namely that it is supposed to be "easily" usable as JSON.
>> Framing would be needed here.
>
> Elaborate, please. :)
JSON-LD framing (http://json-ld.org/spec/latest/json-ld-framing/)
allows JSON-LD documents to take a certain shape.
Only if the resource above is forced in a certain shape,
it would be usable as simple JSON as well.
So my argument is: simply mandating application/ld+json
does not necessarily simplify things for developers.
We probably need to impose a certain frame as well.
Best,
Ruben
Received on Tuesday, 6 October 2015 11:57:58 UTC