W3C home > Mailing lists > Public > public-webpayments@w3.org > May 2012

Re: json-schema?

From: David I. Lehn <dil@lehn.org>
Date: Thu, 3 May 2012 18:34:15 -0400
Message-ID: <CADcbRRM6uQmn=b5qRKNNxwc5i7n5-OwohUwSR94=10b-p_0DGQ@mail.gmail.com>
To: David Nicol <davidnicol@gmail.com>
Cc: Web Payments <public-webpayments@w3.org>
On Wed, May 2, 2012 at 6:00 PM, David Nicol <davidnicol@gmail.com> wrote:
>
> http://json-schema.org/
>
> is this format compatible or not, with JSON-LD?
>

The quick answer is yes it is compatible in a limited context, but no
it's not easily compatible in the general case.

I haven't used JSON Schema but it is similar to the Monarch validator
system we use at Digital Bazaar in our PaySwarm implementation.  Both
are basically tree and leaf validators whereas JSON-LD can represent
the same linked data graph with a variety of representations.  We
accept JSON-LD in PaySwarm but, currently, you have to format your
JSON-LD in a specific way that works with our validators.  This is
sort of like "pre-framing" the JSON-LD data.  We added enough
validator features that make it possible to validate complex JSON-LD
but some of the validator code is a nightmare.  Parts that are too
complex to do in a schema language have to be done in code.  For the
PaySwarm work we've done so far the data we validate has fit into
validatable JSON tree structures, but that may not always work.

I think a JSON-LD specific schema language would simplify all this.
It would probably look much like what the RDF world uses.  I think the
theory is that a human readable vocab doc should be generated from a
schema doc (or the other way around via RDFa in the doc).  This schema
would have all the domain, range, type, and other info included.  I
think validating triples with such a schema is probably easier than
using JSON Schema on JSON-LD forced into a tree.  I'm guessing this
will turn into a larger side project than we are handling at the
moment.

As general theory of using linked data for APIs, this is all pretty
neat.  A system could accept lots of input formats as long as the
needed triples can be extracted.  Pass in n-triples, turtle, RDFa, or
JSON-LD, extract and validate triples, process and store however you
want internally, and produce whatever output format the clients want.
For ease of use in web apps, default to generating nice looking
JSON-LD with a known context and frame.  I imagine we'll head that
direction.

-dave
Received on Thursday, 3 May 2012 22:34:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 3 May 2012 22:34:45 GMT