JSON-LD Working Group Telco — Minutes

Date: 2019-08-09

See also the Agenda and the IRC Log

Attendees

Present: Adam Soroka, Benjamin Young, Ruben Taelman, Pierre-Antoine Champin, Gregg Kellogg, Tim Cole, Dave Longley

Regrets: Rob Sanderson, David Newbury

Guests:

Chair: Benjamin Young

Scribe(s): Pierre-Antoine Champin, Benjamin Young

Content:

1. Scribe Selection

2. Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-08-02-json-ld

Gregg Kellogg: +1

Ruben Taelman: +1

Adam Soroka: +1

Ivan Herman: +1

Tim Cole: +1

Pierre-Antoine Champin: +0

Resolution #1: minutes approved

3. Announcements / Reminders

3.1. Standing TPAC reminder

Benjamin Young: I hope everyone’s booked

Ivan Herman: if the DID WG is accepted, there will be a F2F on Monday
… that might cause a conflict with the Web Publishing WG

4. issues

4.1. Consider obsoleting use of blank nodes for properties and “generalized RDF”

Benjamin Young: See Issue 37

Benjamin Young: we more or less already agreed to deprecate this one
… but it turns out that ActivityStreams is using a bnode @vocab
… Note that AS is part of AvivityPub, which is used by Mastodon and other
… All those people get worrying warnings when using the AS context.

Gregg Kellogg: there is a comment in there, indicating that they don’t believe that they are actually creating any property.
… pchampin suggested to raise the warning only when the bnode @vocab does create a bnode property
… I think that solves Mastodon’s issue. I did it in my implementation.

Benjamin Young: could this warning be limited to 1.1 mode?

Gregg Kellogg: yes

Benjamin Young: is this the default? because these people are not parsing JSON-LD 1.1, AFAIK

Gregg Kellogg: actually, that’s right, the warning is not mode dependent
… the purpose of the warning is precisely to warn people that his may go away in the future

Ruben Taelman: are these warnings specified in the spec or implementation specific?

Gregg Kellogg: the spec says “feature at risk”. It does not actually says anything about issuing a warning.
… We indeed do not specify how warnings are issued.
… I usually use a ‘validation’ flag to decide whether warning are issued or not,
… although obviously I didn’t to that in that case.

Benjamin Young: https://w3c.github.io/json-ld-api/#h-issue-0

Benjamin Young: https://w3c.github.io/json-ld-api/#h-note-3

Benjamin Young: distributed documents are long lived,
… we should take this into account when it comes to issuing warnings.
… The person we are targetting here is the context author.
… Hence my suggestion to limit the warning to 1.1 mode,
… meaning “it will still work here, but may break in the future”.
… People mining old 1.0 data will get the warning, but there is nothing they can do about it.

Gregg Kellogg: without warnings, the developers will not get pressure from their user to drop deprecated features
… the ‘validation’ flag is probably a good way to solve this

Dave Longley: there are a lot of implementations that can only report errors, not warnings

Benjamin Young: so do we need to change the spec?

Gregg Kellogg: https://www.w3.org/TR/json-ld11-api/#algorithm-2

Gregg Kellogg: we need to be clearer about the bnode properties

Benjamin Young: should we recommend an alternative to the bnode $MD_CODE$?
… such as a “fake bnode” IRI acting as a catch-all for undefined properties?
… The AS context shows that there is a need for that;
… JSON users do not like their properties to disappear through JSON-LD processing.

Gregg Kellogg: the most suitable replacement would be "@vocab": "#"
… this is common in other uses of RDF,

Dave Longley: +1 to "@vocab": "#"

Gregg Kellogg: and the reason why we allowed relative IRIs as @vocab

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/37#issuecomment-515799176

Benjamin Young: and in the spec

Gregg Kellogg: If we provide such an alternative to bnode properties, we can change the ‘AT RISK’s to simple notes.

Benjamin Young: https://www.w3.org/TR/json-ld11/#h-issue-0

Dave Longley: when we go to CR, I’m afraid people would object to bnode properties if we remove the ‘AT RISK’…

Gregg Kellogg: these AT RISK are not normative. We could leave them for CR, and remove them afterwards.

timecole: for me the purpose of ‘AT RISK’ is testing; it draws the attention to points that we are not sure can be implemented.

Ivan Herman: timCole is right. It is used to mark features that can be removed if they lack implementation, without having to go through CR again.

Proposed resolution: turn blank node issue https://www.w3.org/TR/json-ld11/#h-issue-0 into a note to suggest new context authors avoid using "@vocab": "_:" as well as direct use of blank nodes as properties. (Benjamin Young)

Ivan Herman: +1

Tim Cole: +1

Gregg Kellogg: +1

Benjamin Young: +1

Ruben Taelman: +1

Adam Soroka: This would be a note that accompanies 1.1?

Dave Longley: +0 fine with me

Pierre-Antoine Champin: +1

Adam Soroka: +0.5

Resolution #2: turn blank node issue https://www.w3.org/TR/json-ld11/#h-issue-0 into a note to suggest new context authors avoid using "@vocab": "_:" as well as direct use of blank nodes as properties.

Gregg Kellogg: we will then turn the ‘AT RISK’ issues into notes;
… we will recommend to use # relative IRIs instead;
… we will suggest to issue a warning whenever a bnode property is generated.
… None of these points are normative. So they don’t need more WG action.

Dave Longley: if don’t have a base IRI set and use a relative IRI for the $MD_CODE$,
… then properties will still be dropped when converted to RDF.
… So we are improving the situation, but not solving it 100%.

Proposed resolution: close https://github.com/w3c/json-ld-syntax/issues/37 once blank node property issue is changed to a note (Benjamin Young)

Ivan Herman: +1

Benjamin Young: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Tim Cole: +1

Resolution #3: close https://github.com/w3c/json-ld-syntax/issues/37 once blank node property issue is changed to a note

4.2. What is null base URL for an embedded json-ld?

Ivan Herman: See Issue 103

Benjamin Young: the question is raised when JSON-LD is embedded in HTML or anything.

Ivan Herman: someone came up with this example involving data: URL and iframe,
… leading to a situation where the base URL is not clear.

Gregg Kellogg: the fact that it is in HTML does not change anything,
… the processor tries to determine the base URL based on the source document URL.

Proposed resolution: close #103 as wontfix because the JSON-LD document would be treated as if it were alone–and not embedded. (Benjamin Young)

Ivan Herman: the problem is the use of the data: URL. The question is not JSON-LD specific. It would be the same with HTML

Gregg Kellogg: this is a TAG issue

Ivan Herman: It is a HTML problem. Whatever HTML does, we do it.

Dave Longley: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Benjamin Young: +1

Benjamin Young: and if HTML has no answer wrt to the base URL, then you are on your own.

Ivan Herman: +1

Pierre-Antoine Champin: +1

Tim Cole: +1

Resolution #4: close #103 as wontfix because the JSON-LD document would be treated as if it were alone–and not embedded.

4.3. Please review https://github.com/w3c/json-ld-api/pull/132

Gregg Kellogg: See also the editorial PR issue from Pierre-Antoine

4.4. Link header for HTML and JSON-LD

Benjamin Young: See Issue 204

Gregg Kellogg: this was trying to rely to danbri’s concern about relying on content negotiation
… the best solution I came up with was to rely on a link HTTP header
… A JSON-LD processor expecting a context at a given URL would check for this header,
… and follow the link if any.

Ivan Herman: other people do that, with rel="manifest"
… the Web Publication WG does something similar with rel="publication"
… we can bikeshed about what rel value we want. But this makes sense.

Ruben Taelman: link headers are not always possible on static websites, e.g. github pages.

Benjamin Young: just to be clear, the link header we are talking about is a HTTP header, not HTML $MD_CODE$
… It is not as common as content negotiation on static sites.
… So we should specify that JSON-LD processors should first try content-negotiation,
… if it fails, it should try HTML (which implies embedding a HTML parser)

Dave Longley: +1 to link headers, -1 to involving HTML processing at all w/context processing as it breaks the ecosystem

Benjamin Young: then it should check the link header.

Pierre-Antoine Champin: I think this solution makes sense
… whether content negotiation has priority or not, I think this would be nice to have
… the way I saw it this was a way to get rid of a dependency on HTTP

Gregg Kellogg: this is all because the desire of schema.org (and may be others)
… to avoid doing content negotiation.
… Whenever we can’t do conneg nor HTTP headers,
… we are back to parsing HTML.

Dave Longley: I would be in favor of the link HTTP header solution,
… even if it does not solve all problems.
… I am against the reliance on HTML parser. This would break the ecosystem.
… Also, we should not make decision on the features that github pages have today.
… That may change in the future.

Benjamin Young: (a cosmetic argument that I missed)

Ruben Taelman: I don’t see the benefit of the link header over conneg;
… if a host supports one, it should supports the other, right?

Dave Longley: some static sites can do link headers.
… It requires less processing on the server side than conneg.

Pierre-Antoine Champin: +1

5. Resolutions