Re: Please help with JSON-LD processing

On Wed, Jul 9, 2014 at 12:11 AM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> +CC public-hydra
>
>
> On 8 Jul 2014 at 23:16, Tomasz Pluskiewicz wrote:
>> On Stackoverflow [1] Dave gave me some advice about how a client would
>> either expand or use a well-known context to compact a resource
>> representation to inspect its contents.
>>
>> I intend to implement a Hydra client,
>
> That's great!
>
>
>> which would allow passing a well-known context.
>
> What do you mean by this? Do you mean a client which can be "configured" by passing it a context?
>

I mean that the end client (as opposed to the Hydra client) can
request a resource compacted in a specific context.

>
>> Now I'm wondering what is your suggested algorithm to process the
>> resource to discover hydra:Links and hydra:Operations.
>
> It depends on what exactly you are trying to achieve. The Hydra console [2] does everything by just using JSON-LD that is framed by a proxy [3]. An alternative would be to convert everything to triples and put it in a triple store (client side) that can be queried to get the hydra:Links/Operations of interest.
>

I want to create the Hydra client to retrieve a resource and discover
all links and operations by looking at the representation and by
inspecting hydra:Classes and hydra:Links. Thus types and properties
would also have to be dereferenced.

My current approach is that the resource object will expose additional
functions, which will process the representation. So the usage would
something like below.

var resource = hydra.$get('/some/resource', context /* optional */ );

var links = hydra.$links();
links['http://some/link/propety'].$get();

var operations = resource.$operations();
operations['http://some/OperationType'].$invoke()

I expect the $get() and $invoke() methods on links and operations to
allow optional parameters such as template params or operation body.

Does this make sense?

>
>> 1.Would you keep an expanded/flattened document for processing and a
>> compacted to return to the client?
>
> Keep it where?
>

Keep in memory during representation processing. For example, the end
client requests a resource representing a person:

<AnakinSkywalker> a ex:Person; ex:knownAs "Darth Vader"; ex:child
<LukeSkywalker> .

The end client may want that resource as JSON-LD in a custom context

{ "alias": "ex:knownAs", "offspring": "ex:child" }

So the expected document should be

{
  "@context": { "alias": "ex:knownAs", "offspring": "ex:child" },
  "@id": "AnakinSkywalker",
  "@type": "ex:Person",
  "alias": "Darth Vader",
  "offspring": <LukeSkywalker>
}

And at the same time I would like to extract information about links
and operations and serve it

1. compact first and discover links and operation by processing the result
2. expand, discover links/operations and compact in the end
3. convert to triples, discover links/operations from those triples
and compact whenver, because these two processes are not
interdependent

Or maybe another approach would be better?

I kind of like the idea of processing triples, because it spearates
concerns. Though I expect it will be more difficult with external
resources, ie. types and properties that need to be dereferenced and
inspected. Unless there is a SPARQL processor in JS, which allows
fetching remote URIs from GRAPH patterns.

>
>> or
>> 2. Would you only keep the compacted document and use the
>> processContext() method to expand any prefixed URIs?
>
> No, I definitely wouldn't hack into the processContext method.
>
>
>> [1] http://stackoverflow.com/questions/23996953/json-ldhydra-link-discovery
> [2] https://github.com/lanthaler/HydraConsole
> [3] https://github.com/lanthaler/HydraConsole/blob/master/proxy.php#L95-L143
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>

Received on Wednesday, 9 July 2014 08:51:24 UTC