W3C home > Mailing lists > Public > public-hydra@w3.org > June 2014

Re: Hydra API discovery

From: Tomasz Pluskiewicz <tomasz@t-code.pl>
Date: Sun, 8 Jun 2014 15:04:20 +0200
Message-ID: <CAAFOhSdS3P5_y+iCrH-moqNZbEFg_rHzdCzmEZeAuEGVTwpOYw@mail.gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Cc: public-hydra@w3.org
On Fri, Jun 6, 2014 at 6:20 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> On Friday, June 06, 2014 8:39 AM, Tomasz Pluskiewicz wrote:
>> I've looked at the Building Next-Generation Web APIs with JSON-LD and
>> Hydra presentation by Marcus *again* :) and one detail is still
>> unknown to me. The example resource contains a comments property,
>> which is a hydra:Link.
>>
>> How would you propose to actually discover the URL of that property in
>> a Javascript app. I know of course that the information is right there
>> in the @context, but do you us the jsonld.processContext() function or
>> somehow manually follow the definitions?
>
> You mean to what URL the token "comments" expands to, i.e., http://www.markus-lanthaler.com/hydra/api-demo/vocab#Issue/comments?
>
> With JSON-LD we not only defined a serialization format, but also a number of processing algorithms:
>
>   http://www.w3.org/TR/json-ld-api/
>
> If you look at that document, you will find out that there exists something called Expansion. This is effectively what you call jsonld.processContext(). It expands all properties to full URLs, applies type-coercions etc.
>
>
>> That said I examined what the Hydra console does to find my answer and
>> actually I was surprised that the calls are proxied and by all the
>> "__activectx" etc in responses. I expected the service actually return
>> Hydra documents similar to those documented and then have the client
>> do the magic. Currently it actually looks a little bit like trickery,
>> because this is not how a generic client would work. By which I
>> understand tapping into any API entrypoint, which serves JSON-LD +
>> Hydra and discovering the links from there by examining the document
>> structure.
>
> There isn't really any trickery. It is still a generic client, but the functionality has, as you rightly point out, been split into a server-side and a client-side component. The reason for that was that in order to render the response that way it is rendered (tooltips, inline links etc.), you need a slightly modified JSON-LD processor. Namely one that expands the document, but, at the same time, also preserves the documents original structure. Standard JSON-LD processors don't do that, so you have to use a modified one.
>
> Since I implemented my JSON-LD processor in PHP and needed a proxy to work around same-origin limitations anyway, I decided to do all of that server side. But of course it could also be done entirely on the client. My modified JSON-LD processor can be found on GitHub [1] (look for the $debug flag). The proxy script to invoke it is also available [2]. Please note that framing isn't standardized yet so my implementation differs slightly from, e.g., jsonld.js [3].
>
> Does this clarify it?
>

I see. So to wrap it up your JSON-LD processor expands the original
document, analyzes the predicates and datatypes used to retrieve their
metadata and appends that information to the original document so that
it can be used on the client side to render a friendly UI. Is that
right?

>
> [1] https://github.com/lanthaler/JsonLD/blob/expansion-debug/Processor.php#L288
> [2] https://github.com/lanthaler/HydraConsole/blob/master/proxy.php
> [3] https://github.com/digitalbazaar/jsonld.js
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
Received on Sunday, 8 June 2014 13:05:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:53:59 UTC