JSON-LD Working Group Telco — Minutes

Date: 2019-03-29

See also the Agenda and the IRC Log

Attendees

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

Regrets: Benjamin Young, Jeff Mixter

Guests:

Chair: Rob Sanderson

Scribe(s): Pierre-Antoine Champin, Rob Sanderson

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-03-22-json-ld (Rob Sanderson)

Rob Sanderson: +1

David Newbury: +1

Ivan Herman: +1

Dave Longley: +1

Gregg Kellogg: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Resolution #1: Approve Minutes of Previous Call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-22-json-ld

2. Introductions

Rob Sanderson: we have delayed Ruben’s introduction

Rob Sanderson: working on the usability of linked data, including with JSON-LD

Gregg Kellogg: presently with Specops; involved with JSON-LD since the beginning

Adam Soroka: Apache Software Foundation

Pierre-Antoine Champin: Pierre Antoine, Associate Prof at University of Lyon, Research includes sem web, lod, and interest in JSON-LD joined after last TPAC in Lyon

rubenworks: from Ghent University; research on publishing and querying LD on the Web
… I implement a streaming JSON-LD processor

David I. Lehn: from Digital Bazaar; long involved with JSON-LD

Dave Longley: also Digital Bazaar; one of the co-creators of JSON-LD, and implementor

Tim Cole: UIUC library; worked with JSON-LD in the Annotation WG, and increasingly using it

Ivan Herman: W3C staff contact, former lead of the Semantic Web activity

3. Announcements/ Reminders

Rob Sanderson: we have reserved Thursday/Friday for our meeting at TPAC in September
… we can cancel it if it turns out that too few people can join (possibly because we will be advanced enough)

Ivan Herman: we should set a date to make that decision
… probably around 1st of July

Action #1: facilitate decision by July 1 for TPAC (Rob Sanderson)

Gregg Kellogg: we should see if we want to liaise with other groups during TPAC

Rob Sanderson: next week, EU/UK will have switched to DST, so the teleconf will be back to the usual time

4. Issues

4.1. Defining term without @id

Rob Sanderson: Link: https://github.com/w3c/json-ld-syntax/issues/129

Rob Sanderson: we discussed this in the F2F in Washington DC
… as part of 116 (allow redefinition of terms), but reducing it

Gregg Kellogg: the original issue was about redefining a term without @id in the term definition
… I did a few experiment; this should be fairly straightforward

Ivan Herman: this would radically change the behaviour compared to 1.0,
… which we are not allowed to be done.

Gregg Kellogg: no, it fails in 1.0, so this is not backward incompatible per se

Dave Longley: +1 to mark as editorial for gregg to markup (also, thanks gregg!)

Rob Sanderson: is it just editorial, or do we need to discuss how it works?

Gregg Kellogg: it should be mostly editorial

Pierre-Antoine Champin: if I set “foaf:knows” to an exotic URI, then redefine “foaf:knows” without an @id, does the new definition inherit the exotic URI, or is it back to what “foaf:knows” resolves to?
… ex: [{"foaf:knows": {"@id": "http://hahaha.org/foo"}, {"foaf:knows": {"@type": "@id"}]

Gregg Kellogg: this kind of redefinition is an anti-pattern, possibly even an attack
… so may be we should consider it as a bug in 1.0 and publish an errata to fix it

Dave Longley: I’m in favour of fixing security issues

Action #2: make an issue for security issue on IRI as term definition (Gregg Kellogg)

Gregg Kellogg: I even think there’s some special logic when the term is an absolute IRI, which we can possibly remove

4.2. Sealing and Order (propose close, no issue)

Rob Sanderson: Link: https://github.com/w3c/json-ld-syntax/issues/153

rubenworks: I was reading the new 1.1 features, including sealing (now renamed protected)
… the example shows a property defined as sealed, then a second definition fails to override it
… but it was not entirely clear to me whether this worked when reversing the order of the definitions
… but pchampin pointed out that the spec reads “prevent further redefinitions”
… may be it would still be good to add an example to make it clearer

Dave Longley: +1 editorial, we’re in agreement

Rob Sanderson: it is mostly editorial

Gregg Kellogg: I think there are already many examples
… maybe a test case would be better here

Ivan Herman: this could be mentioned in the Best Practices document
… I’m always the guy who asks for more examples, but in this case I agree with gkellogg

Proposed resolution: Close #153, no issue, no editorial change needed in the spec. (Rob Sanderson)

Rob Sanderson: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

Gregg Kellogg: +1

Dave Longley: +1

Tim Cole: +1

David I. Lehn: +1

David Newbury: +1

Ivan Herman: +1

Resolution #2: Close #153, no issue, no editorial change needed in the spec.

4.3. @container [@id, @set]

Rob Sanderson: Link: https://github.com/w3c/json-ld-syntax/issues/140

Rob Sanderson: this issue questions the relevance of @container [@id, @set]
… many people have answered, in the line of “it’s a feature, not a bug”

Proposed resolution: Close #140 as a feature not a bug - no need to use it if you don’t want it, and gives consistency (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Dave Longley: +1

Tim Cole: +1

David Newbury: +1

Gregg Kellogg: it is about consistency and orthogonality, despite the lack of use case

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Adam Soroka: +1

Ivan Herman: +1

Resolution #3: Close #140 as a feature not a bug - no need to use it if you don’t want it, and gives consistency

David I. Lehn: +1

4.4. (Not) removing @omitdefault

Rob Sanderson: Link: https://github.com/w3c/json-ld-framing/issues/41

Rob Sanderson: Link: https://github.com/w3c/json-ld-framing/issues/46

Gregg Kellogg: I already closed issues 41 and 46 (framing) which I raised myself

4.5. Keywords / Flags

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

Rob Sanderson: would we have complete parity between keywords and flags?

Proposed resolution: Close #37, only edge cases when there is disparity (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: we have the parity for most of them;

Ivan Herman: +1

Dave Longley: +1

Ruben Taelman: +1

Gregg Kellogg: +1

Tim Cole: +1

Ivan Herman: those were we don’t are edge cases, so I’m fine with closing it

Pierre-Antoine Champin: +1

David Newbury: +1

David I. Lehn: +1

Resolution #4: Close #37, only edge edge cases when there is disparity

Adam Soroka: +1

4.6. Indexing without a predicate

Rob Sanderson: Link: https://github.com/w3c/json-ld-syntax/issues/19

Rob Sanderson: we discussed at the F2F
… there was an action of gkellogg and pchampin to look into it

Gregg Kellogg: I didn’t have time to look into it yet

Pierre-Antoine Champin: me neither

Rob Sanderson: when an item appears randomly in multiple places in the document,
… it would be nice to put this item in a kind of “bucket” where its full description is stored,
… rather than to have to browse the full document to find the random place where the full description is included

Ivan Herman: this is essentially the ‘itemref’ feature of microdata
… copying that mechanism in JSON-LD seems complicated, but maybe not impossible

Dave Longley: sounds like a framing issue, similar to "@anywhere"

Rob Sanderson: this is not only related to framing, you need something in the context as well

Gregg Kellogg: this is indeed very much like ‘itemref’
… my concern is that it will be complicated if we want to ensure round-trip (compaction/expansion)
… like we do for other features
… that could be done using default and framing, but seems like a very complex solution

Dave Longley: we do have special keywords in the framing compaction algorithm that are treated differently to avoid dropping undefined terms, etc.

David Newbury: is there a way to handle this as a post-processing step?

Gregg Kellogg: the RDFa reference mechanism involves looking in the graph, adding triples and remove triples that were part of the pattern

Ivan Herman: if we do that (i.e., reproduce the RDFa ref mechanism) people will run away screaming
… what we are trying to do is some sort of internal references, essentially relative URIs
… it would still require to define a bush and not a tree, which forces us to use @graph,
… but it might work

Dave Longley: if we consider working in memory, consider @link which is implemented in the Javascript processor
… to ensure that an object is stored only in one place

Gregg Kellogg: the problem is that you would typically create cycles internally
… I’m not sure relative URIs can be used without introducing a level of indirection

Action #3: propose a concrete solution, considering link and nest (Rob Sanderson)

Action #4: propose a concrete solution, considering link and nest (David Newbury)

Gregg Kellogg: if we are moving towards better support for streaming profiles
… we can’t rely on in-memory storage only
… You would need a lot of bookkeeping to handle this.

5. Adjourn

Rob Sanderson: next week, we will talk about the Primer / Best Practices document

6. Resolutions

7. Action Items