15:03:32 <RRSAgent> RRSAgent has joined #json-ld
15:03:32 <RRSAgent> logging to https://www.w3.org/2019/04/05-json-ld-irc
15:03:33 <ivan> rrsagent, set log public
15:03:33 <ivan> Meeting: JSON-LD Working Group Telco
15:03:33 <ivan> Chair: azaroth
15:03:33 <ivan> Date: 2019-04-05
15:03:33 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0013.html
15:03:33 <ivan> ivan has changed the topic to: Meeting Agenda 2019-04-05: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Apr/0013.html
15:27:07 <azaroth> azaroth has joined #json-ld
15:43:14 <azaroth> regrets+ David_Newbury
15:43:21 <azaroth> regrets+ Gregg_Kellogg
15:43:32 <azaroth> regrets+ Ruben_Taelman
15:49:05 <azaroth> regrets+ Dave_Longley
15:49:55 <bigbluehat> present+ Benjamin_Young
15:51:07 <ajs6f> ajs6f has joined #json-ld
15:51:21 <azaroth> present+ Rob_Sanderson
15:55:07 <pchampin> pchampin has joined #json-ld
16:00:50 <simonstey> simonstey has joined #json-ld
16:02:23 <simonstey> simonstey has joined #json-ld
16:03:31 <ivan> present+
16:03:37 <pchampin> present+
16:03:41 <ajs6f> present+
16:04:15 <jeff_mixter> jeff_mixter has joined #json-ld
16:04:26 <azaroth> Chair: bigbluehat
16:04:30 <bigbluehat> Topic: Select scribe
16:04:51 <bigbluehat> Zakim, pick a victim
16:04:51 <Zakim> Not knowing who is chairing or who scribed recently, I propose Benjamin_Young
16:05:14 <bigbluehat> Zakim, pick a victim
16:05:14 <Zakim> Not knowing who is chairing or who scribed recently, I propose ajs6f
16:05:24 <azaroth> scribenick: azaroth
16:05:33 <azaroth> TOPIC: Approve minutes
16:05:34 <bigbluehat> Topic: Approve minutes of last call
16:05:37 <bigbluehat> https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-29-json-ld
16:05:49 <azaroth> PROPOSAL: Approve minutes of last call
16:05:51 <azaroth> +1
16:05:58 <simonstey> +1
16:06:06 <bigbluehat> +1
16:06:08 <jeff_mixter> +0
16:06:12 <pchampin> +1
16:06:33 <azaroth> RESOLVED: Approve minutes of last call
16:06:46 <azaroth> ACTION: @id to pick a better github handle
16:07:10 <bigbluehat> Topic: Announcements/Reminders
16:07:19 <azaroth> bigbluehat: Any announcements?
16:07:34 <azaroth> ... Good on F2F until TPAC. Just passed feature freeze deadline.
16:07:41 <hsolbrig> hsolbrig has joined #json-ld
16:07:43 <azaroth> ... Anything else, other than issues?
16:07:49 <hsolbrig> present+ hsolbrig
16:07:57 <bigbluehat> Topic: Best Practices / Primer / Cookbook
16:08:04 <bigbluehat> https://github.com/w3c/json-ld-wg/issues/17
16:08:46 <azaroth> bigbluehat: We have a stub primer that Ivan has made
16:08:50 <bigbluehat> https://w3c.github.io/json-ld-bp/
16:08:54 <ajs6f> +1https://github.com/w3c/json-ld-bp
16:09:01 <azaroth> ... and so I think we can close the meta issue
16:09:39 <bigbluehat> PROPOSAL: close #17 as started with other issues/work to follow
16:09:40 <azaroth> pchampin: It says community group?
16:09:51 <ivan> +1
16:09:51 <azaroth> ivan: Yes, that will be changed ASAP ... it's imported from the CG
16:09:52 <bigbluehat> +1
16:09:52 <pchampin> +1
16:09:53 <azaroth> _1
16:09:54 <hsolbrig> +1
16:09:54 <azaroth> +1
16:09:56 <simonstey> +1
16:09:57 <azaroth> s/_1//
16:09:57 <jeff_mixter> +1
16:10:04 <ajs6f> +1
16:10:09 <azaroth> bigbluehat: Should I close by hand?
16:10:20 <bigbluehat> RESOLVED: close #17 as started with other issues/work to follow
16:10:21 <azaroth> ivan: I usually put in comments
16:10:37 <bigbluehat> Topic: Issues
16:10:46 <dlehn> present+
16:10:51 <simonstey> present+
16:10:52 <azaroth> bigbluehat: Diving into the actual issues...
16:10:53 <jeff_mixter> present+
16:12:28 <bigbluehat> Topic: Recommended base context
16:12:35 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/59
16:12:47 <simonstey> bigbluehat: feature freeze was not regarding the primer document
16:12:49 <azaroth> azaroth: Issues for today about the primer document, so not subject to feature freeze
16:13:11 <azaroth> bigbluehat: Idea is to have a default context, similar to RDFa. Discussion about the risks and concerns, mostly about backwards compatibility
16:13:32 <ivan> q+
16:13:33 <azaroth> ... should it be a best practice / prevailing pattern. Make these available, as a lot of content is in these namespaces
16:13:48 <azaroth> ... dlongley raised that keys not curies are a good pattern
16:13:59 <bigbluehat> ack ivan
16:14:00 <azaroth> ... repeating common prefixes makes sense.
16:14:22 <azaroth> ivan: need to be a little bit careful with rdfa comparison.  It had the extra difficulty of not having an equivalent of importing a file with prefixes
16:14:32 <azaroth> ... so supposed to put everything in your document, which becomes a pain
16:14:45 <azaroth> ... so default for RDFa is important.  We don't have that difficulty
16:15:12 <azaroth> ... Can import context file, so the load is not the same.  Building in an automatic mechanism for these prefixes may not be a good idea
16:15:27 <azaroth> ... in the RDFa case, the consequence is that every implementation has to regularly update their defaults
16:15:57 <azaroth> ... when the defaults are changed. So writing the lines, I forgot to add something into my implementation, so updated it this morning. A pain on implementers and uses of those implementations
16:16:30 <azaroth> ... I think that having an automatic mechanism is not a good idea, but having a context in a well known place with a number of useful things, and is maintained by the community via GH, is a good idea
16:16:33 <azaroth> +1 to Ivan
16:16:35 <pchampin> +1 to *not* make it automatic
16:16:43 <azaroth> ... what this context should contain is a separate discussion
16:17:03 <pchampin> q+
16:17:12 <azaroth> ... not really agreeing with dlongley. The number of vocabs in RDFA is quite extensive, so flattened would become a problem, and there would be a clash
16:17:16 <bigbluehat> q+ to clarify dlongley's point about "bare"/non-CURIE'd terms
16:17:33 <azaroth> ... in favor of reproducing the rdfa stuff. If people don't like CURIEs they don't have to use it
16:17:36 <bigbluehat> ack pchampin
16:18:19 <azaroth> pchampin: totally agree with ivan. dlongley's concern is orthogonal to this.  This context is useful for more RDFy, and don't mind CURIEs. Also to context designers, for a base to import
16:18:30 <azaroth> ... to not worry about the prefixes, in order to define the flat namespace
16:18:35 <azaroth> +1 to pchampin!
16:18:41 <bigbluehat> +1 to having a handy context for common namespaces
16:18:44 <bigbluehat> ack bigbluehat
16:18:44 <Zakim> bigbluehat, you wanted to clarify dlongley's point about "bare"/non-CURIE'd terms
16:19:14 <azaroth> bigbluehat: I don't think dlongley was suggesting we discourage curies, but that the prevailing pattern is that communities publish their own context, with imports
16:19:38 <azaroth> ... at the data document level, discouraging curies is fine... but as pchampin pointed out it looks normal for some communities
16:19:54 <azaroth> ... so having a context with common mappings and making it available to import would be nice
16:20:07 <azaroth> ... process wise we need to decide how to maintain it
16:20:09 <ivan> q+
16:20:14 <azaroth> ... could be in the primer, but not extractable
16:20:14 <bigbluehat> ack ivan
16:20:37 <azaroth> ivan: I think you are right -- copy/paste is not the right solution.  We can set up a mini repository that contains that stuff and the readme
16:20:38 <azaroth> q+
16:20:49 <azaroth> ... need to agree on a URL to be put somewhere, w3/ns could work
16:20:55 <azaroth> ... would then redirect to the GH document
16:21:13 <azaroth> ... for a start that would be okay, then need to see once the WG is done, then the CG could take over
16:21:23 <azaroth> ... and would have the right to decide on PRs and so on
16:21:37 <azaroth> ... whether it's on json-ld or not ... it doesn't really matter
16:21:59 <azaroth> bigbluehat: question of URL simplicity, but related to the process
16:22:23 <azaroth> ivan: No problem with it, but i don't know who maintains the domain and if it will be still around
16:22:31 <azaroth> ... in W3C URL space it's not our problem
16:22:32 <bigbluehat> q+ to note some prior art in the ActivityStreams space
16:22:36 <bigbluehat> ack azaroth
16:22:51 <pchampin> scribeassist: pchampin
16:22:51 <bigbluehat> scribenick: pchampin
16:23:16 <pchampin> azaroth: I agree with Ivan that a W3C url is less worry about maintaining domain names.
16:24:04 <bigbluehat> ack bigbluehat
16:24:04 <Zakim> bigbluehat, you wanted to note some prior art in the ActivityStreams space
16:24:07 <azaroth> scribenick: azaroth
16:24:09 <pchampin> ... There is prior art in maintaining a namespace at W3C. We can do the same.
16:24:27 <azaroth> bigbluehat: The activity streams space is now maintained by the CG. They have additive process for getting stuff into it
16:24:32 <azaroth> ... some more prior art there
16:24:49 <ivan> q+
16:24:54 <azaroth> ... The CORS issues also highlights the need for stability
16:25:00 <bigbluehat> PROPOSAL: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward "bare" (non-CURIE'd) terms
16:25:10 <simonstey> +1
16:25:14 <jeff_mixter> +1
16:25:18 <hsolbrig> +1
16:25:19 <dlehn> with common resources need to consider caching issues so as to not overload servers
16:25:21 <ajs6f> +1
16:25:30 <pchampin> +1
16:25:31 <azaroth> +1
16:25:32 <bigbluehat> +1
16:25:32 <ivan> +1
16:25:41 <bigbluehat> RESOLVED: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward "bare" (non-CURIE'd) terms
16:25:44 <bigbluehat> ack ivan
16:26:16 <azaroth> ivan: I would propose to create a separate repository that will have a readme and a json context file, and redirect from a /ns/ name
16:26:37 <azaroth> ... as a first approximation, for something to talk about, there is already a context file that was set up some time ago that mimics the RDFA defaults
16:26:49 <azaroth> ... I would take that and put it up, and we can discuss what should be in it
16:26:55 <bigbluehat> q+ to ask about just operationalizing the RDFa one--strength in numbers
16:26:59 <bigbluehat> ack bigbluehat
16:26:59 <Zakim> bigbluehat, you wanted to ask about just operationalizing the RDFa one--strength in numbers
16:27:34 <azaroth> bigbluehat: What if we were to make this a shared effort to build off the RDFA one, to make it more operationalized
16:27:42 <ivan> q+
16:27:47 <bigbluehat> ack ivan
16:27:47 <azaroth> ... it exists, we could make it less brittle
16:28:06 <azaroth> ivan: do you mean we do this together with the RDFA file?
16:28:40 <azaroth> bigbluehat: yes, create the repo and process and make that happen using the existing RDFA file. New process would then maintain it, and strengthen the one that's there
16:28:44 <azaroth> q+
16:28:55 <bigbluehat> ack azaroth
16:28:56 <azaroth> ... good to not have two that are 99% the same
16:29:04 <bigbluehat> scribenick: bigbluehat
16:29:21 <bigbluehat> azaroth: it seems like there will be things we'd like to do in a context, which won't be possible in RDFa
16:29:29 <bigbluehat> ...so they'd be related, but different
16:29:39 <bigbluehat> ...like we might want "label" as a bare term in the default context
16:29:52 <bigbluehat> ...or `@id` to `id`, and `@none` to `none`, etc
16:29:58 <bigbluehat> ...those make no sense in RDFa
16:30:12 <azaroth> scribenick: azaroth
16:30:13 <bigbluehat> ...so, like where this is headed, but the specific documents would need to be separate
16:30:40 <azaroth> ivan: Agree, to add to it, the way the RDFA doc was created i describe in the issue, but worth looking at the document critically and see if it's still relevant
16:30:45 <azaroth> ... Another aspect to it
16:30:52 <bigbluehat> q+
16:30:58 <azaroth> ... merging is risky, and may create problems
16:31:11 <bigbluehat> ack bigbluehat
16:31:11 <azaroth> ... keep them separate, and w3c's problem to maintain the RDFA doc
16:31:29 <azaroth> bigbluehat: Good points about different needs. Want the prefixes to match, and to stay matching.
16:31:32 <ivan> q+
16:31:51 <azaroth> ... We use them together, so lean on the RDFA doc quite a bit
16:32:11 <azaroth> ... Should be as stable and maintained as possible
16:32:20 <bigbluehat> ack ivan
16:33:15 <pchampin> I spotted a discrepency btw schema.org and RDFa with dublin core
16:33:21 <azaroth> ivan: Prefixes should be the same, as much as possible.  Will need to check, eg that schema.org does the same thing, with a smaller set of prefixes. The schema.org context file has foaf, and there should be compatibility there. If there's a clash, we shuold be in favor of schema?
16:33:40 <azaroth> ... but I'll set up the initial thing. We can come back and look at it
16:34:15 <bigbluehat> PROPOSAL: have ivan setup initial repository for publishing a "common" context featuring prefixes and "bare" terms for use in the Best Practices document (and beyond)
16:34:24 <ivan> +1
16:34:26 <azaroth> +1
16:34:26 <jeff_mixter> +1
16:34:28 <pchampin> +1
16:34:28 <bigbluehat> +1
16:34:28 <ajs6f> +1
16:34:29 <simonstey> +1
16:34:41 <hsolbrig> +1
16:34:43 <bigbluehat> RESOLVED: have ivan setup initial repository for publishing a "common" context featuring prefixes and "bare" terms for use in the Best Practices document (and beyond)
16:34:46 <azaroth> ivan: in the mean time ... bikeshed ... but what URL for /ns ?
16:35:08 <azaroth> bigbluehat: Let's do that on the GH repo :)
16:35:10 <bigbluehat> Subtopic: Multilingual Values
16:35:16 <bigbluehat> https://github.com/w3c/json-ld-syntax/issues/105
16:35:24 <azaroth> bigbluehat: Another easy one ;)
16:35:53 <timCole> timCole has joined #json-ld
16:36:00 <azaroth> ... this one is about how JSON-LD currently works, and our past decisions to use HTML for multi lingual values (strings with multiple languages)
16:36:09 <azaroth> ... so use straight up HTML, which is not ideal
16:36:27 <azaroth> ... Looking at text level semantics HTML, but that's for the future.
16:36:48 <azaroth> ... so what do we need to propose in the primer to close the issue?
16:37:10 <azaroth> ... related - there's no way to do multi-language language maps
16:37:34 <azaroth> q+
16:37:40 <bigbluehat> ack azaroth
16:37:40 <dlehn> i wasn't sure how to vote on those proposals.  will need to consider proper versioning and caching to make shared resources work.  already an issue with similar things at w3id.org.  but perhaps making a common context is a good experiment that will force related best practices to be developed.
16:37:45 <bigbluehat> scribenick: bigbluehat
16:38:04 <bigbluehat> azaroth: it seems we should split this into a primer issue
16:38:09 <bigbluehat> ...eg how do you use language tags
16:38:15 <bigbluehat> ...and what do you do with multiple languages
16:38:39 <bigbluehat> ...and then have a syntax issue around gkellogg's issue for the normative specs
16:39:03 <ivan> q+
16:39:13 <azaroth> scribenick: azaroth
16:39:14 <bigbluehat> ...about, is it an error to have English and Japanese in a string that is stated to be only one of those
16:39:16 <azaroth> ack ivan
16:39:54 <bigbluehat> q+
16:40:04 <azaroth> ivan: What was put there by gregg sounds like a solution, but a bit misleading. The use of language tags gives the wrong impression -- should be just indexes
16:40:08 <azaroth> q+ to explain :)
16:40:13 <bigbluehat> q-
16:40:18 <azaroth> ivan: Language tags are defined by ISO
16:40:20 <bigbluehat> ack azaroth
16:40:20 <Zakim> azaroth, you wanted to explain :)
16:40:24 <bigbluehat> scribenick: bigbluehat
16:40:38 <azaroth> "<span lang=\"en\">Ninja in japanese: <span lang=\"jp\">忍者</span>"@ja
16:40:41 <bigbluehat> azaroth: I agree ivan. to your question, the RDF would look like that
16:41:00 <azaroth> "<span lang=\"en\">Ninja in japanese: <span lang=\"jp\">忍者</span>"@ja^^rdf:langString
16:41:16 <bigbluehat> ...this has been my issue for 5+ years
16:41:22 <bigbluehat> ...language tags must be langString
16:41:31 <azaroth> ivan: an RDF issue that is not ours to solve
16:41:36 <bigbluehat> scribenick: azaroth
16:41:44 <bigbluehat> q?
16:41:49 <bigbluehat> q+
16:41:49 <pchampin> q+
16:41:52 <azaroth> ... Lots of nice discussions in dbooth's repo, but it should happen in RDF not here
16:41:56 <azaroth> ... same as missing base direction
16:42:20 <bigbluehat> ack bigbluehat
16:42:21 <azaroth> ... we can only set a single language. And this is the same as base direction, shouldn't touch it
16:42:24 <azaroth> +1 to ivan
16:43:00 <azaroth> bigbluehat: RDF is woefully broken in this way, but Gregg's proposal of HTML +  language map would be desirable by JSON developers
16:43:18 <azaroth> https://iiif.io/api/presentation/3.0/#44-html-markup-in-property-values
16:43:20 <azaroth> q+
16:43:49 <azaroth> ... If built to contain HTML, they're not going to take it into RDF, so a little misuse has advantages
16:43:50 <ivan> q=
16:43:53 <ivan> q+
16:44:11 <bigbluehat> ack pchampin
16:44:15 <azaroth> ... our audience is interested in JSON, with a side plate of a graph
16:44:37 <bigbluehat> ack azaroth
16:44:40 <bigbluehat> q+ pchampin
16:45:03 <bigbluehat> scribenick: bigbluehat
16:45:14 <bigbluehat> azaroth: I put this link in earlier https://iiif.io/api/presentation/3.0/#44-html-markup-in-property-values
16:45:22 <bigbluehat> ...it uses exactly what gkellogg describes
16:45:35 <bigbluehat> ...it is common and exactly what people want to be able to do
16:45:39 <bigbluehat> ack ivan
16:45:40 <azaroth> scribenick: azaroth
16:46:10 <azaroth> ivan: The funny thing is what you wrote is legal but ugly RDF -- a microsyntax for a string, which is outside of RDF or JSON-LD
16:46:17 <azaroth> ... it happens to be a subsyntax of HTML
16:46:30 <azaroth> ... don't need anything in the syntax document to do this, its a private agreement between parties
16:46:34 <azaroth> +1 to Ivan
16:46:41 <azaroth> ... this is probably the only thing we can do
16:46:46 <azaroth> ... so no issue in the syntax document
16:47:00 <bigbluehat> ack pchampin
16:47:01 <azaroth> ... it's an ugly but best practice given the current technologies
16:47:52 <azaroth> pchampin: Going to propose a crazy idea, in the line of what Ivan said. We don't need to change RDF, we could define a custom datatype. langString is syntactic sugar for a standard datatype for a more ugly microsyntax of the language inside the value
16:48:12 <ivan> q+
16:48:34 <azaroth> ... we could define a more complex but similar datatype. That's the crazy idea :) We could instrument it in RDF, with another container type, so that what gregg proposed would generate the appropriate structure
16:48:40 <azaroth> ... but it's quite some work
16:48:40 <bigbluehat> ack ivan
16:49:18 <azaroth> ivan: technically ... yes ... and now I put on the W3C hat, it's outside of our charter.  This would be a RDF datatype.
16:49:22 <bigbluehat> q+
16:49:24 <azaroth> pchampin: What about JSON data type?
16:49:55 <azaroth> ivan: JSON is closer to our charter. But language isn't.
16:50:17 <azaroth> ... it would be a lot of work ... the flood gates would be open. Ruby, direction, etc.
16:50:18 <bigbluehat> ack bigbluehat
16:50:41 <bigbluehat> https://w3c.github.io/string-meta/
16:51:08 <azaroth> bigbluehat: worth pausing on the JSON data type. I hear the concerns ... is there a way around them? This string-meta document from i18n suggests JSON-LD as a solution for multi-language use
16:51:15 <azaroth> ... feel that there's an opportunity here
16:51:32 <ivan> q+
16:51:37 <azaroth> ... And if we miss it, there'll be a lot of terrible looking JSON-LD
16:52:00 <azaroth> ... I see that it evokes process spectres, but it comes up a lot
16:52:26 <azaroth> ... The genie won't go back into the bottle. So any hope of this?
16:52:27 <bigbluehat> ack ivan
16:52:55 <azaroth> ivan: Don't remember the issue, but got into a long discussion with the editors. The examples are mostly wrong.
16:52:56 <bigbluehat> https://github.com/w3c/string-meta/issues/27
16:53:17 <bigbluehat> also https://github.com/w3c/string-meta/issues/13
16:53:23 <azaroth> ... I understand the problem. Would love for the problem to be solved, but outside our influence
16:53:30 <bigbluehat> oh...and https://github.com/w3c/string-meta/issues/23
16:53:43 <azaroth> ... I don't see any other proper way, other than having it done at the RDF level.
16:53:44 <bigbluehat> ...and another https://github.com/w3c/string-meta/issues/11
16:53:45 <azaroth> q+ to agree
16:53:48 <bigbluehat> q+
16:53:49 <bigbluehat> ack azaroth
16:53:49 <Zakim> azaroth, you wanted to agree
16:54:37 <bigbluehat> q-
16:55:28 <azaroth> azaroth: The bigger risk is to build on shifting sands and have RDF come up with a different syntax that's incompatible with whatever we come up with
16:55:46 <azaroth> ... should instead use it as a way to highlight the need, and potentially a micro-chartered group to solve it for RDF
16:56:23 <azaroth> bigbluehat: Not ready to recharter, or make a new datatype. Rob proposes to kick it to another group and then an update to JSON-LD. Not a solution, but don't want to lose the actions
16:56:40 <azaroth> ... to close the issue we should state what can be done
16:57:00 <azaroth> ... but need to be clear as to what /should/ be done that's not confusing
16:59:36 <jeff_mixter> +1 to that
16:59:40 <bigbluehat> PROPOSAL: highlight the need for work is ongoing, but it should present what can be done today via language/data maps and/or using HTML (or other) micro-syntax for expressing multiple language
16:59:46 <azaroth> +1
16:59:50 <bigbluehat> +1
16:59:52 <jeff_mixter> +1
16:59:55 <ivan> +1
16:59:55 <timCole> +1
16:59:57 <pchampin> +1
17:00:03 <simonstey> +1
17:00:05 <ivan> present+ timCole
17:00:07 <ajs6f> +1
17:00:11 <bigbluehat> RESOLVED: highlight the need for work is ongoing, but it should present what can be done today via language/data maps and/or using HTML (or other) micro-syntax for expressing multiple language
17:00:49 <azaroth> ivan: procedural question - if we close the issue, then I think we will lose it for the bp doc. For the time being we don't have an editor for the document. So don't want it lost.
17:01:08 <azaroth> ... should be raised in the BP repo
17:01:13 <azaroth> +1
17:01:17 <bigbluehat> +1
17:01:20 <azaroth> ... should go through the issues to make sure we don't lose them
17:01:32 <azaroth> bigbluehat: Agreed -- open editorial issues on BP?
17:01:47 <azaroth> ... keep these initial discussion in the syntax doc, to not have the comments scattered
17:01:54 <azaroth> ivan: Wouldn't close this one
17:02:00 <simonstey> https://github.com/w3c/json-ld-bp/issues
17:02:06 <azaroth> bigbluehat: not until there's another issue to write it up
17:02:19 <azaroth> ivan: editor will write it up as they see best
17:02:30 <azaroth> bigbluehat: And it's the top of the hour
17:02:36 <azaroth> ... thanks for all the input
17:02:47 <azaroth> TOPIC: Adjourn
17:02:54 <ivan> rrsagent, draft minutes
17:02:55 <RRSAgent> I have made the request to generate https://www.w3.org/2019/04/05-json-ld-minutes.html ivan