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

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

From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
Date: Wed, 21 Jan 2015 16:47:16 +0100
Message-ID: <54BFCA04.6040803@wwelves.org>
To: Dan Brickley <danbri@google.com>, Linked JSON <public-linked-json@w3.org>
CC: W3C Credentials Community Group <public-credentials@w3.org>
On 01/21/2015 02:05 PM, Dan Brickley 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.
Thanks Dan,

Yesterday during Credentials CG call[1] I brought up issue in
http://schema.org related to NOT including mapping in @context

 "url": "@id"

Open Badges Technical Specification[2] currently also uses url and maps
it[3]:

  "schema": "http://schema.org/",
  "url": { "@id": "schema:url", "@type": "@id" }

I also couldn't find past conversations about this issue even that
recall seeing them somewhere...

My main concerns relates to ending up with lots of not intentional
*blank nodes* if people use url and leave out @id!

Cheers!

[1] http://opencreds.org/minutes/2015-01-20/#64
[2] http://standard.openbadges.org/
[3] http://standard.openbadges.org/1.1/context.json


Received on Wednesday, 21 January 2015 15:47:41 UTC

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