JSON-LD Working Group Telco — Minutes

Date: 2019-04-26

See also the Agenda and the IRC Log

Attendees

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

Regrets:

Guests:

Chair: Rob Sanderson

Scribe(s): Simon Steyskal

Content:

1. Approve minutes of previous call

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

Rob Sanderson: +1

Benjamin Young: +1

Dave Longley: +1

Ruben Taelman: +1

Ivan Herman: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +0

Tim Cole: +1

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

2. Announcements / Reminders

Rob Sanderson: any announcements/reminders?

Benjamin Young: fyi, Ivan and I will be at the publishing WG f2f in a couple of days
… json-ld is talking a rather important role there
… would be helpful to have some review/comments on their work

Ivan Herman: from now on, the minutes I’ll create will have schema.org mark up in it too

3. Scoping of 1.1 issues

Ivan Herman: we will have to mark up the issues properly
… at the end of the day we have to report what we plan to do

Rob Sanderson: now that we are at the point of deciding what issues to tackle and what not
… I’m fine with changing the label
… we have 3 issues in syntax, 1 in api and 2 in framing currently labelled as deferred

3.1. several frames in the same document

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

Rob Sanderson: are we still agreeing that we don’t do this particular issue in the scope of the current wg?

Gregg Kellogg: SPARQL 1.2 CG discusses framing in the context of construct queries
… I’m fine with deferring

Proposed resolution: Defer framing #38 until future WG (Rob Sanderson)

Ivan Herman: +1

Rob Sanderson: +1

Dave Longley: +1

Tim Cole: +1

Benjamin Young: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Ruben Taelman: +1

David Newbury: +1

Pierre-Antoine Champin: +1

Resolution #2: Defer framing #38 until future WG

3.2. class-scoped framing

Ivan Herman: link: https://github.com/w3c/json-ld-framing/issues/29

Rob Sanderson: idea is that framing starts with a tree, but if you don’t know where a class starts in a tree then things get complicated
… likely would require multiple frames within a frame document

Benjamin Young: +1

David Newbury: +1

Proposed resolution: Defer framing #29 until future WG (Rob Sanderson)

Ivan Herman: +1

Dave Longley: +1

David Newbury: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Tim Cole: +1

Simon Steyskal: +1

Resolution #3: Defer framing #29 until future WG

3.3. context by reference with metadata

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

Rob Sanderson: metadata specified in a document without context
… this has been asked for and discussed (as it has some privacy/security implications)
… we need to have a good answer for not doing it, if we do so

Ivan Herman: the example given in the issue is now outdated
… is there any other example that would require this? (other than the SRI one)

Rob Sanderson: I don’t.. other than comment, description, etc.

Gregg Kellogg: by providing metadata one might not to have to download a context
… just verify that the remote context hasn’t changed

David Newbury: the other thing we talked about was finding documentation about contexts

Ivan Herman: back to the various URI schemes, if we use that argument then some people might raise some eyebrows
… as most of those schemes are more or less experimental
… but we can say that it would require fundamentally new syntax to be able to handle those metadata, hence deferring

Rob Sanderson: +1 that this would be a bigger change than a .1 ; and to refer abstractly to other work

Dave Longley: I think we can refer to other work that’s going on in that space
… not necessarily say one has to use them

Proposed resolution: Defer syntax #108 to future WG, too large a syntactic change for 1.1, refer in HR to other ongoing work (Rob Sanderson)

Gregg Kellogg: +1

Ruben Taelman: +1

Rob Sanderson: +1

Tim Cole: +1

Benjamin Young: +1

Dave Longley: +1

Ivan Herman: +1

Simon Steyskal: +1

David I. Lehn: +1

Adam Soroka: +1

Resolution #4: Defer syntax #108 to future WG, too large a syntactic change for 1.1, refer in HR to other ongoing work

3.4. Can SRI be used in JSON-LD and for which use cases?

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/86

Rob Sanderson: answer is no

Ivan Herman: I propose this issue can simply be closed by referring to the previous issue

Proposed resolution: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it (Rob Sanderson)

Gregg Kellogg: +1

Benjamin Young: +1

Rob Sanderson: +1

Ruben Taelman: +1

Simon Steyskal: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Dave Longley: +1

David Newbury: +1

Ivan Herman: +1

David I. Lehn: +1

Resolution #5: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it

3.5. TriG graphs in JSON-LD

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

Simon Steyskal: [ivan contemplating about issue 128]

Ivan Herman: there was some activity on this issue in February
… there is a comment on it from pchampin providing a solution and asking whether that’s valid
… idk though

Gregg Kellogg: I think I had an action on looking into interaction with nest/container stuff
… we def. need a dedicated section on graphs/trig etc. in the bpr document

Ivan Herman: then let’s leave it open for now

Proposed resolution: Leave #128 open until we can determine the effects of @container / @nest (Rob Sanderson)

Ruben Taelman: +1

Rob Sanderson: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Tim Cole: +1

Simon Steyskal: +1

Ivan Herman: +1

Dave Longley: +0

Adam Soroka: +1

David Newbury: +1

David I. Lehn: +1

Resolution #6: Leave #128 open until we can determine the effects of @container / @nest

3.6. Streaming Profiles for JSON-LD to/from RDF

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

Rob Sanderson: this came from the community group

Ivan Herman: what does a profile mean?

Gregg Kellogg: I reckon in the sense of serializing json-ld in a way that it’s easier for stream processors to deal with it
… or how would you create json-ld from a stream
… the best thing we can do is to provide requirements that should be followed

Ivan Herman: so not like profiles in the http context

Ruben Taelman: basically like gkellogg described
… I’m more than happy to summarize this in the best practice document

Dave Longley: +1 to doing this in best practices

Simon Steyskal: I don’t think it should be normative. You can do what you want. But it’s perfectly fine for a best practices document and should be in there, giving guidelines on this.

Gregg Kellogg: the one thing I’m not sure whether we can move to a bp document is something that allows one to require stream data (?)

Ivan Herman: I would propose to leave it to best practice

Tim Cole: I’m a little concerned that by not following gkellogg’s suggestions people will create json-ld that cannot be used properly by a streaming processor

Adam Soroka: we frequently get questions about streaming json-ld
… I second the concern timCole raised

Benjamin Young: https://github.com/w3c/json-ld-bp/issues/3

Benjamin Young: a lot of the stuff I’m reading there is about key ordering
… one potential option could be not to require ordering
… but processors outputting a preferred ordering

Ivan Herman: I hear bigbluehat’s argument which is perfectly valid, and maybe a future version of json-ld will have key ordering

Rob Sanderson: +1 - unordered keys are ordered by necessity of a serialization

Gregg Kellogg: serialization vs. data model wrt. ordering

Tim Cole: +1 to ivan since it will provide experience to inform normalization

Ivan Herman: I repeat what I just said, getting into a normative thing in that area is probably premature
… or too much work

Rob Sanderson: what’s the happy middle ground? key ordering for streaming?

Benjamin Young: I would like to get as much as possible into the best practice document

Ruben Taelman: scoped contexts shouldn’t be an issue
… as long as they are the first object

Proposed resolution: Describe preferred key ordering for serialization over the wire to enable streaming parsers as a best practice (Rob Sanderson)

Gregg Kellogg: +1

Adam Soroka: +1

Rob Sanderson: +1

Ivan Herman: +1

Dave Longley: +1

Benjamin Young: +1

Simon Steyskal: +1

David I. Lehn: +1

Ruben Taelman: +1

Gregg Kellogg: Scoped contexts might require that @type come after @id

Pierre-Antoine Champin: +1

Tim Cole: +1 as long as leave defer for future

David Newbury: +1

Resolution #7: Describe preferred key ordering for serialization over the wire to enable streaming parsers as a best practice

4. context response as HTML

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

Rob Sanderson: what happens if you deref. a context and you get back HTML
… currently it’s an error
… however we opened the door of dealing with HTML within json-ld
… is it justified though?

Gregg Kellogg: we did look to this as part of our solution on how to document json-ld
… I created an example as part of one of the pull requests
… what does this mean in terms of processing
… you get HTML turn that into JSON and pass that to the processor
… where that didn’t work was with contexts
… related to WebIDL section of the api spec that discusses framing (?)

David Newbury: workergnome_ has joined #json-ld

Rob Sanderson: having a context that self-documents with HTML seems like a potential benefit
… if you don’t want to have HTML then just use content negotiation to request json only

Benjamin Young: web of things/credentials/etc. more than likely won’t ship with dom parsers
… if there’s a way of making html parsing more modular
… or at least not making it a requirement, would be preferred

Dave Longley: +1 to everything bigbluehat just said

Ivan Herman: if I don’t care about the implementation, and that I can use json-ld with HTML
… user’s might be confused when they can actually use json-ld+html

Benjamin Young: if there’s any req. that a context stays the same (e.g. for hashing or what not) than you would properly not want to have it in HTML
… verifiable claims would properly freak out if they have to include a dom parser too
… if there’s a way to achieve this in the api spec, then +1!

Dave Longley: perhaps we can have a conformance class around document loaders and push everything that way—and say that you have to use a document loader that understands JSON-LD in HTML if you want to support that, and then we don’t need two specs, just more conformance classes around document loaders (maybe)

Gregg Kellogg: wondering whether we can actually pull the HTML part out into an own spec, or define a profile for it

5. Resolutions