16:22:18 <RRSAgent> RRSAgent has joined #json-ld
16:22:18 <RRSAgent> logging to https://www.w3.org/2019/01/25-json-ld-irc
16:22:19 <ivan> rrsagent, set log public
16:22:19 <ivan> Meeting: JSON-LD Working Group Telco
16:22:19 <ivan> Chair: azaroth
16:22:19 <ivan> Date: 2019-01-25
16:22:19 <ivan> Agenda: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0007.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html)
16:22:20 <ivan> Meeting Agenda 2019-01-25: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0007.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html)
16:22:20 <ivan> Regrets+ simon
16:37:11 <azaroth> azaroth has joined #json-ld
16:58:09 <pchampin> pchampin has joined #json-ld
16:59:28 <gkellogg> present+ Gregg_Kellogg
16:59:41 <dlongley> present+ Dave_Longley
17:00:07 <azaroth> present+ Rob_Sanderson
17:00:50 <timCole> timCole has joined #json-ld
17:00:55 <bigbluehat> present+ Benjamin_Young
17:00:59 <azaroth> azaroth has changed the topic to: Meeting Agenda 2019-01-25: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0007.html
17:01:57 <azaroth> scribenick: dlongley
17:02:00 <pchampin> present+
17:02:11 <workergnome> workergnome has joined #json-ld
17:02:15 <azaroth> TOPIC: Approve minutes of the last call
17:02:15 <bigbluehat> +1
17:02:39 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-18-json-ld
17:02:41 <azaroth> PROPOSAL: Approve minutes https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-18-json-ld
17:02:44 <azaroth> +1
17:02:47 <gkellogg> +1
17:02:47 <bigbluehat> +1
17:02:50 <pchampin> +1
17:02:52 <dlongley> +1
17:03:00 <azaroth> RESOLVED: Approve minutes https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-18-json-ld
17:03:05 <timCole> +1
17:03:15 <azaroth> TOPIC: Face to Face
17:03:35 <ivan> present+
17:03:42 <dlongley> azaroth: We have confirmed the location as the Folger and I updated the Google Doc and the wiki page with the information about it.
17:03:43 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/F2F/2019.02.DC
17:03:44 <workergnome> present+
17:03:49 <dlongley> azaroth: The Folger has asked if there are any dietary restrictions.
17:04:01 <timCole> present+
17:04:06 <dlongley> azaroth: We should let them know if people are allergic to anything and they'll do coffee for us, etc.
17:04:24 <dlongley> azaroth: If you are coming and have any special needs let me know or put it into the Google Doc (that's even better).
17:04:31 <hsolbrig> hsolbrig has joined #json-ld
17:04:38 <hsolbrig> present+ hsolbrig
17:04:42 <dlongley> azaroth: We'll let them know towards the end of next week. Otherwise... no other logistic details have changed.
17:04:44 <dlongley> azaroth: Any questions?
17:04:50 <bigbluehat> q+
17:04:55 <azaroth> ack bigbluehat
17:05:03 <dlongley> bigbluehat: One quick one -- do we need someone to provide lunches or how are we doing that?
17:05:16 <ivan> q+
17:05:21 <dlongley> azaroth: 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.
17:05:56 <dlongley> azaroth: 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.
17:06:03 <dlongley> azaroth: We can chat over lunch without an issue.
17:06:16 <dlongley> azaroth: Unless there was money and I don't think there is, it would be easier to grab lunch out.
17:06:24 <dlongley> gkellogg: A bigger issue is if planes are going to be flying.
17:06:27 <azaroth> ack ivan
17:06:32 <dlongley> azaroth: Yes.
17:06:53 <dlongley> ivan: I might be the only one in the group outside the US that's coming, any idea if it affects that?
17:07:00 <dlongley> gkellogg: There might be a longer line at immigration potentially.
17:07:22 <dlongley> gkellogg: You might not be able to fly in.
17:07:25 <dlongley> ivan: Or out.
17:07:32 <dlongley> ivan: I will have to be prepared.
17:08:00 <dlongley> dlongley: That's a real concern, airport delays being announced today.
17:08:19 <dlongley> azaroth: I had relatives come in with significant delays.
17:08:28 <azaroth> q?
17:08:59 <dlongley> gkellogg: Do we have an agenda for the F2F?
17:09:06 <bigbluehat> q+
17:09:09 <dlongley> azaroth: Not yet, Benjamin and I will discuss and we'll share and then finalize next week.
17:09:09 <azaroth> ack bigbluehat
17:09:28 <dlongley> bigbluehat: 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.
17:09:35 <ivan> q+
17:09:43 <dlongley> bigbluehat: Otherwise we'll go through the list and pick off things that seem to be ready to be solvable issues.
17:09:46 <azaroth> ack ivan
17:10:27 <dlongley> ivan: 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.
17:10:42 <dlongley> ivan: We need to figure out priorities for that and could influence what we discuss at F2F.
17:10:54 <dlongley> gkellogg: I think that depends on what implementations we think might be ready. I can't speak for DB.
17:11:08 <dlongley> gkellogg: My implementation should be, is within shooting distance.
17:11:25 <dlongley> ivan: Is it a reasonable thing to say, as a target, that we should have a CR at the end of summer?
17:11:46 <dlongley> ivan: We have to wrap up in June 2020 to get to Rec.
17:12:19 <dlongley> gkellogg: 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?
17:12:29 <dlongley> gkellogg: That would allow us to do a PR subsequent to that.
17:12:39 <dlongley> ivan: Ok, we may have some non-recommendation documents to write as well, so that should be fine.
17:13:22 <dlongley> azaroth: 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?
17:14:34 <bigbluehat> q+
17:14:41 <azaroth> ack bigbluehat
17:14:42 <dlongley> dlongley: We will update our JavaScript implementation surely and eventually PyLD (our Python one) but it will lag behind.
17:14:51 <bigbluehat> https://github.com/jsonld-java/jsonld-java
17:14:58 <dlongley> bigbluehat: Does any one know the reach of the Java library?
17:15:03 <ivan> regrets+ ajs6f
17:15:19 <dlongley> azaroth: Our current triple store is built on Jena and uses that.
17:15:42 <dlongley> gkellogg: I know they've been looking for help on that and there are bits and pieces of 1.1 stuff that's come in.
17:15:49 <dlongley> q+
17:15:56 <dlongley> gkellogg: I know they are looking for help to do more.
17:16:09 <dlongley> ivan: I know Niklas was working rdflib, I wonder if he's still active.
17:16:15 <hsolbrig> q+
17:16:16 <azaroth> ack dlongley
17:16:17 <dlongley> azaroth: I've seen him talking about things... and can look into it.
17:16:36 <azaroth> ACTION: azaroth to ping niklas about rdflib plans for 1.1
17:16:56 <azaroth> q?
17:16:58 <azaroth> ack hsolbrig
17:17:06 <dlongley> dlongley: There was a C++ implementation that might be in the works, can't remember the details.
17:17:30 <azaroth> q?
17:17:40 <dlongley> hsolbrig: There's a sync issue and maybe I can work with both of them [missed context] to get them going.
17:17:54 <dlongley> ivan: Can we set CR by TPAC in September?
17:18:07 <dlongley> azaroth: In CR at TPAC seems reasonable.
17:18:33 <dlongley> azaroth: 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.
17:19:28 <dlongley> ivan: 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.
17:19:30 <azaroth> q?
17:19:50 <bigbluehat> q+
17:19:55 <dlongley> azaroth: Any concerns on that timeframe?
17:19:57 <azaroth> ack bigbluehat
17:20:25 <dlongley> bigbluehat: 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?
17:20:32 <dlongley> azaroth: Let's see what we get done at the F2F.
17:20:36 <dlongley> ivan: Let's discuss at the F2F.
17:20:42 <dlongley> bigbluehat: That's a great topic.
17:21:00 <azaroth> q?
17:21:02 <dlongley> azaroth: Let's move onto the sealed context issue?
17:21:08 <azaroth> TOPIC: Sealed Context Issues
17:21:26 <bigbluehat>  Subtopic: https://github.com/w3c/json-ld-syntax/issues/116
17:21:34 <dlongley> bigbluehat: Our first set of issues is the new ones that have been filed since we last spoke.
17:21:43 <dlongley> bigbluehat: Rob, you filed if you want to summarize.
17:23:01 <dlongley> azaroth: 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.
17:23:32 <dlongley> azaroth: The issue provides an example where a scoped context is added without overriding the `@id` property.
17:24:10 <azaroth> q?
17:24:10 <gkellogg> q+
17:24:12 <dlongley> azaroth: The question is would the sealing algorithm be able to duplicate all of the sealed term definition attributes and then add something else?
17:24:14 <azaroth> ack gkellogg
17:24:36 <bigbluehat> q+
17:24:48 <ivan> q+
17:25:07 <dlongley> gkellogg: 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.
17:25:09 <dlongley> q+
17:25:14 <dlongley> gkellogg: I would vote against such a feature.
17:25:15 <azaroth> ack bigbluehat
17:25:15 <bigbluehat> ack bigbluehat
17:25:47 <dlongley> bigbluehat: 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.
17:26:10 <dlongley> bigbluehat: 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.
17:26:24 <dlongley> bigbluehat: But as Gregg noted this would be a massive change and complicated to reason about.
17:26:38 <bigbluehat> ack ivan
17:26:42 <dlongley> bigbluehat: The case in practice might be more complicated than our examples.
17:26:46 <dlongley> bigbluehat: Have to be ready to deal with pain.
17:27:18 <dlongley> ivan: 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.
17:27:43 <azaroth> +1 to Ivan
17:28:02 <dlongley> ivan: 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.
17:28:21 <dlongley> ivan: My mind has began to have problems with various combinations -- it's fine with me, the question is are we ok with that?
17:28:23 <bigbluehat> ack dlongley
17:28:27 <gkellogg> q+ to note that dlongley’s suggested change to limit sealing to just the immediate values of sealed properties
17:28:32 <bigbluehat> scribenick: bigbluehat
17:28:48 <bigbluehat> dlongley: I'm mostly in agreement with gkellogg here
17:28:55 <bigbluehat> ...I don't think we want to enable partial redefinitions
17:29:05 <bigbluehat> ...except for explaining how sealed contexts work
17:29:22 <bigbluehat> ...I'm in agreement that we should not start specifying partial updates to terms defintions
17:29:25 <ivan> q+
17:29:29 <bigbluehat> ...but we should think in the context of sealing
17:29:38 <azaroth> ack gkellogg
17:29:38 <Zakim> gkellogg, you wanted to note that dlongley’s suggested change to limit sealing to just the immediate values of sealed properties
17:29:41 <bigbluehat> ...so things behave as developers expect
17:29:43 <bigbluehat> scribenick: dlongley
17:29:51 <ivan> q-
17:30:10 <dlehn> present+ David_Lehn
17:30:16 <azaroth> q+ to question exactly which features are sealed
17:30:21 <dlongley> gkellogg: 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.
17:30:26 <dlongley> ivan: Can you explain that?
17:31:37 <bigbluehat> q+
17:31:44 <dlongley> q+
17:31:45 <ivan> q+
17:31:46 <bigbluehat> ack azaroth
17:31:47 <Zakim> azaroth, you wanted to question exactly which features are sealed
17:31:49 <dlongley> gkellogg: The concept is that once you're inside of a scope you're outside of the domain of sealing.
17:32:01 <pchampin> q+
17:32:34 <dlongley> azaroth: What parts of a term definition are sealed?
17:32:53 <dlongley> gkellogg: The entire definition is sealed. When you are going to create a term definition, there's currently a step to handle this.
17:32:57 <azaroth> So https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-456045025 /is/ an error?
17:33:12 <dlongley> gkellogg: Currently a new term definition will remove an old one -- and that's just blocked by sealing.
17:33:24 <dlongley> gkellogg: There is no mechanism and there never has been one to reach into a term definition and replace it.
17:33:42 <dlongley> azaroth: So then, if you have a scoped context that tries to redefine a sealed term...
17:34:16 <dlongley> gkellogg: 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 but they are inline.
17:34:25 <dlongley> s/but they/as if they/
17:34:31 <dlongley> q+
17:34:34 <bigbluehat> ack bigbluehat
17:34:55 <dlongley> bigbluehat: That last little bit was clearer, thanks.
17:35:29 <dlongley> bigbluehat: 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.
17:35:46 <dlongley> bigbluehat: To say this is how it works and once you add sealed this is how it changes, etc.
17:36:07 <bigbluehat> ack dlongley
17:36:08 <dlongley> bigbluehat: Any time someone feels like they are reaching an understanding for how this may work and has paper, etc. that owuld help.
17:36:11 <bigbluehat> scribenick: bigbluehat
17:36:15 <dlongley> https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-457599005
17:36:21 <bigbluehat> dlongley: now seems like a good enough time to bring up issue 20
17:36:35 <bigbluehat> ...this is an attempt to explain how this is meant to work
17:36:41 <bigbluehat> ...the focus is specifications which have JSON in them
17:36:49 <bigbluehat> ...which have fixed semantics for fixed terms
17:36:54 <bigbluehat> ...but that also have extension points
17:37:17 <bigbluehat> ...folks who write JSON specs express these things in relation to the tree
17:37:24 <bigbluehat> ...but there's no consistent way to enforce these things
17:37:31 <bigbluehat> ...and that's where bringing in a JSON-LD processor could help
17:37:47 <bigbluehat> ...the first example I give is a spec which has different semantics based on the nesting within the tree
17:38:02 <bigbluehat> ...where the meaning of the term changes based on where it appears
17:38:13 <azaroth> q+ to assert that sealed1.sealed2.sealed1 is an error?
17:38:19 <bigbluehat> ...so, creating a term definition for that would be creating a sealed term with its own context
17:38:35 <bigbluehat> ...the other example is about explaining where extensions go
17:38:48 <bigbluehat> ...this term has this id/definition, but within that term you can put whatever you want in there
17:38:54 <workergnome> q+
17:39:09 <bigbluehat> ...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
17:39:18 <bigbluehat> ...we need to think about how this applies to type scoping as well
17:39:27 <bigbluehat> ...I think we can handle all of these
17:39:40 <bigbluehat> ...but I do think it would help to think about these features in terms of how people write JSON
17:39:50 <bigbluehat> ...and how they want to extend JSON-based documents
17:39:58 <gkellogg> q+
17:40:01 <bigbluehat> ...and how we can best express those extension points and semantics
17:40:03 <azaroth> ack ivan
17:40:11 <bigbluehat> scribenick: dlongley
17:40:55 <dlongley> ivan: 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.
17:41:22 <dlongley> ivan: 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.
17:41:28 <dlongley> gkellogg: That's the behavior today.
17:42:02 <dlongley> ivan: I have to figure out how that works with sealed, that bothers me.
17:42:39 <dlongley> ivan: 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.
17:42:56 <azaroth> +1 to Ivan - that seems like the comprehensible compromise.
17:43:01 <dlongley> ivan: 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.
17:43:02 <bigbluehat> ack pchampin
17:43:49 <dlongley> pchampin: 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.
17:44:33 <dlongley> pchampin: 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.
17:44:48 <dlongley> pchampin: Whenever we traverse a term that isn't part of the sealed then we do not honor any more.
17:44:56 <dlongley> +1 that sounds pretty good so far (have to think about it more)
17:45:28 <ivan> q?
17:45:36 <gkellogg> +1 that is what I was trying to describe
17:45:37 <bigbluehat> ack azaroth
17:45:37 <Zakim> azaroth, you wanted to assert that sealed1.sealed2.sealed1 is an error?
17:45:37 <dlongley> pchampin: 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.
17:45:39 <dlongley> q+
17:45:47 <bigbluehat> ack gkellogg
17:46:31 <dlongley> gkellogg: 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.
17:46:59 <dlongley> gkellogg: 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...
17:47:27 <dlongley> gkellogg: 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.
17:47:33 <dlongley> q+ to say I agree with the latter there
17:47:52 <dlongley> gkellogg: People tend to put all of their stuff at the top to use scoping and it helps with framing, etc.
17:48:26 <bigbluehat> ack azaroth
17:48:30 <dlongley> gkellogg: I think that this will be closer to existing behavior.
17:48:45 <pchampin> q+
17:48:56 <dlongley> azaroth talks about an example I can't scribe :)
17:49:07 <bigbluehat> scribenick: bigbluehat
17:50:28 <bigbluehat> azaroth: I also like pchampin's suggestion
17:50:38 <bigbluehat> ...I think type-based sealed contexts will run into issues regardless
17:51:04 <bigbluehat> ...if you have in the first context `agent` as `foaf:agent`
17:51:15 <bigbluehat> ...and in a second you have `schema:producer` which is not sealed
17:51:33 <bigbluehat> ...but within `schema:producer` the `agent` term would no longer be sealed, correct?
17:51:58 <bigbluehat> ...so it seems like type-based mechanisms, the sealing is irrelevant
17:52:02 <bigbluehat> gkellogg: well. I think it's the same
17:52:11 <bigbluehat> ...if you have an object for an unsealed property
17:52:14 <bigbluehat> ...but that type is sealed
17:52:22 <bigbluehat> ...then that type introduces sealing
17:52:39 <bigbluehat> ...whether its a property or a scope, the behavior is whether it happens inline
17:52:52 <bigbluehat> ...nonetheless after that point you would be in the scope of something being sealed
17:52:53 <dlongley> q+
17:53:02 <bigbluehat> ivan: I think that this really needs a f2f meeting
17:53:28 <bigbluehat> gkellogg: this seems like an important feature, but it does come with complication...which will decrease adoption
17:53:34 <bigbluehat> workergnome: I think I'm agreeing with the complication thing
17:53:41 <dlongley> priority of constituencies applies here, IMO
17:53:47 <bigbluehat> ...and wondering if there are ways of reducing the comprehensiveness of this feature
17:53:48 <bigbluehat> ack workergnome
17:54:13 <bigbluehat> ...can we scope this to say that it does not apply in scoped contexts etc?
17:54:20 <bigbluehat> ...just at the top as a master-list?
17:54:25 <bigbluehat> ...does that meet our use cases?
17:54:44 <bigbluehat> ...are there ways to meet the use cases around this, but by reducing the various ways we use contexts?
17:54:46 <bigbluehat> ack dlongley
17:54:46 <Zakim> dlongley, you wanted to say I agree with the latter there and to
17:55:01 <bigbluehat> dlongley: a couple points to make. first, pchampin's point is really important
17:55:16 <bigbluehat> ...I think it would help both explain it and how we implement it
17:55:34 <bigbluehat> ...processors will start at the top of the document and work their way down
17:55:41 <bigbluehat> ...if it's something they don't understand, they'll be ignored
17:55:51 <bigbluehat> ...anytime there's a new thing defined, you're introducing a new processing model
17:56:02 <bigbluehat> ...the point of the feature is to lock in the terms that were originally meant to be sealed
17:56:13 <bigbluehat> ...if you get outside of that space, then you could go back to the old processing model
17:56:28 <bigbluehat> ...the other point I wanted to make is a priority of constituents that we need to take into account
17:56:39 <bigbluehat> ...this is an extremely important feature for JSON developers
17:56:56 <bigbluehat> ...as it improves the ergonomics for end users
17:57:13 <bigbluehat> ...my last point was that there seems to be a lot of miscommunication that we seem to have resolved on this call
17:57:23 <bigbluehat> ...I'm more in agreement with gkellogg than we probably first thought
17:57:36 <bigbluehat> ...working them out on github seems better than talking them out at this point
17:57:43 <bigbluehat> pchampin: with the goal of keeping things simple
17:58:03 <bigbluehat> ...my mental model works well in two scenarios
17:58:23 <bigbluehat> ...I'm concerned about sealed contexts containing terms which are not sealed
17:58:40 <bigbluehat> ...and I think only one context should be sealed at any point in the tree
17:58:50 <bigbluehat> ...and that introduces a lot of complexity
17:58:59 <bigbluehat> ...and the corner cases don't seem like driving reasons to support that
17:59:18 <bigbluehat> ...last point, under those conditions, the typed scoping behaves quite well
17:59:37 <azaroth> q?
17:59:39 <azaroth> ack pchampin
17:59:40 <bigbluehat> ivan: we should write all this down in spec text
17:59:44 <bigbluehat> pchampin: that's my plan
17:59:55 <dlongley> i think we're actually making good progress, despite how it may appear :)
18:00:14 <azaroth> I agree we're making progress. It's complicated :)
18:00:14 <bigbluehat> ivan: test cases are good, but some explanation would also be helpful
18:00:24 <bigbluehat> pchampin: please put the action for me to do that
18:01:03 <bigbluehat> azaroth: we're at the top of the hour, but I do think we've made great progress
18:01:13 <ivan> action: pchampin to write spec text of his mental model
18:01:17 <bigbluehat> ...and I do think we'll be helped by having a whiteboard
18:01:24 <ivan> rrsagent, draft minutes
18:01:24 <RRSAgent> I have made the request to generate https://www.w3.org/2019/01/25-json-ld-minutes.html ivan
18:01:24 <ivan> zakim, bye
18:01:24 <ivan> rrsagent, bye
18:01:24 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2019/01/25-json-ld-actions.rdf :
18:01:24 <RRSAgent> ACTION: azaroth to ping niklas about rdflib plans for 1.1 [1]
18:01:24 <RRSAgent>   recorded in https://www.w3.org/2019/01/25-json-ld-irc#T17-16-36
18:01:24 <RRSAgent> ACTION: pchampin to write spec text of his mental model [2]
18:01:24 <RRSAgent>   recorded in https://www.w3.org/2019/01/25-json-ld-irc#T18-01-13
18:01:24 <Zakim> leaving.  As of this point the attendees have been Gregg_Kellogg, Dave_Longley, Rob_Sanderson, Benjamin_Young, pchampin, ivan, workergnome, timCole, hsolbrig, David_Lehn
18:01:24 <Zakim> Zakim has left #json-ld
18:01:29 <bigbluehat> ...we'll talk again next week!