RE: Please help with JSON-LD processing

On 9 Jul 2014 at 10:49, Tomasz Pluskiewicz wrote:
> On Wed, Jul 9, 2014 at 12:11 AM, Markus Lanthaler wrote:
>> 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.

You mean the application controlling/driving the Hydra client requests a compacted resource, right? Makes sense.


>>> 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.

Yeah, to really get every possible operation and link, you would need to reference all of them. I'm still a bit on the fence about that because it is extremely inefficient in most cases. I was thinking about adding a statement to the spec that basically requires all links and operations to be declared either in the ApiDocumentation or inline so that there are only those two places for a client to look at. Of course people can place information also directly in vocabularies but then it wouldn't be guaranteed that those things are discovered *unless* they are also referenced by a apiDocumentation HTTP Link header.


> 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()

Do not forget that a representation can contain information about multiple resources. Think of the representation of a collection. There's not only the collection itself but also a number of members of that collection and each of them can support various links/operations.


> 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?

Yep. There *probably* also needs to be a way to find out what parameters are available.


>>> 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

Since the context is supplied by the application and not defined by the client library itself, this is probably the most difficult thing to implement.


> 2. expand, discover links/operations and compact in the end

I would separate them. Instead of expanding I would flatten or frame the response to discover links and operations and separately compact (frame?) the response for the application using the client library.


> 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.

There's no difference regarding external resources IMO.



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 9 July 2014 16:08:08 UTC