- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 30 Sep 2019 08:48:37 -0700
- To: Ivan Herman <ivan@w3.org>
- Cc: Benjamin Young <byoung@bigbluehat.com>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org>, Matt Garrish <matt.garrish@gmail.com>
- Message-Id: <F4FA2F0A-B8D2-4157-9C55-DBD8D82BB520@greggkellogg.net>
> On Sep 30, 2019, at 8:37 AM, Ivan Herman <ivan@w3.org> wrote: > > Yep. What this means is that if we use @direction in the Publication Manifest, then we do have to add a note that this is a 1.1 feature, and if an application uses a JSON-LD processor _and_ @direction is used, then it is necessary to use 1.1 I believe the feeling of the group was that you should normatively reference JSON-LD 1.1, not 1.0. You may note the specific 1.1 features you’re limited to, but the future is longer than the past, and I would expect that the distinction would fade pretty rapidly. Gregg > We can mitigate the effect if we do _not_ add a "direction":"@direction" alias into the publication manifest context. > > I realize the Publication manifest is not the JSON-LD WG's problem, but it is an obvious use case for the transition… > > Thx > > Ivan > >> On 30 Sep 2019, at 16:56, Gregg Kellogg <gregg@greggkellogg.net <mailto:gregg@greggkellogg.net>> wrote: >> >> We discussed this quite a bit at the F2F. IIRC, the feeling was that if schema.org <http://schema.org/> decide to use this, the impact would be limited, but would require the use of a 1.1 processor. And, not properly ignoring non-keywords that look like keywords could be considered a 1.0 bug, as the syntax spec says they should be ignored. >> >> Gregg Kellogg >> >> Sent from my iPad >> >> On Sep 30, 2019, at 6:59 AM, Benjamin Young <byoung@bigbluehat.com <mailto:byoung@bigbluehat.com>> wrote: >> >>> That's because of the schema.org <http://schema.org/> context using `@vocab`. If they didn't, then a JSON-LD 1.0 processor wouldn't choke. For example: https://tinyurl.com/y3vzjegw <https://tinyurl.com/y3vzjegw> (maps `name` directly in `@context`). >>> >>> Sadly, the most widely used context files (presumably Schema.org <http://schema.org/> and ActivityStreams) use `@vocab`. >>> >>> We did discuss this for a long while at TPAC...but I don't think we ever found a solution for old processors + `@vocab` containing context files... >>> >>> It's best expressed in this issue: >>> https://github.com/w3c/json-ld-syntax/issues/259 <https://github.com/w3c/json-ld-syntax/issues/259> >>> >>> Which resulted in reopening this one: >>> https://github.com/w3c/json-ld-syntax/issues/16 <https://github.com/w3c/json-ld-syntax/issues/16> >>> >>> We can make sure getting us all in sync around this status is on the agenda for this Friday. >>> >>> Cheers, >>> Benjamin >>> -- >>> http://bigbluehat.com/ <http://bigbluehat.com/> >>> http://linkedin.com/in/benjaminyoung <http://linkedin.com/in/benjaminyoung> >>> From: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> >>> Sent: Monday, September 30, 2019 4:29 AM >>> To: W3C JSON-LD Working Group <public-json-ld-wg@w3.org <mailto:public-json-ld-wg@w3.org>> >>> Subject: @direction in json ld 1.0 >>> >>> Maybe I did not remember right, but we thought that "@direction" should be absorbed by a JSON-LD 1.0 processor, ie, we can deploy it safely. However, the construction: >>> >>> >>> { >>> "@context":"https://schema.org <https://schema.org/>", >>> "name" : { >>> "@value": "na mi van", >>> "@language": "hu", >>> "@direction": "ltr" >>> } >>> } >>> >>> will not work either; there will be an error message due to the presence of value and direction in one object (see [1]). >>> >>> I guess we cannot do anything about it, but it is a bit of a pain:-) >>> >>> [1] https://tinyurl.com/y6goh76p <https://tinyurl.com/y6goh76p> >>> >>> >>> ---- >>> Ivan Herman, W3C >>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/> >>> mobile: +31-641044153 >>> ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704> >>> >>> > > > ---- > Ivan Herman, W3C > Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/> > mobile: +31-641044153 > ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704> >
Received on Monday, 30 September 2019 15:49:06 UTC