15:14:35 <RRSAgent> RRSAgent has joined #json-ld
15:14:35 <RRSAgent> logging to https://www.w3.org/2020/04/17-json-ld-irc
15:14:37 <Zakim> RRSAgent, make logs Public
15:14:39 <Zakim> please title this meeting ("meeting: ..."), ivan
15:14:52 <ivan> ivan has changed the topic to: Meeting Agenda 2020-04-10: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Apr/0011.html
15:14:53 <ivan> Date: 2020-04-17
15:14:53 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Apr/0011.html
15:14:53 <ivan> Chair: azaroth
15:14:53 <ivan> Meeting: JSON-LD Working Group Telco
15:14:53 <ivan> Regrets+ bigbluehat
15:50:14 <pchampin> pchampin has joined #json-ld
15:53:31 <azaroth> azaroth has joined #json-ld
15:56:05 <azaroth> present+
15:56:12 <pchampin> present+
15:57:36 <rubensworks> rubensworks has joined #json-ld
15:57:46 <gkellogg> gkellogg has joined #json-ld
16:00:42 <azaroth> Chair: azaroth
16:00:49 <ivan> present+
16:01:16 <rubensworks> present+
16:01:23 <gkellogg> present+
16:01:34 <azaroth> regrets+ bigbluehat
16:01:56 <dlehn> present+
16:01:56 <azaroth> scribenick: pchampin
16:02:11 <azaroth> TOPIC: Announcements / Reminders?
16:02:36 <pchampin> rubensworks: I don't see the namespace PR mentioned on the agenda. I think we have to discuss that.
16:02:37 <azaroth> agenda+ namespace PR
16:03:03 <azaroth> TOPIC: Transition to PR
16:03:21 <azaroth> SUBTOPIC: Dispose remaining issues
16:03:48 <azaroth> https://github.com/w3c/json-ld-syntax/issues/255
16:04:30 <pchampin> azaroth: the example about the `@included` keyword was not very easy to understand;
16:04:48 <azaroth> https://github.com/w3c/json-ld-syntax/pull/348
16:04:49 <pchampin> ... last week, I finally pushed a PR to fix it
16:05:25 <pchampin> ... It replaces the anonymous "things" with "categorisations" with
16:05:39 <pchampin> ... "members" of an organization, with "roles"
16:06:11 <pchampin> The PR has been approved by pchampin gkellogg ivan bigbluehat .
16:06:33 <pchampin> ... Any objection from the others?
16:06:45 <azaroth> https://github.com/w3c/json-ld-syntax/issues/343
16:07:34 <pchampin> gkellogg: this was mostly a misunderstanding, about which document should be accessed
16:08:11 <pchampin> ... the published document does not have the issue
16:08:13 <azaroth> PROPOSAL: Close #343 invalid, as the final form will have anchors in the html
16:08:16 <azaroth> +1
16:08:18 <pchampin> +1
16:08:19 <gkellogg> +1
16:08:22 <rubensworks> +1
16:09:00 <dlehn> +1
16:09:04 <azaroth> RESOLVED: Close #343 invalid, as the final form will have anchors in the html
16:09:25 <pchampin> azaroth: if the previews were working efficienly we could point to them
16:10:02 <azaroth> SUBTOPIC: Implementation Reports
16:10:05 <pchampin> azaroth: all open issues have been addressed
16:10:09 <gkellogg> https://w3c.github.io/json-ld-api/reports/
16:10:18 <pchampin> ... Where are we with the implementation reports?
16:10:56 <pchampin> gkellogg: we now have 10 tested implementations in various languages;
16:11:20 <pchampin> ... a CSS trick adds a red cross next to tests that don't have 2 passing implementations.
16:12:50 <pchampin> ... With the latest implementations that were added, all tests now are good w.r.t. this criterion.
16:13:05 <azaroth> q?
16:13:15 <pchampin> azaroth: it would be nice to get a Java implementation, but we can go
16:13:37 <pchampin> ivan: we are fine to submit to the director;
16:13:50 <pchampin> ... the Java implementation may even come in the meantime.
16:14:22 <pchampin> ... We must include proofs of wide review (pointers to github).
16:14:31 <gkellogg> https://github.com/w3c/json-ld-api/issues?q=is:issue+is:closed+label:wr:spec-updated
16:14:42 <gkellogg> https://github.com/w3c/json-ld-syntax/issues?q=is:issue+is:closed+label:wr:spec-updated
16:14:50 <gkellogg> https://github.com/w3c/json-ld-framing/issues?q=is:issue+is:closed+label:wr:spec-updated
16:14:50 <pchampin> gkellogg: that's the ones I did put.
16:15:04 <pchampin> ivan: perfect
16:15:06 <azaroth> SUBTOPIC: Transition Request
16:15:39 <pchampin> azaroth: the process is for ivan to submit an issue on the magic github.
16:15:53 <pchampin> ivan: I will do it, but I need a formal resolution.
16:16:32 <azaroth> PROPOSAL: WG agrees that we should progress the three core specifications, syntax, api and framing, to Proposed Recommendation status
16:16:44 <gkellogg> +1
16:16:44 <ivan> +1
16:16:44 <azaroth> +1
16:16:45 <rubensworks> +1
16:16:46 <pchampin> +1
16:17:01 <dlehn> +1
16:17:08 <azaroth> RESOLVED: WG agrees that we should progress the three core specifications, syntax, api and framing, to Proposed Recommendation status
16:17:43 <pchampin> ivan: to be really precise, this will only be effective in a week (to leave time for objections).
16:18:02 <gkellogg> q+
16:18:11 <pchampin> ... But I can submit it right away, it will be a week before the director looks at it.
16:18:32 <pchampin> ... I had a chat with Ralph, explaining why we have many FAILs on the HTML features.
16:18:42 <azaroth> ack gkellogg
16:18:53 <pchampin> ... There are good chances that we get it without a telco.
16:19:07 <pchampin> ... gkellogg, I assume all the docs pass all validators?
16:19:21 <pchampin> gkellogg: I'll check today.
16:19:49 <pchampin> gkellogg: the HTML tests are all marked with a specific feature;
16:20:02 <pchampin> ... the spec states that processors are not required to implement this feature;
16:20:36 <pchampin> ... some parsers have only FAIL (go, ruben's), it does not mean that they *attempt* to do it and fail.
16:20:54 <pchampin> ... This is an issue with earl statuses. They should rather not report anything.
16:21:55 <pchampin> gkellogg: I also marked in gray the tests about non-normative features.
16:22:12 <azaroth> q?
16:22:14 <pchampin> ... We have implementations of the i18n datatype and compound literals.
16:22:45 <pchampin> azaroth: any other questions about transition?
16:23:02 <pchampin> gkellogg: is it prematue to freeze versions with a given date?
16:23:05 <azaroth> SUBTOPIC: Transition for Streaming Note
16:23:09 <pchampin> ivan: yes, we will see to it later
16:23:42 <pchampin> azaroth: homefully, people had time to read the latest version of the Streaming note
16:23:53 <pchampin> s/homefully/hopefully/
16:24:00 <azaroth> json-ld11-streaming ?
16:24:07 <pchampin> ivan: the resolution should mention the short name we want to use
16:24:34 <pchampin> dlehn: does it require the 11 in the name?
16:24:56 <pchampin> azaroth: I think it does, in case version 1.2 changes something in the note
16:24:58 <rubensworks> q+
16:25:02 <azaroth> ack rubensworks
16:25:17 <pchampin> rubensworks: are we going to ask for a redirect without the 11?
16:25:26 <pchampin> ivan: yes we can
16:25:39 <azaroth> PROPOSAL: Request publication of the Streaming note with short name of json-ld11-streaming, and a redirect from json-ld-streaming
16:25:46 <azaroth> +1
16:25:47 <gkellogg> +1
16:25:53 <pchampin> +1
16:25:54 <rubensworks> +1
16:25:57 <ivan> +1
16:26:06 <dlehn> +1
16:26:08 <azaroth> RESOLVED: Request publication of the Streaming note with short name of json-ld11-streaming, and a redirect from json-ld-streaming
16:26:27 <pchampin> ivan: I would propose to sync the publication of this one with the PR.
16:26:54 <pchampin> ... rubensworks we need to check that the document passes through all the pub-rules checker.
16:27:09 <pchampin> gkellogg: I can help Ruben with that
16:27:34 <pchampin> ivan: also, is it worth setting up Echidna for it?
16:27:57 <pchampin> gkellogg: there is only one implementation for the moment;
16:28:16 <pchampin> ... I'm trying to build another one, but the note lacks some precisions, which is ok,
16:28:31 <azaroth> PROPOSAL:  Setup echidna for future publications of the streaming note
16:28:33 <azaroth> +1
16:28:34 <pchampin> ... but if others give it a try, issues may arise
16:29:19 <pchampin> ivan: gkellogg can you copy your echidna setting from the other specs?
16:29:29 <ivan> +1
16:29:42 <rubensworks> +1
16:29:44 <gkellogg> +1
16:29:46 <pchampin> +1
16:29:51 <dlehn> +1
16:29:53 <azaroth> RESOLVED:  Setup echidna for future publications of the streaming note
16:30:17 <azaroth> SUBTOPIC: Namespace issue
16:30:27 <rubensworks> https://github.com/w3c/json-ld-wg/pull/140
16:31:13 <pchampin> azaroth: rubensworks would like to provide a profile IRI in the JSON-LD namespace,
16:31:28 <pchampin> ... to mark content as complying with the Streaming note
16:31:59 <pchampin> ... I think that we decided last week to wait until the note was approved,
16:32:14 <pchampin> ... before changing the namespace.
16:32:50 <pchampin> ivan: we could sync that with the publication.
16:33:20 <pchampin> ... The HTML files are not redirected, they are copied.
16:33:32 <pchampin> ... What about the TTL file?
16:33:46 <pchampin> gkellogg: it is generated from the CSV file.
16:34:10 <pchampin> rubensworks: The changed to the CSV file should be included in the pull request.
16:34:36 <pchampin> ivan: if we are confident that this is the final text, we can merge the PR.
16:34:46 <rubensworks> q+
16:34:51 <azaroth> ack rubensworks
16:35:03 <rubensworks> https://www.w3.org/TR/json-ld11-streaming/
16:35:19 <pchampin> rubensworks: will that be the final URL or the note?
16:35:22 <pchampin> ivan: yes
16:35:36 <azaroth> PROPOSAL: Merge the NS PR after updating the links, and ivan will publish to /ns/ when the note is published
16:35:40 <azaroth> +1
16:35:45 <pchampin> +1
16:35:47 <gkellogg> +1
16:35:51 <dlehn> +1
16:35:58 <ivan> +1
16:36:01 <rubensworks> +1
16:36:02 <azaroth> ACTION: ivan to republish the NS document when streaming note is published
16:36:08 <azaroth> RESOLVED: Merge the NS PR after updating the links, and ivan will publish to /ns/ when the note is published
16:36:46 <pchampin> ivan: another administrative info
16:36:53 <azaroth> SUBTOPIC: Other Admin Info
16:37:11 <pchampin> ... I will submit the JSON-LD maintainance charter at the same time as the PR,
16:37:16 <pchampin> ... that can go through the same AC vote
16:38:28 <azaroth> TOPIC: Base Context Discussion
16:38:36 <azaroth> https://github.com/w3c/json-ld-rc/issues/
16:39:39 <pchampin> azaroth: two weeks ago we discussed whether we should mark the prefixes with `"@prefix": true`
16:39:45 <azaroth> https://github.com/w3c/json-ld-rc/issues/3
16:39:58 <pchampin> ... this would be more explicit, but ivan and gkellogg noticed that it makes the document more complicated
16:40:10 <pchampin> ... and is not strictly required (this is the default)
16:40:19 <azaroth> PROPOSAL: Close rc #3 won't fix, as the `@prefix: true` is the default anyway
16:40:21 <azaroth> +1
16:40:27 <gkellogg> +1
16:40:45 <rubensworks> +1
16:40:51 <pchampin> +1
16:40:57 <ivan> +1
16:40:57 <azaroth> RESOLVED: Close rc #3 won't fix, as the `@prefix: true` is the default anyway
16:41:11 <azaroth> https://github.com/w3c/json-ld-rc/issues/4
16:41:40 <pchampin> azaroth: this issue proposes to split the context into two different ones:
16:41:53 <gkellogg> https://github.com/w3c/json-ld-rc/tree/split_contexts/contexts
16:41:55 <pchampin> ... one defining only keyword aliases
16:42:11 <pchampin> ... the other one defining common prefixes
16:42:48 <pchampin> ... This came from a concern from bigbluehat and ivan that keyword aliases are not always relevant.
16:43:07 <pchampin> ivan: I think that's over-complicating things.
16:43:22 <pchampin> ... if the recommended context does not work for you, then don't use it.
16:44:26 <pchampin> gkellogg: the idea of separating prefixes was to avoid the burden of maintaining them,
16:44:35 <pchampin> ... when things get out of fashion for example.
16:44:53 <pchampin> ... But we still have the burden if we publish them somewhere else.
16:45:14 <azaroth> PROPOSAL: Close #4 wontfix, as it adds complications for minimal value. context editors that know what they're doing, know how to fix any conflicts with the base context, and those that don't won't know they have the problem
16:45:16 <azaroth> +1
16:45:19 <ivan> +1
16:45:20 <rubensworks> +1
16:45:24 <pchampin> +1
16:45:32 <azaroth> RESOLVED: Close #4 wontfix, as it adds complications for minimal value. context editors that know what they're doing, know how to fix any conflicts with the base context, and those that don't won't know they have the problem
16:45:32 <gkellogg> +12
16:45:33 <dlehn> +1
16:45:40 <gkellogg> -11
16:46:03 <azaroth> https://github.com/w3c/json-ld-rc/issues/6
16:46:44 <pchampin> ivan: I feel that we must keep the prefixes to the strict minimal;
16:47:05 <pchampin> ... the comparison with RDFa is wrong, because RDFa does not have a mechanism of @context
16:47:53 <pchampin> s/@context/`@context`/
16:48:15 <pchampin> ... JSON-LD users can use ad-hoc contexts for specific use;
16:48:43 <pchampin> ... we only need to put in this context those that we think every body need.
16:49:05 <pchampin> ... One question was raised about the mess with both Dublin Core namespaces,
16:49:16 <gkellogg> q+
16:49:21 <azaroth> ack gkellogg
16:49:22 <pchampin> ... what prefixes should be put for them.
16:49:55 <pchampin> gkellogg: I think we should leave "dc" out;
16:50:17 <azaroth> q+
16:50:18 <gkellogg> Don’t publish “dc” as a prefix
16:50:25 <pchampin> ... in the RDFa, it is mapped to dcterms, although many people use it for dc11
16:50:25 <azaroth> ack azaroth
16:51:02 <pchampin> azaroth: I would have gone the other way: "dc" for dc elements, and "dct" for dc terms
16:51:16 <azaroth> dc11 and dcterms
16:51:18 <azaroth> ?
16:51:19 <pchampin> gkellogg: this would introduce an incompatibility with RDFa
16:52:30 <azaroth> https://www.w3.org/TR/json-ld11/#conformance
16:52:38 <azaroth> has dc11 and dcterms
16:52:47 <pchampin> gkellogg: I think at some points even we were inconsistent in the spec, in our use of "dc:"
16:53:30 <pchampin> azaroth: in the conformance section, we used "dc11" and "dcterms"
16:53:37 <azaroth> PROPOSAL: Use the dc11 and dcterms prefixes as per the syntax doc's prefixes
16:53:39 <pchampin> ivan: that's a killer argument :)
16:53:43 <gkellogg> +1
16:53:45 <rubensworks> +1
16:53:46 <azaroth> +1
16:53:49 <pchampin> +1
16:53:53 <azaroth> RESOLVED: Use the dc11 and dcterms prefixes as per the syntax doc's prefixes
16:53:58 <ivan> +1
16:54:29 <pchampin> ivan: the file is in the repository; do we want to use the github.io directly?
16:54:37 <pchampin> ... or do we went to store it somewhere else?
16:54:50 <pchampin> ... Do we want a W3C URL?
16:55:06 <pchampin> azaroth: I think we should have one.
16:55:44 <pchampin> gkellogg: it would be under w3.org/ns/json-ld/
16:56:15 <azaroth> FWIW, annotation context:  https://www.w3.org/ns/anno
16:56:55 <pchampin> ... e.g. w3.org/ns/json-ld/base-context
16:57:22 <pchampin> ivan: currently the json-ld files under ns are not in a directory,
16:57:30 <pchampin> ... so I would prefer not to do that.
16:57:31 <azaroth> ns/json-ld11-base-context ?
16:58:10 <pchampin> gkellogg: versioning namespace documents has proven to be a bad idea.
16:58:27 <pchampin> azaroth: yes but this is not *really* a namespace document
16:58:59 <pchampin> ... My fear is that if we add a new keyword in 1.2, with an alias in the base context,
16:59:10 <pchampin> ... that would blow up for 1.1 processors.
16:59:33 <ivan> sometthing /ns/json-ld-base
17:00:36 <pchampin> ivan: we don't have versions for the core files
17:01:11 <azaroth> PROPOSAL: Use /ns/json-ld-base as the name for the base context
17:01:16 <ivan> +1
17:01:16 <azaroth> +1
17:01:17 <pchampin> +1
17:01:19 <rubensworks> +1
17:01:19 <gkellogg> + 0.5
17:01:25 <azaroth> RESOLVED: Use /ns/json-ld-base as the name for the base context
17:01:36 <azaroth> ACTION: ivan to PR to the context for new version
17:02:30 <azaroth> TOPIC: Adjourn
17:03:01 <ivan> zakim, end meeting
17:03:01 <Zakim> As of this point the attendees have been azaroth, pchampin, ivan, rubensworks, gkellogg, dlehn,  0.5
17:03:03 <Zakim> RRSAgent, please draft minutes
17:03:03 <RRSAgent> I have made the request to generate https://www.w3.org/2020/04/17-json-ld-minutes.html Zakim
17:03:06 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
17:03:10 <Zakim> Zakim has left #json-ld
17:09:10 <ivan> rrsagent, bye
17:09:10 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2020/04/17-json-ld-actions.rdf :
17:09:10 <RRSAgent> ACTION: ivan to republish the NS document when streaming note is published [1]
17:09:10 <RRSAgent>   recorded in https://www.w3.org/2020/04/17-json-ld-irc#T16-36-02
17:09:10 <RRSAgent> ACTION: ivan to PR to the context for new version [2]
17:09:10 <RRSAgent>   recorded in https://www.w3.org/2020/04/17-json-ld-irc#T17-01-36