JSON-LD Working Group — Minutes

Date: 2019-05-17

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Simon Steyskal, David Newbury, Benjamin Young, Dave Longley, Jeff Mixter, David I. Lehn

Regrets: Ivan Herman, Ruben Taelman, Pierre-Antoine Champin, Tim Cole, Adam Soroka, Gregg Kellogg

Guests:

Chair: Rob Sanderson

Scribe(s): Benjamin Young

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-05-10-json-ld (Rob Sanderson)

Rob Sanderson: +1

Dave Longley: +1

Benjamin Young: +1

Simon Steyskal: +1

David Newbury: +2

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

2. Announcements

Rob Sanderson: I sent the notification about TPAC registration being open
… currently we’re scheduled to meet
… if everything goes very smoothly
… we might not meet
… but we’ll know closer to the time
… any other announcements or reminders?

3. Issues

3.1. Type-scoped contexts: https://github.com/w3c/json-ld-syntax/issues/174

Rob Sanderson: dlongley the first one of timeliness for you is type scoped contexts
… would you like to summarize?

Dave Longley: I went to use type scoped contexts to create the Verifiable Credentials context
… but immediately hit issues
… these actually bleed beyond being scoped to a particular type
… I fixed our implementation…and gkellogg fixed his implementation
… this issue is about fixing the text to match the implementations

Rob Sanderson: so what you’ve described definitely sounds like a bug
… it shouldn’t bleed outside of that type
… so, because name is defined in Person, it’s scoped to Person
… but you can also have name in Library and have that be scoped to Library

Dave Longley: right, but if you combine them, then you get a clash of terms
… if you put protected on these things in the next example
… you would be told that there were issues…when in fact there aren’t
… this is more like a bug that is revealed by protected
… so if you had also used some other terms that you intended to be dropped, those would get picked up by Library terms

Rob Sanderson: right. without Person being in the hierarchy

Dave Longley: even if it were there
… if you had them nested, and had terms you wanted dropped, if that same term is defined earlier, it remains defined
… so the Library terms don’t stay within Library, they bleed out

Rob Sanderson: well…that sounds like what I’d expect, actually

Dave Longley: so, for property scoped contexts
… but for the type scoped contexts, it’s more like object oriented expectations
… so you don’t want unrelated contexts showing up in unexpected places
… property scoped terms are different
… those stick around
… the property scoping works as expected
… but the type scoping shouldn’t behave like a property scoped context

Rob Sanderson: so the situation we have in IIIF.io is…
… we use ActivityStreams properties
… which are very very broad…like items
… it’s the same JSON key and RDF property
… it’s just, “here’s the things in this list”
… but at various places in the tree, the items are of various types
… so when you get to an Annotation, you then need to use type scoping to deal with that change
… so we’d need it to re-re-redefine its terms to deal with this change

Dave Longley: you can put a property scoped context inside a typed scoped space

Rob Sanderson: what happens when those continue into an @container: @list scenario
… so, for example, you can have collections, which either contains collections or things
… so a tree, or leaf nodes
… so trees get one context, and leafs get another
… how would that not collide
… I assume you’d use type scoped?

Dave Longley: it’s OK to use type scopes
… your concern is that using type scopes don’t travel down the branch

Rob Sanderson: yes. specifically when there are 1.0 contexts

Dave Longley: when you use type scopes, you can choose which path is traveled down
… you can say in TypeA use this context, and then within these properties use that other context

Rob Sanderson: 1.1 context for IIIF - https://preview.iiif.io/api/image-prezi-rc2/api/presentation/3/context.json

Dave Longley: one of the goals is to deal with ActivityStreams scenarios specifically using protected for use with non-JSON-LD processors using ActivityPub

Rob Sanderson: in that example, there are typed contexts which should be overridden further down
… like below Annotation, there are further nodes
… what is the context there?

Dave Longley: if the only thing that’s bringing in the context is this type scoped context
… that context will get removed if you move on to something that is not scoped to the same thing
… like an ordered collection or something
… they’ll need to define their own
… or use the earlier one

Rob Sanderson: that’s not what 1.0 would say

Dave Longley: well, 1.0 didn’t have typed scoped contexts at all

Rob Sanderson: there doesn’t seem to be a solution for this particular case

Dave Longley: well, there is a solution, which is to say for those properties, you can
… if you want every single property in an AnnotationCollection, then you’d need to use that via typed scoped contexts throughout the collection

Rob Sanderson: but given that most of these contexts are just the properties
… you’re doing an awful lot of rewriting with that approach

Dave Longley: there is a solution
… which is unpleasant
… but without this bug fix, there’s no way to do the other approaches
… you literally cannot use type scoped contexts and protected terms together in the way you’d expect

Rob Sanderson: is there a way to flag which of the two?
… that seems like a lot of processing
… it would require context import metadata…
… like only this class + all that descend from it

Dave Longley: yeah, we do that with property scoped contexts
… but you want to do that without redefinition

Rob Sanderson: right. if the Annotation context got updated, we’d then have to synchronize this context with that one.
… so…maybe…if there were an Annotation 1.1 context
… could it then redefine things within itself?

Dave Longley: yes. that would work

Rob Sanderson: so for this particular case, that would be the right solution

Dave Longley: correct

Rob Sanderson: so, given that context files are not versioned in the same way that specifications are
… we could propose a 1.1 context

Dave Longley: this would also afford the ability to use the @protected feature
… which would help JSON processors
… who don’t want to do JSON-LD processing
… and want terms to remain identical in both ecosystems

David Newbury: does this only protect at a certain level in the hierarchy?
… or does to descend into the tree?

Dave Longley: any term definition does not continue down the tree–if you change type scope

David Newbury: given your definition, that makes sense
… but that’s not what I expected
… I’d thought that this covered the terms in the hierarchy under that type

Dave Longley: my opinion of that is when you’re thinking of it from either OOP or graph perspectives
… you move into a node, and that node has a class with certain properties

Rob Sanderson: Another type scoped context: https://linked.art/ns/v1/linked-art.json

Dave Longley: so to go into a node is to move into a new space
… and if it cascaded as you describe it would be incompatible with @protected

David Newbury: I think its two different contextual models of how this work

Rob Sanderson: yep. we just need to verify the models against the use cases
… so here’s another type scoped context
… right at the top, there’s some vanilla ones
… but the 4th class is Period
… we want to rename some of these to simpler names
… there’s no importing of anything
… so these would not descend down

Dave Longley: yep. that should work just fine

Rob Sanderson: anyone have other 1.1 contexts?

Simon Steyskal: I was also kind of confused
… given that we have multiple people confused by this–or having differing expectations…maybe we should put this in the primer or something?
… if we decided on the specific way to deal with this, then we should write-up the foundation of how this works
… because it’s not like a class hierarchy
… and we want to avoid those expectations causing confusion

Rob Sanderson: one of the reasons why I had the opposite expectations from dlongley
… is that the way gkellogg has expressed in the past
… was to avoid contexts inline in the JSON
… if you had a top-level node with a context, then that context would extend down
… whereas if you had @type with a scoped context, it would be equivalent to putting that context in at that part of the tree
… which would come with the expectation of cascading–as in the case of an inline context at that point in the tree

David Newbury: so, say someone else is using our vocabulary
… what would it require us to do to rewrite the linked-art context
… to be sure that our terms stay scoped into our context
… is it the same as what’s being considered for ActivityStreams?

Rob Sanderson: only if they’re type scoped

Dave Longley: you either define properties that can appear anywhere
… or those that can be used within certain types
… or those that can be used within any type
… so, yes the way gkellogg had stated this as pulling context into a type
… and thinking about it as pulling a context in “in place” as a context object would
… that, however, doesn’t work well with protected, etc.
… so, the change would be that type scoped would now map singularly to that scope

David Newbury: so, assuming that someone uses a type scoped definition
… when I put this type in, it’s a vocabulary concept
… so where we put our contexts have names and dates
… we wouldn’t want to implement them at every level
… we’d have to protect the linked-art context against being used as type scope context

Rob Sanderson: so, like IIIF includes Annotations
… so when you descend from Concept to name via identifiedBy property
… you’d no longer have an active context
… the context doesn’t have a notion of inheritance
… so it’s not really Object Oriented
… if it did, then you’d be fine
… so we instead would have to enumerate every possible property of every possible class

Dave Longley: given that I have no knowledge of what you’re talking about…
… from the high level it sounds correct
… if you want to scope against types, use types on everything
… if you want your types to survive under all the properties, then yes…this will be verbose
… there could be another simpler syntax
… but I don’t think the solution is to not handle this sort of inheritance
… if that is indeed a need to solve that verbose syntax, then we should solve that on its own and not give up this sort of inheritance

David Newbury: this sounds like shallow scoping vs. deep scoping

Dave Longley: to me its a difference between property scoping vs. type scoping
… when you use property scoping, you’re cascading into the tree
… but with type scoping, you have no idea where it’s going next
… this gets worse with protected
… because if you don’t know where a type usage is going next, there’s no way to correctly protect its terms
… so maybe we need like an @any property to handle this scoping with protecting

David Newbury: so, if you do want shallow scoped types, could you reimport the base context back via nullifying?

Dave Longley: nullifying can’t do that

David Newbury: but if you knew what it was, could you bring it back in?

Dave Longley: that would be dependent on how you got that base context
… which sounds very difficult

David Newbury: so, if we have deep scoping, then shallow scoping seems hard, and vice verse

Dave Longley: there might be a cleaner way to say, in this scoped context, you can use these type scopes
… to me one seems easier to solve than the other
… but it certainly seems like they do differ

David Newbury: I think there is to do them both…and maybe syntax sugar would make things simpler

Dave Longley: think where we’re at now, shallow is broken
… so if we fix for shallow, we make deep harder
… and that’s where this syntactic sugar might help

Rob Sanderson: what about nullification and circular re-importing?
… I fear you’d end up recursively recursing and cursing about recursion
… so the @properties: use-this-context is way less verbose than defining every single property

Dave Longley: yeah, it’s effectively a way of defining a base context

Rob Sanderson: right. @base-context (vs. @base)
… it was very good to discuss this
… anything else? or are we at proposal time

Dave Longley: so, we’d need to change this to default to shallow, so VCWG can use protected
… so the VCWG testing can move forward

Proposed resolution: Type scoped contexts will be shallow and not be inherited via properties of instances of the type, and we will add a syntactic sugar for a wildcard match on properties on the type to define their context (Rob Sanderson)

Dave Longley: +1

Benjamin Young: +1

Rob Sanderson: +1

David Newbury: +1

Simon Steyskal: +1

Rob Sanderson: so this solution seems better than the other options…which all seem worse

Jeff Mixter: +1

David I. Lehn: +1

Benjamin Young: ..and for the linked-art case, we simply have in the context generating script, “for each class, put in magic-ness to use self for all the properties of this thing”

Resolution #2: Type scoped contexts will be shallow and not be inherited via properties of instances of the type, and we will add a syntactic sugar for a wildcard match on properties on the type to define their context

3.2. Tweak @protected algorithm to allow reuse of existing contexts w/o conflicts

Dave Longley: https://github.com/w3c/json-ld-api/issues/90

Dave Longley: so this one is about reusing existing contexts
… the syntax spec says that a protected term definition with @protected: true
… it prevents it being overridden
… possibly by setting context to null
… what is prohibited is introducing other definitions
… but what happens when new terms come in
… what this change could provide is allowing using 1.0 contexts alongside protected
… so, things that define aliases for id/type

Rob Sanderson: +1 to this issue

Dave Longley: you can’t currently bring those in with protected, because that throws an error
… because you’re trying to redefine terms–even though the result would be the same
… so the only caveat is reusing old contexts won’t come with @protected set
… so in that case, you just keep @protected flag to on
… so update the API to switch where we check that protected is set, not update existing terms that are identical–modulo the protected flag

David Newbury: it does seem to make complete sense
… I’d want gkellogg to weigh in
… to get another implementer’s input on this

Dave Longley: so, the only sticky issue is two scoped contexts, then you have to do a full comparison

Rob Sanderson: if they’re by value rather than by reference…yeah…that would be rough
… so with the caveat that the editors are OK
… here’s a proposal

Proposed resolution: Assuming the update to the algorithm is not controversial, protected definitions of terms do not raise an error when the term is redefined in exactly the same way, with the potential exception of not being protected (Rob Sanderson)

David Newbury: +1

Jeff Mixter: +1

Dave Longley: +1

Rob Sanderson: +1

Simon Steyskal: +1

David I. Lehn: +1

Benjamin Young: +1

Resolution #3: Assuming the update to the algorithm is not controversial, protected definitions of terms do not raise an error when the term is redefined in exactly the same way, with the potential exception of not being protected

3.3. Compact IRIs #177

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

Rob Sanderson: if you define a term that’s the same as a URI scheme
… then you’ll have problems
… so there are schemes that are very likely to be used in values
… like mailto: which could be high jacked in this scenario
… we could fix this by being able to protect URI schemes that are in use
… by making it possible to set certainly ones to null
… so, for instance, you could also set them within certain properties–like foaf:mailbox
… and then protect them to keep upstream ones from overriding mailto:
… so this means we don’t need to put all possible URI schemes in the spec

Dave Longley: not enough time to consider it :/

Rob Sanderson: and context authors can limit the damage to specific spaces where it could be damaging
… so, something to think about over the week

4. Adjourn

5. Resolutions