- From: peter <peter.amstutz@curoverse.com>
- Date: Fri, 05 Dec 2014 11:36:00 -0500
- To: Nate Otto <nate@ottonomy.net>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, "Kesterson, Robert D" <robert.d.kesterson@lmco.com>, John Walker <john.walker@semaku.com>, "public-linked-json@w3.org" <public-linked-json@w3.org>
Just to chime in here, I have a json document that I want to make
compatible with json-ld. We're currently using json-schema for
validation. Unhappily, because json-schema "properties" have
semantically import keys with an unbounded range, you can't represent
json-schema itself using json-ld 1.0. This is an example where a
feature like "@container": "@id" (or "@container": "@label") is
necessary.
It's not clear what the right answer to validating json-ld is.
json-schema is not ideal for the above reason, RDFS is not very
powerful, and OWL is not really intended for validation (so I'm told).
Are there other options?
On Fri, 2014-12-05 at 16:13 +0000, Nate Otto wrote:
> We have been using JSON-schema to do syntactic validation for the new
> version of Open Badges (enforce required properties, data types,
> structure, etc). Though it isn't any standard beyond our own, we
> devised a way to link to the schema files from the context in order to
> declare that "contract" like you felt there should be.
>
> It took me a long time to figure out what JSON-LD was really for, I
> felt. But now I'm happy with how we eventually figured out how to
> combine these two technologies to do what we wanted to do.
>
> Nate Otto, Developer
> concentricsky.com
>
> On Thu, Dec 4, 2014, 12:36 PM Gregg Kellogg <gregg@greggkellogg.net>
> wrote:
> > 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, which does validation
> against 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> wrote:
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > I found the 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 provides
> > the information that a type of Person exists. Hence
> > my question is how is this validation done with
> > 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 context using code in my
> > implementation
> > (see 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/ would be a good idea. The HTTP version
> > could use rel=describedby to reference the vocabulary too.
> >
> >
> >
> >
> >
> > Gregg
> >
> >
> >
> >
> > Thank you,
> >
> >
> >
> > Robert
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
Received on Friday, 5 December 2014 16:35:50 UTC