JSON-LD Working Group Telco — Minutes

Date: 2020-02-28

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Harold Solbrig, Rob Sanderson, Ruben Taelman, Gregg Kellogg, Pierre-Antoine Champin, Benjamin Young, David I. Lehn, Tim Cole

Regrets: Dave Longley, Jeff Mixter

Guests:

Chair: Rob Sanderson

Scribe(s): Ruben Taelman

Content:

1. CR republication

Ivan Herman: Good news: intermediate CR got approved. Bad news: Echidna doesn’t like us, so we have to publish it in the traditional way.

Gregg Kellogg: There is a workaround, related to the name of the issue. Easiest way to go forward is the old way.

Gregg Kellogg: I will create snapshots.
… We already pushed the framing update, so that worked.

Rob Sanderson: So everything is under control with the CR publication.

Ivan Herman: An issue was raised at Echidna that this should be solved.

Gregg Kellogg: Biggest last-minute changes to API and framing were from people from the WebIDL team. Some names have changes, which are editorial.
… Now, things would work if someone would generate an interface for a browser.

2. IETF and Process for media types

Rob Sanderson: IETF is not certain about multiple +’s in the media type. They want to take that out of the registration.
… Manu and the DID folks seemed ok with it. It’s their fight to take up later.

Gregg Kellogg: We eliminated the paragraph from the docs. It does not appear in the published spec.

Ivan Herman: I will answer them this evening that we will take it out. And I will ask them how we can get the double-+ discussed. Because someone will come back to it in the future.

3. Issues

3.1. Nested property-scoped fields

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

Gregg Kellogg: Last week we discussed that supporting this would be editorial, as no normative changes are required to make this work, only algorithm steps needs to be changed.
… Algorithm should be changed to take property-scoped context to be taken into consideration. The problem is that it is not feasible IMO to do the compaction side of this using the same context, because term selection could be based on prop-scope or nested terms. So we have to decide to only do this for expansion only, and accept that it will come out differently after compaction. What do you think?

Pierre-Antoine Champin: I agree. I don’t see a way to ensure round-trip of this. I’m not too concerned about that, because nested structures are not entirely round-tripable. For example, recursive lists are not round-trippable.
… So I could live with scoped contexts handled in expansion, and not handled in compaction.
… This raises another problem: current addition Gregg did, it is possible to expand something using scoped contexts, to get back a semantically different result, because expansion does not take into account scoped contexts.
… We should probably not merge this addition change because of this unforeseen consequence. Or we can refrain from compaction if there is a scoped context. It would be a shame, but we should at least be careful not to break compaction as it is.

Ivan Herman: Unsure I understand all the details. I doubt this is something we should do at this point. It sounds like something close to a new feature, and that is a no-no, which goes back to WD.
… We may come back to it at some point in time, which depends on what the future holds for JSON-LD.
… This sounds too much for a CR that we plan to close in a few weeks.

Rob Sanderson: pchampin, could you clarify the scenario where you expand+compact and get different semantics?

Pierre-Antoine Champin: https://github.com/w3c/json-ld-api/issues/380#issuecomment-590574392

Rob Sanderson: I agree that this is on the border of a new feature.

Pierre-Antoine Champin: If you compact the linked data, then it will compact with @nest with a custom meaning of bar in the scoped context. But if I re-expand, bar will have a different meaning.

Rob Sanderson: I can see this happening in practice.

Gregg Kellogg: This is editorial because the syntax doc doesn’t disallow this use-case. So we may need to do something to not make people infer that this is possible. The use case is nice, but not worth the disruption at this point. So we should defer this to a future version.

Pierre-Antoine Champin: https://github.com/w3c/json-ld-api/issues/380#issuecomment-590796364

Pierre-Antoine Champin: The last comment was also in that direction. The algorithm is not meant for this. Niklas agrees that this is not the right moment to handle this.

Ivan Herman: Ok, let’s defer.

Rob Sanderson: Does this also apply to your other issue pchampin?

Pierre-Antoine Champin: No, that one points out the assymetry.

Proposed resolution: Defer #380 for future version as (1) can be experimental as not forbidden, (2) borderline new feature in feature freeze, (3) dangerously asymmetric (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Harold Solbrig: +1

Ruben Taelman: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Rob Sanderson: +1

Benjamin Young: +1

David I. Lehn: +1

Resolution #1: Defer #380 for future version as (1) can be experimental as not forbidden, (2) borderline new feature in feature freeze, (3) dangerously asymmetric

Gregg Kellogg: The problem with these types of things, compaction comes down to term selection algo, which is already insanely complicated. Anything adding more complexity should be carefully considered.

3.2. Recursive Nesting and Compaction

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

Rob Sanderson: Next one is related by pchampin.

Pierre-Antoine Champin: This issue is just to check that recursively nested properties are … after round-tripping.
… I didn’t suggest any change. This can be closed. This was just to support my other arguments in the previous issue.

Gregg Kellogg: We should also defer this, rather than close.

Proposed resolution: Defer #391 on recursively nested properties to future version as new feature that can be experimented with (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Ruben Taelman: +1

Tim Cole: +1

Harold Solbrig: +1

Resolution #2: Defer #391 on recursively nested properties to future version as new feature that can be experimented with

3.3. @prefix

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

Harold Solbrig: We talked about this last week.
… There is a whole community out there that uses JSON-LD mainly for prefix mgmt.
… Their prefixes are non-standard.
… The @prefix feature we put in broke their stuff a while back, the only noticed recently when things started breaking.
… This used to work in JSON-LD 1.0, but breaks in 1.1. Sometimes they treat it as regular JSON.
… I suggested @prefix true in root making all terms prefixes.
… We’re not going to get that one in without going back to WD.
… Alternative solution, make it an API parameter to mark all terms as prefixes. Problem: this changes the semantics. But community would be happy with it.
… Alternative 2: we can add _ (and possibly more characters) to gen-delim list.
… We don’t want to loose this community.

Rob Sanderson: Should there be syntactic sugar to prefix? And what about backwards-compatibility with 1.0?

Gregg Kellogg: If you use an expanded term def without @prefix true, we don’t …

Rob Sanderson: We gave people the ability for people using non-gen-delim as last character a way to still force the term as a prefix.
… The change is in the context, which no one would be processing as JSON?

Harold Solbrig: Yes, they process the context as just JSON. Mainly for prefix-management.

Benjamin Young: I don’t want to change the language to match the translation book.
… We are seeing this pattern happening in other communities, where people are processing JSON-LD as JSON.
… It’s a space we need to watch. People want a minimal set of tooling to work with contexts without going all into RDF land.

Harold Solbrig: +1 on bigbluehat – folks are thinking about using context files as declarative mappings as well

Rob Sanderson: This looks to me like a new feature.
… Unless we agree that this is something is broken, we shouldn’t go back to WD and go back again.

Harold Solbrig: Are there any options I mentioned that doesn’t require us to go back to WD?
… Can we just add the option? Or add something to the gen-delim list? Do these require going back to WD?

Rob Sanderson: Yes, it makes current tests invalid and changes behaviour.

Pierre-Antoine Champin: I agree that it would be a normative change. We could argue that we don’t change the intention. Would content-negotiation be an alternative option for this community?
… Would not be possible if hosted on GitHub pages, which I think it is.

Harold Solbrig: I’m scared of the outrage of JSON-LD being the URL police. They are reasonable, but we have to step in an be nice, because I’m scared that they will step away from JSON-LD if we can’t come up with something.

Gregg Kellogg: This is about terms, not URLs. For example, in Turtle prefix are unambiguous, but that’s not the case in JSON-LD. I’m sympathetic with what they are going through, but the WG has been open for a while, so they could/should have listened to what is going on.

Rob Sanderson: There is a solution that would make it work, which is to put prefix: true on all prefixes. I think this is a valid answer because we did the same with another community for @propagates. The solution was to pick one of the two options, and one of the option was implicit, and the other option requires another explicit keyword.
… I suggest that we say that they have to make prefixes explicit.

Harold Solbrig: I don’t think it’s going to fly for them. They have another use for the contexts and reading them as JSON. This would triple the size of their file, which may be a problem for them.
… I have to leave now…

Benjamin Young: I think this is the JSON-LD versus the world question, and how we best interface with the various communities.
… We are highlighting several problems with different communities.
… I would love there to be other options next to us saying we’re out of time.
… Harold is probably right that we’re going to loose them.
… We need to have a better answer for the future of JSON-LD.
… For resolving issues, such as is going on now with RDF.

Ivan Herman: Let’s be careful with this discussion.
… The RDF community has lost activity, but this is a different case.
… For cases like these we need a strict deadline, saying when we do a release.
… There were discussions in Fukuoka which means that it would be possible to introduce a different kind of processing for an existing spec.
… Where a new feature could be added in a much shorter round.
… What would happen here, if we already had a rec, and this issue came in, we go to something like a CR, that has to show implementations, and can be added to the recommendation.
… What is happening now, there will be a vote on this new process soon-ish.
… I would expect it to be accepted. Then we have to understand how this affects existing specs, and we have to decide if there is a community out there that wants to maintain JSON-LD like this.
… It means that member companies to maintain a WG, which not all companies will want to do.
… If there had been such a process around at the RDF spec time, I’m not sure such a process would have been applied for RDF, as the community became less active.
… There are high probabilities that the AC meeting in Korea will not happen because of the coronavirus, so this may slow down the discussion:-(.

Gregg Kellogg: A living standard-type process would be good. JSON-LD is substantially different than the RDF community, because there are less things people disagree on. We shouldn’t wait for 3-5 years for future changes.

Ivan Herman: The goal of this new process would be to avoid gaps of several years.
… The current process slows down things.

Benjamin Young: People want two things: hope and a path. Our current conversations go away from that, when we say that the time is up.
… We should tell people what they should do when we say time is up, instead of just saying ‘defer’.
… Because this shrinks the size of the community, and we should give people hope.

Rob Sanderson: The value of the current process is about scoping.
… If we didn’t have this feature scope, we would never finish, because new good ideas would always come.

Gregg Kellogg: +1 to azaroth

Rob Sanderson: For new product releases, you have to define the set of features a product supports.
… To me, the prefix block would be a good feature to support in the future, but can not do at the moment.

Pierre-Antoine Champin: The global flag would be an easy thing to implement, which we could do as implementors, even if it is not supported formally.

Rob Sanderson: Is it actually the best solution?

Gregg Kellogg: The advantage of having @prefix of context level instead of term level, is that the processor would do the right thing when it sees it.
… We definitely need some messaging to the community on what the processing is.

Ivan Herman: We should decide now on a resolution.

Proposed resolution: @prefix flag is a good idea, but a new feature that will be added to a future version with the hope that this will come quickly, given new W3C process options (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Ruben Taelman: +1

David I. Lehn: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Benjamin Young: +1

Harold Solbrig: -1 (see also separate opinion)

Resolution #3: @prefix flag is a good idea, but a new feature that will be added to a future version with the hope that this will come quickly, given new W3C process options

5. Resolutions