16:37:16 <RRSAgent> RRSAgent has joined #json-ld
16:37:16 <RRSAgent> logging to https://www.w3.org/2019/12/20-json-ld-irc
16:37:17 <ivan> rrsagent, set log public
16:37:17 <ivan> Meeting: JSON-LD Working Group Telco
16:37:17 <ivan> Date: 2019-12-20
16:37:17 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Dec/0018.html
16:37:17 <ivan> ivan has changed the topic to: Meeting Agenda 2019-12-20: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Dec/0018.html
16:37:18 <ivan> Chair: azaroth
16:37:18 <ivan> Regrets+ dlongley
16:50:22 <azaroth> azaroth has joined #json-ld
16:52:04 <rubensworks> rubensworks has joined #json-ld
16:54:00 <azaroth> present+
16:56:34 <gkellogg> present+
16:58:31 <ivan> present+
16:58:32 <pchampin> present+
17:00:34 <rubensworks> present+
17:00:48 <timCole> timCole has joined #json-ld
17:00:55 <ivan> regrets+ bigbluehat
17:01:07 <azaroth> TOPIC: Scribe selection
17:01:26 <azaroth> scribenick: rubensworks
17:01:32 <azaroth> TOPIC: Approve minutes of last call
17:01:49 <azaroth> PROPOSAL: Approve minutes of last call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-13-json-ld
17:01:50 <azaroth> +1
17:01:51 <gkellogg> +1
17:02:01 <azaroth> RESOLVED: Approve minutes of last call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-13-json-ld
17:02:02 <rubensworks> +0
17:02:02 <ivan> +1
17:02:08 <pchampin> +1
17:02:10 <timCole> present+
17:02:11 <azaroth> TOPIC: Announcements?
17:02:12 <jeff_mixter> jeff_mixter has joined #json-ld
17:02:32 <ivan> present+ jeff_mixter
17:02:40 <azaroth> TOPIC: General Issues
17:02:56 <azaroth> SUBTOPIC: xsd:double vs xsd:decimal
17:03:05 <azaroth>  https://github.com/w3c/json-ld-syntax/issues/318
17:03:39 <rubensworks> gkellogg: The JSON data model uses IEEE floats, they can not reliably encode doubles.
17:03:46 <ajs6f> present+
17:04:17 <azaroth> PROPOSAL: Close syntax#318 as solved
17:04:19 <azaroth> +1
17:04:22 <rubensworks> ... The spec has been updated to add a note. This should be sufficient to close the issue.
17:04:24 <ivan> +1
17:04:24 <rubensworks> +1
17:04:24 <gkellogg> +1
17:04:24 <pchampin> +1
17:04:46 <azaroth> RESOLVED: Close syntax#318 as solved
17:04:46 <jeff_mixter> +1
17:04:46 <timCole> +1
17:05:07 <azaroth> SUBTOPIC: omit graph example
17:05:14 <azaroth> https://github.com/w3c/json-ld-framing/issues/88
17:05:46 <rubensworks> gkellogg: The issuer pointed out that we are using double negation, as omitGraph true is the default.
17:06:17 <rubensworks> ... It made more sense in 1.0. But now the default value is reversed.
17:06:36 <rubensworks> ... We could rename it in 1.1.
17:07:00 <rubensworks> azaroth: We probably don't want to rename it to `includeGraph`?
17:07:36 <azaroth> PROPOSAL: Update examples 4 & 5 in Framing to be instructive as well as correct
17:07:36 <rubensworks> ... We should update the examples in framing to be more instructive.
17:07:49 <rubensworks> ... This is just editorial.
17:08:00 <azaroth> PROPOSAL: Update examples 4 & 5 in Framing to be instructive as well as correct and close when updated
17:08:04 <ivan> +1
17:08:04 <azaroth> +1
17:08:05 <timCole> +1
17:08:05 <rubensworks> +1
17:08:05 <jeff_mixter> +1
17:08:09 <ajs6f> +1
17:08:13 <pchampin> +1
17:08:13 <gkellogg> +1
17:08:21 <azaroth> RESOLVED: Update examples 4 & 5 in Framing to be instructive as well as correct and close when updated
17:08:40 <azaroth> TOPIC:  API Algorithm Issues
17:08:58 <azaroth> SUBTOPIC: Processing `@none`
17:09:07 <azaroth> https://github.com/w3c/json-ld-api/issues/259
17:09:38 <rubensworks> azaroth: Now a bunch of issues with the algorithms in the API doc, which come from my engineer who is implementing framing from scratch in perl.
17:10:12 <rubensworks> gkellogg: They are small things, but important things to correct nevertheless.
17:10:26 <rubensworks> ... I don't think any of them fundamentally change the output.
17:10:34 <rubensworks> ivan: That's what CR is for.
17:10:54 <rubensworks> azaroth: This issue is how `@none` is handled.
17:11:24 <rubensworks> gkellogg: pchampin has a PR for this.
17:12:13 <rubensworks> pchampin: Yes, I did a PR for a few of the issues, as they are quite straightforward.
17:12:50 <rubensworks> gkellogg: It would be good to mention the issue in the PR, so we have a link between them.
17:13:11 <azaroth> PROPOSAL: Agree `@none` is missing in 13.4, accept pchampin's PR #268, and close
17:13:17 <rubensworks> +1
17:13:18 <pchampin> +1
17:13:18 <azaroth> +1
17:13:20 <ajs6f> +1
17:13:23 <timCole> +1
17:13:25 <gkellogg> +1
17:13:27 <jeff_mixter> +1
17:13:35 <ivan> +1
17:13:35 <azaroth> RESOLVED: Agree `@none` is missing in 13.4, accept pchampin's PR #268, and close
17:13:45 <azaroth> SUBTOPIC: `@direction` etc missing in step 28
17:13:52 <azaroth> https://github.com/w3c/json-ld-api/issues/261
17:13:58 <rubensworks> azaroth: This issue is more extensive.
17:14:24 <rubensworks> ... The Create Term Definition lists a few keywords, but some are missing.
17:14:35 <rubensworks> ... pchampin also has a PR for this.
17:14:45 <azaroth> PROPOSAL: Agree missing keywords in step 28, accept pchampin's PR #267, and close
17:14:48 <gkellogg> +1
17:14:52 <azaroth> +1
17:14:53 <rubensworks> +1
17:14:53 <timCole> +1
17:14:55 <jeff_mixter> +1
17:15:03 <pchampin> +1
17:15:38 <azaroth> SUBTOPIC: Nest handling at wrong level of indent
17:15:48 <azaroth> RESOLVED: Agree missing keywords in step 28, accept pchampin's PR #267, and close
17:15:52 <azaroth> https://github.com/w3c/json-ld-api/issues/262
17:17:11 <rubensworks> azaroth: There were a couple of expansion issues that would cause it to blow up. The problem is that nested entries in the context, would recursively require processing of that node.
17:17:35 <rubensworks> ... We figured out that it was just an indentation issue in the algorithm, which fixes the problem.
17:18:12 <azaroth> PROPOSAL: Accept API #262 and move 13.15 to new step 14, renumber following steps (and can close when complete)
17:18:14 <gkellogg> +1
17:18:16 <azaroth> +1
17:18:18 <jeff_mixter> +1
17:18:18 <rubensworks> +1
17:18:19 <timCole> +1
17:18:25 <ivan> +1
17:18:28 <ajs6f> +1
17:18:32 <pchampin> +1
17:18:43 <azaroth> RESOLVED: Accept API #262 and move 13.15 to new step 14, renumber following steps (and can close when complete)
17:19:12 <azaroth> SUBTOPIC: Missing markup in step 28
17:19:14 <azaroth> https://github.com/w3c/json-ld-api/issues/260
17:19:51 <rubensworks> azaroth: This next issue is also very editorial.
17:20:07 <rubensworks> ... Te value in the linked step has no markup.
17:20:13 <rubensworks> s/Te/The/
17:20:46 <rubensworks> gkellogg: The formatting that allows you to click on it, and see other usages, is only available on GitHub, and will go away once we go to Rec.
17:21:01 <rubensworks> ... It would be good to look into making this survive the transition.
17:21:35 <azaroth> PROPOSAL: Add formatting to create term def step 28  (no entry in changelog as the /text/ doesn't change)
17:21:37 <gkellogg> +1
17:21:39 <azaroth> +1
17:21:39 <jeff_mixter> +1
17:21:40 <rubensworks> +1
17:21:41 <timCole> +1
17:22:09 <pchampin> +1
17:22:15 <ajs6f> +1
17:22:24 <azaroth> RESOLVED: Add formatting to create term def step 28  (no entry in changelog as the /text/ doesn't change)
17:22:37 <azaroth> SUBTOPIC: 16.1 needs more indents
17:22:42 <rubensworks> azaroth: The last one needs discussion.
17:22:43 <azaroth> https://github.com/w3c/json-ld-api/issues/241
17:22:55 <rubensworks> gkellogg: The change we made before was regarding a spec update in 16.1.
17:23:13 <rubensworks> ... We typically don't do a change like this.
17:23:54 <rubensworks> ... We want to do the minimum change possible that addresses the issue, which is not necessarily how we would do it prior to CR.
17:24:08 <pchampin> q+
17:24:39 <rubensworks> azaroth: I'm happy eitherway. The further indentation is clearer and more consistent, but reducing the changes to what is necessary is probably a good operating mode.
17:24:41 <azaroth> ack pchampin
17:24:48 <rubensworks> pchampin: I also made a PR on this issue.
17:25:05 <rubensworks> ... I propose to not add an indentation, but change the step numbers.
17:25:23 <rubensworks> ... My proposal merges 16.1 into 16.
17:25:58 <pchampin> https://github.com/w3c/json-ld-api/pull/266
17:26:11 <rubensworks> gkellogg: I need to look into it more carefully, but it looks like a better solution. It sticks with our normal style.
17:26:54 <rubensworks> azaroth: This is the last issue before moving to BP.
17:27:17 <rubensworks> gkellogg: Have we closed all issues that I marked as propose-closing?
17:27:40 <rubensworks> azaroth: Do we want to accept pchampin's change? Or do you want to read it first gkellogg?
17:27:47 <rubensworks> gkellogg: We can go with pchampin's change.
17:27:57 <pchampin> q+
17:28:00 <azaroth> ack pchampin
17:28:53 <azaroth> PROPOSAL: Accept pchampin's addition in PR 266 to further improve #241
17:28:57 <rubensworks> pchampin: I anticipated that this PR might be rejected because it is sensitive. The first commit in the PR fixes an obvious typo, so it should definitely be retained, even if the PR is not merged.
17:29:04 <azaroth> +1
17:29:09 <ivan> +1
17:29:10 <rubensworks> gkellogg: This PR is good anyways, but I may nitpick it a bit.
17:29:11 <rubensworks> +1
17:29:12 <timCole> +1
17:29:14 <pchampin> +1
17:29:14 <gkellogg> +1
17:29:16 <ajs6f> +1
17:29:23 <azaroth> RESOLVED: Accept pchampin's addition in PR 266 to further improve #241
17:29:30 <azaroth> SUBTOPIC: Close editorial issues
17:29:58 <azaroth> PROPOSAL: Close completed editorial issues API#242, #243, #244, #245, #246
17:30:01 <rubensworks> +1
17:30:02 <gkellogg> +1
17:30:03 <ivan> +1
17:30:04 <pchampin> +1
17:30:05 <jeff_mixter> +1
17:30:06 <timCole> +1
17:30:07 <azaroth> +1
17:30:08 <ajs6f> +1
17:30:15 <azaroth> RESOLVED: Close completed editorial issues API#242, #243, #244, #245, #246
17:30:53 <azaroth> TOPIC: Best Practices
17:31:08 <rubensworks> azaroth: There was an issue you wanted to talk about ivan, about the base context.
17:31:39 <rubensworks> ivan: We wanted to setup some kind of base context, not sure what the right name is for it.
17:31:48 <rubensworks> gkellogg: kitchen sink context.
17:32:09 <azaroth> SUBTOPIC: toolkit [bikeshed] context
17:32:11 <rubensworks> ivan: I setup this stuff months ago, I even forgot about it.
17:32:11 <azaroth> https://github.com/w3c/json-ld-bp/issues/9
17:32:16 <rubensworks> ... Do we want to do it or not?
17:33:00 <rubensworks> ivan: We may decide to drop it. But we need to decide.
17:33:06 <gkellogg> q+
17:33:14 <azaroth> ack gkellogg
17:33:17 <rubensworks> ... I called it a recommended context.
17:33:20 <ivan> Recommended context: https://github.com/w3c/json-ld-rc/blob/master/context.jsonld
17:33:46 <rubensworks> gkellogg: We approached things like this in the past. There is a CSVW context.
17:34:27 <rubensworks> ... We have a couple of contexts that ivan needs to maintained, so if we just have a base jsonld context, those can refer to this base context, which would simplify maintenance.
17:34:45 <azaroth> q+ to agree with the utility of  it
17:34:48 <rubensworks> ivan: To be honest, I don't really maintain the CSVW context anymore.
17:35:09 <rubensworks> ... All of these things eventually end up with one responsible person, who may go away eventually, and it dies.
17:35:15 <rubensworks> ... This is my worry with that.
17:35:21 <gkellogg> https://www.w3.org/ns/csvw.jsonld
17:35:27 <rubensworks> ... I do still maintain the RDFa one.
17:35:42 <rubensworks> ... If I leave W3C, I doubt anyone will do anything with it.
17:35:55 <rubensworks> ... I'm neutral about this.
17:36:04 <azaroth> ack azaroth
17:36:04 <Zakim> azaroth, you wanted to agree with the utility of  it
17:36:22 <rubensworks> azaroth: I think it's useful, even if it becomes static in the long term.
17:36:34 <rubensworks> ... At least in the meantime the systems that point to it have some advantage.
17:36:44 <rubensworks> ... It is an encoding of the best practises.
17:36:47 <ajs6f> q+
17:36:59 <rubensworks> ... It includes the aliases that we recommend, so users get that for free.
17:37:13 <rubensworks> ... If a future WG want to add their NS to that context, they are free to do so.
17:37:30 <gkellogg> q+
17:37:40 <rubensworks> ... If there is a jsonld 2.0, we may want to add new entries to the context for that era.
17:37:47 <azaroth> ack ajs6f
17:37:51 <rubensworks> ... I'd like to go ahead with it.
17:38:30 <rubensworks> ajs6f: If we want to minimize maintenance, we could have a more minimal context that includes some aliases, but does not include namespaces.
17:38:39 <rubensworks> ... This would not require (as much) updates.
17:38:56 <azaroth> ack gkellogg
17:39:01 <rubensworks> azaroth: We could have two contexts: one with aliases based on BP, and one including the namespaces.
17:39:04 <gkellogg> https://www.w3.org/ns/json-ld
17:39:17 <rubensworks> gkellogg: We also have a jsonld NS document, which references a jsonld and ttl version.
17:39:38 <rubensworks> ... It was put in place to define a jsonld context, so we can define a jsonld context in RDF.
17:40:05 <rubensworks> ... This vocab probably needs some work.
17:40:09 <azaroth> q?
17:40:30 <rubensworks> ... The issue with this doc is that the links to jsonld and ttl are missing.
17:41:00 <rubensworks> ... If you give me an action, I can update this document.
17:41:08 <azaroth> ACTION: gkellogg to update json-ld vocabulary at ns/json-ld
17:42:15 <rubensworks> gkellogg: In this RDF document, the data model of a context is defined.
17:42:33 <rubensworks> ... One may think that this is a natural place to look for a default jsonld context.
17:43:05 <rubensworks> ivan: This is already a pretty sizely thing. I'm afraid that it may become too large.
17:43:40 <rubensworks> ... I would not give that out as a BP thing. I would keep them separate.
17:44:27 <rubensworks> ... The list of NS that is there comes from the RDFa stuff. I didn't make a choice of what we should keep or not. There are some vocabs there that are pretty rarely used, or focused used?
17:44:33 <rubensworks> s/?/./
17:44:53 <rubensworks> ... I would just keep a couple of them.
17:45:01 <rubensworks> ... But this is personal.
17:45:39 <rubensworks> ... Either we keep it as-is, or we remove namespaces and just keep aliases, labels, comments, licenses.
17:45:47 <azaroth> q?
17:46:33 <azaroth> PROPOSAL: We will produce a baseline context that provides some degree of general utility
17:46:37 <gkellogg> +1
17:46:37 <azaroth> +1
17:46:38 <jeff_mixter> +1
17:46:39 <timCole> +1
17:46:39 <pchampin> +1
17:46:40 <rubensworks> +1
17:46:42 <ivan> +1
17:46:46 <azaroth> RESOLVED: We will produce a baseline context that provides some degree of general utility
17:46:48 <ajs6f> +1
17:46:56 <rubensworks> ivan: Now what does it contain?
17:47:09 <rubensworks> gkellogg: With a GH redirect, we can finese that over time.
17:47:27 <rubensworks> ... Where should it live?
17:47:35 <rubensworks> ivan: What should it be called?
17:47:56 <rubensworks> azaroth: Where does it live, what is it called, and what does it contain?
17:48:12 <rubensworks> azaroth: We agreed that it should at least contain all the aliases from the BP.
17:48:35 <azaroth> PROPOSAL: baseline context should contain (at least) all of the aliases from the best practices (eg id: `@id`)
17:48:36 <pchampin> q+
17:48:41 <azaroth> ack pchampin
17:49:28 <rubensworks> pchampin: We have an @json keyword, and we don't have an alias for it.
17:49:37 <rubensworks> ivan: We have some shortnames for datatypes.
17:50:06 <rubensworks> gkellogg: In BP, we talk about aliasing keywords. So it makes sense to also have the json alias.
17:50:28 <rubensworks> ... We could have capital json vs lowercase json, but that may make it confusing.
17:50:41 <rubensworks> ivan: So I should add an json->@json alias.
17:50:41 <gkellogg> JSON => rdf:JSON, json => `@json`
17:50:42 <pchampin> q+
17:50:46 <azaroth> ack pchampin
17:51:40 <rubensworks> pchampin: There are two aliases that may be confusing. Anywhere the @json keyword can appear, the rdf:JSON would work too?
17:51:58 <azaroth> q+ to note `@type` also has special handling
17:52:17 <azaroth> ack azaroth
17:52:17 <Zakim> azaroth, you wanted to note `@type` also has special handling
17:52:22 <rubensworks> gkellogg: Not really, @json is used for marking a value as things that should be interpreted as JSON instead of JSON-LD.
17:52:48 <azaroth> PROPOSAL: baseline context should contain (at least) all of the aliases from the best practices (eg id: `@id`)
17:52:56 <rubensworks> +1
17:52:57 <azaroth> +1
17:52:59 <gkellogg> +1
17:53:00 <timCole> +1
17:53:01 <pchampin> +1
17:53:04 <ivan> +1
17:53:07 <ajs6f> +1
17:53:09 <azaroth> RESOLVED: baseline context should contain (at least) all of the aliases from the best practices (eg id: `@id`)
17:53:18 <ivan> q+
17:53:21 <azaroth> ack ivan
17:53:48 <rubensworks> ivan: There are also currently some terms that we defined (outcome of earlier comments): license, label, comment.
17:54:03 <rubensworks> ... There is an RDF term for this, so we can just use that.
17:54:12 <rubensworks> ... I believe these three are things that we should keep.
17:54:28 <rubensworks> ... I am less sure about isDefinedBy and ...
17:55:00 <rubensworks> ivan: Both label and comment are strings I think.
17:55:07 <rubensworks> gkellogg: I don't think their range is defined even.
17:55:30 <rubensworks> azaroth: In IIIF we said that labels should be strings.
17:55:47 <pchampin> I'm pretty sure I saw both xsd:strings and LanguageStrings used with rdfs:label
17:56:17 <rubensworks> gkellogg: Both have rdfs:Literal as range.
17:56:35 <timCole> q+
17:57:06 <rubensworks> azaroth: We can redefine the default, but given I18N, we should say that a label should handle languages.
17:57:14 <azaroth> ack timCole
17:57:16 <rubensworks> ivan: Yes, we should use I18N strings.
17:57:45 <rubensworks> timCole: I'm concerned that not everything is essential for everyone. We may be getting ahead of ourselves.
17:58:22 <rubensworks> ... Some people may pickup the context, and may not realise aliases that are defined, and may be unaware of clashes.
17:58:58 <azaroth> PROPOSAL: Explore which other definitions are widely used and include in baseline (sic) context
17:59:02 <timCole> +1
17:59:03 <azaroth> +1
17:59:04 <rubensworks> +1
17:59:04 <jeff_mixter> +1
17:59:08 <ivan> +1
17:59:09 <pchampin> +1
17:59:19 <gkellogg> +1
17:59:25 <ajs6f> +0
17:59:28 <azaroth> RESOLVED: Explore which other definitions are widely used and include in baseline (sic) context
18:00:55 <ivan> rrsagent, draft minutes
18:00:55 <RRSAgent> I have made the request to generate https://www.w3.org/2019/12/20-json-ld-minutes.html ivan
18:00:55 <ivan> zakim, bye
18:00:55 <ivan> rrsagent, bye
18:00:55 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2019/12/20-json-ld-actions.rdf :
18:00:55 <RRSAgent> ACTION: gkellogg to update json-ld vocabulary at ns/json-ld [1]
18:00:55 <RRSAgent>   recorded in https://www.w3.org/2019/12/20-json-ld-irc#T17-41-08
18:00:55 <Zakim> leaving.  As of this point the attendees have been azaroth, gkellogg, ivan, pchampin, rubensworks, timCole, jeff_mixter, ajs6f
18:00:55 <Zakim> Zakim has left #json-ld