JSON-LD Working Group Telco — Minutes

Date: 2019-12-20

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Ivan Herman, Pierre-Antoine Champin, Ruben Taelman, Tim Cole, Jeff Mixter, Adam Soroka

Regrets: Dave Longley, Benjamin Young

Guests:

Chair: Rob Sanderson

Scribe(s): Ruben Taelman

Content:

1. Scribe selection

2. Approve minutes of last call

Proposed resolution: Approve minutes of last call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-13-json-ld (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Resolution #1: Approve minutes of last call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-12-13-json-ld

Ruben Taelman: +0

Ivan Herman: +1

Pierre-Antoine Champin: +1

3. Announcements?

4. General Issues

4.1. xsd:double vs xsd:decimal

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/318

Gregg Kellogg: The JSON data model uses IEEE floats, they can not reliably encode doubles.

Proposed resolution: Close syntax#318 as solved (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: The spec has been updated to add a note. This should be sufficient to close the issue.

Ivan Herman: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

Resolution #2: Close syntax#318 as solved

Jeff Mixter: +1

Tim Cole: +1

4.2. omit graph example

Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/88

Gregg Kellogg: The issuer pointed out that we are using double negation, as omitGraph true is the default.
… It made more sense in 1.0. But now the default value is reversed.
… We could rename it in 1.1.

Rob Sanderson: We probably don’t want to rename it to includeGraph?

Proposed resolution: Update examples 4 & 5 in Framing to be instructive as well as correct (Rob Sanderson)

Rob Sanderson: We should update the examples in framing to be more instructive.
… This is just editorial.

Proposed resolution: Update examples 4 & 5 in Framing to be instructive as well as correct and close when updated (Rob Sanderson)

Ivan Herman: +1

Rob Sanderson: +1

Tim Cole: +1

Ruben Taelman: +1

Jeff Mixter: +1

Adam Soroka: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Resolution #3: Update examples 4 & 5 in Framing to be instructive as well as correct and close when updated

5. API Algorithm Issues

5.1. Processing @none

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/259

Rob Sanderson: 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.

Gregg Kellogg: They are small things, but important things to correct nevertheless.
… I don’t think any of them fundamentally change the output.

Ivan Herman: That’s what CR is for.

Rob Sanderson: This issue is how @none is handled.

Gregg Kellogg: pchampin has a PR for this.

Pierre-Antoine Champin: Yes, I did a PR for a few of the issues, as they are quite straightforward.

Gregg Kellogg: It would be good to mention the issue in the PR, so we have a link between them.

Proposed resolution: Agree @none is missing in 13.4, accept pchampin’s PR #268, and close (Rob Sanderson)

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Rob Sanderson: +1

Adam Soroka: +1

Tim Cole: +1

Gregg Kellogg: +1

Jeff Mixter: +1

Ivan Herman: +1

Resolution #4: Agree @none is missing in 13.4, accept pchampin’s PR #268, and close

5.2. @direction etc missing in step 28

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/261

Rob Sanderson: This issue is more extensive.
… The Create Term Definition lists a few keywords, but some are missing.
… pchampin also has a PR for this.

Proposed resolution: Agree missing keywords in step 28, accept pchampin’s PR #267, and close (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Ruben Taelman: +1

Tim Cole: +1

Jeff Mixter: +1

Pierre-Antoine Champin: +1

Resolution #5: Agree missing keywords in step 28, accept pchampin’s PR #267, and close

5.3. Nest handling at wrong level of indent

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/262

Rob Sanderson: 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.
… We figured out that it was just an indentation issue in the algorithm, which fixes the problem.

Proposed resolution: Accept API #262 and move 13.15 to new step 14, renumber following steps (and can close when complete) (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Jeff Mixter: +1

Ruben Taelman: +1

Tim Cole: +1

Ivan Herman: +1

Adam Soroka: +1

Pierre-Antoine Champin: +1

Resolution #6: Accept API #262 and move 13.15 to new step 14, renumber following steps (and can close when complete)

5.4. Missing markup in step 28

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/260

Rob Sanderson: This next issue is also very editorial.
… The value in the linked step has no markup.

Gregg Kellogg: 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.
… It would be good to look into making this survive the transition.

Proposed resolution: Add formatting to create term def step 28 (no entry in changelog as the /text/ doesn’t change) (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Jeff Mixter: +1

Ruben Taelman: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Adam Soroka: +1

Resolution #7: Add formatting to create term def step 28 (no entry in changelog as the /text/ doesn’t change)

5.5. 16.1 needs more indents

Rob Sanderson: The last one needs discussion.

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/241

Gregg Kellogg: The change we made before was regarding a spec update in 16.1.
… We typically don’t do a change like this.
… We want to do the minimum change possible that addresses the issue, which is not necessarily how we would do it prior to CR.

Rob Sanderson: 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.

Pierre-Antoine Champin: I also made a PR on this issue.
… I propose to not add an indentation, but change the step numbers.
… My proposal merges 16.1 into 16.

Pierre-Antoine Champin: https://github.com/w3c/json-ld-api/pull/266

Gregg Kellogg: I need to look into it more carefully, but it looks like a better solution. It sticks with our normal style.

Rob Sanderson: This is the last issue before moving to BP.

Gregg Kellogg: Have we closed all issues that I marked as propose-closing?

Rob Sanderson: Do we want to accept pchampin’s change? Or do you want to read it first gkellogg?

Gregg Kellogg: We can go with pchampin’s change.

Proposed resolution: Accept pchampin’s addition in PR 266 to further improve #241 (Rob Sanderson)

Pierre-Antoine Champin: 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.

Rob Sanderson: +1

Ivan Herman: +1

Gregg Kellogg: This PR is good anyways, but I may nitpick it a bit.

Ruben Taelman: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Adam Soroka: +1

Resolution #8: Accept pchampin’s addition in PR 266 to further improve #241

5.6. Close editorial issues

Proposed resolution: Close completed editorial issues API#242, #243, #244, #245, #246 (Rob Sanderson)

Ruben Taelman: +1

Gregg Kellogg: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Jeff Mixter: +1

Tim Cole: +1

Rob Sanderson: +1

Adam Soroka: +1

Resolution #9: Close completed editorial issues API#242, #243, #244, #245, #246

6. Best Practices

Rob Sanderson: There was an issue you wanted to talk about ivan, about the base context.

Ivan Herman: We wanted to setup some kind of base context, not sure what the right name is for it.

Gregg Kellogg: kitchen sink context.

6.1. toolkit [bikeshed] context

Ivan Herman: Recommended context: https://github.com/w3c/json-ld-rc/blob/main/context.jsonld

Rob Sanderson: https://github.com/w3c/json-ld-bp/issues/9

Ivan Herman: I setup this stuff months ago, I even forgot about it.
… Do we want to do it or not?
… We may decide to drop it. But we need to decide.
… I called it a recommended context.

Gregg Kellogg: We approached things like this in the past. There is a CSVW context.
… 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.

Ivan Herman: To be honest, I don’t really maintain the CSVW context anymore.
… All of these things eventually end up with one responsible person, who may go away eventually, and it dies.
… This is my worry with that.

Gregg Kellogg: https://www.w3.org/ns/csvw.jsonld

Ivan Herman: I do still maintain the RDFa one.
… If I leave W3C, I doubt anyone will do anything with it.
… I’m neutral about this.

Rob Sanderson: I think it’s useful, even if it becomes static in the long term.
… At least in the meantime the systems that point to it have some advantage.
… It is an encoding of the best practices.
… It includes the aliases that we recommend, so users get that for free.
… If a future WG want to add their NS to that context, they are free to do so.
… If there is a jsonld 2.0, we may want to add new entries to the context for that era.
… I’d like to go ahead with it.

Adam Soroka: If we want to minimize maintenance, we could have a more minimal context that includes some aliases, but does not include namespaces.
… This would not require (as much) updates.

Rob Sanderson: We could have two contexts: one with aliases based on BP, and one including the namespaces.

Gregg Kellogg: https://www.w3.org/ns/json-ld

Gregg Kellogg: We also have a jsonld NS document, which references a jsonld and ttl version.
… It was put in place to define a jsonld context, so we can define a jsonld context in RDF.
… This vocab probably needs some work.
… The issue with this doc is that the links to jsonld and ttl are missing.
… If you give me an action, I can update this document.

Action #1: update json-ld vocabulary at ns/json-ld (Gregg Kellogg)

Gregg Kellogg: In this RDF document, the data model of a context is defined.
… One may think that this is a natural place to look for a default jsonld context.

Ivan Herman: This is already a pretty sizely thing. I’m afraid that it may become too large.
… I would not give that out as a BP thing. I would keep them separate.
… 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?

Ruben Taelman: s/?/./

Ivan Herman: I would just keep a couple of them.
… But this is personal.
… Either we keep it as-is, or we remove namespaces and just keep aliases, labels, comments, licenses.

Proposed resolution: We will produce a baseline context that provides some degree of general utility (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Jeff Mixter: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Ivan Herman: +1

Resolution #10: We will produce a baseline context that provides some degree of general utility

Adam Soroka: +1

Ivan Herman: Now what does it contain?

Gregg Kellogg: With a GH redirect, we can finese that over time.
… Where should it live?

Ivan Herman: What should it be called?

Rob Sanderson: Where does it live, what is it called, and what does it contain?
… We agreed that it should at least contain all the aliases from the BP.

Proposed resolution: baseline context should contain (at least) all of the aliases from the best practices (eg id: @id) (Rob Sanderson)

Pierre-Antoine Champin: We have an @json keyword, and we don’t have an alias for it.

Ivan Herman: We have some shortnames for datatypes.

Gregg Kellogg: In BP, we talk about aliasing keywords. So it makes sense to also have the json alias.
… We could have capital json vs lowercase json, but that may make it confusing.

Ivan Herman: So I should add an json->@json alias.

Gregg Kellogg: JSON => rdf:JSON, json => @json

Pierre-Antoine Champin: There are two aliases that may be confusing. Anywhere the @json keyword can appear, the rdf:JSON would work too?

Gregg Kellogg: Not really, @json is used for marking a value as things that should be interpreted as JSON instead of JSON-LD.

Proposed resolution: baseline context should contain (at least) all of the aliases from the best practices (eg id: @id) (Rob Sanderson)

Ruben Taelman: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

Adam Soroka: +1

Resolution #11: baseline context should contain (at least) all of the aliases from the best practices (eg id: @id)

Ivan Herman: There are also currently some terms that we defined (outcome of earlier comments): license, label, comment.
… There is an RDF term for this, so we can just use that.
… I believe these three are things that we should keep.
… I am less sure about isDefinedBy and …
… Both label and comment are strings I think.

Gregg Kellogg: I don’t think their range is defined even.

Rob Sanderson: In IIIF we said that labels should be strings.

Pierre-Antoine Champin: I’m pretty sure I saw both xsd:strings and LanguageStrings used with rdfs:label

Gregg Kellogg: Both have rdfs:Literal as range.

Rob Sanderson: We can redefine the default, but given I18N, we should say that a label should handle languages.

Ivan Herman: Yes, we should use I18N strings.

Tim Cole: I’m concerned that not everything is essential for everyone. We may be getting ahead of ourselves.
… Some people may pickup the context, and may not realize aliases that are defined, and may be unaware of clashes.

Proposed resolution: Explore which other definitions are widely used and include in baseline (sic) context (Rob Sanderson)

Tim Cole: +1

Rob Sanderson: +1

Ruben Taelman: +1

Jeff Mixter: +1

Ivan Herman: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Adam Soroka: +0

Resolution #12: Explore which other definitions are widely used and include in baseline (sic) context

7. Resolutions

8. Action Items