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

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?

I think it might. Rdf has been used for flexible meaningful messaging for systems integration, but maybe its open world assumption and lack of graph constraint validation kept it from catching on for that. So I am wondering if there is another similar useful case that might encourage developers, where Hydra/JSON-LD is used only to set up communication via the API, i.e. perhaps for tooling for generation of code at both ends, and/or the creation of the messages, but not outside that narrow function. 
As an experiment I wrap a non-semantic, server side application in a Hydra-type API, and create a client that uses a JSON-LD-aware stub (using a JSON-LD processor and optionally a triple store) for API communication. Application-level manipulation and validation is done on plain JSON trees.

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.

Thanks for the pointer to the example. I'm interested in 'framing' but haven't got my head round it yet.

Paul.

______________________________________________________________
> Od: "Markus Lanthaler" <markus.lanthaler@gmx.net>  
> Komu: <p_j_anderson@volny.cz>, <public-hydra@w3.org>
> Datum: 14.08.2016 19:07
> Předmět: 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 23:33:20 UTC