15:38:14 <RRSAgent> RRSAgent has joined #json-ld
15:38:14 <RRSAgent> logging to https://www.w3.org/2019/10/18-json-ld-irc
15:38:15 <ivan> rrsagent, set log public
15:38:15 <ivan> Meeting: JSON-LD Working Group Telco
15:38:15 <ivan> Date: 2019-10-18
15:38:15 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0007.html
15:38:15 <ivan> ivan has changed the topic to: Meeting Agenda 2019-10-18: hhttps://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0007.html
15:38:16 <ivan> Chair: azaroth
15:38:16 <ivan> Regrets+ bigbluehat
15:43:54 <pchampin> pchampin has joined #json-ld
15:47:33 <rubensworks> rubensworks has joined #json-ld
15:48:55 <azaroth> azaroth has joined #json-ld
15:56:02 <gkellogg> gkellogg has joined #json-ld
15:57:18 <ivan> present+
15:59:09 <azaroth> present+
15:59:31 <dlongley> dlongley has changed the topic to: Meeting Agenda 2019-10-18: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Oct/0007.html
16:00:13 <rubensworks> present+
16:00:23 <gkellogg> present+
16:01:00 <dlongley> present+
16:02:12 <azaroth> scribenick rubensworks
16:02:17 <azaroth> scribenick: rubensworks
16:02:34 <gkellogg> I  have webex client problems, need to redowdnload client
16:03:08 <rubensworks> azaroth: Call next week will be skipped due to Thanksgiving.
16:03:17 <azaroth> TOPIC: Approve minutes of previous call
16:03:27 <azaroth> PROPOSAL: Approve minutes of previous call:     https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-11-json-ld
16:03:29 <azaroth> +1
16:03:31 <gkellogg> present+
16:03:31 <rubensworks> +1
16:03:47 <gkellogg> +1
16:03:48 <dlongley> +1
16:03:50 <ivan> +1
16:03:51 <azaroth> RESOLVED: Approve minutes of previous call:     https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-10-11-json-ld
16:04:06 <azaroth> TOPIC: Announcements?
16:04:17 <dlongley> q+
16:04:27 <dlehn> present+
16:04:38 <azaroth> s/Call next week/Last call of November/
16:04:42 <azaroth> ack dlehn
16:04:44 <azaroth> ack dlongley
16:05:43 <azaroth> TOPIC: Issues
16:05:55 <azaroth> SUBTOPIC: Blanket approve "propose closing" to be closed
16:06:02 <azaroth>   https://github.com/orgs/w3c/projects/4?fullscreen=true&card_filter_query=label%3A%22propose+closing%22
16:06:13 <rubensworks> azaroth: We should close all issues labelled with "propose closing".
16:06:26 <jeff_mixter> jeff_mixter has joined #json-ld
16:06:41 <jeff_mixter> present+
16:06:51 <azaroth> PROPOSAL: Close all completed editorial actions
16:06:54 <azaroth> +1
16:06:54 <gkellogg> +1
16:06:56 <rubensworks> +1
16:07:00 <jeff_mixter> +1
16:07:00 <ivan> +1
16:07:09 <dlongley> +1
16:07:16 <dlehn> +1
16:07:17 <azaroth> RESOLVED: Close all completed editorial actions
16:07:26 <rubensworks> azaroth: People have weighed in on every issue, so we can safely close them.
16:07:33 <azaroth> SUBTOPIC: Lazy evaluation of 1.1 processing mode
16:07:39 <azaroth>   https://github.com/w3c/json-ld-api/issues/161
16:08:10 <gkellogg> Also https://github.com/w3c/json-ld-syntax/pull/284
16:08:40 <gkellogg> https://github.com/w3c/json-ld-framing/pull/76
16:08:54 <rubensworks> azaroth: It would be easier for version migration compliance to handle `@version` keyword lazily, and let processors detect them based on the features that are being used.
16:08:58 <gkellogg> https://github.com/w3c/json-ld-api/pull/170
16:09:14 <rubensworks> gkellogg: When we discussed it, the idea was that we would do feature detection, and move up to 1.1 when we saw that.
16:09:51 <rubensworks> ... If you are explicitly in 1.0 mode, then you don't run any 1.1 features. If one such feature would be 1.1, then a 1.0 processor would terminate.
16:10:17 <rubensworks> ... This would happen in any case on old processors if they see unknown (new) features.
16:10:57 <rubensworks> ... The PRs describe this slight change and the necessary steps.
16:11:10 <dlongley> +1 to gregg's description of how lazy eval works
16:11:24 <rubensworks> azaroth: There was a question about the tests to see if there were any issues.
16:11:37 <rubensworks> gkellogg: There weren't any exceptions. I just added a couple of tests.
16:12:20 <rubensworks> ... I've updated many tests that used to the processing mode explicitly, and things seem to work correctly.
16:13:06 <dlongley> q+
16:13:10 <azaroth> ack dlongley
16:13:43 <rubensworks> dlongley: As we will probably will have a JSON-LD 1.2 at some point, we don't want to lock down the version in the algorithm.
16:13:45 <ivan> +1 dlongley
16:14:01 <rubensworks> gkellogg: I agree.
16:14:07 <azaroth> +1 as well
16:14:09 <rubensworks> azaroth: Is this written like that in the PRs?
16:14:15 <dlongley> +1 to remove those clauses
16:14:44 <rubensworks> gkellogg: Yes, the PRs make it so that processing mode can be "unset", which allows the silent upgrade.
16:14:57 <pchampin> present+
16:15:15 <dlongley> +1 to merge the PRs with the above changes
16:15:49 <ivan> +1 for me, too
16:16:35 <rubensworks> gkellogg: The conformance section describes changes to proc mode as well, besides the algorithmic changes.
16:16:56 <azaroth> PROPOSAL: Accept changes after changing clause for explicit 1.1 for API #161, lazy evaluation of processing mode
16:16:59 <azaroth> +1
16:16:59 <gkellogg> +1
16:17:02 <rubensworks> +1
16:17:05 <dlongley> +1
16:17:08 <dlehn> +1
16:17:13 <pchampin> +1
16:17:56 <azaroth> RESOLVED: Accept changes after changing clause for explicit 1.1 for API #161, lazy evaluation of processing mode
16:18:08 <rubensworks> gkellogg: Another useful thing would be a doc/post about the process to update to 1.1.
16:18:34 <azaroth> SUBTOPIC: @default for @type
16:18:41 <azaroth>  https://github.com/w3c/json-ld-framing/issues/74
16:18:42 <rubensworks> ivan: We have to clarify that this is not just lazy evaluation, but it is better than just that.
16:19:13 <rubensworks> azaroth: The only thing you can't consider `@default` for is `@type`.
16:19:20 <rubensworks> gkellogg: Also not `@id`.
16:19:44 <azaroth> q+
16:20:02 <dlongley> q+ to say no additional thoughts, just add `@type` to allow defaults
16:20:03 <rubensworks> ... Framing was mentioned as the proper way to handle these cases, but it does not work right now.
16:20:11 <azaroth> ack azaroth
16:20:35 <rubensworks> azaroth: This fits with our general pattern to allow @type to allow more functionality and context, such as @container and @set.
16:20:56 <azaroth> ack dlongley
16:20:56 <Zakim> dlongley, you wanted to say no additional thoughts, just add `@type` to allow defaults
16:21:00 <rubensworks> ... While our feature window is closed, we can consider this a bug.
16:21:12 <azaroth> q?
16:21:14 <rubensworks> dlongley: This is indeed an oversight, something we can fix.
16:21:50 <pchampin> q+
16:22:18 <rubensworks> pchampin: So the idea is that @type with @default would set the type on node object or value objects, or any of them?
16:22:24 <rubensworks> gkellogg: I think only on node objects.
16:22:24 <azaroth> ack pchampin
16:22:34 <dlongley> q+
16:22:35 <rubensworks> ... We would have to check at the algorithm.
16:22:55 <azaroth> ack dlongley
16:22:58 <rubensworks> s/ at the/ the/
16:23:00 <azaroth> q+ re @default for @direction
16:23:14 <azaroth> ack azaroth
16:23:14 <Zakim> azaroth, you wanted to discuss @default for @direction
16:23:19 <rubensworks> dlongley: I think gkellogg is correct.
16:23:43 <rubensworks> azaroth: Me too. Otherwise we would open up weird issues with @direction and @value.
16:23:46 <dlongley> +1 to azaroth
16:24:22 <azaroth> PROPOSAL: Accept framing #74 as an oversight to be fixed for `@type` on node objects
16:24:23 <gkellogg> +1
16:24:24 <jeff_mixter> +1
16:24:25 <azaroth> +1
16:24:26 <rubensworks> +1
16:24:26 <dlongley> +1
16:24:30 <pchampin> +1
16:24:31 <ivan> +1
16:24:36 <azaroth> RESOLVED: Accept framing #74 as an oversight to be fixed for `@type` on node objects
16:24:51 <azaroth> SUBTOPIC: Reframing relationships
16:24:56 <azaroth> https://github.com/w3c/json-ld-framing/issues/73
16:25:48 <gkellogg> q+
16:25:55 <azaroth> ack gkellogg
16:26:01 <rubensworks> azaroth: There's a graph in the first example, and they want to restructure it so that the actor created has an event. But they can not do everything they want. This looks like a new feature, so we should defer this to the next version, or wontfix.
16:26:14 <rubensworks> gkellogg: It beggs the question: what is the purpose of framing?
16:26:29 <rubensworks> ... You could keep adding features to lead to a complex construct language.
16:26:45 <rubensworks> ... We should understand the boundaries of what framing is intended to do.
16:27:06 <rubensworks> ... best practises might describe how you can do more advanced things using sparql constructs.
16:27:09 <azaroth> q?
16:27:23 <dlongley> q+
16:27:27 <azaroth> ack dlongley
16:27:54 <rubensworks> dlongley: I would mark this as defer, for future discussion in a future version. We may not want to say outright that we don't want this as a framing feature.
16:28:02 <rubensworks> azaroth: We would likely say no, but agreed.
16:29:33 <azaroth> PROPOSAL: Defer framing #73 to future version, as new feature after the proposal window is closed
16:29:36 <dlongley> +1
16:29:37 <azaroth> +1
16:29:37 <rubensworks> +1
16:29:38 <gkellogg> +1
16:29:46 <jeff_mixter> +1
16:29:53 <ivan> +1
16:30:02 <dlehn> +1
16:30:06 <pchampin> +1
16:30:08 <azaroth> RESOLVED: Defer framing #73 to future version, as new feature after the proposal window is closed
16:30:40 <dlehn> q+
16:30:44 <rubensworks> azaroth: Any other issues?
16:30:44 <ivan> q+
16:30:45 <azaroth> ack dlehn
16:31:04 <rubensworks> dlehn: For best practises: jsonld.org site still points to old site, should we point to the new one.
16:31:16 <rubensworks> s/\./\?/
16:31:36 <rubensworks> gkellogg: Agreed, let's do it like the prev specs.
16:31:53 <rubensworks> dlehn: How should we track new features after this WG?
16:31:57 <gkellogg> q+
16:32:07 <rubensworks> azaroth: We should still file the issues, but don't handle them at the moment.
16:32:12 <azaroth> ack gkellogg
16:32:32 <rubensworks> gkellogg: We discussed this as TPAC, and it depends on evolution of WG into CG.
16:33:01 <rubensworks> ... We can pull back in the WG group into the existing CG.
16:33:28 <rubensworks> ... This would be a sustainable way to manage the issues in the CG, until a new WG is chartered.
16:33:41 <rubensworks> ivan: I would postpone this issue for now.
16:34:02 <rubensworks> ... There are discussions that the process at W3C might change, before the charter of this group runs out.
16:34:18 <rubensworks> ... There may be a possibilty to keep this WG alive at a low-scale, in maintenance mode.
16:34:30 <rubensworks> ... So I would wait a bit.
16:34:58 <rubensworks> ... People can still report issues in the repos. When we publish the recs, we will have to work out how to handle errata.
16:35:17 <rubensworks> ... I have tools from CSVW WG that we can reuse for errata.
16:35:23 <rubensworks> ... For now, just use WG repos.
16:35:47 <rubensworks> azaroth: This was also discussed at chairs lunch.
16:36:05 <rubensworks> ... I can't report on what was discussed.
16:36:17 <rubensworks> ivan: I was there, but it was not really discussed.
16:37:07 <azaroth> q?
16:37:11 <rubensworks> q+
16:37:17 <azaroth> ack rubensworks
16:37:43 <azaroth> ack ivan
16:37:48 <rubensworks> rubensworks: what is timeline for implementations?
16:38:04 <rubensworks> ivan: This will come back during the CR discussion, depends on where we are with that.
16:38:28 <rubensworks> azaroth: You have best oversight on amount of editorial work to be done.
16:39:02 <rubensworks> gkellogg: One of biggest remaining things is algorithmic folding, which pchampin works on.
16:39:09 <pchampin> q+
16:39:22 <rubensworks> ivan: It would be an editorial change.
16:39:33 <azaroth> ack pchampin
16:39:35 <rubensworks> ... I would prefer to go to CR when that stuff is done.
16:39:49 <rubensworks> pchampin: I agree, it's only editorial, but there would be a substantial change.
16:40:15 <rubensworks> ... I wanted to wait until algorithms are stabilitized.
16:40:26 <rubensworks> ... Because the folding stuff would be impacted by that.
16:40:34 <rubensworks> ... So once that's done, we can go to CR.
16:40:37 <rubensworks> ivan: So when?
16:41:06 <rubensworks> gkellogg: End of november I think.
16:41:33 <rubensworks> ivan: Can I set a proposal of 8th of November, we aim at voting to go to CR.
16:41:42 <rubensworks> ivan: Is that an acceptable goal?
16:41:47 <rubensworks> gkellogg: I think we can do that.
16:42:10 <rubensworks> gkellogg: 15th of november may be better.
16:42:22 <rubensworks> ivan: Ok. But we get near Thanksgiving.
16:42:38 <rubensworks> ... We have to prepare documents, and may have to have some calls.
16:42:47 <rubensworks> gkellogg: Maybe we should do the 8th then.
16:42:50 <rubensworks> ivan: Ok
16:43:08 <rubensworks> azaroth: How long to those docs be prepared in advance?
16:43:18 <rubensworks> ivan: Up to the WG. Usually five working days.
16:43:32 <rubensworks> azaroth: 1st of november would be beginning of concensus.
16:43:44 <rubensworks> ... By then the documents would need to be fixed.
16:43:48 <rubensworks> ... Is that feasible?
16:44:09 <rubensworks> gkellogg: Yes, if I work on editorial issue, and folding is for pchampin.
16:44:28 <rubensworks> ivan: I've made this wiki page for things we have to collect.
16:44:43 <rubensworks> ... The request for CR simply means raising an issue at the specific repo.
16:44:56 <rubensworks> ... I hope the template has not changed, we may want to check that.
16:45:03 <rubensworks> ... Let me pick it up...
16:45:25 <ivan> -> https://github.com/w3c/json-ld-wg/wiki/%5BJSON-LD-WG%5D-CR-transition-for-json-ld11,-json-ld11-api,-and-json-ld11-framing CR template
16:45:59 <rubensworks> ivan: I have no idea what exactly to write on focus on substantive changes.
16:46:04 <rubensworks> ... I need help for that.
16:46:19 <rubensworks> ... We have a set of changes in the document, right?
16:46:34 <rubensworks> gkellogg: Yes, since last WG and since CG.
16:46:41 <rubensworks> ivan: Great, let's link to those.
16:47:09 <rubensworks> ... "Requirements satisfied", not sure to write there either.
16:47:20 <azaroth> ACTION: gkellogg to add links to changes to CR request wiki page
16:47:20 <rubensworks> gkellogg: Requirements were fed from github issues.
16:47:32 <rubensworks> ivan: CG github?
16:48:05 <rubensworks> gkellogg: CG work began because of issues posted to CG repo. So those were requirements.
16:48:13 <rubensworks> ivan: So we list that as requirements to WG.
16:48:46 <rubensworks> gkellogg: We need to identify issues from CG we want to use.
16:49:00 <azaroth> ACTION: azaroth to find CG issues and reference in CR request wiki page
16:49:14 <rubensworks> ivan: "Wide review" is in issues, nothing via e-mail.
16:49:42 <rubensworks> ... Last thing is information on implementation acceptance criteria.
16:50:09 <rubensworks> gkellogg: We want to give an adequate amount of time to let implementations update.
16:50:23 <rubensworks> ivan: Three months from Christmas?
16:50:51 <rubensworks> s/Christmas/publication of CR/
16:51:19 <rubensworks> gkellogg: Three months sounds fine to me.
16:51:39 <rubensworks> ivan: What will our criteria be?
16:51:49 <rubensworks> gkellogg: Standard is two implementations per feature.
16:52:14 <rubensworks> ... We still may want to think about the specific features, if we need it for those.
16:52:19 <azaroth_> azaroth_ has joined #json-ld
16:52:19 <rubensworks> ivan: Yes, let's do that later.
16:52:34 <rubensworks> ivan: We now have a set of tests for every feature.
16:52:51 <rubensworks> ... We can say we need two independent impls for every feature to pass tests.
16:53:07 <rubensworks> ... gkellogg can you send me a mail with authorative tests?
16:53:18 <gkellogg> https://w3c.github.io/json-ld-api/reports/
16:53:22 <rubensworks> gkellogg: Sure, they can also be found at the top of implementation report.
16:54:00 <rubensworks> ivan: When we say "features", they are tested.
16:54:18 <rubensworks> gkellogg: Some tests will test more than one feature at a time.
16:54:32 <rubensworks> ... It requires looking at description of test to know what is being tested.
16:54:42 <rubensworks> ... tc023 is an example of many features.
16:55:10 <rubensworks> ivan: I see test has a description of relevant features, so that's ok.
16:55:22 <rubensworks> ... Can we say something about additional implementations?
16:55:43 <rubensworks> ... CR is asking for informative test saying how many impls we expect.
16:56:19 <rubensworks> ivan: Ruby, JS, and maybe C/C++?
16:56:36 <rubensworks> gkellogg: Hopefully Java
16:56:47 <gkellogg> See Developers section in https://json-ld.org
16:57:30 <rubensworks> dlongley: Hopefully Python
16:57:49 <rubensworks> rubensworks: And one more JS/TypeScript, but not for compacting/framing.
16:59:16 <azaroth> TOPIC: Adjourn
16:59:17 <ivan> rrsagent, draft minutes
16:59:17 <RRSAgent> I have made the request to generate https://www.w3.org/2019/10/18-json-ld-minutes.html ivan
16:59:17 <ivan> zakim, bye
16:59:17 <ivan> rrsagent, bye
16:59:17 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2019/10/18-json-ld-actions.rdf :
16:59:17 <RRSAgent> ACTION: gkellogg to add links to changes to CR request wiki page [1]
16:59:17 <RRSAgent>   recorded in https://www.w3.org/2019/10/18-json-ld-irc#T16-47-20
16:59:17 <RRSAgent> ACTION: azaroth to find CG issues and reference in CR request wiki page [2]
16:59:17 <RRSAgent>   recorded in https://www.w3.org/2019/10/18-json-ld-irc#T16-49-00
16:59:17 <Zakim> leaving.  As of this point the attendees have been ivan, azaroth, rubensworks, gkellogg, dlongley, dlehn, jeff_mixter, pchampin
16:59:17 <Zakim> Zakim has left #json-ld