Re: Please help with JSON-LD processing

On Wed, Jul 9, 2014 at 6:07 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> 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.
>

That's a good point. Each resource contained in a representation
should get equal processing treatment to discover the links
operations. In fact each such resource should be a separate JavaScript
object, so if they are shared, they are accessed be reference. Also as
a client I would expect the JSON object to always contain the actual
requested resource as the tree's root, regardless of how the raw
response was structured.

I know there is a work item for an 'objectify' operation [1]. Does it
intend to achieve a similar goal when implemented?

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

I think I know what you mean, but could you please elaborate. Are
there some edge cases you are concerned about?

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

You're right of course. I would just dereference each required
resource this way or another and then put it is a store or process its
JSON-LD representation depending on the approach. Not much of a
difference after all.

>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>

[1] https://github.com/json-ld/json-ld.org/issues/140

Received on Wednesday, 9 July 2014 19:57:06 UTC