JSON-LD Working Group Telco — Minutes

Date: 2019-11-22

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Benjamin Young, Ruben Taelman, Pierre-Antoine Champin, Harold Solbrig, Adam Soroka, David I. Lehn, Tim Cole

Regrets: Ivan Herman, Dave Longley, Gregg Kellogg

Guests:

Chair: Rob Sanderson

Scribe(s): Ruben Taelman

Content:

1. Approve minutes

Proposed resolution: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-11-15-json-ld (Rob Sanderson)

Rob Sanderson: +1

Adam Soroka: +1

Harold Solbrig: +0

Pierre-Antoine Champin: +1

Ruben Taelman: +0

Benjamin Young: +1

Resolution #1: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-11-15-json-ld

2. Announcements?

Rob Sanderson: We have the open call for consensus to go for CR.

3. Issues

3.1. embedding issue #300

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/300

Rob Sanderson: All new issues are editorial, which is good for our transition to CR.
… The first one was about some confusion about how embedding worked.
… It was clarified in the issue, and there is a PR open to fix it.

Pierre-Antoine Champin: Gregg and I both submitted a separate PR to fix this problem.
… But now we merged both of them. So this issue should be closed once the PR is merged.

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/300

Benjamin Young: https://github.com/w3c/json-ld-syntax/pull/307

Pierre-Antoine Champin: The current sentence is wrong. The actual reason why embedding does not work is that nodes are unrelated to each other. So this is a reason to have @graph at the top level.
… I’ll make a change suggestion on the PR. After that, we can close the issue if everyone agrees.

Rob Sanderson: Part of the fix has been merged to master already, part of it not yet.
… Any further questions about issue 300?

Pierre-Antoine Champin: PR 307 can be closed because the fix was part of another PR.

Rob Sanderson: So issue 300 can be closed then.

3.2. Stars on type on example 13

Rob Sanderson: Next one is about the stars. This has been solved and is closed.

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/303

3.3. Clarify language in JsonLdProcessor API

Rob Sanderson: Next, two issues on API.

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/212

Rob Sanderson: First one is about the use of WebIDL and the JavaScript-specific language that WebIDL has.

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/212#issuecomment-556476697

Rob Sanderson: The language talks about JS-specific promises to talk about asynchronous operations, while other languages may not have promises.
… Gregg already clarified that we settled with WebIDL, but we don’t require promises, it’s just a way to get it into WebIDL. Gregg suggested to add a note saying that you don’t have to implement promises to do async operations.
… The way forward on this one is clear.

3.4. Expansion with blank node mapped prefixes

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/219

Rob Sanderson: On this next issue, the author started from scratch. So he saw something that does not usually occur in brand new implementations.
… If you have a blank node prefix without a non-gen-delim char at the end, it is expected to be used as a prefix in the tests, but the spec does not describe this strictly.
… We can’t remove features, so we have to allow this.

Pierre-Antoine Champin: https://github.com/w3c/json-ld-api/issues/205

Pierre-Antoine Champin: This seems related to a previous issue where this was discussed.
… Gregg came into a similar problem where a bnode was used as a prefix.
… I thought we settled on this, and marking those tests that rely on bnodes as prefixes as 1.0-only.
… In practice this is a breaking change in 1.1.
… At the time we agreed that anyone in their right mind would do this. So this wasn’t a problem.
… I guess that the solution to this issue would be to mark this as a 1.0-only test as well.
… Not sure why Gregg didn’t suggest this, perhaps he overlooked the link to the previous discussion.
… I will add it to the issue.

Rob Sanderson: Those were the raised issues.

4. Document Process Issues

4.1. Transition to CR

Rob Sanderson: We agreed on the last call that we would leave the call for consensus open until Monday.
… Today, we can have a resolution to go for CR if no one else puts in a -1 on the mailinglist before Monday.
… This allows Ivan to send it to the director then to request the transition.

Proposed resolution: In the absence of any objections before the close of the CfC, the WG resolves to transition to CR on Monday November 25th (Rob Sanderson)

Rob Sanderson: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Adam Soroka: +1

Harold Solbrig: +1

David I. Lehn: +1

Benjamin Young: +1

Resolution #2: In the absence of any objections before the close of the CfC, the WG resolves to transition to CR on Monday November 25th

4.2. Java implementation

Rob Sanderson: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Nov/0024.html

Rob Sanderson: There was an e-mail to the list about the Java impl from David Booth, which prompted a little thread.
… There is a Java 1.1 impl that has 1/3 failing tests, which is good.
… They have similar reasons, so they may start working at the same time soon.
… Someone will start updating early next week.
… We always said we needed the Java impl as code.

Harold Solbrig: We started to prototype the use of 1.1 in healthcare, and it’s been successful, and the Java impl will be important for this.

Benjamin Young: Next phase of this is that fabulous like this start happening, so we have to write things like blog posts to increase visibility.

4.3. Best Practices Doc

Harold Solbrig: We’re going to need a more approachable document, like a primer.

Rob Sanderson: Where are we with BP?

Benjamin Young: https://github.com/w3c/json-ld-bp/pull/17

Benjamin Young: This PR restructures everything to make suggestions.

Rob Sanderson: https://github.com/w3c/json-ld-bp/issues/1

Rob Sanderson: This PR would close issue 1.

Adam Soroka: https://github.com/w3c/json-ld-bp/issues/15

Benjamin Young: Several new sections, and API-related sections from 1.0.

Rob Sanderson: +1 to removing non-spec practices

Benjamin Young: My plan is to take the API-related things out, and capture the things that have come across in the last months.
… Any help on this is welcome.

Benjamin Young: https://w3c.github.io/json-ld-bp/

Benjamin Young: How should we look at the current document state.
… It is github-pages-based.

Rob Sanderson: We should now look through what there is now. And propose new sections through issues, with some ticks on what the issue is.

Benjamin Young: If you don’t have time, just write it down in an issue, and then we can figure out where to put it later.

Rob Sanderson: We have some time left, so let’s brainstorm on some issues.

Pierre-Antoine Champin: I just realized that Gregg mentioned in his regrets something.
… He said that there may be a WG decision needed.

5. API #219 redux

Pierre-Antoine Champin: he would be more comfortable to keep the spec text as-is, and that we are introducing a breaking change in a note.
… He wants to record this as a decision.

Benjamin Young: gkellog’s note about #219 https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Nov/0033.html

Rob Sanderson: We’re stuck with it, especially as we plan to go for CR.

Pierre-Antoine Champin: He wants to keep the spec as-is, but mark the tests as 1.0-only, and continue on the same path.
… Nobody is affected by this change.

Benjamin Young: It was an accidental feature in 1.0.

Rob Sanderson: So it is not a breaking change, but a clarification that this should never have been possible.

Benjamin Young: It would be good to see where this can actually be used. And if it has widely been used in practise. Probably no one did.

Pierre-Antoine Champin: If we want to support it now, we would have to change some normative text right before CR.

Benjamin Young: This won’t happen.

Proposed resolution: Keep the current text as clarification that blank node as prefix was never intended to be a feature, just a side effect of loose 1.0 text (Rob Sanderson)

Rob Sanderson: If there was a test, it was supposed to be a feature, right?

Benjamin Young: [https://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%7B%22%40vocab%22%3A%22%3A%22%2C%22term%22%3A%22term%22%7D%2C%22term%22%3A%22hi%22%7D](https://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%7B%22%40vocab%22%3A%22%3A%22%2C%22term%22%3A%22term%22%7D%2C%22term%22%3A%22hi%22%7D)

Benjamin Young: {"@context": {"@vocab": "_:", "term": "term"}, "term": "hi"}

Benjamin Young: This case will occur when someone when someone without much knowledge of jsonld will use it.

Pierre-Antoine Champin: The alternative would be to go for Gregg’s proposal, to add a sentence to explicitly allow that.

Rob Sanderson:

{
"@context": {
  "@vocab": "_:",
  "term": "term",
  "pre": "_:pre",
  "fix": "pre:fix"
 },
"term": "hi",

Pierre-Antoine Champin: This is normative text. That’s meaning that’s already carried by the tests.

Rob Sanderson: “fix”: “me please”

Rob Sanderson: }

Rob Sanderson: –>

Benjamin Young: the extension use case {"@context": [{"@vocab": "_:"}, {"term": "term"}], "term": "hi"}

Rob Sanderson:

"_:prefix": [
{
  "@value": "me please"
}
],

Rob Sanderson: The prefix thing is what’s currently broken.
… Currently, this case above works in 1.0, but not in 1.1 when you implement it from scratch.
… If people don’t remove it from their 1.1 impls, we would have inconsistencies.
… I think we should fix the typo which removes this feature unintentionally. Even if it is a stupid feature.

Pierre-Antoine Champin: https://github.com/w3c/json-ld-api/blob/main/tests/expand/0118-in.jsonld#L31

Pierre-Antoine Champin: The previous issue was raised by Gregg. The mention the test (above).
… (wrong test)

Benjamin Young: an updated extension example (based on azaroth’s) {"@context": [{"@vocab": "_:"}, {"pre": "pre", "fix": "pre:fix"}], "pre": "hi", "fix": "thing"}

Rob Sanderson: https://github.com/w3c/json-ld-api/blob/main/tests/toRdf/0118-in.jsonld

Rob Sanderson: This is the test that checks term appended to bnode.
… I think that if someone would come to us an say that this test was supposed to be 1.0, but there was no resolution saying that this was a 1.0-only feature, and no errata. I would have a hard time explaining why this feature was removed from 1.0, even though it is stupid.
… We want to avoid changing the API spec.

Benjamin Young: I’m confused to see how it was an accident while it has tests.

Rob Sanderson: I becomes harder to implement, and it is a case that no one will use.
… We said we wouldn’t introduce incompatibilities.
… We should say we are fixing a typo, which removes an unintentional feature.

Pierre-Antoine Champin: I think gregg and dave’s concern about explicitly allowing that, would make the spec text more complicated.
… In 1.0, nothing was required to allow it. While our 1.1 text would need to explicitly state that it is not allowed.
… I also think we should fix the typo.

Benjamin Young: Does it make sense to use the at-risk process, and have the implementors in the room, and remove at-risk if all implementors agree?

Rob Sanderson: In the 1.0 spec, there wasn’t any text saying that you should be able to do this?

Pierre-Antoine Champin: I will look into it.

Rob Sanderson: If the normative 1.0 spec didn’t say that you can do this, we can remove it, as the tests are not normative.
… But we need to be sure that the spec did not say it.
… We can try the at-risk “trick”.

Tim Cole: If there was a test for 1.0, do we have a case where an implementor supported this?

Rob Sanderson: Tests got run to prove implementations.

Benjamin Young: It’s working now in the playground.

David I. Lehn: pyld passed all 1.0 tests at one point too

Rob Sanderson: https://dvcs.w3.org/hg/json-ld/raw-file/default/test-suite/reports/cr-20131022.html#transform-json-ld-to-rdf

Rob Sanderson: There are 9 implementations passing the test.
… That’s hard to argue against.

Tim Cole: +1

Rob Sanderson: We should not put at-risk, and fix the unintentional removal of the feature.

Proposed resolution: Fix the typo in API to reinstate the ability to append terms to blank node prefixes, such that test to-rdf/0118 should pass (Rob Sanderson)

Benjamin Young: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Tim Cole: +1

Adam Soroka: +0.5

Resolution #3: Fix the typo in API to reinstate the ability to append terms to blank node prefixes, such that test to-rdf/0118 should pass

Benjamin Young: https://dvcs.w3.org/hg/json-ld/raw-file/default/test-suite/reports/cr-20131022.html#test_62d35540b74360eb216acec8dd0298fa

Benjamin Young: “Triples with blank node predicates are not dropped if the produce generalized RDF flag is true.”

Benjamin Young: The issue that I posted seems to indicate that there was a purpose for this.

6. Adjourn

7. Resolutions