15:43:41 RRSAgent has joined #json-ld 15:43:41 logging to https://www.w3.org/2019/06/21-json-ld-irc 15:43:42 rrsagent, set log public 15:43:42 Meeting: JSON-LD Working Group Telco 15:43:42 Chair: azaroth 15:43:42 Date: 2019-06-21 15:43:42 Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0018.html 15:43:42 ivan has changed the topic to: Meeting Agenda 2019-06-21: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jun/0018.html 15:43:43 Regrets+ azaroth 15:56:35 azaroth has joined #json-ld 15:57:20 present+ 15:57:28 present+ 15:58:35 present+ 15:58:46 regrets= 15:59:13 present+ 15:59:31 present+ 16:00:40 workergnome has joined #json-ld 16:00:46 present+ 16:01:13 https://github.com/w3c/json-ld-syntax/issues/9 16:02:46 chair: bigbluehat 16:03:02 ajs6f has joined #json-ld 16:03:14 present+ 16:03:52 scribe: dlongley 16:04:18 present+ pchampin 16:04:24 Topic: Approve last week's minutes 16:04:25 https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-14-json-ld 16:04:27 +1 16:04:30 +1 16:04:30 +1 16:04:31 +1 16:04:31 +1 16:04:31 +1 16:04:42 RESOLVE: minutes from last week approved 16:04:51 Topic: Announcements / Reminders 16:05:01 Subtopic: TPAC registration is open https://www.w3.org/2019/09/TPAC/ Early bird pricing ends June 22 (that's tomorrow!) 16:05:10 q+ to bring up July 5th 16:05:19 ack azaroth 16:05:19 azaroth, you wanted to bring up July 5th 16:05:42 azaroth: A point that came up for a different call, ... July 4th falls on a Thursday, I anticipate that many folks in America will be taking Friday off. 16:06:06 azaroth: I was wondering if we could do a quick straw poll this week to see who will be available on Friday. If not enough people will be there we can cancel in advance 16:06:16 +1 16:06:16 +0 16:06:18 +1 :-) 16:06:19 -1 16:06:19 -1 16:06:20 +0 16:06:21 pchampin has joined #json-ld 16:06:24 +1 16:07:23 bigbluehat: It might be worth reviewing the horizontal review status and getting those sent out if they aren't already. 16:07:34 azaroth: I have sent out requests to privacy and security but haven't heard back yet. 16:07:57 ivan: I've made a first step on the i18n one. 16:08:19 azaroth: I've gone through the a11y one but only one question that matters. 16:08:28 azaroth: I think we're up to date until we hear back now. 16:08:42 azaroth: Let's cancel the call on the 5th. 16:08:46 RESOLVE: no call on the 5th 16:08:49 bigbluehat: Fine by me. 16:08:51 i18n review draft -> https://github.com/w3c/json-ld-wg/wiki/I18N-review 16:08:53 present+ 16:09:05 bigbluehat: TPAC registration price goes up after tomorrow. 16:09:09 q+ 16:09:24 ack pchampin 16:09:30 bigbluehat: We are on for TPAC and Rob has gotten call in data/requested it, so there will be remote participation. Only a few of us will be in person. 16:09:45 pchampin: Wanted to make sure the days for the WG meeting are fixed. 16:09:52 ivan: Yes, Thursday and Friday. 16:10:06 pchampin: Trying to make it. 16:10:30 ivan: If you plan to come, one trick is to fly via Seoul, not Tokyo. Tokyo might make you change airport and it can add 5 hours. 16:11:37 Topic: Issues 16:11:44 Subtopic: Consider context by reference with metadata #108 16:11:49 https://github.com/w3c/json-ld-syntax/issues/108 16:12:26 bigbluehat: This is about a more advanced context object that includes referencing other contexts with meta data for a whole host of issues. Most recent use case is around setting propagation. 16:12:44 bigbluehat: Rob you were the last to propose some things. 16:13:17 q+ 16:13:22 q+ to ask a precision about the use cases 16:13:25 azaroth: At this point I think we need this particular pattern. Of the proposed colors for the bikesheds, `@src` seems to convey the appropriate semantics. It's not necessarily a link/href, `@context` and `@id` would make for a lot of overloading that would maybe cause confusion. 16:13:36 azaroth: `@import` isn't too bad but pchampin indicated why it may not be ideal. 16:13:53 q+ 16:13:56 ack gkellogg 16:13:58 azaroth: It seems to me like a reasonable way forwards, assuming, it's implementable and unambiguous. 16:14:01 q+ 16:14:57 q+ to question inline contexts 16:14:59 ack pchampin 16:14:59 pchampin, you wanted to ask a precision about the use cases 16:15:02 gkellogg: I guess my concern about `@src` is ... one is that we don't typically use abbreviated keywords in JSON-LD, `@source` might solve that. The other thing is that my familiarity is similar to href like in HTML where it doesn't provide for an inline option, if we wanted to allow for those there which would sort of make sense. `@import` seems a little more unambigious. 16:15:46 pchampin: Regarding what Gregg just said, I think you have a point, indeed. I wanted to ask about the use cases, I realized after making those proposals, we might not cover one of those. We reactivated this issue about the idea that parameters could be added to this context, to allow this context to propagate/not propagate. 16:16:02 Reference: The propagate case - https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-497809905 16:16:18 pchampin: For this use case we might want to do this with a URL reference or an embedded `@context`. Meta data is always about a referenced context not one that is directly embedded. Does that cover all our use cases. 16:16:19 ack ivan 16:16:23 bigbluehat: Good flag to raise. 16:16:27 q- 16:16:43 ivan: It's very close to what I wanted to ask. I'm not completely sure what we'll use it for apart from the fact that it looks nice. 16:17:01 ivan: There are things like sealed and SRI that came up but we're not talking about that anymore. What are the use cases we want to use it for? 16:17:12 ack azaroth 16:17:12 azaroth, you wanted to question inline contexts 16:17:15 ivan: Btw, 'src' is in use for the image URL in HTML, very close to href. 16:17:42 q+ to suggest a reference only 16:17:45 azaroth: I wanted to ask the same question, do we really want to/need embedded contexts here or external sufficient? I don't know why you would use an embedded one. 16:17:48 q+ 16:17:53 ack gkellogg 16:17:53 gkellogg, you wanted to suggest a reference only 16:17:58 azaroth: If it's only for reference, `@src` is ok, but what's the use case for embedded. 16:18:48 gkellogg: I think we might want to constrain ourselves to a keyword that references an external resource about which we might assert some meta data. Rather than keeping it open about importing several things -- which of them are we asserting things about, as well as an embedded case. There's no use case for that, only some notion of uniformity to allow that. 16:19:22 gkellogg: Now it starts looking overly generalized. If we need a way for a context to reference another one with the semantics that that context is imported into the referencing context that would also allow some room for asserting information about the referenced context, that is a narrow solution which addresses that use case. 16:19:26 +1 16:19:38 bigbluehat: Roughly like what Rob just posted in chat. 16:19:52 gkellogg: In which case `@source` is ok, want some consistency. 16:19:54 ack ivan 16:20:29 Suggested syntax example: `{"@context": [{"@src": "http://.../context.json", "@propagate": false}, ...] }` 16:20:42 q+ 16:20:43 ivan: I must admit that I didn't even consider having this embedded. Rob would you want to comment ... a question I have is are we sure this is the only property? We don't have any other meta data properties to define in 1.1 so far? 16:20:59 azaroth: I don't think so, this is the only one we have so far `@propagate`. 16:21:00 ack pchampin 16:21:06 ivan: I'd like to be sure this is the right solution. 16:21:34 timCole has joined #json-ld 16:21:50 pchampin: Just to be clear, I was not trying to generalize or over generalize, I was just pointing out that as Ivan and Rob pointed out ... `@propagate` is what we unearthed this issue. When I think about it, it makes sense to use it on an embedded context. It started with scoped contexts, most of the time those are embedded. 16:22:00 pchampin: Is `@source` really a solution to the problem we were trying to solve? 16:22:18 present+ timCole 16:22:29 q+ 16:22:32 pchampin: My personal answer would be "no it's not" and maybe we reopened the wrong issue to solve that problem. This mechanism as we envisioned it is more about referenced contexts, not embedded ones. 16:22:33 ack azaroth 16:23:00 azaroth: I think it is still the right thing to reopen. If it's embedded we don't really need this pattern at all. 16:23:07 azaroth: You could restructure your context to do things differently. 16:23:21 azaroth: When you want to reuse an external context, then you need to say whether or not the terms of that context propagate or not. 16:23:30 azaroth: If it's embedded you just set it and you're done. 16:23:47 azaroth: When you pull in another context, like a 1.0 from Annotations, it assumes something that isn't intended and you need to change it. 16:24:01 azaroth: I think the case is an external context and it should not have the default propagation value. 16:24:14 gkellogg: If it's within a type then type contexts don't propagate. 16:24:21 azaroth: Right and this is to change this behavior so it does. 16:24:23 q+ 16:24:34 ack ivan 16:24:35 azaroth: Yes, it's to fix the impedance mismatch between 1.0 and 1.1. 16:25:11 q+ 16:25:16 ivan: I am a little bit lost. What I would propose is that somebody comes up with text, possibly a PR that defines this syntax so that it's clear what it is. Defines its usage with propagate and what that means. I'm a little bit lost. Having something specific written down would help. 16:25:26 ack gkellogg 16:26:00 gkellogg: So I think my confusion is that I recall the discussion about this ... as wanting the ability to reference an external 1.0 context where we'd have to have `@version` specified within there. You can't update the referenced context to do that. 16:26:44 q+ 16:26:48 ack azaroth 16:26:50 gkellogg: If that is one of the use cases .. the other use case is to override the propagation behavior of type-scoped behavior. Not sure how it does that cleanly. Not sure how this relates to the type-scoped propagatability without something more explicit. 16:27:32 azaroth: This is the issue that we discussed a couple of weeks ago now. Where, it's the combination of the 1.0 and the type-scoped context where it really matters. Because 1.0 contexts are defined without the notion of type-scoped contexts or propagation then they'd never be written in such a way that it's prevented because it's not possible in 1.0. 16:27:47 azaroth: When type-scoped contexts gets prevented in 1.1 we need a way to override that for 1.0 and potentially for 1.1. 16:27:56 azaroth: That would be a useful side effect I think to be able to do that. 16:28:06 azaroth: The referenced context might be defined without any notion of type scoping at all. 16:28:29 azaroth: If you want to include it in a way that is compatible with the rest of your constructions which would be propagating or not -- you'd want to make sure it was interpreted consistently. 16:29:13 gkellogg: I think there's a bunch of use cases that need to be considered about what the effect is. Does this include the use of a `@propagate` keyword or not? In one example -- an embedded context that references another one and that includes `@propagate: false`, is that keyword in play and if not, what are the behaviors? 16:29:21 gkellogg: If you reference a 1.0 context does that change the behavior? 16:29:32 gkellogg: I think we need test cases for what the expected behavior is. 16:29:47 q+ 16:29:48 azaroth: I'm happy to write up in the issue in 108 rather than in the propagating one ... a proposed syntax and the proposed functionality. 16:29:56 ack gkellogg 16:30:27 gkellogg: I think part of that functionality is ... if I have a context that defines things and it references things as a source, what is the order of processing. Presumably the point is to process `@version` bits first but can it override term definitions and what's the effect on language, base, and vocab. 16:31:02 gkellogg: The result sort of considered an atomic context such that if it did adhere to some type-scoping or partial type-scoping behavior, does part of it go away, some of it, those are the things I need to understand. 16:31:13 scribe+ bigbluehat 16:31:21 azaroth: Dave ... the propagation point was from VC ... what was the expectation? 16:31:39 dlongley: for external would behave in the same way as external ones would today 16:31:47 ...the context would only apply to the type 16:31:58 ...and it would follow property scope behavior 16:32:08 ...so their should be consistency with how things happen today 16:32:11 gkellogg: Good. 16:32:40 gkellogg: If properties within a type-scoped context, they propagate only if used. 16:32:44 dlongley: Yes. 16:32:54 ACTION: azaroth to write up proposed syntax and functionality for @src/@propagate 16:32:56 azaroth: Unless the propagate flag is set to true. 16:33:09 gkellogg: There seem to be two different concerns, one is embedded contexts and the other is propagation. 16:33:19 azaroth: Yes, we're complicating it. But I don't think there's another solution. 16:34:01 azaroth: We need something like this... the other option is to always propagate but then that's what wont work for the VC folks. 16:34:40 gkellogg: The other option is to have a type-scoped context that sets propagate to true and then it's not removed when we go out of the node object. If we have referenced contexts then it's as if that context were inserted through some process into the referencing one. 16:34:57 q? 16:34:59 gkellogg: Well, what is the effect of property scoped contexts on embedded contexts? 16:35:07 q+ 16:35:10 ack pchampin 16:35:33 gkellogg: What is the effect of `@propagate` on property-scoped contexts or referenced contexts. 16:35:53 pchampin: If I understand correctly, that's the kind of thing Rob is planning to do. 16:35:56 azaroth: Yes, exactly. 16:36:24 pchampin: I want to use the original JSON-LD 1.0 annotation context as a type-scoped context, but since it assumes propagation, I want a way to override the type-scoped behavior which is not to propagate. 16:36:32 azaroth: If there is some other way to do that, that's perfect, totally fine to do that. 16:36:47 azaroth: I don't understand how they are completely orthogonal, then we don't need `@source`. 16:37:02 gkellogg: I think you need `@source` because you need to be able to pull in the definitions from an external context so that you can assert 1.1 types of things about it. 16:37:08 gkellogg: I follow that. 16:37:11 q+ to propose another way 16:37:36 gkellogg: I can see that you might use `@propagate` true on one that doesn't reference an external source and you use `@source` because might want to assert things about that context like SRI. 16:38:05 gkellogg: For your use case you need both of these bits but their behavior is ... we could create test cases that explore the various different uses and test cases for external referencing, and we should have a test case that combines the two. Largely their impact is orthogonal. 16:38:10 ack pchampin 16:38:10 pchampin, you wanted to propose another way 16:38:11 azaroth: I think we're in violent agreement. 16:38:52 pchampin: Here's an idea. The problem seems to come from the fact that you're trying to use the Web Annotation context in a place where it was not designed to be used. It's a 1.0 context. There are not scoped contexts, only local ones, no scoped ones. 16:39:18 pchampin: In a way it makes that it doesn't quite fit in this position. Wouldn't a solution be to have a dedicated version of the Web Annotation context that would be appropriate to be embedded as a type-scoped context? 16:39:28 pchampin: Maybe the solution is not to change the spec but to change the context that you use in this use case? 16:39:53 azaroth: But to go back to the definition of `@propagate` can we say on an `@type`, `@propagate` true? 16:39:57 gkellogg: Yes. 16:40:40 azaroth: If we anticipate that the major schemas that are in use via context referencing... annotations would be one, schema.org etc. ... if they are going to go to 1.1 and they can set propagate or not that would be one other way to do it. 16:40:54 azaroth: It could be defined locally somewhere until they do. But yeah. 16:41:32 azaroth: It seems a bit of a stretch to say that if you want to use this 1.1 feature then because of this weird rule that type-scoped contexts don't behave like property-scoped contexts that you can't use any of the 1.0 contexts. 16:41:57 azaroth: The flip side would be that `@propagate` true is the default and then 1.1 contexts that want to turn it off can set `@propagate: false`. 16:42:15 ivan: How many contexts are we talking about that are really widely known and would have to be updated in this sense? 16:42:30 ivan: What are talking about? We are hearing about two or three possible contexts right now, which is just peanuts. 16:42:43 azaroth: I'm not sure that we know, I would say schema.org, annotations, maybe ldp. 16:42:53 ivan: schema.org might not be easy to change, but the others are peanuts. 16:43:06 workergnome: Is it everything that has included those that also have to be updated at this point? 16:43:13 q+ 16:43:26 ack gkellogg 16:43:28 azaroth: Assuming that there's a different 1.1 context I think that's ok, you'd reference that. 16:43:41 q+ 16:44:05 gkellogg: I think it's dangerous road to assume that we know the impact of all the contexts that are out there and the solution is to just update those contexts. Particularly if it requires that they adhere to 1.1 and the toolchains don't get updated immediately after we release the spec. 16:44:24 gkellogg: Maybe the safest thing is to change the semantics to allow the propagation semantics to default to true but allow for false. 16:45:08 ack bigbluehat 16:45:12 gkellogg: It allows that propagate to be used in other contexts as well. I think there's a use for referencing to be able to do things like that, but you might want to use a 1.0 context and not have it propagate. Then you'd use an envelope with `@propagate` but then no weird stuff. 16:46:08 bigbluehat: Rolling out your contexts and managing multiple versions is an ambient concern. I don't mean to derail your conversation. Our smaller more tightly knit communities aren't going to face this as badly. But any of the ones that are actually doing deployments of other people's vocabularies are going to be up a creek. 16:46:29 bigbluehat: I'm not sure we yet have any vehicle to help them survive. This is taking them to another level, incompatibility concerns. 16:46:50 azaroth: This would be an argument in favor of having the default to be to propagate rather than to not propagate? 16:47:04 bigbluehat: It may not really even matter because of the way we've used versioning it doesn't really matter. 16:47:16 bigbluehat: As soon as that gets stuck into anything you will have to shift to supporting two different ecosystems. 16:47:26 bigbluehat: We'll have that for an unknowable amount of time. 16:47:29 q? 16:47:58 azaroth: In terms of the VC side of things, requiring the context to turn off `@propagate` a hardship? 16:48:09 dlongley: so, VC spec goes into PR on Tuesday 16:48:27 ...everyone has written their tests against the context that does not use `@propogate` false 16:48:32 ...so that would be the main concern 16:48:40 ...it's a major timing issue 16:48:46 s/propogate/propagate/ 16:48:48 ...if we miss PR, the VC spec would fail 16:49:06 ...the other features from 1.1 don't compose 16:49:27 ...so...it'd be strange to have things not work and then have to go find the `@propagate` term to make things work 16:49:46 ...it seems to me that once you pull in a 1.0 context 16:49:55 ...that's been interpreted in a 1.0 scenario 16:50:04 ...folks will have to be ready for the meaning changes 16:50:12 ...if they're processed both as 1.0 and 1.1 16:50:23 ...I understand the desire to make them play nice 16:50:24 q+ 16:50:36 ...but I'm not sure about what we'd give up to keep that happening 16:50:39 ack gkellogg 16:50:44 +q 16:51:42 q+ to suggest that 1.0 contexts should be treated as all classes being @propagate: true 16:51:47 ack workergnome 16:51:51 gkellogg: I'd say maybe the way forward is to add a `@propagate` keyword which changes the behavior of the context it's in to not survive the node object it's used within, but we don't the default behavior for type-scoped contexts. We can add `@propagate: true` to allow to survive or `@propagate: false` on a property-scoped or embedded context to allow it to be removed. It gives us the ability to not mess up the expectations of VCs. 16:52:25 workergnome: A lot of the `@propagate: true/false` default is whether you're coming from a programming background or a JSON-LD background. 16:52:32 q+ to mention priority of constituencies 16:52:45 ack azaroth 16:52:45 azaroth, you wanted to suggest that 1.0 contexts should be treated as all classes being @propagate: true 16:53:05 azaroth: What about if 1.0 contexts were treated that all had an implicit `@propagate: true` on them. 16:53:23 q+ 16:53:27 azaroth: When a 1.0 is imported, all of the classes in that context are treated as if they had `@propagate: true` defined on them because that was the expectation. 16:53:29 ack dlongley 16:53:29 dlongley, you wanted to mention priority of constituencies 16:54:46 ack pchampin 16:54:52 are we taking { "@context": { "Foo": {"@context": { "@propagate": true, ... } } } or { "@context": { "Foo": {"@context": { ... }, "@propagate": true } } 16:55:18 pchampin: I'm not sure Rob's suggestion. The difference is subtle -- is the `@propagate` flag supposed to occur in the context or next to the term definition. 16:55:31 q+ 16:55:32 gkellogg: Inside the context. 16:55:47 pchampin: I don't understand Rob's position then. 16:56:37 azaroth: The primary mismatch is that between contexts defined in 1.0 days, there wasn't any scoping, once defined it's always true. That remains true for property-scopes but not for type-scopes. In 1.1 we want to be able to override that default. We want to be able to have it be explicitly set so a particular class does propagate. 16:57:42 q- 16:57:58 azaroth: The issue then is ... a 1.0 context where it's not a valid keyword, how can we have propagation be true. Given that the expectation in 1.0 was that everything propagated, that when a 1.0 context is imported, we should assume that there was a flag that propagate was set to true for that context. We don't have to put it into the referring context -- if that was just the way that it always worked. If you want to have a 1.1 context that imports 16:57:58 other contexts with propagate false then that's fine you don't have to set anything. 16:58:09 azaroth: It would matter if you want a 1.0 to come in and not have it propagate. 16:58:16 azaroth: But that seems even more marginal than the inverse. 16:59:20 azaroth: I don't think we need `@source` at all if we do that. We can just define `@propagate` with the notion that a 1.0 context acts as if it is true. 16:59:31 q+ 16:59:32 q+ 16:59:59 workergnome: This would need a very big explanation note somewhere because I don't think anyone pays attention to `@version` and having things operate differently seems very confusing. 17:00:08 ack gkellogg 17:00:13 bigbluehat: And the fact that the same context could change its version under the hood changing how it propagates. 17:00:18 +1 workergnome 17:00:28 gkellogg: I'm concerned about that too and it's possible to use 1.1 features without saying `@version` in the context. 17:00:30 Zakim, close the queue 17:00:30 ok, bigbluehat, the speaker queue is closed 17:00:58 gkellogg: Trying to infer things after the fact that we do things differently I think is fraught. I think solution is to be explicit in the wrapper and to set propagation in the referencing context. 17:00:59 ack ivan 17:01:36 ivan: I am acting now as administrator because the minutes will be confusing, I have the impression we're discussing 174 but started with 108. I would add the comments on both of them, and I'm not sure where we are. 17:01:44 ivan: Administratively I think 174 is just being reopened now. 17:01:56 bigbluehat: I think where we are -- this will be the topic that we discuss next week and I'll send out the same agenda. 17:02:05 gkellogg: Please add the issue that I referenced, number 9. 17:02:28 ivan: Can someone come up with a proposal we can follow and read? 17:02:44 azaroth: I'm happy to write up a proposal for the use of external references with an `@propagate` flag. 17:03:02 bigbluehat: Thanks everyone, apologies for going past time. 17:03:24 rrsagent, draft minutes 17:03:24 I have made the request to generate https://www.w3.org/2019/06/21-json-ld-minutes.html ivan