Re: JSON Hyper-Schema

And then there is https://github.com/antoniogarrote/json-ld-macros.
Makes json-ld from json.

Best regards,
Dietrich

Am 05.04.2015 um 13:33 schrieb Miguel:
> Hi everybody,
> thanks again for the feedback.
> I have been traveling these days and delayed the reply, but I would
> like to keep discussing these ideas with you.
> 
> I have found Jsonary [1,2], that is a tool that allows to use JSON
> Hyper Schema the way I was thinking too: to add "semantics" to
> existing JSON-based web APIs.
> The author, Geraint Luff, has even built as proof of concept an
> adapter for part of Facebook API [3].
> What I like of that approach is that is mostly based on a declarative,
> static specification of the mapping (using JSON Hyper Schema), with
> just a few tweaks for authentication.
> 
> I would like to find something similar but based on the RDF data
> model, in order to adapt native APIs like Facebook or Gmail to a
> Linked Data standard API like Hydra Core or LDP Server.
> I am trying to build a draft example of a Gmail adapter using Hydra
> Core and JSON-LD contexts, but I still have to better understand Hydra
> Core.
> 
> The Restbucks example was very useful to understand a lot of Hydra concepts.
> But in that example the affordances are always dynamically attached to
> instance data.
> I guess that the Hydra concepts of Class, Property, Link and Operation
> allow also a static description of an API, but I am still not
> completely sure of how to do it.
> It would be useful to have an example of such use of Hydra.
> 
> I guess that in a static description with Hydra Core most of the cases
> of "taking away a transition" as result of a state change could be
> managed by subclassing and changing the type of the relevant instance
> dynamically from a subclass to another.
> 
> Best regards,
> Miguel
> 
> [1] http://jsonary.com/
> [2] https://github.com/jsonary-js/jsonary
> [3] http://jsonary.com/walkthrough-facebook/stage2-schemas/
> 
> On Wed, Mar 25, 2015 at 1:48 AM, Dietrich Schulten <ds@escalon.de> wrote:
>> Hi Miguel,
>>
>> the concern of Json Schema and Hyperschema is to constrain data types of json attributes, and to describe expected json objects for http method request bodies which can be used on certain resources. E.g. "In order to post to that resource, always use this object type with such and such attributes".
>>
>> The concern of json-ld is to assign linked data names to json attributes, effectively underlaying an RDF model to a json object. Plus, optionally, to apply type information which allows a jsonld processor to interpret json types as RDF literals.
>>
>> I do not see that json-schema integrates RDF and I think it would be difficult to integrate linked data names right into json schema - it has no notion of that. But both can be applied independently to a given json.
>> The @context could say "firstname is schema.org/givenName" and the json schema could say it must appear etc.
>>
>> One limitation of hyperschema is that supported operations and request types are statically defined. That means, the server cannot take away a transition because the application state would require it. Not a good match for HATEOAS. Hydra is more flexible in that regard.
>>
>> The descriptive power for expected request objects in hydra is limited. For that we need help from an external vocab.
>>
>> Compared to json-schema, the SHACL draft from the RDF shapes WG aims at describing constraints specifically for RDF. I tend to see that as a better match than json-schema in the mid-term. If you are into schema.org, http://schema.org/PropertyValueSpecification is officially out there and may be used.
>>
>> Which language or platform is your existing service running on?
>>
>> Best regards,
>> Dietrich
>>
>> Am 22.03.2015 03:52 schrieb Miguel <miguel.ceriani@gmail.com>:
>>>
>>> Hi,
>>> I stumbled upon JSON Hyper-Schema [1], a module defined on top of JSON
>>> Schema [2].
>>> It seems to me a sort of JSON-LD (with a more powerful templating
>>> mechanism) + Hydra Core Vocabulary (without description of available
>>> operations).
>>> Possibly it could be used to build an LD (maybe even Hydra) front-end
>>> to existing JSON-based Web APIs (at least simple ones). The REST
>>> support is quite limited (just GET and POST) but that could be
>>> extended somehow.
>>> What do you think of it?
>>>
>>> Have you considered some form of integration or reference to that spec?
>>> Do you know if there is work going on on that?
>>>
>>> Thanks,
>>> Miguel
>>>
>>> [1] http://json-schema.org/latest/json-schema-hypermedia.html
>>> [2] http://json-schema.org/latest/json-schema-core.html
>>>
>

Received on Sunday, 19 April 2015 08:27:31 UTC