JSON-LD Working Group Telco — Minutes

Date: 2019-02-15

See also the Agenda and the IRC Log

Attendees

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

Regrets: Tim Cole, Jeff Mixter

Guests:

Chair: Rob Sanderson

Scribe(s): Pierre-Antoine Champin

Content:

1. Approve minutes of Face to Face

Rob Sanderson: there are some questions here
… on Friday, we discussed some complicated issue about framing,
… but the issue referenced in the minutes seems to be the wrong one

Ivan Herman: I put a PR with the change fixing this: https://github.com/w3c/json-ld-wg/pull/28

Gregg Kellogg: the issue that we originally discussed was the overloading of bnode
… while the issue we referenced is the use of bnode in frames, which I don’t think is controversial

Proposed resolution: Approve the minutes of the F2F, with the changes for the framing issue actually discussed rather than the issue number recorded (Rob Sanderson)

Dave Longley: +1

Pierre-Antoine Champin: +1

Rob Sanderson: +1

Harold Solbrig: +1

Simon Steyskal: +1

Ivan Herman: +1

Benjamin Young: +1

Gregg Kellogg: +1

David I. Lehn: +1

David Newbury: +1

Adam Soroka: +1

Resolution #1: Approve the minutes of the F2F, with the changes for the framing issue *actually discussed rather than the issue number recorded*

2. Administrivia

Rob Sanderson: thank you everyone who attended the F2F
… (either in person on remotely)

2.1. meeting with the TAG

Benjamin Young: a while ago, we took it to the TAG for some “HTML & JSON-LD” related discussion

Benjamin Young: https://github.com/w3ctag/design-reviews/issues/312#issuecomment-463373808

Benjamin Young: we have proposed a few date for them to attend one of our calls
… this might be either March 1 or March 15

Benjamin Young: some members of the TAG have some ideas about relations between JSON-LD and HTML modules
… which are part of the future “Web component” standard
… It is not clear what exactly they want to discuss, but this might have deep relations with the future of HTML.
… It also seems that Google is planning to include some JSON-LD processing in their Lighthouse tool.
… Some JSON-LD is becoming more and more coupled with HTML.

Ivan Herman: It would be could if they could provide some pointers in advance,
… so that we can look at them before the call,
… this will make the discussion more interesting.

Benjamin Young: I’ll check with Travis and Alex if they want to address Lighthouse,
… and I can provide some pointers on the list.
… Let’s have the TAG join our call on the 1st of march.

2.2. WG Timing

Rob Sanderson: We intend to have our first CR by the end of summer.
… We propably have the time for 2 CR, then PR, and our REC on June 2020.
… We need to set a date beyond which new features will not be accepted.
… I would propose March 1st, and publicize this date.

Gregg Kellogg: people need to understand which features we currently have.
… I suggest that we wait for a couple of weeks after the WD is published,
… which will be hard to achieve by March 1st.

Rob Sanderson: we can wait until the end of March, then.

2.3. Implementation tracking

Benjamin Young: the plan is for Rob and I to write a blog post to call for implementations.
… I also hope to go through a list of existing implementations, and reach out to each of those project, to suggest them to implement 1.1 features.
… If anyone has any contact with / contributes to one of these groups, please take an action to notify them.
… Also, let me know if you know about other implementations not registered on json-ld.org .

Rob Sanderson: our hope is to have more than the minimum 2 implementations for each feature.

David I. Lehn: would be great if we could at least get implementations to be able to run the 1.1 test suite, even if they just ignore all the marked 1.1 tests.

Gregg Kellogg: we need to highlight those implementations that do not have the resource at the moment to implement all 1.1 features.
… we must encourage people to contribute PR to those.

Ivan Herman: the list I see on json-ld.org are the developers of 1.0
… we should have a marker for those that implement 1.1

Dave Longley: +1 to adding some notation about implementations that support or will support 1.1

Gregg Kellogg: the test-suite page on json-ld.org now shows/redirects the location of the new test suite

2.4. General Outreach

Rob Sanderson: then there is some outreach and dissemination to be done

Gregg Kellogg: we could update json-ld.org to announce some of the coming features in 1.1
… the only thing it says for the moment is that the WG has been launched

Action #1: Benjamin Young to update json-ld.org home page for 1.1 coming features

Ivan Herman: I thought we were talking about the WH homepage.

Gregg Kellogg: it wouldn’t hurt to update that one as well.
… we could use the wiki for that.

Rob Sanderson: ivan, pchampin and gkellogg are going to the Berlin workshop (https://www.w3.org/Data/events/data-ws-2019/)

Gregg Kellogg: danbri should be here as well

3. Sealed Contexts’ timing

Rob Sanderson: a discussion started yesterday about the decisions made during F2F about sealed contexts
… we need to see to which extent the current proposal works and does not work with existing use cases;
… we have spent several week and close to half the F2F time to talk about it;
… continuing is not in the interest of the group.

Dave Longley: We plan on implementing next week and we’ll engage on Github
… we are globally happy with the decision of the F2F,
… but we need sealing to be a little more restrictive.
… We will come up with an implementation of what we need.

Rob Sanderson: this will help to assess how much additional complexity is required

Gregg Kellogg: what we have been looking at was doable (I did implement it),
… but we still decided that it added too much complexity.
… That being said, I’m happy to discuss with you about it.

Dave Longley: All we want to do is add constraints on when the context can be cleared with ‘null’.
… We don’t think it adds that much complexity.

4. Framing blank node unnamed graphs (Issue frame27)

Rob Sanderson: the issue is about Framing blank node unnamed graphs

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

Dave Longley: I have an example of a document with a graph container,
… and couldn’t to get the same document as my input using framing.
… It seems to defeat the purpose of framing.

Gregg Kellogg: It is true that this should be possible,
… but I doubt we can address that problem before the next publication.

Rob Sanderson: should there be a note in the next WD about that issue?

Proposed resolution: Leave framing 27 open, and to investigate the cause. Record open issue in the next PWD of Framing. (Rob Sanderson)

Gregg Kellogg: this would appear in the list of open issue that we append to each WD

Simon Steyskal: +1

Pierre-Antoine Champin: +1

Rob Sanderson: +1

Dave Longley: +1

Adam Soroka: +1

Harold Solbrig: +1

Ivan Herman: +1

David Newbury: +1

Benjamin Young: +1

Rob Sanderson: given the low number of open issue, I would prefer some editor text to make the issue more visible

David I. Lehn: +1

Resolution #2: Leave framing 27 open, and to investigate the cause. Record open issue in the next PWD of Framing.

Gregg Kellogg: +1

Dave Longley: once we get sealed contexts working the way we need we might be able to look into addressing this one next

Dave Longley: (we == Digital Bazaar)

5. Class-scoped Framing (issue frame29)

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

Rob Sanderson: framing is like programming by example;
… you need to know the exact structure from the root down.
… For some properties (like “link” or “tag”),

Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/29#issuecomment-463295607

Rob Sanderson: you would need to be able to say “anywhere this property appears, it should conform with this structure”
… but this is not currently possible.

Ivan Herman: isn’t it related to the issue I raised recently, while reading the framing document (issue 38)?
… We can not currently have a “bush-shaped” frame, with several patterns,
… the first matching one being used.
… Wouldn’t it solve your issue as well?

Gregg Kellogg: I think it is possible to have a bush.

Ivan Herman: not for the pattern itself.

Dave Longley: this is pretty close: http://tinyurl.com/y356yzo8

Dave Longley: to what Ivan wants – in JSON-LD 1.0 framing

Gregg Kellogg: I think your particular example could still be solved.
… I’m not sure this completely addresses what Rob wants.
… This is more like a “macro” feature.
… It is somehow similar to scoped contexts… Something like a scoped frame.

Rob Sanderson: +1 to similarity (but not identity) to scoped contexts

Dave Longley: I think that what Ivan wants is similar.
… And I do think that there is a gap in the current framing document.
… It makes sense for us to create like a ‘type frame’.

Gregg Kellogg: If we do it for types, we should probably do it for properties, too

Dave Longley: something like @anywhere makes sense to me as well … defining “subframes” at the top of the frame that get applied when certain types or properties are encountered

Rob Sanderson: @frame :D

Gregg Kellogg: we might define something parallel to contexts, that could appear anywhere contexts can appear,

Proposed resolution: Work on a proposal for solving framing#29 along the lines of embedded contexts / scoped contexts, but for embedded sub-frames (Rob Sanderson)

Rob Sanderson: +1

Dave Longley: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Pierre-Antoine Champin: +1

Ivan Herman: +1

David I. Lehn: +1

David Newbury: +1

Benjamin Young: +1

Resolution #3: Work on a proposal for solving framing#29 along the lines of embedded contexts / scoped contexts, but for embedded sub-frames

Gregg Kellogg: We should look to ShEx and SHACL for similar patterns we might leverage

6. Resolutions

7. Action Items