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

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?

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

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

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

Many thanks, Paul

Received on Thursday, 11 August 2016 04:00:54 UTC