16:39:41 <RRSAgent> RRSAgent has joined #json-ld
16:39:41 <RRSAgent> logging to https://www.w3.org/2020/02/28-json-ld-irc
16:39:44 <Zakim> RRSAgent, make logs Public
16:39:45 <Zakim> please title this meeting ("meeting: ..."), ivan
16:41:03 <ivan> Date: 2020-02-28
16:41:03 <ivan> Agenda:https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Feb/0034.html
16:41:03 <ivan> ivan has changed the topic to: Meeting Agenda 2020-02-28: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Feb/0034.html
16:41:04 <ivan> Chair: azaroth
16:41:04 <ivan> Meeting: JSON-LD Working Group Telco
16:41:59 <rubensworks> rubensworks has joined #json-ld
16:55:30 <gkellogg> gkellogg has joined #json-ld
16:58:06 <pchampin> pchampin has joined #json-ld
16:59:02 <ivan> present+
17:00:08 <hsolbrig> hsolbrig has joined #json-ld
17:00:10 <dlongley> regrets+
17:00:13 <hsolbrig> present+
17:00:17 <azaroth> present+
17:00:21 <rubensworks> present+
17:00:22 <azaroth> regrets+ jeff_mixter
17:01:19 <gkellogg> present+
17:01:21 <pchampin> present+
17:01:29 <azaroth> scribenick: pchampin
17:01:43 <ivan> q+
17:01:47 <azaroth> ack ivan
17:02:13 <rubensworks> ivan: Good news: intermediate CR got approved. Bad news: ??? doesn't like us, so we have to publish it in the traditional way.
17:02:31 <rubensworks> gkellogg: There is a workaround, related to the name of the issue. Easiest way to go forward is the old way.
17:02:36 <azaroth> s/???/Echidna/
17:02:47 <rubensworks> gkellogg: I will create snapshots.
17:02:53 <azaroth> scribenick: rubensworks
17:03:08 <azaroth> scribe- pchampin
17:03:19 <rubensworks> gkellogg: We already pushed the framing update, so that worked.
17:03:59 <rubensworks> azaroth: So everything is under control with the CR publication.
17:04:18 <rubensworks> ivan: An issue was raised at Echidna that this should be solved.
17:05:05 <rubensworks> gkellogg: Biggest last-minute changes to API and framing were from people from the WebIDL team. Some names have changes, which are editorial.
17:05:20 <azaroth> q?
17:05:25 <rubensworks> ... Now, things would work if someone would generate an interface for a browser.
17:05:37 <azaroth> TOPIC: IETF and Process for media types
17:06:12 <bigbluehat> present+
17:06:15 <rubensworks> azaroth: IETF is not certain about multiple +'s in the media type. They want to take that out of the registration.
17:06:39 <dlehn> present+
17:06:42 <rubensworks> ... Manu and the DID folks seemed ok with it. It's their fight to take up later.
17:06:56 <timCole> timCole has joined #json-ld
17:07:06 <rubensworks> gkellogg: We eliminated the paragraph from the docs. It does not appear in the published spec.
17:07:51 <rubensworks> ivan: 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.
17:08:18 <azaroth> TOPIC: Issues
17:08:35 <azaroth> SUBTOPIC: Nested property-scoped fields
17:08:42 <azaroth> https://github.com/w3c/json-ld-api/issues/380
17:09:30 <rubensworks> gkellogg: 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.
17:10:58 <rubensworks> ... 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?
17:11:56 <rubensworks> pchampin: 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.
17:12:12 <rubensworks> ... So I could live with scoped contexts handled in expansion, and not handled in compaction.
17:12:56 <rubensworks> ... 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.
17:13:27 <ivan> q+
17:13:57 <azaroth> q+ re false compaction
17:14:01 <rubensworks> ... 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.
17:14:04 <azaroth> ack ivan
17:14:44 <rubensworks> ivan: 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.
17:15:04 <rubensworks> ... We may come back to it at some point in time, which depends on what the future holds for JSON-LD.
17:15:11 <gkellogg> q+
17:15:14 <pchampin> q+
17:15:17 <rubensworks> ... This sounds too much for a CR that we plan to close in a few weeks.
17:15:19 <azaroth> q?
17:15:21 <azaroth> ack azaroth
17:15:21 <Zakim> azaroth, you wanted to discuss false compaction
17:16:05 <rubensworks> azaroth: pchampin, could you clarify the scenario where you expand+compact and get different semantics?
17:16:06 <pchampin> https://github.com/w3c/json-ld-api/issues/380#issuecomment-590574392
17:16:34 <rubensworks> ... I agree that this is on the border of a new feature.
17:17:39 <azaroth> q?
17:17:55 <rubensworks> pchampin: 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.
17:18:30 <azaroth> ack gkellogg
17:18:32 <rubensworks> azaroth: I can see this happening in practise.
17:19:30 <azaroth> q?
17:19:33 <azaroth> ack pchampin
17:19:39 <rubensworks> gkellogg: 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.
17:19:46 <pchampin> https://github.com/w3c/json-ld-api/issues/380#issuecomment-590796364
17:19:55 <azaroth> q?
17:20:38 <rubensworks> pchampin: 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.
17:20:43 <rubensworks> ivan: Ok, let's defer.
17:21:06 <rubensworks> azaroth: Does this also apply to your other issue pchampin?
17:21:28 <gkellogg> q+
17:21:29 <azaroth> PROPOSAL: Defer #380 for future version as (1) can be experimental as not forbidden, (2) borderline new feature in feature freeze, (3) dangerously asymmetric
17:21:32 <gkellogg> +1
17:21:36 <rubensworks> pchampin: No, that one points out the assymetry.
17:21:36 <ivan> +1
17:21:38 <hsolbrig> +1
17:21:39 <rubensworks> +1
17:21:43 <timCole> +1
17:21:49 <pchampin> +1
17:21:57 <azaroth> +1
17:21:59 <ivan> zakim, who is here?
17:21:59 <Zakim> Present: ivan, hsolbrig, azaroth, rubensworks, gkellogg, pchampin, bigbluehat, dlehn
17:22:01 <Zakim> On IRC I see timCole, hsolbrig, pchampin, gkellogg, rubensworks, RRSAgent, Zakim, azaroth, ivan, dlehn, manu, dlongley, bigbluehat, ChristopherA, hadleybeeman, dorian
17:22:03 <bigbluehat> +1
17:22:09 <ivan> present+ timCole
17:22:12 <azaroth> RESOLVED: Defer #380 for future version as (1) can be experimental as not forbidden, (2) borderline new feature in feature freeze, (3) dangerously asymmetric
17:22:15 <azaroth> ack gkellogg
17:22:16 <dlehn> +1
17:22:48 <azaroth> SUBTOPIC: Recursive Nesting and Compaction
17:22:51 <azaroth> https://github.com/w3c/json-ld-api/issues/391
17:22:55 <rubensworks> gkellogg: 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.
17:23:04 <rubensworks> azaroth: Next one is related by pchampin.
17:23:37 <rubensworks> pchampin: This issue is just to check that recursively nested properties are ... after round-tripping.
17:24:03 <rubensworks> ... I didn't suggest any change. This can be closed. This was just to support my other arguments in the previous issue.
17:24:11 <rubensworks> gkellogg: We should also defer this, rather than close.
17:24:27 <azaroth> PROPOSAL: Defer #391 on recursively nested properties to future version as new feature that can be experimented with
17:24:32 <gkellogg> +1
17:24:34 <azaroth> +1
17:24:36 <pchampin> +1
17:24:38 <dlehn> +1
17:24:39 <rubensworks> +1
17:24:40 <timCole> +1
17:24:41 <hsolbrig> +1
17:24:52 <azaroth> RESOLVED: Defer #391 on recursively nested properties to future version as new feature that can be experimented with
17:25:07 <azaroth> SUBTOPIC: @prefix
17:25:13 <azaroth> https://github.com/w3c/json-ld-syntax/issues/329
17:25:22 <rubensworks> hsolbrig: We talked about this last week.
17:25:38 <rubensworks> ... There is a whole community out there that uses JSON-LD mainly for prefix mgmt.
17:25:46 <rubensworks> ... Their prefixes are non-standard.
17:26:09 <rubensworks> ... The @prefix feature we put in broke their stuff a while back, the only noticed recently when things started breaking.
17:26:37 <rubensworks> This used to work in JSON-LD 1.0, but breaks in 1.1. Sometimes they treat it as regular JSON.
17:26:54 <rubensworks> ... I suggested @prefix true in root making all terms prefixes.
17:27:18 <rubensworks> ... We're not going to get that one in without going back to WD.
17:27:50 <rubensworks> ... 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.
17:28:11 <azaroth> q+ to ask about syntactic sugar vs unfixable backwards incompatibility
17:28:20 <rubensworks> ... Alternative 2: we can add _ (and possibly more terms) to gen-delim list.
17:28:28 <rubensworks> s/terms/characters/
17:28:51 <azaroth> ack azaroth
17:28:51 <Zakim> azaroth, you wanted to ask about syntactic sugar vs unfixable backwards incompatibility
17:28:59 <rubensworks> hsolbrig: We don't want to loose this community.
17:29:19 <rubensworks> azaroth: Should there be syntactic sugar to prefix? And what about backwards-compatibility with 1.0?
17:30:23 <rubensworks> gkellogg: If you use an expanded term def without @prefix true, we don't ...
17:30:52 <rubensworks> azaroth: We gave people the ability for people using non-gen-delim as last character a way to still force the term as a prefix.
17:31:39 <rubensworks> azaroth: The change is in the context, which no one would be processing as JSON?
17:31:53 <bigbluehat> q+
17:31:54 <rubensworks> hsolbrig: Yes, they process the context as just JSON. Mainly for prefix-management.
17:32:20 <azaroth> ack bigbluehat
17:32:53 <rubensworks> bigbluehat: I don't want to change the language to match the translation book.
17:33:19 <rubensworks> ... We are seeing this pattern happening in other communities, where people are processing JSON-LD as JSON.
17:33:56 <azaroth> q?
17:34:00 <rubensworks> ... 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.
17:34:10 <hsolbrig> +1 on bigbluehat -- folks are thinking about using context files as declarative mappings as well
17:34:27 <gkellogg> q+
17:34:37 <pchampin> q+
17:34:38 <rubensworks> azaroth: This looks to me like a new feature.
17:34:54 <rubensworks> ... Unless we agree that this is something is broken, we shouldn't go back to WD and go back again.
17:35:12 <rubensworks> hsolbrig: Are there any options I mentioned that doesn't require us to go back to WD?
17:35:25 <gkellogg> q-
17:35:35 <rubensworks> ... Can we just add the option? Or add something to the gen-delim list? Do these require going back to WD?
17:36:01 <azaroth> q?
17:36:03 <azaroth> ack pchampin
17:36:10 <rubensworks> azaroth: Yes, it makes current tests invalid and changes behaviour.
17:36:52 <rubensworks> pchampin: 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?
17:37:09 <azaroth> q?
17:37:19 <rubensworks> ... Would not be possible if hosted on GitHub pages, which I think it is.
17:39:06 <azaroth> q?
17:39:07 <rubensworks> hsolbrig: 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.
17:40:59 <rubensworks> gkellogg: 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.
17:42:44 <rubensworks> azaroth: 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.
17:42:57 <hsolbrig> q+
17:43:10 <azaroth> ack hsolbrig
17:43:16 <rubensworks> ... I suggest that we say that they have to make prefixes explicit.
17:43:54 <rubensworks> hsolbrig: 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.
17:44:07 <rubensworks> ... I have to leave now...
17:44:08 <azaroth> q?
17:44:29 <bigbluehat> q+
17:44:33 <azaroth> ack bigbluehat
17:44:57 <rubensworks> bigbluehat: I think this is the JSON-LD versus the world question, and how we best interface with the various communities.
17:45:08 <ivan> q+
17:45:14 <rubensworks> ... We are highlighting several problems with different communities.
17:45:28 <rubensworks> ... I would love there to be other options next to us saying we're out of time.
17:45:49 <rubensworks> ... Harold is probably right that we're going to loose them.
17:46:03 <rubensworks> ... We need to have a better answer for the future of JSON-LD.
17:46:10 <gkellogg> q+
17:46:27 <azaroth> ack ivan
17:46:32 <rubensworks> ... For resolving issues, such as is going on now with RDF.
17:46:42 <rubensworks> ivan: Let's be careful with this discussion.
17:46:55 <rubensworks> ... The RDF community has lost activity, but this is a different case.
17:47:18 <rubensworks> ... For cases like these we need a strict deadline, saying when we do a release.
17:47:52 <rubensworks> ... There were discussions in Fukuoka which means that it would be possible to introduce a different kind of processing for an existing spec.
17:48:02 <rubensworks> ... Where a new feature could be added in a much shorter round.
17:48:44 <rubensworks> ... 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.
17:48:50 <gkellogg> q-
17:49:05 <rubensworks> ... What is happening now, there will be a vote on this new process soon-ish.
17:49:45 <rubensworks> ... 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.
17:50:18 <rubensworks> ... It means that member companies to maintain a WG, which not all companies will want to do.
17:50:50 <gkellogg> q+
17:51:04 <rubensworks> ... If there was 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.
17:51:49 <azaroth> ack gkellogg
17:51:58 <rubensworks> ... There are high probabilities that the vote meeting will not happen because of the virus, so this process may take a while.
17:53:17 <bigbluehat> q+
17:53:24 <rubensworks> gkellogg: 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.
17:53:42 <rubensworks> ivan: The goal of this new process would be to avoid gaps of several years.
17:53:49 <azaroth> ack bigbluehat
17:53:51 <rubensworks> ... The current process slows down things.
17:54:20 <rubensworks> bigbluehat: People want two things: hope and a path. Our current conversations go away from that, when we say that the time is up.
17:54:35 <azaroth> q+
17:54:42 <rubensworks> ... We should tell people what they should do when we say time is up, instead of just saying 'defer'.
17:55:08 <azaroth> ack azaroth
17:55:13 <rubensworks> ... Because this shrinks the size of the community, and we should give people hope.
17:55:54 <rubensworks> azaroth: The value of the current process is about scoping.
17:56:14 <rubensworks> ... If we didn't have this feature scope, we would never finish, because new good ideas would always come.
17:56:22 <gkellogg> +1 to azaroth
17:56:30 <rubensworks> ... For new product releases, you have to define the set of features a product supports.
17:56:44 <pchampin> q+
17:56:50 <azaroth> ack pchampin
17:56:56 <rubensworks> ... To me, the prefix block would be a good feature to support in the future, but can not do at the moment.
17:57:39 <rubensworks> pchampin: The global flag would be an easy thing to implement, which we could do as implementors, even if it is not supported formally.
17:57:59 <rubensworks> azaroth: Is it actually the best solution?
17:58:41 <rubensworks> gkellogg: 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.
17:59:16 <rubensworks> ... We definitely need some messaging to the community on what the processing is.
17:59:52 <rubensworks> ivan: We should decide now on a resolution.
18:00:33 <azaroth> PROPOSAL: @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
18:00:40 <gkellogg> +1
18:00:41 <azaroth> +1
18:00:41 <rubensworks> +1
18:00:42 <dlehn> +1
18:00:43 <timCole> +1
18:00:46 <pchampin> +1
18:00:47 <ivan> +1
18:00:56 <bigbluehat> +1
18:00:58 <azaroth> RESOLVED: @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
18:01:09 <azaroth> TOPIC: Adjourn
18:01:40 <ivan> zakim, end meeting
18:01:40 <Zakim> As of this point the attendees have been ivan, hsolbrig, azaroth, rubensworks, gkellogg, pchampin, bigbluehat, dlehn, timCole
18:01:42 <Zakim> RRSAgent, please draft minutes
18:01:42 <RRSAgent> I have made the request to generate https://www.w3.org/2020/02/28-json-ld-minutes.html Zakim
18:01:45 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
18:01:49 <Zakim> Zakim has left #json-ld
18:02:51 <ivan> rrsagent, bye
18:02:51 <RRSAgent> I see no action items