W3C home > Mailing lists > Public > public-linked-json@w3.org > January 2015

Re: JSON-LD context file at schema.org - request for feedback

From: James M Snell <jasnell@gmail.com>
Date: Wed, 21 Jan 2015 06:19:20 -0800
Message-ID: <CABP7Rbdd7GZPGba4h=KaBSv=ZKc4n2fr-C+6kF3tCYix3RaJ7g@mail.gmail.com>
To: Dan Brickley <danbri@google.com>
Cc: Linked JSON <public-linked-json@w3.org>
We have similar cases with AS2 with properties that can be optionally
language tagged. The way we handle it is to map two terms to the same ID
with different types. You could do something similar.

  "@context": {
    "foo": { "@type": "@id", "@id": "s:foo"},
    "fooPlain": { "@type": "xsd:string", "@id": "s:foo"}

It's a pain but it works.

- James
On Jan 21, 2015 5:06 AM, "Dan Brickley" <danbri@google.com> wrote:

> Hello JSON-LD people!
> I'm looking for a sanity check on the basic functionality of
> schema.org's JSON-LD context file.
> The context is content negotiable from the site homepage but also
> available at  http://schema.org/docs/jsonldcontext.json.txt
> I realise it could potentially contain more information, e.g. actual
> schema assertions. But for now I would mostly appreciate review on
> whether it meets community expectations around the basics.
> https://github.com/schemaorg/schemaorg/issues/51 records an open issue
> regarding properties that might take either strings or URLs as values.
> I understand that for these, instance data can always use a "long
> form" and datatype accordingly, so the concern is more about
> defaulting when this isn't done. The relevant Python code is
> https://github.com/schemaorg/schemaorg/blob/master/api.py#L434
> http://schema.org/namedPosition takes both Text and URL values. The
> current context says
>         "namedPosition": { "@type": "@id" },
> which I believe means  "namedPosition": { "@value": "Quarterback" } is
> needed to override this.
> My feeling from the github discussion is that we should suppress this
> and default to text. E.g. Gregg commented that
> "When I generate my own JSON-LD context for schema.org I do not set
> @type to @id for properties where the range includes schema:text (or
> similar literal value). IMO, it's more intuitive for an author to use
> {"@id": "/foo"} than {"@value": "foo"}."
> I'd like to close out our basic context support before getting into
> any fancier business such as exposing the actual schema data, so any
> feedback on this or related points would be much appreciated.
> cheers,
> Dan
> p.s.
> http://googlewebmastercentral.blogspot.co.uk/2015/01/new-structured-data-testing-tool.html
> and
> http://googlewebmastercentral.blogspot.co.uk/2015/01/upcoming-events-in-knowledge-graph.html
> show some of the use we're making of JSON-LD lately around Google. In
> particular the new testing tool can extract JSON-LD, even (within
> reason) from a Javascript-generated DOM...
Received on Wednesday, 21 January 2015 14:19:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:43 UTC