JSON-LD Working Group Telco — Minutes

Date: 2019-07-26

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Simon Steyskal, Benjamin Young, David I. Lehn, Dave Longley, Jeff Mixter

Regrets:

Guests:

Chair: Rob Sanderson, Benjamin Young

Scribe(s): Simon Steyskal

Content:

1. Approve minutes of last call

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

Rob Sanderson: +1

Simon Steyskal: +1

Gregg Kellogg: +1

Benjamin Young: +1

David I. Lehn: +1

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

2. Announcements / Reminders

Rob Sanderson: this is your standing reminder for TPAC

Simon Steyskal: https://www.w3.org/2019/09/TPAC/

3. Horizontal Reviews

Rob Sanderson: continuing with horizontal review

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

Rob Sanderson: as anticipated, the privacy folks don’t really know what to do with us
… remark says it’s not really a web api.. so you tell us

Benjamin Young: I’m wondering there’s any text we can add.. that we are not assuming Web === browser
… we don’t assume it inherits everything the browser dictates; we don’t assume everything is HTTP(s)
… the web is much larger than that
… JSON-LD is already used in WoT
… which will face the same challenges eventually

Gregg Kellogg: https://w3c.github.io/json-ld-api/#the-jsonldprocessor-interface

Gregg Kellogg: one issue we have is that webidl is heavily biased towards browsers
… when I looked at that, I wasn’t able to come up with anything better

Benjamin Young: most specs are encouraged to use webidl
… if we just make it clear that we use webidl because that’s what everyone is supposed to be using

Rob Sanderson: is there an example anyone can think of, where the api is defined via webidl but is obviously not supposed to be ran in the browser?

Dave Longley: https://heycam.github.io/webidl/#Exposed

Gregg Kellogg: I added “exposed” because it wouldn’t pass the pub check otherwise

Benjamin Young: do we know if this exposed requirement is a new one?

Gregg Kellogg: respec started complaining a week or so ago
… they were tightening the screws everywhere recently, hence checking became more thorough
… yeah respec is complaining now.. but it’s possible it’s also a TAG issue?

Benjamin Young: do you have the PR/commit for it?

Rob Sanderson: the webidl def. doesn’t say “exposed” is mandatory

Dave Longley: https://github.com/heycam/webidl/issues/365, https://github.com/heycam/webidl/pull/423 <– makes Exposed mandatory

Rob Sanderson: continuing with response to privacy
… requests must not have any user describing state

Dave Longley: that will cause problems

Rob Sanderson: e.g. when you need auth.?

Dave Longley: yeah.. including cookies and what not

Rob Sanderson: is there anything else we can say? other than saying the same thing with different words?
… I’ll have a go at responding after the call..

4. Issues

4.1. Indexing with @includes

Simon Steyskal: https://github.com/w3c/json-ld-syntax/issues/19

Rob Sanderson: this is one I brought up in the community group
… gkellogg has implemented it

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/19#issuecomment-513976987

Rob Sanderson: gkellogg had a bunch of questions which I tried to answer.. any thoughts/comments?

Gregg Kellogg: regarding what I’ve implemented in the api doc
… I’ve satisfied most/all requirements
… node references work just as well (not for values though..)
… if you add nesting though, this allows for it
… any keyword that’s included in an object would lead to colliding keywords.. so I added necessary wording for that
… I was pretty happy with the way it turned out (we might want to bikeshed the term @included though)

Dave Longley: there’s a very large thread with lots of stuff in there..
… is there an example of what the compact form would look like?
… any pointers to this?

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/pull/207

Rob Sanderson: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/207.html#shared-value-indexing

Gregg Kellogg: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/207.html#shared-value-indexing

Dave Longley: (example 103)
… ex 105 shows the effects of adding nesting
… if you need more things that need to be added, you may run into issues
… with different aliases

Gregg Kellogg: the idea is to have a single included block

Dave Longley: so one has to hope that not more than one section is required

Gregg Kellogg: well kinda like it’s done with types
… and folding
… it could be done..

Dave Longley: I’ve the feeling we are missing one more layer to make this complete and sound

Gregg Kellogg: I don’t really understand the uc. for needing more than one included block

Dave Longley: [explained uc]
… my only concern is that the second someone would come along needing > 1 included block
… we would have to through this away and come up with something different

Gregg Kellogg: refining the place where we out this in the API doc. might result in it not having to be thrown away though
… btw. it wouldn’t survive round-tripping though
… [elaborating on some hacks to make it potentially round-trippable]
… maybe using framing? haven’t investigated this solution thoroughly though
… possible but challenging.. without enough reason for doing it, it’s probably not worth the time

Dave Longley: just wanted to make sure there’s no other trivial uc it stands in the way

Benjamin Young: graph containers feel kinda similar
… wondering whether the same sort of plumbing would work for this?

Gregg Kellogg: @graph has the same req. though
… included maps are purely syntactic
… whereas @graph is a semantic entity

Rob Sanderson: the uc was “Assuming a nested set of resources where leaf nodes are frequently repeated, it is difficult to find the definition of the node after compaction. Imagine a classification that is used on the second item in a list, and again on the 26th. It would be nice to have a place to look up the label for the classification, instead of repeating it on both 2 and 26. Similarly, information about repeated people, services, ..”
… or anything else could benefit from this pattern.”

Dave Longley: yeah.. that sounds to me like the reason we have framing for

Rob Sanderson: we would still need to be able to expand it though

Gregg Kellogg: framing isn’t entirely for “pretty” compaction
… [discussing ways of folding values in using framing]
… it isn’t something one would expect though
… but that’s something that would require a lot of changes to framing.. and I don’t know whether we want to go down that road

Dave Longley: maybe it’s as simple as having a targeted @embed
… it would be in there as a keyword

Rob Sanderson: maybe we can resort to good old code rather than having to rely on framing or compaction for this

Dave Longley: somewhat of a “meh” feeling…

Gregg Kellogg: [explains what would happen if including happens as part of framing]
… the included block would go in the frame

Rob Sanderson: the intent is, when an API engineer gets an instance of the data

Benjamin Young: https://jsonapi.org/

Rob Sanderson: I mean this would be the eq. of always embedding which we can do today already

Benjamin Young: it sounds in their case more like named graph inclusion

Dave Longley: seems like we need an @default @graph container

Dave Longley: “included”: {“@container”: “@graph”, “@graph”: “@default”}

Dave Longley: and then you can frame documents with “@embed”: “some_top_level_key_to_embed_this_under”

Benjamin Young: if we include something like this, we have to clarify it’s not the stuff jsonapi is talking about

Dave Longley: I agree with what bigbluehat was saying
… I’m wondering whether we need a default as I posted in irc

Benjamin Young: example 103 https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/207.html#included-values-to-be-expanded

Dave Longley: so what the syntax would need is something like that (where it’s saying it’s not a named graph)

Gregg Kellogg: in 103, it’s value is a node object
… before expansion it was a node IRI
… it would be an ID graph/map
… what it doesn’t do is the nesting bit
… where the value isn’t folded back in base too

Benjamin Young: "@type": "@included" would make a lot of sense

Rob Sanderson: it would need to have some way of asserting that whatever the default graph is is not a new graph
… that’s just syntactic sugar
… very similar to an ID map

Dave Longley: I would very much prefer us to reuse existing stuff
… instead of having a new feature for each uc

Rob Sanderson: nested id map?

Gregg Kellogg: if we somehow would have a toplvl id map
… then we would have a place for that

Dave Longley: a toplvl idmap could accomplish that.. maybe

Gregg Kellogg: then we should put this on hold for now and figure out how we could do a toplvl id map
… instead of @id leading to a named graph, maybe allowing @id @default
… if you could look at the other issue that’s in the agenda dlongley

5. Adjourn

6. Resolutions