JSON-LD Working Group Telco — Minutes

Date: 2019-02-01

See also the Agenda and the IRC Log

Attendees

Present: Benjamin Young, Gregg Kellogg, Dave Longley, David Newbury, Simon Steyskal, Rob Sanderson, Ivan Herman, Jeff Mixter, Adam Soroka, Harold Solbrig, David Lehn

Regrets: Pierre-Antoine Champin

Guests:

Chair: Benjamin Young

Scribe(s): David Newbury

Content:

1. Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-01-25-json-ld

Benjamin Young: +1

Benjamin Young: Time to approve the minutes.

Proposed resolution: approve minutes (Benjamin Young)

Benjamin Young: +1

Gregg Kellogg: +1

Dave Longley: +1

David Newbury: +1

Rob Sanderson: +1

Simon Steyskal: +1

Ivan Herman: +1

Resolution #1: approve last week’s minutes

Benjamin Young:

2. Face to Face - Feb 7 & 8

Benjamin Young: next topic, Face to Face!
… note that the location did Change to the Folger Shakespeare Library, which is in the same area of the national mall

Rob Sanderson: Rob’s double-checking that we just show up at 10 to 9am.

Ivan Herman: should we have IDs?

Rob Sanderson: won’t hurt. I’ll confirm.

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/F2F/2019.02.DC

Benjamin Young: show up at the Folger

Gregg Kellogg: let’s organize a dinner wednesday night.

Benjamin Young: https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit

Benjamin Young: if you’re into that, add your name to the agenda doc and someone will pick a location.

3. Review the F2F agenda

Benjamin Young: https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit#heading=h.1ryfaao4cgcc

Benjamin Young: let’s review the agenda for F2F
… this is based on very rough estimates, but there’s a list of issues to address
… hope you’ve all looked through that, but we’ve talked about them over the past six months
… queue up if you want to add new things to that agenda

Rob Sanderson: +1 to the list :)

Rob Sanderson: note one thing…pretty soon, we’ll need to close the issue list for new features.
… if we’re going to meet august timeframe, we can’t keep adding things.
… if there are things that have come up in your work, get them in now. You’ve got three weeks or so.
… the intent of the f2f is to knock out the big ones like sealed context, contexts with metadata, and things we’ve talked about, but haven’t come back to, circular contexts, unmappped JSON, etc.

Benjamin Young: can we go over the rough timeline for CR?

Ivan Herman: we have to count backwards..the charter goes till June 2020
… we should wait 6,7 weeks, so we should publish a recommendation in May, so the rest is what we think we’ll need to go through CR.
… if you’re not familiar with the Jargon, that’s Candidate recommendation. At that point, no new technical features
… but we need to prove to the world that all features can be implemented by two independent implementations.
… doing implementations, technical issues may come up, so we may have to republish a CR, but hopefully that won’t happen
… we need to think about how much time will we need to generate two implementations.
… ideally, it would be nice to have 3 or 4 implementations. 5, even!
… we should discuss at some point the testing procedure, test suites, reporting, etc.
… this is usually a complicated thing to do
… we are lucky that gkellogg has done this before
… what we’ve said is that to be one the safe side we should be in CR by TPAC in Sept. 2019 in Japan
… that’s a reasonable goal, so we have six months to go through testing
… knowing that there are some implementations, so we’re not starting from scratch.
… for CR to be published in September, taking into account the editorial work, clarity, etc, I would think that we should have things solved or postponed by early mid-summer this year

Benjamin Young: Based on what Rob said, then feature freeze is TPAC?

Ivan Herman: sort of, we need editorial work before hand.

Benjamin Young: That gives us sixish months.
… that’s the target. other questions?

Rob Sanderson: if you could all look through the issues before showing up, it’ll make it quicker to discuss

Gregg Kellogg: we inherited a robust testing structure from 1.0, and we’ve maintained tests, my implementation is tracking them, the primary thing is to migrate that to W3 space so we can get redirect access.

Ivan Herman: is this true for framing?

Gregg Kellogg: framing doesn’t need HTTP magic, but it would still be good to move it to W3 space

Ivan Herman: is the test suite for framing available?

Gregg Kellogg: yes—I bifurcated the tests so they’re in two repositories, but it’s up to implementations to figure out how to run them themselves.
… we’ve got reporting structure

Benjamin Young: don’t we need to move that to W3C testing space?

David I. Lehn: the implementation report: https://json-ld.org/test-suite/reports/

Ivan Herman: the w3c test environment is geared toward testing browser components/features, and may not be suitable for this. We had the same issue with Annotations.

Gregg Kellogg: we’re closer to what’s been used for RDF/Sparql tests
… you can run them off of GitHub now
… for something with a base URI, having a good uri would be nice. But it has nothing to do with the browser test implementations

Benjamin Young: do we go that route, like annotations, or do we move to w3c? We can take it offline, but we should try it out, to encourage early testing

Gregg Kellogg: encourage people to try other people’s software, and ping the implementers who may not have been involved in this process

Rob Sanderson: regarding the list: we haven’t talked about circular imports. What should we do? issue 14. 108, 86…those two are about assertions in one context about an external context?
… if you load schema.org, can you expect a hash for changes
… take various nodes from the graph and put them in a set location (includes), rather than have them show up in various locations via walking the tree
… support JSON values not mapped, includes JSON within a JSON-LD document, not in a string
… these are the ones that are good to do in person
… that means that we should be able to close out all the open issues

Benjamin Young: https://docs.google.com/document/d/11agKfDU1vTjyKBI_ytLBYFChFCqEfFePNVposnmSW_8/edit#heading=h.cuj1fpex2b35

Benjamin Young: I missed the 4 Friday issues, and check out the real agenda items

Gregg Kellogg: something that is related is the ability to reference a context without needing it to be loaded, which in hash link etc address a lot of the usecases
… I didn’t know if hash links addresses Schema.org
… if you assume that what they want to see is no way to change the way that it looks, and the context is the same, without making a lot of more complex things, it seems unlikely they’d want to go there

Ivan Herman: maybe we should try and get Danbri online?

4. Review Pierre-Antoine’s proposal for sealed context processing

Benjamin Young: https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0016.html

Ivan Herman: https://github.com/w3c/json-ld-syntax/pull/119

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/issues/20

Ivan Herman: -> the proposed text for the syntax draft: https://pr-preview.s3.amazonaws.com/w3c/json-ld-syntax/pull/119.html#sealed-contexts

Benjamin Young: API PR https://github.com/w3c/json-ld-api/pull/60

Gregg Kellogg: I can represent pchampin’s issue, since he can’t call in due to internet connectivity problems
… There’s an issue, and discussion in the PR
… the principle issue in #20, and pchamin’s work is around syntax
… basically, he suggests sealing contexts, not terms, though it’s not design limited that way
… and sealing a context, the term definitions are tagged with an identifier associated with that context
… an implementation, for each term def., you know which context it comes from (for sealed contexts)
… so if you attempt to update that within a sealed node, you can only update it if the update is coming from the sealing context
… this would happen for embedded context
… so if I define a term foo, and that context wants to update a term in that context, you can see the terms that the updated terms came from the same context
… that would allow terms defined in other sealed contexts to not interfere
… so you cannot create a term that interferes with a different sealed contexts.
… there is a list of active sealed contexts active during expansion…
… that effectively unseals all the other contexts when processing
… if you were to descend into another property not associated, that would have the effect of unsealing all contexts.
… if you use a term from a context, even if it’s unsealed, you now enter a mode where the context is sealed.
… what this means for sealing contexts or terms, since you’re tagging the context info per-term, it seems straightforward to do that per-term. There is no support for sealing part of a term, say the ID, but not the container
… no use cases

Rob Sanderson: does the seal ID need to be different than the context ID? is it specified explicitly?
… does this mean that the top context might be sealed, but an embedded one might be unsealed?

Ivan Herman: he also put a text into the syntax document which describes things and makes it clear and easy to understand
… there was also an issue: what happens if you do something that is not kosher? one possibility is a warning and you ignore, the other is to throw an error
… and some of the examples will change based on that answer. It’s a decision

Benjamin Young: This felt a lot like one context being last
… it would be super if we could have our use cases written up, both verifiable claims and web of things
… have use cases

Dave Longley: I am thinking about this and reviewing it, and looking at it, I’m not sure how it would impact caching of active contexts.
… I haven’t thought through how it works…can we keep track of an ancestry tree?
… whatever we put in the spec, whatever matches the output, it’s OK. Still thinking through it

Ivan Herman: I am worried that what’s described is an implementation strategy, not a requirement for a spec

Rob Sanderson: +1 to Ivan

Ivan Herman: we should make sure that we don’t define the process, but instead what we need to have as normative

Dave Longley: +1 to Ivan

Ivan Herman: informatively, we can put in examples. What counts is the test cases

Benjamin Young: we currently don’t track term overriding and who overwrote what in what order

Dave Longley: +1 … that would be a helpful tool

Benjamin Young: so if you have two contexts and one overrides it, there’s no awareness of that in the code. So in a context dev, and to keep sealing in, it would be helpful to know what happened and in which order. that could clear a lot of confusion

Gregg Kellogg: My feeling tis that we’ve been overly prescriptive to ensure interoperability
… embedded contexts cerate a new ID and inherit from the one embedded
… so I think we need to try and describe that in a way that stays as close as possible to the behavior, and the mental model has to be described in the syntax doc to understand orders of operations
… but adding more complexity threatens to degrade performance

Rob Sanderson: in the proposal, does that include externally referenced, but scoped contexts? So if I had a doc that had sealing at the top level, and I scoped in schema.org within a term, would that then seal schema.org?

Dave Longley: {"@context": {"sealed": true, "foo": {"@context": "http://schema.org"}}}?

Rob Sanderson: does that seal by reference schema.org? if you had it as an externally reference, sealed context.
… what dave said in the chat
… what happens?

Gregg Kellogg: my feeling is that scoped context is not explicitly sealed. So, no. schema.org would not be sealed in that example.
… what you need to know is there is a reference, and we might restrict that to being things in a local/embedded context, have the ability to affect things that were defined in the outer context, but not implicitly sealed
… does the sealing act valid for everything, or are there parts like vocab that are not sealed?

Gregg Kellogg: three top-level directives: version, vocab, language, and base
… context is not a member of a context, it’s a member of a term definition

Dave Longley: i’ll just say — my view of “sealed contexts” is that someone made a specification for a bunch of terms (a “sealed context”) and JSON-only devs will read that spec and apply the rules therein — not running any JSON-LD processing after that… and we should consider how sealed contexts according to that line of reasoning.

Gregg Kellogg: the body is an object that contains term definitions, default vocabs…a term definition can itself be sealed, and if that includes an embedded context, and if that’s sealed, then the context that it defined in not implicitly sealed
… I can’t update the context with a new context…otherwise the use of context within a context is in the document, and….
… . too many uses of the word “context”.

Dave Longley: so if we want to allow people to write specs that say: “everything under this term will use schema.org’s context” … that’s what JSON devs would expect, no changes

Dave Longley: we could of course, require those spec writers to redefine all those terms manually if need be

Benjamin Young: the top level directives…is it imagined that those would be sealed?

Gregg Kellogg: we don’t seal base, vocab. if you want to seal, seal a term. if the default vocab is schema.org, and can’t override it…

Dave Longley: the main use is a spec, like W3c, and they’re defining terms in the spec, and will provide the context, and will only apply the rules in the spec.

Rob Sanderson: I agree with that too, but then to me it’s going to be clearer if the individual terms are sealed, rather than the terms defined in a context that’s sealed, but other features (e.g. base and vocab) are not sealed in that context

Dave Longley: first, you’re using JSON-LD to enable extensibility and semantics. that means that you want other terms to be created.
… so I think that losing .vocab won’t work. Sealed contexts should not be constrain things not defined.
… we should think of how they should behave within that domain.
… if we want to figure out how it should work, we should think about it in the context of a spec–if there’s a term not in the spec, you can ignore them.
… none of these term definitions will change. If you’ followed the path in the spec, nothing will change.
… that’s what the feature should guarantee
… everything else is outside of what people who care bout JSON will care about.

Benjamin Young: +1

Dave Longley: think about this domain through the lens of JSON-only developers

Rob Sanderson: Also +1

Ivan Herman: what would happen if Schema.org sealed that context?

Dave Longley: all that would happen is that the terms wouldn’t change.

Ivan Herman: using schema.org, some of the terms are underspecified. So what we do is add our own context that defines, with the same URL, we add additional constraints to the term.
… this would prevent this

Dave Longley: if you’re redefining these terms, this would lock that possibility.

Ivan Herman: even if I use the URL, but I specify the type..

Dave Longley: that’s a separate issue, but an important one

Ivan Herman: this happens a lot with schema.org a lot. Often I want to make them more precise

Benjamin Young: maybe, given large vocabs, sealing many terms, this maybe an API thing, but not a syntax thing? Can the processor seal/not-sealed to create a processor that says that this context is sealed
… but the developer chooses
… and then these terms are sacrosanct
… these are the terms my processor must understand

Gregg Kellogg: echoing ivan, schema.org author: Values are expected to be an org or person, but that’s defined without a type. JSON-LD processor will allow a string value there

Dave Longley: i’ll just say that’s interesting (doing this via an API mode/flags) Benjamin … and worth considering further.

Gregg Kellogg: not a URI.

Dave Longley: interesting, but i don’t think will work :)

Gregg Kellogg: that’s a case for updating it for author is explicitly a URI.

Rob Sanderson: +1 to dlongley, agree it needs to be syntactic

Dave Longley: a good idea, but there will be people who won’t know to read the spec and flip on the flags. it needs to be in the data.

Benjamin Young: we’ll see you in a week or less. look through it, add your notes, etc.

5. Resolutions