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