JSON-LD Working Group Telco — Minutes

Date: 2019-05-31

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Gregg Kellogg, Ruben Taelman, Rob Sanderson, David Newbury, Dave Longley, Benjamin Young, Harold Solbrig, tim cole, David I. Lehn, Pierre-Antoine Champin, Adam Soroka

Regrets: Jeff Mixter

Guests:

Chair: Rob Sanderson

Scribe(s): David Newbury, Benjamin Young

Content:

1. Approve minutes

Rob Sanderson: First thing: minutes!

Proposed resolution: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-17-json-ld (Rob Sanderson)

Rob Sanderson: +1

David Newbury: +1

Ruben Taelman: +1

Benjamin Young: +1

Ivan Herman: 0 :-)

Harold Solbrig: +1

Gregg Kellogg: 0

Dave Longley: +1

Resolution #1: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-05-17-json-ld

2. Announcements / Reminders

Rob Sanderson: the registration for TPAC is open, and it’s earlier than normal
… we’re intending to have a meeting, unless there’s a lot of progress.

Gregg Kellogg: I can’t come, due to other commitments
… and will be unavailable next week

3. Issues

3.1. Type scoped context continued; property wildcard

Rob Sanderson: link - https://github.com/w3c/json-ld-syntax/issues/174

Rob Sanderson: what is the difference between type scope contexts and property scoped contexts. Is it scoped to the properties of that class, and other thought of it as a replacement for an inline context, and would then expand beyond that class.
… where we came to last week is that there are good use cases for both, but the only way to allow for both use cases is to have type scoped contexts be class-only, and to have a way to expand beyond them by setting a default context within.
… is that sufficiently detailed to explain where we are right now?

Gregg Kellogg: I didn’t quite understand until right now. I’m trying to think of the syntax

Dave Longley: my understanding is that what we’re looking for is to take this other context and define it within this scoped context, and then use it for all properties within that scoped ontext
… We want to be able to reuse existing contexts within a type-scoped context, so we don’t have to be verbose typing out all of those contexts again.
… syntactically, we can currently do this by re-writing all contexts within each of those properties, but that’s verbose.

Rob Sanderson: Example use case: https://preview.iiif.io/api/image-prezi-rc2/api/presentation/3/context.json type scopes in http://www.w3.org/ns/anno.jsonld for Annotation and AnnotationPage

Ivan Herman: so, if I want to have all schema properties valid within that type-scoped property, and to inherit, and do it by including the schema context file, not each property inline.

Rob Sanderson: an example: we’re using type scoping within annotations to pull in the annotation context, which is a 1.0 context, and since the decision is that the annotations referred to would no longer inherit, and so this would need to be modified with a new keyword to maintain this behavior instead of retyping each property for each context

Ivan Herman: so we want hasBody to remain an annotation?

Rob Sanderson: we want the resource that is pointed to by that property to be an annotation, even though that annotation context is only valid on that class

Gregg Kellogg: I understood that this could be for specific properties, but I thought of wildcard as applying to all properties
… for instance, if you’re traversing to FOAF, you might not want to continue to use schema.org properties
… syntax and wildcard: we could use full wildcarding or or something like a URI prefix
… but then what happens when they have contexts defined? I presume they’re honored as well
… how deeply have we thought about the various cases
… and would it be a property of the propriety term definition, or a propriety of the class that the class term definition that then defines those terms?

Rob Sanderson: we had not talked about globbing or real wildcarding: we’d talked about a shorthand for not retyping all properties within that context.
… you would then need to define all schema.org contexts for every class that below need to apply
… the question is at what level does the wildcard apply? Is it at the ontology level, or is it at the context level?
… we’d talked about it at the context level, which is consistent with how other things work

Gregg Kellogg: expanding treats properties as terms, not expanded URIs, and compacting we select terms by matching, not via URI. Enumerating properties by terms, not URIs, is more consistent with how we do things currently

Rob Sanderson: some solution that says, for all the terms within this context, treat them as property-scoped within this class
… like what dlongley put in the chat: for all properties, treat them as property-scoped contexts.
… which then wouldn’t need actual wildcarding, just matching
… which seems easier

David Newbury: I’m wondering if this doesn’t suggest that @type scoping itself could be clearer and provide the approach to inheritance that people are expecting here

Rob Sanderson: could we just have two keywords, one for each behavior?

Dave Longley: I don’t know if it’s exactly the same, because comparability differs here.
… when we pull them in, we treat them all as if they’re property-scoped terms, which is different than the behavior before.

Dave Longley: +1 to something along the lines of what gregg is saying

Gregg Kellogg: I think that if we have a property that can appear in a type-scoped context that says that all terms within that context inherit that context, or perhaps enumerated terms inherit, and in the absence, no terms inherit, and then it could not appear only on type-scoped contexts

Dave Longley: I think that we’re thinking that each one of these contexts would then consider the type scoping as if it were defined on all descending properties

Gregg Kellogg: and it would be recursive–this would then travel down the property chain

Dave Longley: yes

Gregg Kellogg: unless that property redefines its own scope
… that seems reasonable

Rob Sanderson: can we see a straw person example?

Gregg Kellogg: @inheritPropertyScopes: true

Gregg Kellogg: @inheritTypeScopes: [‘a’, ‘b’]

Gregg Kellogg: do those terms need to be defined within that scope, or do they just need to have been in scope at the time it’s interpreted?

Rob Sanderson: that would not work for our use case, since the properties of the annotation are not known higher-up the chain

Dave Longley: processing: do you see if it appears up higher to see….(lost the chain here)

Gregg Kellogg: I think your use case would be solved by using true

Rob Sanderson: correct.

Dave Longley: when defining a term within a type-scoped context, look for @inheritPropertyScopes

Dave Longley: and if that appears, add a property-scoped context to the term definition

Dave Longley: (unless one already appears, as that one would take precedence)

Gregg Kellogg: we should come up with a better name

Rob Sanderson: in our case, at the high level, our use case is…

Rob Sanderson: { 'Annotation': {"@id": "oa:Annotation", "@inheritPropertyScopes": true, "@context": "http:...anno.jsonld"}

Pierre-Antoine Champin: @propagates ?

David Newbury: @descends ?

Rob Sanderson: we can then just update the 1.1 context

Benjamin Young: This is pretty ugly, but I think we can make it prettier. Do we use that case anywhere, and you will really need to understand the plumbing to make this understandable.

Gregg Kellogg: @propagates +1

Benjamin Young: we’re really going to need a primer.

Dave Longley: @propagate: true|[terms] seems ok

Benjamin Young: the more we can reduce that cognitive pain…we need something other than reading the spec to explain how this works.

Rob Sanderson: there seems to be consensus around @propagate?

Proposed resolution: Create a new keyword, @propagate, for type scoped contexts which takes either a boolean (false is default) or an array of terms, which when present means that all or the listed terms propagate the context listed as the value of the keyword (Rob Sanderson)

Dave Longley: @propagate “propagates” the type-scoped context as a property-scoped context for all listed terms

Gregg Kellogg: we could consider context as an array, and the first item would be @propagate true. This is getting hacky…we’re pulling on a thread and we can’t stop pulling
… I’m less in favor of this than making it a property of the context itself.
… if it can’t work except this way…
… I think this changes the default…
… and if you want the next one to be false…
… how do you inherit the default again?
… these questions are why I’m not happy with these.

Rob Sanderson: This could be solved with metadata on the context, but we’ve deferred that conversation

Gregg Kellogg: how problematic is it to just refer to it in the context?

Rob Sanderson: it means that we can’t include 1.0 contexts, which is not great.

Gregg Kellogg: you can still refer to them…

Rob Sanderson: for type-scoped contexts, if you want to refer to a 1.0 context, if you want to type-scope them in, you’d need to rebuild those contexts when @property is a property of the context, instead of the referring context

Ivan Herman: Red flag: we were wondering about feature freeze, and we are discussing something here that is not thought through yet, and it’s a long discussion, and it’s practically June
… I am worried here. Protected took two months, and we’re approaching the same place.

Rob Sanderson: the issue is that Verifiable Credentials have assumed one way, and the spec works the other way, so there needs to be a decision one way or the other
… hopefully a solution that works for both.
… we can stick with the spec

Gregg Kellogg: we can do type scope as committed, and without dealing with propagation, or we can remove the type-scoped property…

Rob Sanderson: but that chooses one use case over the other
… we need to deal with the competing use cases
… or revert back to the previous spec

Dave Longley: it doesn’t make the previous use case impossible, just verbose.
… the other way around was literally impossible

Rob Sanderson: consider schema.org, you’d need to enumerate all terms in schema on each property. It’s possible, but implausible.
… a property on the 1.1 context with propagation, and define a 1.1 context, and @propagates : true

David Newbury: does this mean that the writer of this context
… decides whether it propagates up or down?
… wouldn’t that mean the annotations group would need to define two different versions of that context?

Rob Sanderson: yes. that is indeed the case
… which also seems…not ideal

Gregg Kellogg: I think the way to handle this is to set @propagate changes the default to subsequent properties
… we could including contexts judicious…

Rob Sanderson: the ugly version of a list where there are processing flags and contexts within the context definition
… documentable, but not pretty
… and order dependent

David Newbury: do we have a sense of which of these inheritance models is more common?
… at this point it feels like we’ve built in the ability to turn this on or off
… or is that not correct?

Rob Sanderson: I don’t think that we know
… currently, all of the inheritance models are propagate. 1.0, everything does so.
… that implies that propagation is more common, but people coming from object-oriented might think otherwise

Pierre-Antoine Champin: I’m not convinced by this, but…I don’t think this has been considered.
… another keyword for non-propagating contexts?
… remove the flag, make it cleaner

Rob Sanderson: that does seem cleaner

Ruben Taelman: I like the idea, but that might make context even more complicated, but now have two ways to find a context
… is feasible, but complicated

Pierre-Antoine Champin: Just to be clear, I share that concern.
… two keywords for contexts ugly

Dave Longley: it could be a keyword on the type definition instead

David Newbury: .. and I wanted to point out that considering rob’s example, having @context always propagate, and a separate keyword for dlongley’s proposal

Gregg Kellogg: the other thing, considering contexts with metadata, where we had metadata, and that could solve this
… then we could set some of these properties…

Rob Sanderson: two routes: new keyword, context reference metadata

Benjamin Young: 1.0 propagates now, so the default is propagate true. Then what we need is the way to prevent that, and to say that this is exclusive

Rob Sanderson: I would be fine with that

Ivan Herman: here is the issue where this was discussed: https://github.com/w3c/json-ld-syntax/issues/108, with a syntax possibility at: https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-447629312
… there’s a syntax proposal there

Benjamin Young: I see it differently, type-scoped contexts didn’t exist in 1.0 and are a new concept … and scoping “type-scoped contexts” to types makes perfect sense.

Ivan Herman: nobody seemed happy at the time with metadata at the time…if this is the only one we define, it allows others…I would not propose integrity now

Dave Longley: +1 to providing a future hook

Proposed resolution: Un-defer #108 with propogation as the use case (Rob Sanderson)

Rob Sanderson: +1

David Newbury: +1

Gregg Kellogg: +1

Tim Cole: +1

Dave Longley: +1

Ruben Taelman: +1

Harold Solbrig: +1

Ivan Herman: +1

Adam Soroka: +1

Pierre-Antoine Champin: +1

Benjamin Young: +1 (with concerns about scope creep)

David I. Lehn: +1

Resolution #2: Un-defer #108 with propogation as the use case

Rob Sanderson: we should then look at 108 over the week and come up with a proposal for contexts

Gregg Kellogg: it might be good if this were done through more detailed proposals in advance

Rob Sanderson: so, everyone who’s not on a trip, please contribute to the issue
… and it is the top of the hour

4. Misc

Gregg Kellogg: https://github.com/w3c/json-ld-syntax/pull/189

Gregg Kellogg: also, I’ve updated 189 that addresses some concerns
… I’m not convinced it’s the best way to go
… if you’re satisfied with it, though, go ahead and pull it

Rob Sanderson: o.k. Greg and I will look at it asap
… thanks everyone, and we’ll talk again in a week!

5. Resolutions