Re: JSON-LD context for schema.org - work in progress

Hi Dan,

Great to see you're working on this!


On Thu, Apr 17, 2014 at 5:30 PM, Dan Brickley <danbri@google.com> wrote:

> On 17 April 2014 12:36, Dan Brickley <danbri@google.com> wrote:
> > Hi folks
> >
> >  curl -v -H "Accept: application/ld+json"
> http://sdo-context-test.appspot.com/
> >
> > ... is a start at JSON-LD context file serving. For now it just emits
> > a static file that I built with a script from Niklas,
> > https://gist.github.com/niklasl/7873635
> > https://github.com/json-ld/json-ld.org/pull/297
> >
> > My main concern is that this should not impact human users, so the
> > content negotiation settings are a bit conservative: if the client
> > asks for JSON-LD and does not mention HTML or XHTML in its request, I
> > send JSON-LD. Otherwise (and regardless of ;q=0.6 -style HTTP
> > subtleties, I send the normal HTML.
>

That sounds quite reasonable. I wouldn't expect any problems in practise,
since implementations looking for a context really only want it in JSON-LD,
and so shouldn't ask for any fallback formats.



> > Once we're happy with the HTTP mechanism, let's talk about what
> > actually goes into the file.
>
> Let's start that conversation.
>
> Strawman:
>
> {
>   "@context": {
>       "partOfSeries": {"@type": "@id" }
>       "servicePostalAddress": {"@type": "@id" }
>       "workLocation": {"@type": "@id" }
>       "arterialBranch": {"@type": "@id" }
> ...
>  }
> }
>
> https://gist.github.com/danbri/10991489
>
> this lists as @id every property that has at least one non-literal
> expected value type, and leaves the rest to defaults.
>
> Workable?
>

There is a potential problem with this approach. With value coercion, any
non-object value for the property has to be a valid URL (or CURIE) string.
If it isn't, the result will be an invalid @id value. Actually,
implementations of the API algorithm (e.g. the JSON-LD playground) seem to
create a JSON-LD object with a malformed URL ("@id" value). Example:

    {
      "@context": {
        "@vocab": "http://schema.org/",
        "creator": {"@type": "@id"}
      },
      "creator": "Niklas Lindström"
    }

Which yields the triple:

_:b0 <http://schema.org/creator>
<http://json-ld.org/playground/NiklasLindström> .

Coercion is just a syntactic shorthand without any error correction or
smart fallback. It is great for when values are given as strings but always
expected to represent a URL or specific datatype, but that's all.

So the only way to get correct data for properties expecting either strings
or things, is to either not coerce them (which I'd recommend in general),
and thus to and require thing values with only a URL to be written like:

      "creator": {"@id": "http://neverspace.net/id#self"}

Or to do coercion, and require plain strings to be written like:

      "creator": {"@value": "Niklas Lindström"}

Which looks odd and is probably hard to teach. (And it would be better to
use "name" or "alternateName" there anyway.)

I think the better option at this stage of the game is for consumers to
recommend explicit object values for these "hybrid" properties (taking
strings or things), but perhaps to look for string values that look like
URLs and automagically coerce those if needed.

Cheers,
Niklas



> Dan
>