RE: Introduction and a question about JSON-LD

Hi Markus,

> On July 27, 2014 at 2:59 AM Markus Lanthaler <markus.lanthaler@gmx.net> wrote:
>
>
> On 26 Jul 2014 at 02:06, john.walker wrote:
> >> On July 26, 2014 at 6:37 AM Markus Lanthaler wrote:
> >> On 25 Jul 2014 at 13:37, john.walker wrote:
> >>> As you can see I used the Schema.org context off GitHub served
> >>> via RawGit so that it plays nice in the JSON-LD playground.
> >>> Ideally you would just need to use "http://schema.org/", but that
> >>> doesn't work in the playground (guess it sends wrong Accept
> >>> header when fetching the context).
> >>
> >> Which browser do you use? It works for me in the latest versions of
> >> Chrome, IE, and Firefox.
> >
> > I'm using Chrome Version 36.0.1985.125 m
> >
> > It's not that it throws an error, more that the resulting N-Quads are
> > not what I expect.
>
> Oh OK. That's a different story then :-)
>
>
> > EXAMPLE 1:
> >
> > {
> > "@context": [
> > "http://schema.org/"
> > ],
> > "@id": "dimitri",
> > "homeLocation": "Tilburg"
> > }
> >
> > Yields:
> >
> > <http://json-ld.org/playground/dimitri> <http://schema.org/homeLocation>
> > "Tilburg" .
>
> Yeah. This is correct and is what (I think) most people would expect. Please
> note that schema.org allows string literals to be used almost anywhere.
>
>
> > EXAMPLE 2:
> >
> > {
> > "@context": [
> > "https://rawgit.com/json-ld/json-ld.org/master/contexts/schema.org.jsonld"
> > ],
> > "@id": "dimitri",
> > "homeLocation": "Tilburg"
> > }
> >
> > Yields:
> >
> > <http://json-ld.org/playground/dimitri> <http://schema.org/homeLocation>
> > <http://json-ld.org/playground/Tilburg> .
> >
> > Note that in example 1 the object is a literal value, but in example 2 is a
> > URI.
> > My mistake was assuming these two context documents had the same content.
>
> The schema.org context on json-ld.org was more or less a hack to have
> something till schema.org publishes their context. It hasn't been updated for
> quite a while. I will propose to delete it to avoid further confusion.
>
>
> > However it seems that schema:hasLocation is not defined as having @id as the
> > @type in the context served from http://schema.org/
> >
> > So in conclusion the playground is working fine :) , but the 'official'
> > Schema.org context could do with a few additions :(
>
> Type-coercing properties to @id should only be done if string literals don't
> make much sense. Thus, the heuristic that is used when creating the Schema.org
> context is to look for schema:rangeIncludes schema:URL. If URL isn't in the
> range, the property won't be coerced to @id.
>

OK, I get the idea. What threw me was seeing schema:ContactPoint and
schema:Place as the expected type for the value, so jumped to the conclusion
that these *should* be things (not strings).

> As you know, you can always easily overlay those type-coercions yourself:
>
> {
> "@context": [
> "http://schema.org/",
> { "homeLocation": { "@type": "@id" } }
> ],
> "@id": "dimitri",
> "homeLocation": "Tilburg"
> }
>
>

Is it also possible to use this external/local structure in a standalone context
document (that I can reference to in another JSON-LD document).
So for example there might be one context with the minimal type definitions that
could then be 'imported' in another context that overlays the more specific
types.

As an example schema:birthDate is defined as @type schema:Date in the Schema.org
context, but I know for my data that I always use xsd:dateTime so in my local
context I override the type.

I assume it this works on "most-recently-defined-wins" basis.

Cheers,
John

Received on Sunday, 27 July 2014 08:42:01 UTC