15:35:47 <RRSAgent> RRSAgent has joined #json-ld
15:35:47 <RRSAgent> logging to https://www.w3.org/2020/04/24-json-ld-irc
15:35:50 <Zakim> RRSAgent, make logs Public
15:35:51 <Zakim> please title this meeting ("meeting: ..."), ivan
15:35:58 <ivan> ivan has changed the topic to: Meeting Agenda 2020-04-24: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Apr/0029.html
15:35:59 <ivan> Date: 2020-04-24
15:35:59 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Apr/0029.html
15:35:59 <ivan> Chair: azaroth
15:35:59 <ivan> Meeting: JSON-LD Working Group Telco
15:35:59 <ivan> Regrets+ azaroth
15:55:58 <rubensworks> rubensworks has joined #json-ld
15:56:22 <azaroth> azaroth has joined #json-ld
15:56:38 <pchampin> pchampin has joined #json-ld
15:58:03 <azaroth> present+
15:59:37 <gkellogg> gkellogg has joined #json-ld
16:00:11 <rubensworks> present+
16:00:21 <gkellogg> present+
16:05:30 <ivan> present+
16:05:36 <azaroth> scribenick: gkellogg
16:05:37 <gkellogg> scribe+
16:05:44 <azaroth> TOPIC: Announcements / Reminders?
16:05:52 <dlehn> present+
16:06:09 <azaroth> TOPIC: Transitions
16:06:14 <azaroth> SUBTOPIC: Streaming
16:06:24 <azaroth> https://github.com/w3c/transitions/issues/240
16:06:32 <gkellogg> ivan: the streaming note has been approved.
16:06:55 <gkellogg> ACTION: gkellogg to check pubrules on streaming note
16:07:40 <gkellogg> ivan: We’re waiting to hear on transition of rec-track specs
16:08:00 <gkellogg> azaroth: We can move the namespace doc forward, given that the streaming doc has been approved
16:08:20 <gkellogg> ivan: I’ll wait to push the docs to /ns until after publication.
16:08:31 <azaroth> SUBTOPIC: Core Spec Transitions
16:08:46 <azaroth> https://github.com/w3c/transitions/issues/239
16:08:52 <gkellogg> azaroth: Not yet approved by Ralph.
16:09:28 <gkellogg> ivan: Ralph and Phillipe usually have approval sessions on Friday, so may happen today. Otherwise, I’ll start poking
16:10:31 <azaroth> TOPIC:  New issues submitted after PR request
16:10:40 <azaroth> SUBTOPIC: Process
16:10:43 <bigbluehat> present+
16:10:49 <ivan> q+
16:11:21 <azaroth> https://github.com/timothee-haudebourg/json-ld
16:11:33 <gkellogg> azaroth: There are 6+ new issues for the API. (from Rust impl)
16:11:33 <azaroth> ack ivan
16:12:04 <gkellogg> ivan: Things are frozen when the PR is published. We can do editorial changes between now and publication.
16:12:20 <gkellogg> … Once PR is to AC, the documents are frozen once and for all.
16:12:46 <rubensworks> scribe+
16:13:08 <rubensworks> gkellogg: They are some imprecise steps in the algorithm, with things missing.
16:13:16 <rubensworks> ivan: Those things can still be done before PR.
16:13:26 <gkellogg> … If changes are not styistic, then we should wait
16:13:51 <rubensworks> gkellogg: What is the process for dealing with issues that are discovered after the document has been frozen?
16:14:12 <rubensworks> ... We could record these issues as errata.
16:14:35 <gkellogg> ivan: I need to set up errata management. That will be for once the REC is out.
16:14:52 <gkellogg> … For the time being, let’s keep things marked as issues.
16:15:28 <azaroth> SUBTOPIC: Issues
16:16:39 <rubensworks> gkellogg: One issue (#480) is a bit different: @id: null is not a valid jsonld document, which has to do with the fact that we ignore keyword-like entries. A step in the algorithm has issues with this. So this would be more complicated.
16:17:05 <azaroth> https://github.com/w3c/json-ld-api/issues/473
16:18:14 <rubensworks> gkellogg: One of the differences with set versus array is with duplicates. If you compact, there are no duplicates. In expansion, there is nothing that eliminates duplicates. This issue shows something that we may want to look at.
16:18:49 <rubensworks> ... In a future version, this may require an incompatible change.
16:19:03 <rubensworks> ... The editorial change is that expansion does not remove duplicates.
16:19:22 <rubensworks> azaroth: We can do this before the document is frozen.
16:19:52 <azaroth> PROPOSAL: Make editorial change to note that `@set` terms can have duplicate entries during expansion (only)
16:19:54 <azaroth> +1
16:19:56 <gkellogg> +1
16:19:56 <rubensworks> +1
16:19:58 <bigbluehat> +1
16:20:02 <pchampin> +1
16:20:05 <ivan> +1
16:20:07 <azaroth> RESOLVED: Make editorial change to note that `@set` terms can have duplicate entries during expansion (only)
16:20:08 <dlehn> +1
16:20:26 <azaroth> https://github.com/w3c/json-ld-api/issues/475
16:20:48 <rubensworks> azaroth: This issue is a micro-tweak to the algorithms.
16:21:17 <rubensworks> gkellogg: The API document does not explicitly handle @protected: false cases.
16:21:24 <rubensworks> ... I believe this change is editorial.
16:21:36 <rubensworks> azaroth: The change to the text should be very small.
16:22:17 <rubensworks> ... This is a change to a normative section that we have previously decided is editorial, because the tests aren't changed. So we should fix this if we are comfortable given the transition request.
16:22:40 <rubensworks> ivan: Does it affect any implementation already out there? I assume not.
16:23:16 <rubensworks> azaroth: If you implemented strictly, you would fail the test. So this change is required to make implementations pass the test.
16:23:19 <azaroth> PROPOSAL: Make editorial fix for `@protected` in Create Term Definition algorithm per api #475
16:23:20 <gkellogg> +1
16:23:21 <azaroth> +1
16:23:34 <rubensworks> +1
16:23:43 <dlehn> +1
16:23:44 <pchampin> +1
16:23:44 <ivan> +1
16:23:47 <azaroth> RESOLVED: Make editorial fix for `@protected` in Create Term Definition algorithm per api #475
16:23:47 <bigbluehat> +1
16:23:54 <azaroth> https://github.com/w3c/json-ld-api/issues/477
16:24:49 <rubensworks> gkellogg: This is editorial. I suggested an improvement to the wording. This would not change the intention, only improve the wording.
16:25:10 <azaroth> PROPOSAL: Improve wording to clarify any/all and concatenate per api #477
16:25:13 <rubensworks> +1
16:25:14 <gkellogg> +1
16:25:14 <azaroth> +1
16:25:30 <ivan> +1
16:25:31 <pchampin> +1
16:25:41 <bigbluehat> +1
16:25:42 <azaroth> RESOLVED: Improve wording to clarify any/all and concatenate per api #477
16:25:43 <dlehn> +1
16:25:47 <azaroth> https://github.com/w3c/json-ld-api/issues/478
16:26:53 <rubensworks> gkellogg: We have a flag "from map" that was not used, but it is actually used, but got lost. It is required for inherited scoped context. If an implementation does not use this, it can not pass the tests. So this would require restoring the use of this flag to fix this.
16:27:10 <azaroth> PROPOSAL: Add back from_map to 13.8.3.6 to recursive call for scoped contexts per api #478
16:27:13 <gkellogg> +1
16:27:13 <azaroth> +1
16:27:16 <rubensworks> +1
16:27:20 <bigbluehat> +1
16:27:20 <pchampin> +1
16:27:30 <azaroth> RESOLVED: Add back from_map to 13.8.3.6 to recursive call for scoped contexts per api #478
16:27:31 <azaroth> https://github.com/w3c/json-ld-api/issues/479
16:29:29 <pchampin> q+
16:29:29 <rubensworks> gkellogg: It passes active property, while it shouldn't. A node object contains an incl block, and has a rel to another block, the prop relationship should only hold to .... Passing null should be fine here.
16:30:03 <azaroth> ack pchampin
16:30:19 <rubensworks> pchampin: Does passing this active property have some impact on scoped contexts?
16:31:57 <rubensworks> gkellogg: yes, by passing the active property, it is used in an unexpanded sense to find relationships in unscoped contexts, and also for informing the relationship. In a streaming impl, it could be used for creating that triple. I discovered that in my streaming impl. If you strictly follow the algorithm, it doesn't create the issue, as can be seen by the implementations that pass the tests. It is however more correct to not pass an a
16:31:58 <rubensworks> ctive property.
16:32:20 <rubensworks> pchampin: I was afraid that this would cause an unintended ripple effect.
16:32:39 <rubensworks> gkellogg: Those things should be unrelated.
16:33:25 <rubensworks> ... I tried it in my implementation, putting null did not break anything.
16:33:34 <rubensworks> ... But it was required in my streaming implementation.
16:33:51 <azaroth> PROPOSAL: Clarify that in 13.4.6.2 for `@included` an implementation should pass null to avoid creating a reference, per api #179
16:33:55 <gkellogg> +1
16:33:56 <azaroth> +1
16:33:58 <pchampin> +1
16:34:00 <ivan> +1
16:34:03 <rubensworks> +1
16:34:13 <bigbluehat> +1
16:34:16 <azaroth> RESOLVED: Clarify that in 13.4.6.2 for `@included` an implementation should pass null to avoid creating a reference, per api #479
16:34:34 <azaroth> https://github.com/w3c/json-ld-api/issues/480
16:34:43 <rubensworks> gkellogg: This is an implication of ignoring keyword-like things.
16:35:10 <rubensworks> ... The intention is that if you see something that looks like a keyword to be ignired, it would not result in any properties that would be added to the expansion output.
16:35:40 <rubensworks> ... In this case, this reveals that there may be other cases requiring a more substantial change. So we may have to work with this, and tackle it in the future.
16:36:27 <rubensworks> ... It would only be a problem for docs using invalid keywords that are ignored in any case. Those cases may result in invalid documents. There is nothing inherrently wrong with this, but we may need a proper solution in the future.
16:38:15 <rubensworks> gkellogg: @json is only valid for @type values, so if someone would use it as a value for a node, there is no logic that would transform it into rdf:json. Since it is a valid keyword, it could result in a URI if you have an @vocab.
16:39:31 <rubensworks> ... In CBOR, that is not a keyword, the result would be null. Same thing if @type is used in a node object. Neither of those cases would produce anything invalid. It's a special case. The problem may be entirely contained to @id.
16:40:01 <rubensworks> azaroth: We should defer to future version. This is a an edge case that would result in more weirdness through the algorithm.
16:40:14 <azaroth> PROPOSAL: Defer api #480 until future version, as error case of assigning a non-URI as a URI leads to a further (worse) error case, and the solution would be far reaching
16:40:20 <rubensworks> gkellogg: We could annotate the test related to this that this results in invalid jsonld.
16:40:21 <gkellogg> +1
16:40:21 <rubensworks> +1
16:40:22 <azaroth> +1
16:40:22 <ivan> +
16:40:26 <pchampin> +1
16:40:29 <bigbluehat> +1
16:40:31 <azaroth> RESOLVED: Defer api #480 until future version, as error case of assigning a non-URI as a URI leads to a further (worse) error case, and the solution would be far reaching
16:41:02 <azaroth> SUBTOPIC: Errata management
16:41:44 <gkellogg> ivan: The script we use only works with a single repository. We could set up an errata for each repo, or one just for the WG.
16:42:14 <gkellogg> … (I’d rather not hack the script)
16:42:32 <gkellogg> q+
16:42:36 <azaroth> ack gkellogg
16:43:11 <bigbluehat> q+
16:43:26 <gkellogg> ivan: THe cleanest thing is to put the errata close to the document.
16:43:30 <azaroth> ack bigbluehat
16:43:52 <gkellogg> bigbluehat: We talked about doing errata with annotations.
16:44:01 <gkellogg> ivan: We’d need to set up an annotation server on W3C.
16:44:08 <gkellogg> bigbluehat: We use slack now …
16:44:38 <gkellogg> … Other groups use the WHATWG’s kit to do Github-based errata.
16:44:59 <gkellogg> ivan: What I have does that. It was done for the CSVW group.
16:45:27 <gkellogg> … The script gives you a report of the current errata with discussions, resolutions, etc.
16:45:45 <azaroth> e.g. https://www.w3.org/annotation/errata/
16:46:10 <gkellogg> … In theory, we could have one errata for all the documents, but that would be more difficult.
16:46:40 <gkellogg> bigbluehat: I could set up a GitHub template repo to make this easier.
16:46:45 <gkellogg> ivan: Not that simple.
16:47:59 <gkellogg> bigbluehat: It doesn’t show it within the document :(
16:48:00 <azaroth> q?
16:48:57 <azaroth> ACTION: Ivan to put labels into the four repos for errata management
16:49:02 <gkellogg> ivan: I’ll add the labels to the four repos to allow them to appear in the report.
16:49:39 <azaroth> TOPIC: Rechartering
16:49:57 <gkellogg> ivan: I’m still waiting on some things for recharting, but will come in when the PR is done.
16:49:59 <azaroth> TOPIC: Base Context
16:50:24 <azaroth> https://github.com/w3c/json-ld-rc/pull/8
16:50:31 <ivan> -> https://github.com/w3c/json-ld-rc/pull/8#issuecomment-618297517 latest
16:51:16 <gkellogg> ivan: I summarized the changes. I think we agree on prefixes.
16:51:45 <gkellogg> … While bigbluehat and I grugingly accept to use aliases, but perhaps the ship has sailed.
16:51:58 <gkellogg> … I added “direction” and “graph”.
16:52:21 <gkellogg> … We have two types, “HTML” and “JSON”. Note “json” is also a term.
16:52:51 <bigbluehat> q+
16:52:57 <gkellogg> … No one will use these things anyway, so maybe we can skip them.
16:53:14 <azaroth> +1 to removing `JSON` and `HTML`
16:53:21 <gkellogg> … I also lised some pre-defined terms (comment, label, …)
16:53:55 <azaroth> I'm:  +1, +1, +1, +0 (no opinion)
16:54:29 <gkellogg> … “isDefinedBy” and “seeAlso” seem natural.
16:55:01 <gkellogg> … Also, “license” is mapped to schema:license, not XML2.
16:55:08 <azaroth> ack bigbluehat
16:55:43 <bigbluehat> desribedby - https://www.iana.org/assignments/link-relations/link-relations.xhtml
16:55:45 <gkellogg> bigbluehat: You put isDefinedBy as an alternative to describedBy, (they mean different things)
16:55:57 <bigbluehat> from POWDER https://www.w3.org/TR/powder-dr/#assoc-linking
16:56:24 <gkellogg> … As describedBy might become obsolete, I’m reluctant to add it.
16:57:06 <azaroth> https://iiif.io/api/presentation/3.0/#45-html-markup-in-property-values
16:57:16 <gkellogg> bigbluehat: Putting HTML in JSON is extremely common. Whether “rdf:HTML” is harder than “HTML”, I don’t know.
16:57:46 <bigbluehat> "@type": "rdf:HTML" vs. "type": "HTML" in a data document
16:58:03 <bigbluehat> (or "@type": "HTML"...which I'd prefer)
16:58:13 <azaroth> {"value": "<p> ...</p>", "type": "HTML"}
16:58:21 <gkellogg> ivan: I’m less worried about the context author.
16:58:36 <gkellogg> bigbluehat: The risk is naming collision, and it’s harder to remove something than add it.
16:59:03 <pchampin> and as ivan pointed out, 'rdf:HTML' can still be used
16:59:18 <gkellogg> … I’d remove HTML and JSON, along with all the keyword aliases.
16:59:43 <gkellogg> … Others might think that keyword aliases would have different meanings in their contexts.
17:00:20 <gkellogg> ivan: Two different things, are the datatype aliases in there, the other is are the keyword aliases in there.
17:01:17 <gkellogg> bigbluehat: People might have values for these types, and an expectation for existing JSON for a collision is fairly hight.
17:01:27 <gkellogg> s/hight/high/
17:01:42 <azaroth> TOPIC: Adjourn
17:02:02 <ivan> zakim, end meeting
17:02:02 <Zakim> As of this point the attendees have been azaroth, rubensworks, gkellogg, ivan, dlehn, bigbluehat
17:02:04 <Zakim> RRSAgent, please draft minutes
17:02:04 <RRSAgent> I have made the request to generate https://www.w3.org/2020/04/24-json-ld-minutes.html Zakim
17:02:07 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
17:02:11 <Zakim> Zakim has left #json-ld
17:03:00 <ivan> rrsagent, bye
17:03:00 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2020/04/24-json-ld-actions.rdf :
17:03:00 <RRSAgent> ACTION: gkellogg to check pubrules on streaming note [1]
17:03:00 <RRSAgent>   recorded in https://www.w3.org/2020/04/24-json-ld-irc#T16-06-55
17:03:00 <RRSAgent> ACTION: Ivan to put labels into the four repos for errata management [2]
17:03:00 <RRSAgent>   recorded in https://www.w3.org/2020/04/24-json-ld-irc#T16-48-57