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

On 10/03/2013 05:17 PM, Markus Lanthaler wrote:
> On Friday, September 27, 2013 10:02 PM, Thomas Hoppe wrote:
>> Hi Markus,
>>
>> The main purpose of this exercise is to link the schema to the document
>> - yes.
> OK
>
>
>> We use the Link header today in out solution to announce the
>> corresponding JSON schema,
>> with this I just wanted to propose a way link them in-band.
> >From an HTTP (REST) perspective using a Link header is just as in-band as
> the putting that information in the body.
>
>
>> In this solution it is intended that the client dereferences the type
>> and then will
>> get a JSON schema and if he understands JSON schema, he can do what a
>> schema is
>> useful for: introspect. I know that this is a little bit naive an you
>> don't like it but then allow me the following question:
>> What is the actual value of having a type which is not intended to be
>> dereferenced and I'm especially thinking about the schema.org "things"?
> You must have misunderstood me. I never (intended) to say that I don't like
> the follow your nose principle, i.e, dereferencing the URLs to get more
> information about them. That's the main idea behind JSON-LD.
>
> 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.

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.

So how would you propose provide the client with instructions what data 
to send?
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. ;)
>
>
>> 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.
>
>> One more thing:
>> Is a trailing '#' an indicator that a IRI is not dereferencable?
> No. It's basically a trick to serve multiple resources (entities) from a
> single URL. HTTP clients don't send the part after a #, i.e., the fragment
> identifier, to the server. So if you have two resources
> http://example.com/node#1 and http://example.com/node#2 you can retrieve
> them both with a single HTTP request: GET http://example.com/node That
> obviously doesn't work if you use a / at the end of your namespace prefix
> because then all different resources require separate HTTP requests.
I was aware of the fragment notation but I interpreted a statement from 
your previous mail
like the existence of a fragment is a hint that an IRI may not be 
dereferenced but I think
that was a misinterpretation.
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>

Received on Thursday, 3 October 2013 21:27:47 UTC