Re: The survey results are in and they look great

On 2016-06-18 11:20, Dietrich Schulten wrote:
>
> Am 17.06.2016 10:08 schrieb Tomasz Pluskiewicz <tomasz@t-code.pl>:
>>
>> Dietrich,
>>
>> I mean that there is little value in implementing the client so that
> in only ever processes JSON-LD. Internally too
>
> how does the client use rdf internally, as opposed to just using a
> serialization of rdf? Does it *need* to read incoming responses into a
> serialization-agnostic internal rdf model?

As I wrote, I find it quite cumbersome to handle JSON-LD in some 
scenarios. And it is RDF already so why not work with triples to process 
the ApiDocumentation and representations?

As a side effect support for RDF/XML, Turtle etc. comes out of the box.

>
> In my view, the client is a kind of "browser engine" which follows the
> application protocol to achieve a goal, using serializations of rdf as
> message formats.

I'd like to make the distinction here between the client library and the 
client as in consumer. I mostly mean the former when I write 'client'. 
I'll try to be more specific from now on.

> It might be sufficient to operate on the message
> directly to find hydra information. E.g. there could be a pluggable
> json-ld and turtle OperationFinder and a pluggable json-ld and turtle
> LinkFinder - that should be sufficient for "browser engine" operations.
>

Why separate OperationFinder/LinkFinder for JSON-LD and Turtle? The data 
model is the same, just serialized differently. That's why I prefer to 
normalize to in-memory RDF representation.

> Actually working with the non-hydra data the client receives is out of
> scope for the client, don't you think? The component which *uses* the
> hydra client would read a client result into a triple store and reason
> over the data if that is what it needs - not the hydra client.

Ah, see that is where we differ it seems. For me the consumer should be 
RDF-agnostic by default. So despite the fact that the client library 
does some RDF processing, I'm returning plain JavaScript objects so that 
it's easier to handle with JavaScript (my personal requirement is 
declarative data binding with Polymer, which doesn't like URI keys in 
JSON for one).

If, and only if, the consumer want some RDF manipulation, it should be 
possible to load in a store. But I'm willing to write in the 
documentation anything like 'to do X with the representation, load it 
into a triple store'.

Requiring developers to be familiar with RDF etc. will not make Hydra 
popular. We should model it with RDF in mind, yes, but proper tools for 
both client and server side should IMO try to hide the RDF nature of 
Hydra. I think this is the only way for Hydra to gain wider adoption.

>
> What I have in mind are small devices or SPA browser applications which
> use the client for API access. Hence the desire to stay lightweight.
> Requiring a javascript rdf library doesn't sound lightweight to me.
>

This may be the only practical reason. On the other hand I don't want to 
be overly optimizing just yet. rdf-ext gets me where I need quickest. If 
it proves too big or too slow then will be the time to a better 
solution. For now I prefer a feature-complete solution at the cost of an 
external dependency.

Best,
Tom

Received on Saturday, 18 June 2016 10:51:45 UTC