- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Thu, 4 Dec 2014 12:34:52 -0800
- To: "Kesterson, Robert D" <robert.d.kesterson@lmco.com>
- Cc: John Walker <john.walker@semaku.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
- Message-Id: <93F6C1EF-34B9-4FA6-869D-EBFB022CA101@greggkellogg.net>
> On Dec 4, 2014, at 11:44 AM, Kesterson, Robert D <robert.d.kesterson@lmco.com> wrote: > > Gregg and john, > > Thank you for the help…. Maybe I am expecting too much of json-ld and the tooling. What I expected was that an implementation of the json-ld would “validate” that the document was correct. Correct meaning that the document made a valid use of the vocabulary the context asserted that it used. Additionally, I expected that the implementation would have a form of type verification that is, assume the following: > > { "@context" : { "ex" : "http://example.org/" , > "sch" : "http://schema.org/", > "actor" : { "@id" : "ex:actor" , "@type" : "sch:Person"}, > "crime" : {"@id" : "ex:crime"} > }, > "actor" : { > "@id" : "http://example.org/actor/1", > "@context" : {"@vocab" : "http://schema.org/"}, > "name" : "Robert Paulson", "foo" : "bar" } > } > > In this case I would expect the implementation would see that actor is a sch:person then populate the node with the @type and assert an @vocab of “http://schema.org/ and either error or ignore the foo term. > > My concern/wish is that if I use json-ld my code will need to I ensure that the document follows the contract that is made in the context. I am looking at the context as providing a set of element/node level xsd like schema definitions and that a json-ld implementation would validate that the document against those schema’s. Not sure what value a format has if nothing is enforcing conformance, perhaps I don’t understand the use case well enough. > > Am I off base? Is Json-ld meant to be a self-defining message format? > No, JSON-LD is just another syntax, like Turtle or Microdata. Validation is left to other tools. You can try http://linter.structured-data.org <http://linter.structured-data.org/>, which does validation against schema.org <http://schema.org/> for most forms, including JSON-LD. Gregg > Thank you > Robert > > From: Gregg Kellogg [mailto:gregg@greggkellogg.net] > Sent: Thursday, December 04, 2014 1:33 PM > To: Kesterson, Robert D > Cc: public-linked-json@w3.org > Subject: EXTERNAL: Re: validation of json-ld to context schema > > On Dec 3, 2014, at 12:29 PM, Kesterson, Robert D <robert.d.kesterson@lmco.com <mailto:robert.d.kesterson@lmco.com>> wrote: > > Hi, > > I found the schema.org <http://schema.org/> context (by using the ACCEPT header and curl). However, what was returned confused me. I expected the context to layout the type/class hierarchy of the vocabulary but instead it provided a limited number of key names definitions. > > When I use Google Email Markup Tester it does validate the keys are allowed for a given type, but I don’t see how the context at schema.org <http://schema.org/> provides the information that a type of Person exists. Hence my question is how is this validation done with schema.org <http://schema.org/>? Not asking how goggle does it, but how does the spec direct the look up that a Person is a type? > > I auto-generate a schema.org <http://schema.org/> context using code in my implementation (see https://github.com/ruby-rdf/json-ld/blob/develop/etc/schema.org.jsonld <https://github.com/ruby-rdf/json-ld/blob/develop/etc/schema.org.jsonld>); it also includes the entire vocabulary definition (in this case, laid out for rendering using D3.js). Downside is that it is a bit chunky, but a JSON-LD processor using it as a context will ignore the vocabulary bits. > > Someday, Google may publish something more like this. I’ve encouraged Dan to use something like this, but the Ruby toolset has been a barrier for that infrastructure. But, I agree that a more complete context/vocabulary definition at http://schema.org/ <http://schema.org/> would be a good idea. The HTTP version could use rel=describedby to reference the vocabulary too. > > Gregg > > > Thank you, > > Robert > > > >
Received on Thursday, 4 December 2014 20:35:22 UTC