16:36:55 <RRSAgent> RRSAgent has joined #json-ld
16:36:55 <RRSAgent> logging to https://www.w3.org/2019/01/18-json-ld-irc
16:36:56 <ivan> rrsagent, set log public
16:36:56 <ivan> Meeting: JSON-LD Working Group Telco
16:36:56 <ivan> Chair: azaroth
16:36:56 <ivan> Date: 2019-01-18
16:36:56 <ivan> Agenda: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0005.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html)/topic Meeting Agenda 2019-01-18: [https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0005.html](https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0001.html)
17:00:07 <pchampin> pchampin has joined #json-ld
17:00:11 <bigbluehat> present+
17:00:35 <gkellogg> present+ Gregg_Kellogg
17:00:36 <ivan> present+
17:00:42 <azaroth> present+
17:00:57 <pchampin> present+
17:01:38 <ivan> present+ dlongley
17:01:51 <ivan> present+ dlehn
17:02:10 <workergnome> workergnome has joined #json-ld
17:02:51 <bigbluehat> bigbluehat has changed the topic to: Meeting Agenda 2019-01-18: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0005.html
17:03:03 <azaroth> TOPIC: scribe selection
17:03:22 <ivan> present+ Jeff_Mixter
17:03:51 <azaroth> scribenick: gkellogg
17:04:12 <azaroth> ACTION: dlehn to update the playground instead of scribing
17:04:23 <jeff_mixter> jeff_mixter has joined #json-ld
17:04:27 <jeff_mixter> present+
17:04:35 <azaroth> TOPIC: Approve the minutes of the last call
17:04:50 <azaroth> PROPOSAL: Minutes of the last call are approved ( https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-11-json-ld  )
17:04:51 <gkellogg> +1
17:04:52 <azaroth> +1
17:04:54 <ivan> +1
17:05:01 <bigbluehat> +1
17:05:07 <dlehn> +1
17:05:12 <gkellogg> q+
17:05:12 <workergnome> +1
17:05:21 <azaroth> RESOLVED: Minutes of the last call are approved ( https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-11-json-ld  )
17:05:28 <azaroth> scribenick: azaroth
17:05:44 <azaroth> gkellogg: There's a github user called @vocab who gets notified from minutes
17:05:50 <azaroth> ivan: Don't think it's from the minutes
17:06:03 <azaroth> ... what triggers is if it's ... oh ... the transcript
17:06:08 <gkellogg> ivan: it’s triggered by something in the comments.
17:06:10 <azaroth> bigbluehat: Doesn't matter if it's robot or typed
17:06:16 <azaroth> scribenick: gkellogg
17:06:34 <gkellogg> … If we can do that in the minutes, that would help.
17:06:36 <azaroth> s/@vocab/`@vocab`/
17:07:08 <gkellogg> … I’ll either do it by hand, or try to update the software.
17:07:38 <gkellogg> azaroth: bigbluehat is keeper of the software stack, so he might note that.
17:08:38 <azaroth> TOPIC: Logistics
17:09:40 <gkellogg> azaroth: I’ve reached out to Folger a couple of times to confirm that we can use the space, and they haven’t yet responded. I believe that everything’s fine, but I haven’t yet canceled the meeting space at Dupont circle.
17:10:21 <gkellogg> … Eric, contact at Folger, needed to validate with their events people, but we havne’t gotten the final word, yet.
17:10:45 <gkellogg> ivan: I see a mail from Sophie, who has confirmed it.
17:11:42 <gkellogg> azaroth: So, we’ll definitely be there, and I’ll let Dupont know.
17:12:00 <azaroth> ACTION: azaroth to update the web page
17:14:11 <gkellogg> azaroth: There are several places near the Folger we can go for dinner.
17:15:04 <azaroth> TOPIC: Issues - Sealed Contexts
17:15:14 <azaroth> Github issue: https://github.com/w3c/json-ld-syntax/issues/20
17:15:48 <ivan> Related issues: https://github.com/w3c/json-ld-syntax/issues/98 and https://github.com/w3c/json-ld-syntax/issues/108
17:15:56 <gkellogg> azaroth: We want to have it such that contexts that are processed after sealed contexts are unable to change the definition of terms.
17:16:30 <gkellogg> … So, if you see something like “foo” in the context, you can be confident of its meaning from the sealed context.
17:17:03 <gkellogg> … There is also the desire to “unseal” sealed terms. dlongley is champion from Credentidals WG.
17:18:06 <gkellogg> dlongley: THe main reason for the feature is that there are a number of specifications that add prose to text about order of contexts, and that you can extend the context, but may not override terms. There’s no mechanism to inforce this.
17:18:35 <azaroth> An example of such language: https://iiif.io/api/presentation/2.1/#linked-data-context-and-extensions
17:18:37 <gkellogg> … People sometimes don’t use JSON-LD processors, and could interpret the data differently then those using JSON-lD procesors.
17:19:19 <pchampin> q+
17:19:21 <azaroth> And: https://iiif.io/api/presentation/3.0/#45-linked-data-context-and-extensions
17:19:30 <gkellogg> … The other issue is related: we want a base context to define terms, and callout an area where you can clear out the sealed contexts. You could use a scoped context to define a new scoped context for whatever is under that term.
17:19:48 <bigbluehat> q+
17:19:53 <azaroth> ack gkellogg
17:19:54 <gkellogg> q-
17:20:00 <azaroth> ack pchampin
17:20:06 <workergnome> q+
17:20:16 <azaroth> q+ to +1 the issue with refs above
17:20:30 <ivan> present+ workergnome
17:20:49 <gkellogg> pchampin: I’m not sure I understand the use case for allowing people to unseal the context. My understanding is that, in some vocabularies, a term is an extension point, so that below that term the sealed context shouldn’t apply.
17:20:55 <azaroth> q+ to +1 the issue with refs above and give iiif/annotation unsealing case
17:21:21 <gkellogg> … I’d understand the case where it’s always cleared, but not where it “could be”
17:21:34 <gkellogg> dlongley: Yes, it would be a clean-slate by deinition.
17:21:49 <bigbluehat> https://w3c.github.io/web-ledger/
17:22:04 <bigbluehat> https://github.com/digitalbazaar/jsonld-patch/tree/implementation
17:22:17 <gkellogg> … The case for unselaing is used in web ledger, which allows you to store arbitrary data, and has know knowledge of being in a ledger.
17:22:39 <gkellogg> q+
17:23:17 <gkellogg> … In the case of json-ld patch, you want to be able to update arbitrary values in a document, in particular, if you want to be able to digitally sign patches.
17:24:06 <azaroth> ack bigbluehat
17:24:12 <gkellogg> … You could use a scoped context for “value” to clear the context. It’s the case that you want a clean slate and allow users to override the context using embedded or scoped oontexts.
17:24:57 <gkellogg> bigbluehat: Conceptually, this feels like “important!” in CSS, to not allow things to be overridden.
17:25:46 <ivan> q+
17:25:50 <gkellogg> … I think dlongley’s point about how specs are written in the last couple of years is in play in so many places that a sealing mechanism is important.
17:26:04 <dlongley> q+ to say that it's important to use BOTH sealing and keep the existing cascading order we have for the use case i just described with json-ld-patch, for example
17:26:09 <azaroth> ack workergnome
17:26:42 <dlongley> q+ to say no, that won't help with digital signing, it will be worse
17:27:00 <gkellogg> workergnome: We talked about JSON literals before, could that be a way to handle content that is not associated with the context?
17:27:04 <azaroth> ack dlongley
17:27:04 <Zakim> dlongley, you wanted to say that it's important to use BOTH sealing and keep the existing cascading order we have for the use case i just described with json-ld-patch, for example
17:27:07 <Zakim> ... and to say no, that won't help with digital signing, it will be worse
17:27:24 <gkellogg> dlongley: We looked at that, but it ends up being much more difficult, because of how signing works.
17:27:59 <gkellogg> … You’d end up having to canonicalize the JSON, and it becomes a mess. It avoids pitfalls where we want to avoid cauing everything to be marked as a JSON literal.
17:28:01 <azaroth> ack azaroth
17:28:01 <Zakim> azaroth, you wanted to +1 the issue with refs above and to +1 the issue with refs above and give iiif/annotation unsealing case
17:28:45 <gkellogg> azaroth: In IIIF, we have the same wording, but it puts the contexts at the end, rather than the beginning, but we do want to have extension points.
17:29:44 <gkellogg> … Similarly, we use language maps, annotations uses string, we want those to be used together.
17:29:54 <azaroth> q?
17:29:57 <azaroth> ack gkellogg
17:30:05 <azaroth> scribenick: azaroth
17:30:25 <azaroth> gkellogg: Having something that prevents you from saying `@context` None would be inadvisable
17:30:34 <azaroth> ... it does what people have asked for to create the clean slate
17:30:51 <azaroth> ... it requires that values for terms to have their own context, so would need to be explicitly set
17:31:04 <azaroth> ... is there expectation about changing the default content is up higher.
17:31:31 <azaroth> ... If Annotations defines a term, `data`, and you want to unseal it. You add null as a scoped context
17:32:07 <dlongley> q+ to respond to gregg
17:32:11 <azaroth> ... If you want to have the data in schema.org in `data`, you could do it with a scoped context that's an array with null as the first entry, but it's sealed
17:32:17 <azaroth> ... so the context needs to unseal itself
17:32:20 <azaroth> q?
17:32:22 <azaroth> ack ivan
17:32:27 <azaroth> scribenick: gkellogg
17:33:09 <azaroth> q+ to suggest sealing per term, rather than per context
17:33:15 <gkellogg> ivan: The useage of “sealed” seems to be streightforward. I wonder about unsealing only appears when we talk about embedded contexts, is that correct?
17:33:25 <azaroth> q?
17:33:29 <azaroth> ack dlongley
17:33:29 <Zakim> dlongley, you wanted to respond to gregg
17:33:33 <gkellogg> … If I have an array of contexts it’s different than if I have an embedded context.
17:35:04 <azaroth> q+ to suggest sealing per term, rather than per context / qn about redefinition re scoping only
17:35:22 <gkellogg> dlongley: I think that the main use case where you set context to null, should then allow the scoped context, or via an embedded context. If you defined “data” in a sealed context, you’d then say `@context: null`, the second context could then define the term and introspects into the sealed context to see that the term can be overridden because it has a scoped context of null.
17:35:36 <gkellogg> … I think we should keep the cascading order we have.
17:35:37 <azaroth> +1 to last in winning
17:35:39 <gkellogg> q+
17:35:50 <azaroth> q?
17:35:52 <azaroth> ack azaroth
17:35:52 <Zakim> azaroth, you wanted to suggest sealing per term, rather than per context and to suggest sealing per term, rather than per context / qn about redefinition re scoping only
17:35:56 <gkellogg> … It can’t override terms, but can override scoping.
17:36:15 <gkellogg> azaroth: I think we can’t change definition order either.
17:36:44 <dlongley> +1 to sealing individual terms
17:36:51 <workergnome> q+
17:36:58 <jeff_mixter> +1 to individual term sealing
17:37:02 <dlongley> (we've worked out some of these details in #98)
17:37:08 <gkellogg> … what about sealing specific terms in a context? Then, we wouldn’t need to worry about unsealing different things.
17:37:44 <gkellogg> … What would current processors due if they had a …?
17:37:44 <azaroth> q?
17:37:46 <azaroth> ack gkellogg
17:39:01 <dlongley> "data": {"@id": "foo:data", "@container": "@graph", "@context": null, "@sealed": true} => enables a later @context to define: "data": {"@context": "..."}
17:39:05 <azaroth> `"@context": [{"data": {"@id": "eg:data", "@sealed": false}}, {"data": {"@context": "http://example.org/data-context.jsonld"}}]}`
17:39:48 <pchampin> q+
17:40:30 <azaroth> ack workergnome
17:40:38 <pchampin> q-
17:40:50 <azaroth> q?
17:41:00 <bigbluehat> q+ to ask about (possibly) restricting the "stuff inside" overriding to graph containers
17:41:08 <gkellogg> workergnome: The only place I can unseal something is within the context that seals it. I can’t add something that unseals something that had previously been sealed.
17:41:19 <pchampin> q+
17:42:13 <azaroth> q+ to clarify that sealed only seals _defined_ terms, not undefined terms
17:42:38 <azaroth> ack bigbluehat
17:42:38 <Zakim> bigbluehat, you wanted to ask about (possibly) restricting the "stuff inside" overriding to graph containers
17:43:05 <azaroth> -1 to restricting to graph containers
17:43:19 <gkellogg> bigbluehat: I about how we can express this so that the behavior is obvious.
17:43:42 <azaroth> E.g. An LDP implementation for Annotations should not require a graph container to put an annotation in a page
17:43:47 <gkellogg> … Perhaps something the scopes the sealing to the term, the content, or something else.
17:43:57 <bigbluehat> "@sealed": "@id"
17:44:04 <bigbluehat> "@sealed": "@context"
17:44:05 <gkellogg> … Perhaps the `@sealed` could have different values?
17:44:21 <azaroth> q?
17:44:33 <azaroth> ack pchampin
17:44:50 <jeff_mixter> maybe we can walk through the IIIF use case in DC next month
17:45:08 <azaroth> q+ pchampin
17:45:11 <azaroth> ack azaroth
17:45:11 <Zakim> azaroth, you wanted to clarify that sealed only seals _defined_ terms, not undefined terms
17:45:24 <dlongley> i think we can safely add "@sealed": "<foo>" (in a backwards compatible way) if we find that "@sealed": true is insufficient for use cases
17:46:31 <gkellogg> azaroth: My understanding is that if you seal a context (or a set of terms), you’re only sealing the terms it defines. You could have a term outside that context can do whatever it wants, including override terms that would have come from an inherited context.
17:47:07 <jeff_mixter> q+
17:47:40 <azaroth> ` {"data2": {"@context": {"data":  ... }}`
17:47:48 <gkellogg> … If “data2” is defined in a separate context, and within that you define “data”, that could conflict with a sealed “data” term.
17:48:12 <gkellogg> dlongley: If you tried to use that I would expect that to be an error.
17:48:44 <azaroth> q?
17:49:02 <azaroth> ack pchampin
17:50:17 <gkellogg> pchampin: I’m not a fan of sealing or unsealing individual terms, saying `@sealed: false` would not be good.
17:50:34 <ivan> q+
17:50:58 <azaroth> ack jeff_mixter
17:51:53 <gkellogg> jeff_mixter: What if someone want’s to just point at a different context and seal it, but you want to also import additional contexts, wouldn’t that lead to different errors or collisions?
17:52:09 <dlongley> q+ to say that this feature should actually help you make a proper context
17:52:27 <pchampin> -1 to sealing someone else's context
17:52:30 <gkellogg> azaroth: I don’t think you can seal someone else’s context.
17:52:44 <azaroth> q?
17:52:47 <azaroth> ack ivan
17:52:55 <dlongley> q-
17:53:17 <jeff_mixter> so sealing contexts is only within the context of the JSON-ld document?
17:53:24 <gkellogg> ivan: Perhaps dlongley or someone else could come up witha strawman spec text that we can look at. We’re getting lost.
17:53:34 <azaroth> jeff_mixter: Yep.
17:53:34 <ivan> https://github.com/w3c/json-ld-syntax/issues/98#issuecomment-443182908 and the last example of https://github.com/w3c/json-ld-syntax/issues/98#issuecomment-443241467
17:54:06 <dlongley> q+ to say coming up with test cases seems like a good idea
17:54:35 <gkellogg> … These discussions in November we had a table to talk about different ways to seal, and this seems to give a core spec; if it can be written down, we may have something.
17:54:47 <gkellogg> … If it becomes spagetti, we have a problem.
17:54:52 <azaroth> q?
17:55:13 <azaroth> q+ to volunteer to do first hack at the text and examples
17:55:15 <azaroth> ack dlongley
17:55:15 <Zakim> dlongley, you wanted to say coming up with test cases seems like a good idea
17:55:17 <gkellogg> … We have the F2F in three weeks, so maybe we can have a goal to have a final resollution then.
17:55:40 <gkellogg> dlongley: We’d also want test cases so we can experiment with test cases.
17:55:47 <azaroth> ack azaroth
17:55:47 <Zakim> azaroth, you wanted to volunteer to do first hack at the text and examples
17:55:57 <gkellogg> … We intend to implement one way or another.
17:56:09 <gkellogg> azaroth: I’m happy to contribute examples.
17:56:26 <jeff_mixter> so this is not valid - { "@context": [{"@vocab": "http://schema.org/", "@sealed": true}]?
17:56:39 <gkellogg> ivan: We can also use the wiki page.
17:56:43 <azaroth> q?
17:57:02 <jeff_mixter> q+
17:57:12 <azaroth> ACTION: azaroth to document simple input and expected processing of them
17:57:28 <azaroth> ACTION: dlongley to review azaroth's text and add further examples
17:57:31 <dlongley> +1
17:57:35 <bigbluehat> +1
17:57:36 <azaroth> ack jeff_mixter
17:58:45 <azaroth> the best sort of fun :S
17:58:50 <azaroth> s/the best sort of fun :S//
17:58:54 <ivan> q+
17:59:00 <azaroth> ack ivan
17:59:30 <dlongley> jeff_mixter: i think as a first cut of this feature you'd have to seal all of the schema.org terms yourself (defining them yourself in your own @context)
17:59:36 <dlongley> s/@context/`@context`
17:59:38 <gkellogg> ivan: That’s discussed in #108; there was a syntax that might allow for that.
17:59:45 <ivan> https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-447629312
18:00:20 <azaroth> q?
18:00:22 <gkellogg> ivan: I didn’t realize I was sealing it, but it could be done. I’m not sure we want to do that.
18:00:32 <dlongley> thanks everyone for the discussion!
18:00:42 <gkellogg> azaroth: It’s been a useful discussion.
18:01:09 <gkellogg> dlongley: I can probably dial into the F2F.
18:01:52 <azaroth> TOPIC: Adjourn
18:01:55 <ivan> rrsagent, draft minutes
18:01:55 <RRSAgent> I have made the request to generate https://www.w3.org/2019/01/18-json-ld-minutes.html ivan