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

On 10/04/2013 12:32 PM, Markus Lanthaler wrote:
> 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.
Exactly.
>
>> 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 knew you would say that but I posted this question on the JSON-LD list 
for a reason.
The question was meant to be independent from an API scenario.
Meanwhile it became clear to me (also through your answers below) that 
the "semantic coupling" as you
name it works just like that or technically, that's how RDF works.
>
>> 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.
>
Let me ask one more question to verify whether I understood you:
The expects parameter is a pointer to a concept (i. e. RDF class)
and if I'm a client I should know what makes up an instance of this concept;
which properties it has and which validation rules apply?


>>>> 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.
Sure, this is to me one of the major "selling point" of the whole 
semantic Web.
I totally agree with you that it does not make sense to
expect the whole Web is using a canonical form to represent data -- 
JSON-LD is poly-morph --
but for the "writable Web" (opposite of read-only) you will need type 
introspection
and validation at the end of the day to allow for even more generic clients.
This brings me to the API scenario discussed above:
During writing my last response I also thought about something like 
hydra:expects
and I think I will give it a try.

>
>
> --
> Markus Lanthaler
> @markuslanthaler
>

Received on Friday, 4 October 2013 15:36:19 UTC