JSON-LD Working Group Telco — Minutes

Date: 2019-08-02

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Ruben Taelman, Adam Soroka, Gregg Kellogg, Tim Cole, Benjamin Young

Regrets: Rob Sanderson, David Newbury, Dave Longley, Harold Solbrig, Simon Steyskal, Pierre-Antoine Champin

Guests:

Chair: Benjamin Young

Scribe(s): Ruben Taelman, Benjamin Young

Content:

1. Scribe Selection

2. Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-07-26-json-ld

Proposed resolution: minutes look awesome (Benjamin Young)

Benjamin Young: +1

Tim Cole: +1

Ruben Taelman: +0

Gregg Kellogg: +1

Adam Soroka: +1

Resolution #1: minutes look awesome

3. Announcements / Reminders

3.1. Standing TPAC reminder

Benjamin Young: We are going to get together in Japan next month.
… Make sure to book your room as they are getting full. Registration prices are going up sept 1st.

Ivan Herman: See draft agenda

Ivan Herman: I made a page for an agenda draft.

Benjamin Young: How many of us will be there? 6?

Ivan Herman: Registration list shows 3 people: Sebastien, Gregg and myself
… We have nine observers.

Ivan Herman: See registration list

Benjamin Young: TPAC is good for interfacing with other groups using JSON-LD, such as verifiable credentials.

3.2. DID WG Charter

Benjamin Young: https://www.w3.org/2019/08/did-wg-charter.html

Ivan Herman: Vote on DID if you are a member.
… I will be the Staff Contact for the WG (if accepted) and handle F2F in Japan.

4. Issues

4.1. Indexing with @included

Ivan Herman: See issue PR

Ivan Herman: See issue itself

Benjamin Young: We made good progress on this last week.

Gregg Kellogg: It is @included now.
… @included comes from the JSON:API spec, and we are adopting this.

Benjamin Young: See JSON:API spec

Gregg Kellogg: Right now it’s just a container for collecting node objects that don’t have a direct rel with the node in which they are contained.
… There’s been some exchange on the issue highlighting a bush-like use for included.
… In JSON-LD 1.0 the top-level graph is used to collect nodes is a corner case. Everywhere else where graphs are used are seen as named graph.
… Included doesn’t carry that baggage.
… So @included can be used in favor of @graph in these places.
… In 1.0, you can’t have a graph name being a property of another node. With @included you can.
… We can’t use @graph to define a default graph.
… Except when it is the only property in a top-level object.

Benjamin Young: How does the actual inclusion take place?

Gregg Kellogg: The shape is similar to JSON.API. The value is seen as an array of node objects. If you have a node that is a value of a prop….
… Needed in json:api for node references that are not included in the main document as references, but should be included aside.
… Included blocks can be nested, and will be flattened out when done.
… You won’t compact back to included blocks after flattening.
… You can use included in a frame and have it match on diff subjects.
… The name @included is out of sync with other keywords.
… Dave suggested @include
… Just like json:api

Ivan Herman: It’s becoming bikeshedding
… I would go further than what you did. Ex 111 and 112 (bushes) should be removed.
… We should convince people to not use those forms anymore.

Gregg Kellogg: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/208.html#example-111-using-graph-to-explicitly-express-the-default-graph

Gregg Kellogg: By removing these we won’t lose anything. We would have to remove everything after the note.

Gregg Kellogg: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/208.html#example-103-simple-data-with-several-top-level-nodes

Gregg Kellogg: Also, we may want to reverse example 103 and 104. To clarify writing bushes.

Ivan Herman: Referring to @graph is misleading, as it has not been explained yet there.

Gregg Kellogg: We may want to change an example in the @graph section then.
… We can also just leave that out and use it in the best practices document.

Ivan Herman: Yes

Benjamin Young: Flattened representation will still contain @graph, so readers will have to know what it does.
… This plumbing shift is significant.
… This is going to cause issues for the json people that are operating on the flattened form.

Gregg Kellogg: If you flatten with a context, it would introduce a graph to contain it. This would change the shape dramatically.
… Same with framing. In 1.1 we don’t use an @graph at the top level if not needed.
… We could change the algo to use included instead.
… But we may not want to do that.
… So do we want to replace the main usage of @graph to @included?
… Included allows embedded nodes to go to one place. Like in json:api, they don’t want to include referenced things inline, but only a reference to an included block.

Benjamin Young: Useful for reducing payload size. And only including referenced things once.
… These are just IRI references?

Gregg Kellogg: There is no magic going on.

Ivan Herman: In JSON-LD it used to be hard to do these indexed references.
… The bush features can now be expressed in two different ways.
… These things happen.
… It’s a matter of taste which one you prefer.
… I personally always hated graph for representing bushes.
… I like this new included representation for bushes.
… I don’t want to hide the fact that bushes can be described with included instead of the graph ‘hack’.

Gregg Kellogg: We can say that included can also be used without other props in node object for describing node objects without semantic relationship.

Ivan Herman: I’m fine with that.

Benjamin Young: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/208.html#included-blocks-to-be-flattened

Benjamin Young: If @included were @graph, this would make a named graph?

Gregg Kellogg: I think this would make one or two named graphs.

Benjamin Young: With included it won’t make named graphs.

Gregg Kellogg: Yes, just objects.

Benjamin Young: I see the value, but not keen on the new keyword.
… I think we need to explain these next to each other, with their nuances.
… The initial reason for this feature was not meant to displace graph.
… It was meant to bring in other referenced objects in the document.

Gregg Kellogg: What JSON-LD always had was the ability to reference node
… by defining @id or @vocab you can define that thing.
… our mission is to use json in the wild where this is a pattern of usage

Benjamin Young: You said exactly what I was typing.
… it would be good to use an example from json:api

Gregg Kellogg: json:api examples are quite long, with a lot of nesting
… we have a test case from json:api
… may be too long for here. But may be good for best practices document.
… It would overly complicated the spec to include here.

Benjamin Young: This solves the json:api case by aliasing included to @included.

Gregg Kellogg: Yes, you can have multiple properties that have multiple aliases.
… included can be a nested object

Ivan Herman: Can we talk about things that go to the primer?

Gregg Kellogg: What to do with example?

Ivan Herman: Switch the order of problem of Rob. In the primer we will have to spend more words on the fact that there are different things that can be used to do the same thing.
… We must have a primer.
… The current doc is already huge.

Benjamin Young: We need distinction in the main spec explaining diff between included and graph

Ivan Herman: To be honest, at this level there is no real diff between the examples.
… this is a side-effect with included.
… we should not fiddle around with that

Benjamin Young: The graph foundation exists in flattened output, and this won’t go away.
… this needs clarification

Gregg Kellogg: The use of included on its own is a by-product of the feature.
… it does not need its own description in the spec
… There are use cases where that can be useful
… That better lies in a non-normative text.

Benjamin Young: The bush usage would go to the primer
… focus of the text would go back to inter-document referencing.

Ivan Herman: We are falling back to other extreme that I don’t agree with
… we are hiding a feature of included
… In the inclusion part we should mention the alternative representation of bushes.
… because current graph-based bushes are a hack
… It has been around for a while, but we still should mention it.

Benjamin Young: This is an accidental feature since recently.
… it is essential to flattened output. I don’t see it as a hack.
… For non-turtle/trig users.

Ivan Herman: For semweb folks it is a hack, we should care about that, too.
… we get into taste issues
… I don’t want to hide it.

Proposed resolution: focus @included text and example on original inclusion use case; mention value of it as an @graph replacement for bushes–and reference primer for further reading (Benjamin Young)

Ivan Herman: +0.5

Gregg Kellogg: +1

Benjamin Young: +1

Tim Cole: +1

Ruben Taelman: +1

Ivan Herman: If we have a primer, a reference can be put to it in the CR

Resolution #2: focus @included text and example on original inclusion use case; mention value of it as an @graph replacement for bushes–and reference primer for further reading

Ivan Herman: @include or @included?

Benjamin Young: If @include, people may expect a URI to be “included”. But this is wrong.

Ruben Taelman: what was the keyword in JSON:API?

Gregg Kellogg: ‘included’

Ruben Taelman: in that case, it might be helpful to be consistent with that

Tim Cole: +1 for @included

Proposed resolution: close issue #19 with merger of @included related PRs (Benjamin Young)

Tim Cole: +1

Ivan Herman: +1

Ruben Taelman: +1

Benjamin Young: +1

Gregg Kellogg: +1

Resolution #3: close issue #19 with merger of @included related PRs

4.2. Confirm state of @import usage

Benjamin Young: See Issue 108

Benjamin Young: Request by Rob to state to ourselves to not quickly add more features to @import.

Ivan Herman: +1

Benjamin Young: This import issue is closable, as it is in the spec

Gregg Kellogg: +1

Gregg Kellogg: This also puts the nail in for SRI?

Benjamin Young: Yes
… We would defer and close the SRI issue

Proposed resolution: close 108 with statement that potentially related SRI issues will be closed as differed (Benjamin Young)

Ivan Herman: +1

Gregg Kellogg: Can we close the issue on trig graphs?

Ruben Taelman: +1

Benjamin Young: +1

Tim Cole: +1

Gregg Kellogg: +1

Resolution #4: close 108 with statement that potentially related SRI issues will be closed as differed

Proposed resolution: close 128 (Ivan Herman)

Tim Cole: +1

Ruben Taelman: +1

Ivan Herman: +1

Benjamin Young: +1

Gregg Kellogg: +1

Resolution #5: close 128

5. Resolutions