JSON-LD Working Group Telco — Minutes

Date: 2019-06-21

See also the Agenda and the IRC Log

Attendees

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

Regrets: Ivan Herman

Guests:

Chair: Benjamin Young

Scribe(s): Dave Longley, Benjamin Young

Content:

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

1. Approve last week’s minutes

Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-06-14-json-ld

Benjamin Young: +1

Dave Longley: +1

David Newbury: +1

Ivan Herman: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Resolution #1: minutes from last week approved

2. Announcements / Reminders

2.1. call (or not) on July 5th

Rob Sanderson: A point that came up for a different call, … July 4th falls on a Thursday, I anticipate that many folks in America will be taking Friday off.
… I was wondering if we could do a quick straw poll this week to see who will be available on Friday. If not enough people will be there we can cancel in advance

Gregg Kellogg: +1

Rob Sanderson: +0

Ivan Herman: +1 :-)

David Newbury: -1

Benjamin Young: -1

Dave Longley: +0

Pierre-Antoine Champin: +1

Benjamin Young: It might be worth reviewing the horizontal review status and getting those sent out if they aren’t already.

Rob Sanderson: I have sent out requests to privacy and security but haven’t heard back yet.

Ivan Herman: I’ve made a first step on the i18n one.

Rob Sanderson: I’ve gone through the a11y one but only one question that matters.
… I think we’re up to date until we hear back now.
… Let’s cancel the call on the 5th.

Resolution #2: no call on the 5th

Benjamin Young: Fine by me.

Ivan Herman: i18n review draft -> https://github.com/w3c/json-ld-wg/wiki/I18N-review

2.2. TPAC registration is open https://www.w3.org/2019/09/TPAC/ Early bird pricing ends June 22 (that’s tomorrow!)

Benjamin Young: TPAC registration price goes up after tomorrow.
… We are on for TPAC and Rob has gotten call in data/requested it, so there will be remote participation. Only a few of us will be in person.

Pierre-Antoine Champin: Wanted to make sure the days for the WG meeting are fixed.

Ivan Herman: Yes, Thursday and Friday.

Pierre-Antoine Champin: Trying to make it.

Ivan Herman: If you plan to come, one trick is to fly via Seoul, not Tokyo. Tokyo might make you change airport and it can add 5 hours.

3. Issues

3.1. Consider context by reference with metadata #108

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/108

Ivan Herman: also: https://github.com/w3c/json-ld-syntax/issues/174

Benjamin Young: This is about a more advanced context object that includes referencing other contexts with meta data for a whole host of issues. Most recent use case is around setting propagation.
… Rob you were the last to propose some things.

Rob Sanderson: At this point I think we need this particular pattern. Of the proposed colors for the bikesheds, @src seems to convey the appropriate semantics. It’s not necessarily a link/href, @context and @id would make for a lot of overloading that would maybe cause confusion.
… @import isn’t too bad but pchampin indicated why it may not be ideal.
… It seems to me like a reasonable way forwards, assuming, it’s implementable and unambiguous.

Gregg Kellogg: I guess my concern about @src is … one is that we don’t typically use abbreviated keywords in JSON-LD, @source might solve that. The other thing is that my familiarity is similar to href like in HTML where it doesn’t provide for an inline option, if we wanted to allow for those there which would sort of make sense. @import seems a little more unambigious.

Pierre-Antoine Champin: Regarding what Gregg just said, I think you have a point, indeed. I wanted to ask about the use cases, I realized after making those proposals, we might not cover one of those. We reactivated this issue about the idea that parameters could be added to this context, to allow this context to propagate/not propagate.

Rob Sanderson: Reference: The propagate case - https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-497809905

Pierre-Antoine Champin: For this use case we might want to do this with a URL reference or an embedded @context. Meta data is always about a referenced context not one that is directly embedded. Does that cover all our use cases.

Benjamin Young: Good flag to raise.

Ivan Herman: It’s very close to what I wanted to ask. I’m not completely sure what we’ll use it for apart from the fact that it looks nice.
… There are things like sealed and SRI that came up but we’re not talking about that anymore. What are the use cases we want to use it for?
… Btw, ‘src’ is in use for the image URL in HTML, very close to href.

Rob Sanderson: I wanted to ask the same question, do we really want to/need embedded contexts here or external sufficient? I don’t know why you would use an embedded one.
… If it’s only for reference, @src is ok, but what’s the use case for embedded.

Gregg Kellogg: I think we might want to constrain ourselves to a keyword that references an external resource about which we might assert some meta data. Rather than keeping it open about importing several things – which of them are we asserting things about, as well as an embedded case. There’s no use case for that, only some notion of uniformity to allow that.
… Now it starts looking overly generalized. If we need a way for a context to reference another one with the semantics that that context is imported into the referencing context that would also allow some room for asserting information about the referenced context, that is a narrow solution which addresses that use case.

Rob Sanderson: +1

Benjamin Young: Roughly like what Rob just posted in chat.

Gregg Kellogg: In which case @source is ok, want some consistency.

Rob Sanderson: Suggested syntax example: {"@context": [{"@src": "http://.../context.json", "@propagate": false}, ...] }

Ivan Herman: I must admit that I didn’t even consider having this embedded. Rob would you want to comment … a question I have is are we sure this is the only property? We don’t have any other meta data properties to define in 1.1 so far?

Rob Sanderson: I don’t think so, this is the only one we have so far @propagate.

Ivan Herman: I’d like to be sure this is the right solution.

Pierre-Antoine Champin: Just to be clear, I was not trying to generalize or over generalize, I was just pointing out that as Ivan and Rob pointed out … @propagate is what we unearthed this issue. When I think about it, it makes sense to use it on an embedded context. It started with scoped contexts, most of the time those are embedded.
… Is @source really a solution to the problem we were trying to solve?
… My personal answer would be “no it’s not” and maybe we reopened the wrong issue to solve that problem. This mechanism as we envisioned it is more about referenced contexts, not embedded ones.

Rob Sanderson: I think it is still the right thing to reopen. If it’s embedded we don’t really need this pattern at all.
… You could restructure your context to do things differently.
… When you want to reuse an external context, then you need to say whether or not the terms of that context propagate or not.
… If it’s embedded you just set it and you’re done.
… When you pull in another context, like a 1.0 from Annotations, it assumes something that isn’t intended and you need to change it.
… I think the case is an external context and it should not have the default propagation value.

Gregg Kellogg: If it’s within a type then type contexts don’t propagate.

Rob Sanderson: Right and this is to change this behavior so it does.
… Yes, it’s to fix the impedance mismatch between 1.0 and 1.1.

Ivan Herman: I am a little bit lost. What I would propose is that somebody comes up with text, possibly a PR that defines this syntax so that it’s clear what it is. Defines its usage with propagate and what that means. I’m a little bit lost. Having something specific written down would help.

Gregg Kellogg: So I think my confusion is that I recall the discussion about this … as wanting the ability to reference an external 1.0 context where we’d have to have @version specified within there. You can’t update the referenced context to do that.
… If that is one of the use cases .. the other use case is to override the propagation behavior of type-scoped behavior. Not sure how it does that cleanly. Not sure how this relates to the type-scoped propagatability without something more explicit.

Rob Sanderson: This is the issue that we discussed a couple of weeks ago now. Where, it’s the combination of the 1.0 and the type-scoped context where it really matters. Because 1.0 contexts are defined without the notion of type-scoped contexts or propagation then they’d never be written in such a way that it’s prevented because it’s not possible in 1.0.
… When type-scoped contexts gets prevented in 1.1 we need a way to override that for 1.0 and potentially for 1.1.
… That would be a useful side effect I think to be able to do that.
… The referenced context might be defined without any notion of type scoping at all.
… If you want to include it in a way that is compatible with the rest of your constructions which would be propagating or not – you’d want to make sure it was interpreted consistently.

Gregg Kellogg: I think there’s a bunch of use cases that need to be considered about what the effect is. Does this include the use of a @propagate keyword or not? In one example – an embedded context that references another one and that includes @propagate: false, is that keyword in play and if not, what are the behaviors?
… If you reference a 1.0 context does that change the behavior?
… I think we need test cases for what the expected behavior is.

Rob Sanderson: I’m happy to write up in the issue in 108 rather than in the propagating one … a proposed syntax and the proposed functionality.

Gregg Kellogg: I think part of that functionality is … if I have a context that defines things and it references things as a source, what is the order of processing. Presumably the point is to process @version bits first but can it override term definitions and what’s the effect on language, base, and vocab.
… The result sort of considered an atomic context such that if it did adhere to some type-scoping or partial type-scoping behavior, does part of it go away, some of it, those are the things I need to understand.

Rob Sanderson: Dave … the propagation point was from VC … what was the expectation?

Dave Longley: for external would behave in the same way as external ones would today
… the context would only apply to the type
… and it would follow property scope behavior
… so their should be consistency with how things happen today

Gregg Kellogg: Good.
… If properties within a type-scoped context, they propagate only if used.

Dave Longley: Yes.

Action #1: write up proposed syntax and functionality for @src/@propagate (Rob Sanderson)

Rob Sanderson: Unless the propagate flag is set to true.

Gregg Kellogg: There seem to be two different concerns, one is embedded contexts and the other is propagation.

Rob Sanderson: Yes, we’re complicating it. But I don’t think there’s another solution.
… We need something like this… the other option is to always propagate but then that’s what wont work for the VC folks.

Gregg Kellogg: The other option is to have a type-scoped context that sets propagate to true and then it’s not removed when we go out of the node object. If we have referenced contexts then it’s as if that context were inserted through some process into the referencing one.
… Well, what is the effect of property scoped contexts on embedded contexts?
… What is the effect of @propagate on property-scoped contexts or referenced contexts.

Pierre-Antoine Champin: If I understand correctly, that’s the kind of thing Rob is planning to do.

Rob Sanderson: Yes, exactly.

Pierre-Antoine Champin: I want to use the original JSON-LD 1.0 annotation context as a type-scoped context, but since it assumes propagation, I want a way to override the type-scoped behavior which is not to propagate.

Rob Sanderson: If there is some other way to do that, that’s perfect, totally fine to do that.
… I don’t understand how they are completely orthogonal, then we don’t need @source.

Gregg Kellogg: I think you need @source because you need to be able to pull in the definitions from an external context so that you can assert 1.1 types of things about it.
… I follow that.
… I can see that you might use @propagate true on one that doesn’t reference an external source and you use @source because might want to assert things about that context like SRI.
… For your use case you need both of these bits but their behavior is … we could create test cases that explore the various different uses and test cases for external referencing, and we should have a test case that combines the two. Largely their impact is orthogonal.

Rob Sanderson: I think we’re in violent agreement.

Pierre-Antoine Champin: Here’s an idea. The problem seems to come from the fact that you’re trying to use the Web Annotation context in a place where it was not designed to be used. It’s a 1.0 context. There are not scoped contexts, only local ones, no scoped ones.
… In a way it makes that it doesn’t quite fit in this position. Wouldn’t a solution be to have a dedicated version of the Web Annotation context that would be appropriate to be embedded as a type-scoped context?
… Maybe the solution is not to change the spec but to change the context that you use in this use case?

Rob Sanderson: But to go back to the definition of @propagate can we say on an @type, @propagate true?

Gregg Kellogg: Yes.

Rob Sanderson: If we anticipate that the major schemas that are in use via context referencing… annotations would be one, schema.org etc. … if they are going to go to 1.1 and they can set propagate or not that would be one other way to do it.
… It could be defined locally somewhere until they do. But yeah.
… It seems a bit of a stretch to say that if you want to use this 1.1 feature then because of this weird rule that type-scoped contexts don’t behave like property-scoped contexts that you can’t use any of the 1.0 contexts.
… The flip side would be that @propagate true is the default and then 1.1 contexts that want to turn it off can set @propagate: false.

Ivan Herman: How many contexts are we talking about that are really widely known and would have to be updated in this sense?
… What are talking about? We are hearing about two or three possible contexts right now, which is just peanuts.

Rob Sanderson: I’m not sure that we know, I would say schema.org, annotations, maybe ldp.

Ivan Herman: schema.org might not be easy to change, but the others are peanuts.

David Newbury: Is it everything that has included those that also have to be updated at this point?

Rob Sanderson: Assuming that there’s a different 1.1 context I think that’s ok, you’d reference that.

Gregg Kellogg: I think it’s dangerous road to assume that we know the impact of all the contexts that are out there and the solution is to just update those contexts. Particularly if it requires that they adhere to 1.1 and the toolchains don’t get updated immediately after we release the spec.
… Maybe the safest thing is to change the semantics to allow the propagation semantics to default to true but allow for false.
… It allows that propagate to be used in other contexts as well. I think there’s a use for referencing to be able to do things like that, but you might want to use a 1.0 context and not have it propagate. Then you’d use an envelope with @propagate but then no weird stuff.

Benjamin Young: Rolling out your contexts and managing multiple versions is an ambient concern. I don’t mean to derail your conversation. Our smaller more tightly knit communities aren’t going to face this as badly. But any of the ones that are actually doing deployments of other people’s vocabularies are going to be up a creek.
… I’m not sure we yet have any vehicle to help them survive. This is taking them to another level, incompatibility concerns.

Rob Sanderson: This would be an argument in favor of having the default to be to propagate rather than to not propagate?

Benjamin Young: It may not really even matter because of the way we’ve used versioning it doesn’t really matter.
… As soon as that gets stuck into anything you will have to shift to supporting two different ecosystems.
… We’ll have that for an unknowable amount of time.

Rob Sanderson: In terms of the VC side of things, requiring the context to turn off @propagate a hardship?

Dave Longley: so, VC spec goes into PR on Tuesday
… everyone has written their tests against the context that does not use @propagate false
… so that would be the main concern
… it’s a major timing issue
… if we miss PR, the VC spec would fail
… the other features from 1.1 don’t compose
… so…it’d be strange to have things not work and then have to go find the @propagate term to make things work
… it seems to me that once you pull in a 1.0 context
… that’s been interpreted in a 1.0 scenario
… folks will have to be ready for the meaning changes
… if they’re processed both as 1.0 and 1.1
… I understand the desire to make them play nice
… but I’m not sure about what we’d give up to keep that happening

Gregg Kellogg: I’d say maybe the way forward is to add a @propagate keyword which changes the behavior of the context it’s in to not survive the node object it’s used within, but we don’t the default behavior for type-scoped contexts. We can add @propagate: true to allow to survive or @propagate: false on a property-scoped or embedded context to allow it to be removed. It gives us the ability to not mess up the expectations of VCs.

David Newbury: A lot of the @propagate: true/false default is whether you’re coming from a programming background or a JSON-LD background.

Rob Sanderson: What about if 1.0 contexts were treated that all had an implicit @propagate: true on them.
… When a 1.0 is imported, all of the classes in that context are treated as if they had @propagate: true defined on them because that was the expectation.

Pierre-Antoine Champin: are we taking { "@context": { "Foo": {"@context": { "@propagate": true, ... } } } or { "@context": { "Foo": {"@context": { ... }, "@propagate": true } }

Pierre-Antoine Champin: I’m not sure Rob’s suggestion. The difference is subtle – is the @propagate flag supposed to occur in the context or next to the term definition.

Gregg Kellogg: Inside the context.

Pierre-Antoine Champin: I don’t understand Rob’s position then.

Rob Sanderson: The primary mismatch is that between contexts defined in 1.0 days, there wasn’t any scoping, once defined it’s always true. That remains true for property-scopes but not for type-scopes. In 1.1 we want to be able to override that default. We want to be able to have it be explicitly set so a particular class does propagate.
… The issue then is … a 1.0 context where it’s not a valid keyword, how can we have propagation be true. Given that the expectation in 1.0 was that everything propagated, that when a 1.0 context is imported, we should assume that there was a flag that propagate was set to true for that context. We don’t have to put it into the referring context – if that was just the way that it always worked. If you want to have a 1.1 context that imports

Dave Longley: other contexts with propagate false then that’s fine you don’t have to set anything.

Rob Sanderson: It would matter if you want a 1.0 to come in and not have it propagate.
… But that seems even more marginal than the inverse.
… I don’t think we need @source at all if we do that. We can just define @propagate with the notion that a 1.0 context acts as if it is true.

David Newbury: This would need a very big explanation note somewhere because I don’t think anyone pays attention to @version and having things operate differently seems very confusing.

Benjamin Young: And the fact that the same context could change its version under the hood changing how it propagates.

Ivan Herman: +1 workergnome

Gregg Kellogg: I’m concerned about that too and it’s possible to use 1.1 features without saying @version in the context.
… Trying to infer things after the fact that we do things differently I think is fraught. I think solution is to be explicit in the wrapper and to set propagation in the referencing context.

Ivan Herman: I am acting now as administrator because the minutes will be confusing, I have the impression we’re discussing 174 but started with 108. I would add the comments on both of them, and I’m not sure where we are.
… Administratively I think 174 is just being reopened now.

Benjamin Young: I think where we are – this will be the topic that we discuss next week and I’ll send out the same agenda.

Gregg Kellogg: Please add the issue that I referenced, number 9.

Ivan Herman: Can someone come up with a proposal we can follow and read?

Rob Sanderson: I’m happy to write up a proposal for the use of external references with an @propagate flag.

Benjamin Young: Thanks everyone, apologies for going past time.

4. Resolutions

5. Action Items