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
- 2. Introductions
- 3. Announcements/ Reminders
- 4. Issues
- 5. Adjourn
- 6. Resolutions
- 7. Action Items
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
- Resolution #1: Approve Minutes of Previous Call - https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-22-json-ld
- Resolution #2: Close #153, no issue, no editorial change needed in the spec.
- Resolution #3: Close #140 as a feature not a bug - no need to use it if you don’t want it, and gives consistency
- Resolution #4: Close #37, only edge edge cases when there is disparity
7. Action Items
- Action #1: facilitate decision by July 1 for TPAC (Rob Sanderson)
- Action #2: make an issue for security issue on IRI as term definition (Gregg Kellogg)
- Action #3: propose a concrete solution, considering link and nest (Rob Sanderson)
- Action #4: propose a concrete solution, considering link and nest (David Newbury)