JSON-LD Working Group Telco — Minutes
Date: 2018-12-14
See also the Agenda and the IRC Log
Attendees
Present: Benjamin Young, Simon Steyskal, Rob Sanderson, Gregg Kellogg, Ivan Herman, Pierre-Antoine Champin, Jeff Mixter, David I. Lehn, Tim Cole
Regrets: Harold Solbrig
Guests:
Chair: Benjamin Young
Scribe(s): Simon Steyskal
Content:
- 1. Approve minutes of previous call
- 2. Announcements / Reminders
- 3. Recent Changes/Merges
- 4. WD publication
- 5. Issues
- 6. Resolutions
Benjamin Young: Zakim: pick a victim
1. Approve minutes of previous call
Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-12-07-json-ld
Benjamin Young: +1 to approve minutes
Rob Sanderson: +0 (absent)
Benjamin Young: any objections to last week’s minutes?
Simon Steyskal: +1
Resolution #1: minutes approved
2. Announcements / Reminders
2.1. 2019 Late Winter Face-to-Face - February 7-8 in Washington, DC
Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/F2F/2019.02.DC
Benjamin Young: next F2F late winter 2019
Benjamin Young: https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit
Benjamin Young: we’ll meet up in the smithsonian castle; more info to be found in the google docs
… currently looking for suitable hotels
Gregg Kellogg: harrington (?) hotel
Benjamin Young: the other one we had a look at was a “hampton inn” (?)
Gregg Kellogg: I already booked, but you can cancel 24h in advance; 130$/night (via hotels.com)
2.2. Next call January 4th, 2019 (?)
Benjamin Young: I believe this was the consensus of last call
Rob Sanderson: I’m not sure if I can make it
Benjamin Young: maybe we make a role call via email to see who has time
3. Recent Changes/Merges
3.1. Make requirement for entity encoding non-normative
Benjamin Young: https://github.com/w3c/json-ld-syntax/pull/106
Benjamin Young: this first merge made the req. for entity encoding non-normative
Gregg Kellogg: authors may need some guidance
… they are encouraged to encode
3.2. Don’t do HTML html decoding, and update expand/h010 to reflect this.
Benjamin Young: https://github.com/w3c/json-ld-api/pull/54
Gregg Kellogg: it basically says: validate it and turn it in the internal representation
4. WD publication
Benjamin Young: we are due for a WD publication
… we talked about pushing our publications more often
… it doesn’t need to be voted on by the group
Ivan Herman: there are groups that publish every editor’s draft version
Gregg Kellogg: my feeling is that we don’t publish enough
… now is e.g. a very good time for doing so
Proposed resolution: push the current editor’s draft to be our new Working Draft (Benjamin Young)
Benjamin Young: +1
Rob Sanderson: +1
Gregg Kellogg: +1
Tim Cole: +1
Gregg Kellogg: we probably should publish whenever we merged some pull requests
David I. Lehn: +1
Pierre-Antoine Champin: +1
Ivan Herman: +1
Simon Steyskal: +1
Resolution #2: push the current editor’s draft to be our new Working Draft
5. Issues
5.1. Can SRI be used in JSON-LD for which use cases?
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/86
Benjamin Young: https://w3c.github.io/webappsec-subresource-integrity/
Benjamin Young: if anyone understands this first issue, we can discuss it
Benjamin Young: … SRI = Sub-Resource Integrity
Benjamin Young: SRI is something HTML implementors use to state the integrity of things
… I believe adam wanted to introduce something like SRI for e.g., validating contexts
Gregg Kellogg: it’s an intriguing idea, esp. in the context of referencing external contexts
… it does come with a cost though..
… I think the motivation behind this was to provide means for side-loading stuff
Benjamin Young: https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata
Rob Sanderson: is it about whether we can use the abstract definition of integrity stuff SRI defines
Ivan Herman: there have been 2 diff. issues that came up during TPAC
… one of them was about using a local version of the context
… all go in the direction of annotating a link
… maybe we should postpone this specific issue until we investigated the general picture more thoroughly
Benjamin Young: yeah, people want to be able to state “more” things about a context than they currently can
Benjamin Young: related to https://github.com/w3c/json-ld-syntax/issues/9
Benjamin Young: i.e., that it is sealed
… I don’t think we have any specific actions to take
Rob Sanderson: I think there’s some meta discussion going on
Proposed resolution: someone should open an issue about annotating context URLs potentially with validity/integrity, etc. metadata (Benjamin Young)
Rob Sanderson: we may need to introduce new keywords that identify “new metadata” about a context
… distinction between inline context and reference to metadata of external context
Proposed resolution: azaroth to open an issue about annotating context URLs potentially with validity/integrity, etc. metadata (Benjamin Young)
David I. Lehn: if such metadata feature exists, people may see that as a way to add comments and docs and such as in previous closed issues
Rob Sanderson: +1
Benjamin Young: +1
Rob Sanderson: we should not have the same discussion again in January
Gregg Kellogg: +1
Tim Cole: +1
Simon Steyskal: +1
Pierre-Antoine Champin: +1
David I. Lehn: +1
Ivan Herman: +1
Jeff Mixter: +1
Resolution #3: azaroth to open an issue about annotating context URLs potentially with validity/integrity, etc. metadata
5.2. Introduce concept of “sealed” contexts
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/20
David I. Lehn: we should maybe wait on dlongley for this one
5.3. Is there a scope context mechanism for clearing context definitions?
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/98
Rob Sanderson: we should give it a deadline, e.g., F2F in feb
Benjamin Young: this issue is also related to scoped contexts
… most of the hard issues are related to how this relates to sealed contexts
… maybe @context is an array and the first value of that array is null
… and the 2nd value is actually a reference to an external context
… the issue with regard to sealed context, is the fact that because it is sealed it cannot be cleared
… maybe it needs some special language to do so
Rob Sanderson: seems like it fits to the sealed context discussion, so we should discuss them together
5.4. Add ability to restrict overriding of terms with graph containers
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/87
Benjamin Young: this was specifically about graph containers
… related to verifiable claims wg
… where a claim is represented as graph container, where certain parts need to be sealed
Gregg Kellogg: I guess the way I read this is to perhaps extend the scope … to graph containers
… maybe it’s addressed by simply allowing sealed contexts to be applied on graph containers
5.5. Indexing without a predicate
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/19
Rob Sanderson: I opened issue 19 initially in the CG
… based on an observation by 2 communities
Rob Sanderson: last time we discussed this we thought it might be a good fit for framing
… for creating it; and the context definition for understanding what the particular … is
… you could have an “included block” that contains hundreds of items, you only have to reference but don’t have to add all everytime you use them
Gregg Kellogg: looks very much like “itemref” of microdata
… unwinding this in compaction might be challenging to say at least
Benjamin Young: the current container options don’t work because they force you to have a name or these?
Rob Sanderson: no, the issue we like to solve -> if you don’t have the entire graph in memory, you don’t necessarily find the reference for everything
… i.e. optimizing search
Gregg Kellogg: just noting that there’s a CG started on updating N3
… one of the things they tackle first is adding formula/pattern
… in RDFa we did something similar by adding some reasoning
Ivan Herman: I’m looking at the example and I’m not sure I understand what the graph is you want to generate out of that?
Rob Sanderson: a very connected one
… that allows to avoid having to define a specific node every time it is encountered
Ivan Herman: relative URIs within JSON-LD?
… couldn’t we use an internal URL, like one would use in turtle
Pierre-Antoine Champin: I’m a bit confused by Ivan’s last example
Ivan Herman: the original problem is “we don’t want to repeat things”
… one way to do this in turtle is to use internal URIs
Pierre-Antoine Champin: could I extend this by having only the included key in the top-level object and a set of ids in the corresponding object?
… basically what we discussed during TPAC
Rob Sanderson: we can already do that, so you can have the pattern RDF XML kinda uses
… but it’s a very good point
… some things we want to have nested, some enumerated
… potentially a framing algo could say “put these refs separate, but those others nested”
Rob Sanderson: in JSON schema there’s a definitions block one can reference
Benjamin Young: https://json-schema.org/latest/relative-json-pointer.html
Rob Sanderson: $ref something something magic
… I was thinking more about arbitrary ids, or something along those lines
Benjamin Young: $ref is actually here https://json-schema.org/latest/json-schema-core.html#rfc.section.8.3.2.p.1
Gregg Kellogg: it kinda looks like nesting?
Gregg Kellogg: [gives example]
Rob Sanderson: I don’t think it’s a graph container, as there’s only one graph. It could be either an identifier container or a nesting container, without a mapped predicate
Pierre-Antoine Champin: [thinks about possible hacks to do that]
Ivan Herman: not sure which way we want to go
Benjamin Young: no more calls for the rest of the year
6. Resolutions
- Resolution #1: minutes approved
- Resolution #2: push the current editor’s draft to be our new Working Draft
- Resolution #3: azaroth to open an issue about annotating context URLs potentially with validity/integrity, etc. metadata