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

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).


> 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).


> 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.



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 3 October 2013 15:18:13 UTC