RE: JSON Schema (json-schema.org) support?

On Thursday, October 03, 2013 11:27 PM, Thomas Hoppe wrote:
> On 10/03/2013 05:17 PM, Markus Lanthaler wrote:
> > I just don't see much value in shipping data + a syntactic schema
describing
> > its structure. If I built a client, I can either trust the data you send
me
> > or I don't. In the first case I don't need a schema to validate it since
I
> > trust you anyway. In the latter a schema doesn't add any value because
just
> > as I don't trust your data, I won't trust your schema. Schemas are very
> > useful, but IMO only internally (except the case where you wanna
validate
> > some data against some standard).
>
> My use case is exactly the case you put in brackets -- data validation
> for create operations.

So, in other words, you express something like hydra:expects in terms of a
JSON Schema? Right? Well OK.. you could of course say that the schema's URL
identifies that standard.


> Side note:
> Apart from that I think with pure JSON there is value in shipping or
> better announcing a schema
> (a JSON Hyper-Schema e. g.) via Link header because
> that way the client can learn about links and validation rules.
> Discussing on this list implies we have JSON-LD and thus the linking
> part is better solved by using its capabilites.

Right. Pure JSON is a completely different story. The only interoperable way
to do it with application/json is to use a (Link) header as the body has no
semantics whatsoever.


> So how would you propose provide the client with instructions what data
> to send?

Hydra (since we are having discussions on both lists at the moment) :-P


> I think this is a perfect use case for JSON Schema, I'm just seeking for
> a way to tie these things together.
> In Hydra Core you've introduced "hydra:expects" which is nothing else
> than a facility to define a schema btw. ;)

Not a schema, a concept defined by a vocabulary. Hydra couples at the
semantic and not the syntactic layer. But you are right, to solve your use
case you could simply define a property similar to hydra:expects whose
values is a link to a JSON Schema.


> >> Is this the point where I'm supposed to hardcode strings like
> >> http://schema.org/Place
> >> and match it? Wouldn't it be more sensible to dereference also the type
> >> to learn more about about its anatonomy?
> >
> > That depends on the application but I don't see much value in getting a
> > description of the syntactic structure of data typed with that IRI.
JSON-LD
> > tries to raise the coupling to the semantic level instead of coupling at
the
> > syntactic level (which is quite brittle).
>
> Hmm, I'm not sure whether I can agree here... take the schema.org
> example I mentioned.
> When you browse the documentation (i. e. dereference the IRI in your
browser)
> you see a list of supported attributes. I think there is pretty much
> value in giving this
> information to a non-human client. Maybe is impossible on a global level
> as the underlying RDF model is not built like this (open world assumption)
> but think about a specific service like facebook; they surely set up
requirements
> in terms of mandatory attributes when creating an instance of a
> https://schema.org/Place.

I think we are partly talking past each other. What I mean by coupling at
the syntactic level is this. It shouldn't matter whether a client sends

{
  "@context": { 
    "name": "http://schema.org/"
  },
  "@id": "http://me.markus-lanthaler.com/"
  "name": "Markus Lanthaler"
}

or 

[
  {
    "@id": "http://me.markus-lanthaler.com/"
    "http://schema.org/name": "Markus Lanthaler"
  }
]

to a server. Both express exactly the same information. Nevertheless, the
differ syntactically and a JSON Schema wouldn't be able to express such
variability. Using a single vocabulary you could argue that such flexibility
doesn't offer any benefits but just raises the complexity. I fully agree. On
a large distributed, decentralized system as the Web where you potentially
wanna (re-)use multiple vocabularies it is, however, unavoidable IMO.
Without allowing that you make it almost impossible to reuse other people's
stuff and you end up with the situation we have right now. Everyone is
reinventing the wheel when designing a (JSON) Web API because it is
impossible to reuse existing concepts. 

I want to build systems in which I have to define very little myself. I
want, e.g., reuse as much as possible from schema.org so that I don't need
to write the necessary documentation etc. Schema.org however won't cover
everything I need. Thus, I define a few properties/classes myself (or reuse
them from another vocab) to fill those gaps.



--
Markus Lanthaler
@markuslanthaler

Received on Friday, 4 October 2013 10:32:56 UTC