- 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