JSON-LD Working Group Telco — Minutes

Date: 2019-01-25

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Dave Longley, Rob Sanderson, Benjamin Young, Pierre-Antoine Champin, Ivan Herman, David Newbury, Tim Cole, Harold Solbrig, David Lehn

Regrets: Simon Steyskal, Adam Soroka

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Dave Longley, Benjamin Young

Content:

Ivan Herman: Meeting Agenda 2019-01-25: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0007.html

1. Approve minutes of the last call

Benjamin Young: +1

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-18-json-ld

Proposed resolution: Approve minutes https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-18-json-ld (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Benjamin Young: +1

Pierre-Antoine Champin: +1

Dave Longley: +1

Resolution #1: Approve minutes https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-18-json-ld

Tim Cole: +1

2. Face to Face

Rob Sanderson: We have confirmed the location as the Folger and I updated the Google Doc and the wiki page with the information about it.

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/F2F/2019.02.DC

Rob Sanderson: The Folger has asked if there are any dietary restrictions.

Rob Sanderson: We should let them know if people are allergic to anything and they’ll do coffee for us, etc.

Rob Sanderson: If you are coming and have any special needs let me know or put it into the Google Doc (that’s even better).

Rob Sanderson: We’ll let them know towards the end of next week. Otherwise… no other logistic details have changed.

Rob Sanderson: Any questions?

Benjamin Young: One quick one — do we need someone to provide lunches or how are we doing that?

Rob Sanderson: Assuming all of Washington, D.C. hasn’t shut down (not out of the question) there are numerous places we can go within walking distance.

Rob Sanderson: We had a conference for 200-250 people in that area in May and we were able to get people out of the library of Congress to lunch and back again in 90 minutes and I’m sure we can do it in about an hour, etc.

Rob Sanderson: We can chat over lunch without an issue.

Rob Sanderson: Unless there was money and I don’t think there is, it would be easier to grab lunch out.

Gregg Kellogg: A bigger issue is if planes are going to be flying.

Rob Sanderson: Yes.

Ivan Herman: I might be the only one in the group outside the US that’s coming, any idea if it affects that?

Gregg Kellogg: There might be a longer line at immigration potentially.

Gregg Kellogg: You might not be able to fly in.

Ivan Herman: Or out.

Ivan Herman: I will have to be prepared.

Dave Longley: That’s a real concern, airport delays being announced today.

Rob Sanderson: I had relatives come in with significant delays.

Gregg Kellogg: Do we have an agenda for the F2F?

Rob Sanderson: Not yet, Benjamin and I will discuss and we’ll share and then finalize next week.

Benjamin Young: I suggest we pause for a second if there’s anything anyone has they want to discuss now would be a great time to surface that.

Benjamin Young: Otherwise we’ll go through the list and pick off things that seem to be ready to be solvable issues.

2.1. milestones

Ivan Herman: One thing that might influence the agenda … what’s our feeling, how much time do we need for the testing period? We have to count back from June 2020 which is Rec publishing time — we need to figure out our CR publication timeline.

Ivan Herman: We need to figure out priorities for that and could influence what we discuss at F2F.

Gregg Kellogg: I think that depends on what implementations we think might be ready. I can’t speak for DB.

Gregg Kellogg: My implementation should be, is within shooting distance.

Ivan Herman: Is it a reasonable thing to say, as a target, that we should have a CR at the end of summer?

Ivan Herman: We have to wrap up in June 2020 to get to Rec.

Gregg Kellogg: If we had a CR in August, presuming that no one is spending time on implementations prior to that — how much time would they need to update their implementations and get in reports… we’d see them by November?

Gregg Kellogg: That would allow us to do a PR subsequent to that.

Ivan Herman: Ok, we may have some non-recommendation documents to write as well, so that should be fine.

Rob Sanderson: For PyLD and your other implementations, do you have on your work word map for updates to 1.1 and if so, by the end of the calendar year a reasonable time where they’d be able to contribute to a report?

Dave Longley: We will update our JavaScript implementation surely and eventually PyLD (our Python one) but it will lag behind.

Benjamin Young: https://github.com/jsonld-java/jsonld-java

Benjamin Young: Does any one know the reach of the Java library?

Rob Sanderson: Our current triple store is built on Jena and uses that.

Gregg Kellogg: I know they’ve been looking for help on that and there are bits and pieces of 1.1 stuff that’s come in.

Gregg Kellogg: I know they are looking for help to do more.

Ivan Herman: I know Niklas was working rdflib, I wonder if he’s still active.

Rob Sanderson: I’ve seen him talking about things… and can look into it.

Action #1: Rob Sanderson to ping niklas about rdflib plans for 1.1

Dave Longley: There was a C++ implementation that might be in the works, can’t remember the details.

Harold Solbrig: There’s a sync issue and maybe I can work with both of them [missed context] to get them going.

Ivan Herman: Can we set CR by TPAC in September?

Rob Sanderson: In CR at TPAC seems reasonable.

Rob Sanderson: That would be a good target. If we miss it we’ve still got a bit of time — and if we hit it we’ll have a good story at TPAC.

Ivan Herman: There may be a few issues we push off for 1.1.1. We may think about turning JSON-LD 1.1 into some sort of an Evergreen standard at that point. That’s a possibility we will possibly have in 2020. We should not be concerned with saying that some issues will not be handled now and will be put into a minor update as a Rec after that.

Rob Sanderson: Any concerns on that timeframe?

Benjamin Young: In the aim of getting implementers onboard so they can start implementing ASAP, can we say post F2F that we start posting this to the group and getting report status in, etc.? Does that seem reasonable?

Rob Sanderson: Let’s see what we get done at the F2F.

Ivan Herman: Let’s discuss at the F2F.

Benjamin Young: That’s a great topic.

3. Sealed Context Issues

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

Benjamin Young: Our first set of issues is the new ones that have been filed since we last spoke.

Benjamin Young: Rob, you filed if you want to summarize.

Rob Sanderson: Last week we discussed the notion of partially defining rather than redefining completely. If there were two contexts, one that defined that the @id was playground and another term just added a scoped @context and didn’t repeat @id — this came from the sealing discussion — then you’re only sealing the aspects that are defined by the original context rather than sealing all aspects.

Rob Sanderson: The issue provides an example where a scoped context is added without overriding the @id property.

Rob Sanderson: The question is would the sealing algorithm be able to duplicate all of the sealed term definition attributes and then add something else?

Gregg Kellogg: This just seems a completely different thing to sealed contexts to me, it’s term updating. Which I commented on — it’s fraught with all sorts of potential issues. You need enough knowledge about the original term definition to know that what you’re doing make sense … it would be much less ambiguous to just update the term definition. I don’t see enough of a positive (or really any) to make a change like that.

Gregg Kellogg: I would vote against such a feature.

Benjamin Young: I too have big concerns about changing how these term definitions interact from an overwrite to a merge … where this plays into sealing has to do with sealing a term but not its contents.

Benjamin Young: There were proposals that were very similar to ivan’s comment on this issue last week that had things like sealed term / etc. and there’s interplay with sealing specifically.

Benjamin Young: But as Gregg noted this would be a massive change and complicated to reason about.

Benjamin Young: The case in practice might be more complicated than our examples.

Benjamin Young: Have to be ready to deal with pain.

Ivan Herman: If we keep to the current version, which I’m not against, just exploring. It seems that many of the things we’ve discussed with sealing become irrelevant because they are impossible.

Rob Sanderson: +1 to Ivan

Ivan Herman: In a way — sealing becomes maybe pretty simple in a sense that if I put a seal on a given term in a context then nobody can ever do anything with that term in another context. If there’s something that could be done that would wipe out a definition, it can’t be done.

Ivan Herman: My mind has began to have problems with various combinations — it’s fine with me, the question is are we ok with that?

Dave Longley: I’m mostly in agreement with gkellogg here
… I don’t think we want to enable partial redefinitions
… except for explaining how sealed contexts work
… I’m in agreement that we should not start specifying partial updates to terms definitions
… but we should think in the context of sealing
… so things behave as developers expect

Gregg Kellogg: As Dave was saying, I think this has to do with where sealing applies. You could potentially use a term/redefine it under a property which was not sealed. The ability to do that might make a lot of the worries about the ability to get into sealed contexts be not as important.

Ivan Herman: Can you explain that?

Gregg Kellogg: The concept is that once you’re inside of a scope you’re outside of the domain of sealing.

Rob Sanderson: What parts of a term definition are sealed?

Gregg Kellogg: The entire definition is sealed. When you are going to create a term definition, there’s currently a step to handle this.

Rob Sanderson: So https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-456045025 /is/ an error?

Gregg Kellogg: Currently a new term definition will remove an old one — and that’s just blocked by sealing.

Gregg Kellogg: There is no mechanism and there never has been one to reach into a term definition and replace it.

Rob Sanderson: So then, if you have a scoped context that tries to redefine a sealed term…

Gregg Kellogg: I commented on that on a comment earlier this morning, my understanding from last week, it would be ignored — an attempt to change it would be ignored. Scoped contexts aren’t magic, they are just specified as part of a term and introduced in the expansion phase as if they are inline.

Benjamin Young: That last little bit was clearer, thanks.
… I’m thinking that to even explain this to an informed JSON-LD developer is going to take use cases an flow charts of some kind.
… To say this is how it works and once you add sealed this is how it changes, etc.

Benjamin Young: Any time someone feels like they are reaching an understanding for how this may work and has paper, etc. that would help.

Dave Longley: https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-457599005

Dave Longley: now seems like a good enough time to bring up issue 20
… this is an attempt to explain how this is meant to work
… the focus is specifications which have JSON in them
… which have fixed semantics for fixed terms
… but that also have extension points
… folks who write JSON specs express these things in relation to the tree
… but there’s no consistent way to enforce these things
… and that’s where bringing in a JSON-LD processor could help
… the first example I give is a spec which has different semantics based on the nesting within the tree
… where the meaning of the term changes based on where it appears
… so, creating a term definition for that would be creating a sealed term with its own context
… the other example is about explaining where extensions go
… this term has this id/definition, but within that term you can put whatever you want in there
… the other pattern is, here are all our terms, they’re all sealed, but anything inside those terms can be whatever you want them to be
… we need to think about how this applies to type scoping as well
… I think we can handle all of these
… but I do think it would help to think about these features in terms of how people write JSON
… and how they want to extend JSON-based documents
… and how we can best express those extension points and semantics

Ivan Herman: Actually, two things, because one just came up what Dave was saying. Before that, forget about sealing for a moment. Let’s go back to the fundamental issue that Gregg raised about partial definitions. Let’s suppose that I have one context which defines something for a term.
… I have another one coming after that, for the same term, the only thing I do is add the scoped context. Based on what Gregg said, the second appearance in the second context would completely wipe out what was in the first one.

Gregg Kellogg: That’s the behavior today.

Ivan Herman: I have to figure out how that works with sealed, that bothers me.
… I wonder if we would be better off with trying to concentrate on that we need these extensions points and define them explicitly and have a way to say — in this term it’s a clean slate — instead of going to sealed with its semantics raises other issues.

Rob Sanderson: +1 to Ivan - that seems like the comprehensible compromise.

Ivan Herman: It came by when you were talking that we can simplify on some of the use cases and we seem to be down the road in generalizing that and it may be one of the problems we may have.

Pierre-Antoine Champin: One thing I wanted to mention because Dave mentioned it as well. For the moment I have a hard time wrapping around how typed-scoping interacts with sealed contexts. Apart from that I think I have a clear view of what Dave is trying to achieve with that.
… So I will try to help and share with my intuitions. Couldn’t we talk about the scope of the sealing — my idea is that whenever a sealed context becomes active, simple case is at the root of the JSON object, we will honor this seal by preventing redefinitions of the sealed terms whenever we traverse them.
… Whenever we traverse a term that isn’t part of the sealed then we do not honor any more.

Dave Longley: +1 that sounds pretty good so far (have to think about it more)

Gregg Kellogg: +1 that is what I was trying to describe

Pierre-Antoine Champin: The idea here would be that be that sealed contexts work like regular JSON and once you traverse terms that are “extensions” then fall into regular (old style/non-sealed) JSON-LD processing.

Gregg Kellogg: That’s basically what I was trying to relay. Sealing only applies for immediate values of the terms that are sealed. So if you have “sealed1” and its value is “object” then “sealed1” and all other sealed terms remain sealed and I would think that’s the case with a sealed type as well.
… If you introduce a new term that is not sealed and that represents an extension point and sealing does not apply. I think where Dave and I might have different understanding there…
… When you say that the scoped context is null you have to establish whatever context you want from that point. The other is that the context and all the terms remain in scope, they just are no longer sealed at that point.
… People tend to put all of their stuff at the top to use scoping and it helps with framing, etc.

Gregg Kellogg: I think that this will be closer to existing behavior.

Dave Longley: azaroth talks about an example I can’t scribe :)

Rob Sanderson: I also like pchampin’s suggestion
… I think type-based sealed contexts will run into issues regardless
… if you have in the first context agent as foaf:agent
… and in a second you have schema:producer which is not sealed
… but within schema:producer the agent term would no longer be sealed, correct?
… so it seems like type-based mechanisms, the sealing is irrelevant

Gregg Kellogg: well. I think it’s the same
… if you have an object for an unsealed property
… but that type is sealed
… then that type introduces sealing
… whether its a property or a scope, the behavior is whether it happens inline
… nonetheless after that point you would be in the scope of something being sealed

Ivan Herman: I think that this really needs a f2f meeting

Gregg Kellogg: this seems like an important feature, but it does come with complication…which will decrease adoption

David Newbury: I think I’m agreeing with the complication thing

Dave Longley: priority of constituencies applies here, IMO

David Newbury: and wondering if there are ways of reducing the comprehensiveness of this feature
… can we scope this to say that it does not apply in scoped contexts etc?
… just at the top as a master-list?
… does that meet our use cases?
… are there ways to meet the use cases around this, but by reducing the various ways we use contexts?

Dave Longley: a couple points to make. first, pchampin’s point is really important
… I think it would help both explain it and how we implement it
… processors will start at the top of the document and work their way down
… if it’s something they don’t understand, they’ll be ignored
… anytime there’s a new thing defined, you’re introducing a new processing model
… the point of the feature is to lock in the terms that were originally meant to be sealed
… if you get outside of that space, then you could go back to the old processing model
… the other point I wanted to make is a priority of constituents that we need to take into account
… this is an extremely important feature for JSON developers
… as it improves the ergonomics for end users
… my last point was that there seems to be a lot of miscommunication that we seem to have resolved on this call
… I’m more in agreement with gkellogg than we probably first thought
… working them out on github seems better than talking them out at this point

Pierre-Antoine Champin: with the goal of keeping things simple
… my mental model works well in two scenarios
… I’m concerned about sealed contexts containing terms which are not sealed
… and I think only one context should be sealed at any point in the tree
… and that introduces a lot of complexity
… and the corner cases don’t seem like driving reasons to support that
… last point, under those conditions, the typed scoping behaves quite well

Ivan Herman: we should write all this down in spec text

Pierre-Antoine Champin: that’s my plan

Dave Longley: i think we’re actually making good progress, despite how it may appear :)

Rob Sanderson: I agree we’re making progress. It’s complicated :)

Ivan Herman: test cases are good, but some explanation would also be helpful

Pierre-Antoine Champin: please put the action for me to do that

Rob Sanderson: we’re at the top of the hour, but I do think we’ve made great progress

Action #2: Pierre-Antoine Champin to write spec text of his mental model

Rob Sanderson: and I do think we’ll be helped by having a whiteboard
… we’ll talk again next week!

4. Resolutions

5. Action Items