JSON-LD Working Group Telco — Minutes

Date: 2019-08-30

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Adam Soroka, Rob Sanderson, Dave Longley, Gregg Kellogg, Pierre-Antoine Champin, Benjamin Young, David I. Lehn

Regrets: Ivan Herman, ruben taelman

Guests:

Chair: Rob Sanderson

Scribe(s): Pierre-Antoine Champin, Rob Sanderson

Content:

1. Scribe Selection

2. MInutes

Rob Sanderson: the scribe’s job should be easy today

Proposed resolution: Approve minutes of the previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-08-23-json-ld (Rob Sanderson)

Ivan Herman: +1

Gregg Kellogg: +0

Adam Soroka: +1

Rob Sanderson: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

Resolution #1: Approve minutes of the previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-08-23-json-ld

3. Announcements / Reminder

Rob Sanderson: TPAC approaching
… I suggest we have a call next week, but not the following (just before TPAC)

Ivan Herman: +1

Rob Sanderson: Any objection?

Benjamin Young: +1

4. Horizontal Reviews

Rob Sanderson: See horizontal review issues

Ivan Herman: re i18n, I have pinged Richard again. He said he would look at it last week.
… As far as we are concerned, I consider that we are done.
… The proposal for direction in RDF literal got no feedback from the community,
… so the ideal solution will not fly.

Benjamin Young: I reached out to the a11y group
… The current suggestion is to send our answers to the checklist to the mailing list,
… see if anyone cares.

Rob Sanderson: I pinged the Security group this week, no response yet.
… We will see at TPAC.
… The Privacy people did engage, but have nothing much to add.
… We can also meet them at TPAC.

5. Issues

5.1. Final short names

Rob Sanderson: See WG issue #103

Rob Sanderson: Ivan raised this issue. What should ‘jdonld’ point to in the future?
… 1.0 as it currently does, or the most recent version of the spec?
… There has been some discussion on the list.
… The suggestion is that ‘jsonld’ always points to the most recent,
… and ‘jsonld10’ and ‘jsonld11’ point to respective versions.

Ivan Herman: I have to check with the webmasters what exactly the rules are.
… If the WG is fine with this solution, I can start the discussion with them.
… Some people like pointin to the very last working draft,
… I’m not sure that’s a good idea, but we can discuss this later.

Gregg Kellogg: my concern is that this will change what ‘jsonld’ points to…

Ivan Herman: we need not solve this before CR

Rob Sanderson: are there other specifications who reference JSON-LD 1.0 via jsonld?
… this could lead to strange things for readers,
… especially if those spec say something like “JSON-LD does not support this”,
… while in fact JSON-LD 1.1 does.

Pierre-Antoine Champin: Just wanted to point out that JSON-LD pointing to something else is a matter of perspective. Currently it does point to the latest version
… I would argue it doesn’t change what we point to. Rob’s arguemtn about other specs is a good point.

Ivan Herman: to the best of my knowledge, no W3C spec referencing JSON-LD extend it in a way that azaroth suggests
… Groups out there may have done something nasty in that line,
… but well, they shouldn’t have been nasty.

Gregg Kellogg: if a spec has particular version dependency, they should point to a precise version

Benjamin Young: Activity Streams has its own media-type, because JSON-LD didn’t support lists of lists.
… What would be the impact on testing for other specs?

Rob Sanderson: +1 to dlongley

Ivan Herman: +1

Gregg Kellogg: +1

Benjamin Young: for the curious: https://www.specref.org/?q=json-ld

Dave Longley: I think that the benefit of having the latest version come up for ‘jsonld’ outweights the potential costs.

Action #1: contact w3 team to determine possibility of json-ld shortname pointing to latest version (Ivan Herman)

Gregg Kellogg: what does this mean for us? Sounds like “nothing” in the short term,
… except changing our references from ‘jsonld’ to ‘jsonld10’.

Ivan Herman: correct

5.2. Framing blank nodes

Rob Sanderson: See Framing #27

Dave Longley: See a particular comment

Dave Longley: I raised this issue while trying to frame VC-like data,
… asked if other implementations had the same issue.
… This example generate a strange artifact (“ex:subject” at the bottom).

Gregg Kellogg: this artifact does not produce any triple,
… we can remove it by filtering on type. But is the output still correct?
… The issue may not be in framing, but somewhere else (maybe compaction?).

Rob Sanderson: to try and summarize: in the original data, there is exactly one named graph.
… inside that is a proof which is a graph container.
… The frame generates the subject as a separate graph?

Gregg Kellogg: (something about this behavior being legitimate with other data)

Dave Longley: may be this could be solved with @include?

Gregg Kellogg: there might be other holes in framing which we have not seen yet…
… We should try to flesh out the test suite further.

5.3. expandContext

Rob Sanderson: See API issue #141

Gregg Kellogg: Ruben suggest it would be more convenient if we could describe options as IRIs rather than strings.
… In the manifest, options are described by key-value pairs, where values are pairs described in the WebIDL description.
… WebIDL does not support IRIs, it is not our job to do it.
… So I think we should reject this PR.

Dave Longley: I agree

Proposed resolution: Reject #141, as underlying webIDL spec does not use IRIs, and not our place to recast into them (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Dave Longley: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Adam Soroka: +1

Benjamin Young: +1

Ivan Herman: +1

Resolution #2: Reject #141, as underlying webIDL spec does not use IRIs, and not our place to recast into them

5.4. algorithmic readability

Rob Sanderson: See API PR #132

Pierre-Antoine Champin: We discussed this a while ago, and I decided to try and make the algorithms a bit easier to read
… Thought it would be convenient to have another view of it for easier to have a global understanding before diving into the details

Gregg Kellogg: See Example for the algorithm

Pierre-Antoine Champin: Tried on one of them to use <detail> that allows folding/unfolding of the algorithm, and I think it does the job providing we use an appropriate title for the detail to give a good summary
… problem of printing. After some exchange in the issue I added some js that unfolds during printing, so the printed version is complete
… dlongley suggested that an unfold all button would be useful
… only question is about ergonomics – where should the button be? Hovering so it’s always there, or somewhere particular?
… perhaps also a keyboard shortcut for it?

Ivan Herman: In general I’m all for this. Looking for an example for where to put the button
… I’m looking for an example about where to put his button.

Ivan Herman: See OWL Primer example with buttons

Ivan Herman: in the OWL primer, you can switch between syntaxes.

Benjamin Young: buttons are specifically here https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#OWL_Syntaxes

Ivan Herman: There is a set of buttons to do that, somewhere in the introduction.

Gregg Kellogg: we have an similar example in the API.
… How much can we get with CSS selectors? Are there any a11y considerations?
… It shouldn’t be considered as normative change, but could this lead us to change the structure of some algorithms?

Ivan Herman: we should ask Avneesh Singh to have a look at pchampin’s example.

Rob Sanderson: We has a similar button in annotation-model, to switch between Turtle and JSON-LD examples,
… this caused much change in layout, because Turtle was much shorter.

Ivan Herman: that’s why I suggest just one, at the top

Gregg Kellogg: plus each individual <details> has its own button

Action #2: contact Avneesh Singh regarding a11y of fold/unfold button (Ivan Herman)

Rob Sanderson: +1 to complete

Dave Longley: +1 to complete

Ivan Herman: +1 to complete

Benjamin Young: +1 to complete

Pierre-Antoine Champin: we seem to agree that the printed version should be complete, with all details unfoleded

Gregg Kellogg: could this be done via CSS @media query rather than JS?

Pierre-Antoine Champin: unfortunately not

Gregg Kellogg: what about epub?

Ivan Herman: if the JS is self contained, it should work

Rob Sanderson: what if JS does not work?

Pierre-Antoine Champin: it will be printed in its current state: any detail that you opened is printed open

Rob Sanderson: that seems acceptable

6. Miscellaneous

Rob Sanderson: we should go to CR in a short number of weeks after TPAC

Ivan Herman: and we have to decide how long we want to be in CR
… depends how advanced the implementations are

Gregg Kellogg: data-related specs should be more advertised at TPAC

Action #3: email Coralie regarding announcement at TPAC (Rob Sanderson)

Benjamin Young: we will have allies in the WoT group
… I’m reaching out the JSON schema group, to help them liaise with W3C.

Gregg Kellogg: https://www.timeanddate.com/worldclock/japan/fukuoka

7. Resolutions

8. Action Items