Re: Non-semantic client libraries? : Hydra for aggregate roots, pagination and collection filtering

On 2016-08-15 01:32, p_j_anderson@volny.cz wrote:
> By semantic view, I mean when the data is treated as semantic (having
> a context) within the client code - i.e. JSON-LD or similar
> processing is also done outside the marshalling and unmarshalling of
> the API calls, in the application itself. I've noticed that there are
> some (mainly?) semantic web people interested, who presumably have
> semantic applications, but does Hydra stand purely as an API
> technology too, outside semantic applications, interesting for API
> and integration people?

This is probably down too client implementation. I have started 
implementing Heracles [1] in a way that hopefully will remove the 
requirement for JSON-LD processing in application code. The only side 
effect of Hydra (or actually RDF) will be the necessity of using URIs 
for identification of links, operations, contracts, etc.

All intricacies of Hydra/RDF will be hidden behind the client library 
API. The client library manipulates data on triple level but ideally it 
should not leak to the consumer code.

>
> I know that Hydra can be used for implementing performant,
> SPARQL-type queries as a lower level API (the fragments side of
> things). I'm not sure what is more important in the vision -
> fragments, or Hydra as a general API enabler - and whether it is
> mainly for semantic applications or for general integration too.

I wouldn't say either is more important. Hydra enables multiple paths by 
providing enough metadata about API endpoints. It's up to the client how 
it uses that information.

Regards,
Tom

[1]: http://github.com/wikibus/heracles

Received on Monday, 15 August 2016 07:53:33 UTC