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:

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