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

On 7 Aug 2016 at 15:30, p_j_anderson@volny.cz wrote:
> Hi all. I plan to use JSON-LD and Hydra for API's for language resources like
> terminologies, dictionaries and related taxonomies/ontologies.
> I've been looking in detail at the Python client examples and I hope you can enlighten me
> about a couple of things.
> 
> - Is it envisioned that client libraries will always present a *semantic* view of Hydra-based
> API's to a client developer?

What's a "semantic view"?


> Being able to see what the API means is great and it enables better tooling.
> And JSON-LD avoids the interop problems with object references and typing suffered by
> encoded-style SOAP because its typing and graph structure has meaning within the
> communication itself - they are not left to the implementing libraries to map and interpret at
> a higher level.
> 
> However, validating a graph doesn't have standard constraints yet AFAIK, and client

That is actively being worked on by the W3C Data Shapes Working Group


> libraries for REST are mostly not JSON-LD aware (I know JSON-LD is JSON, but in the
> sense that RDF/XML is XML - there's a layer with different characteristics built on top)

There exist JSON-LD processors for lots of programming languages...


> So another useful option might be to treat the message as plain JSON and
> as a tree, leaving any higher structure (graph references) to the app.

Sure.. I have been thinking of defining a profile for this but currently it doesn't exist. The coupling should be on the semantics and not a JSON structure. In the meanwhile you can frame the JSON-LD to bring it into a deterministic shape that can then be validated with standard JSON tools.


> Semantically aware mapping tools could generate adapters (maybe light,
> with no dependency on semantic libraries) and corresponding
> configuration for existing performant plain JSON client libraries, and
> maybe JSON validation configuration too for validating the tree
> structure. A non-semantic client  could then still use Hydra and JSON-LD
> for easy integration - just like a non-semantic server side app can be
> wrapped in the necessary API code.
> 
> - Is there an example Hydra API online that returns an *aggregated*
> resource containing e.g. an address as a blank (or _internally-named)
> node, or even independent but related nodes with URI's (e.g. the most
> recent comments on an issue, to save making another request)?

The demo API does that: http://bit.ly/hydra-console-event-api


> - Is there an example with pagination for a collection? Selection criteria on a collection?

We are still working on the design there so things might still change slightly in that area.



--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 14 August 2016 17:08:15 UTC