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
- 2. Announcements / Reminders
- 3. Scoping of 1.1 issues
- 4. context response as HTML
- 5. Resolutions
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
- Resolution #1: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-04-19-json-ld
- Resolution #2: Defer framing #38 until future WG
- Resolution #3: Defer framing #29 until future WG
- Resolution #4: Defer syntax #108 to future WG, too large a syntactic change for 1.1, refer in HR to other ongoing work
- Resolution #5: Close syntax #86, as being dependent on deferred #108, and duplicates only use case for it
- Resolution #6: Leave #128 open until we can determine the effects of @container / @nest
- Resolution #7: Describe preferred key ordering for serialization over the wire to enable streaming parsers as a best practice