Unexpected @type scope behavior (term definitions persist throughout JSON tree)

[dlongley]

I was trying to use type-scoped contexts to define a @context and was surprised to discover that any type-scoped terms that get defined in the active context continue to be defined beyond the object with the matching @type. I think this is very unexpected behavior from an OOP modeling perspective. Also, it is very problematic for @protected terms, as it means that you can't model objects of one type that contain objects of another type when there is a commonly used JSON key (that may or may not have the same term definition) when terms are protected.

A playground example:

{
  "@context": {
    "@version": 1.1,
    "@vocab": "ex:",
    "@protected": true,
    "Library": {
      "@context": {
        "book": "library:book",
        "name": "library:name"
      }
    },
    "Person": {
      "@context": {
        "name": "person:name"
      }
    }
  },
  "@id": "the:library",
  "@type": "Library",
  "book": {
    "@id": "the:book",
    "about": {
      "@id": "the:person",
      "@type": "Person",
      "name": "Oliver Twist",
      "book": "unexpectedly defined as library:book!"
    }
  }
}

Produces these quads:

<the:book> <ex:about> <the:person> .
<the:library> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <ex:Library> .
<the:library> <library:book> <the:book> .
<the:person> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <ex:Person> .
<the:person> <library:book> "unexpectedly defined as library:book!" .
<the:person> <person:name> "Oliver Twist" .

http://tinyurl.com/y2x4szzb

If you use @protected here, you get an error (which I also find unexpected):

{
  "@context": {
    "@version": 1.1,
    "@vocab": "ex:",
    "@protected": true,
    "Library": {
      "@context": {
        "@protected": true,
        "book": "library:book",
        "name": "library:name"
      }
    },
    "Person": {
      "@context": {
        "@protected": true,
        "name": "person:name"
      }
    }
  },
  "@id": "the:library",
  "@type": "Library",
  "book": {
    "@id": "the:book",
    "about": {
      "@id": "the:person",
      "@type": "Person",
      "name": "Oliver Twist",
      "book": "unexpectedly defined as library:book!"
    }
  }
}

That error happens even if name is defined the same way for both types.

I suspect that type-scoped terms behave this way because it was easy to implement, but I think it is very surprising behavior that may not have been exposed yet due to limited examples.

It's possible that there's an easy fix for this. I think we should change this behavior so that we track whether a term definition in the active context was defined via a type-scoped context and whether or not it replaced a non-type-scoped term when it did so. Then, whenever traversing into one of the typed object's properties during processing, we revert all type-scoped terms to their previous definitions which may mean setting them to null (clearing them) if they were previously undefined. Then processing can continue as normal.

[dlongley]

Also, if this fix works, I think the JSON-LD syntax spec should clarify that the changes to the active context that bring in type-scoped terms only apply for terms used on the object with the matching type.

[dlongley]

I've implemented the fix in a PR to jsonld.js here: digitalbazaar/jsonld.js#312 and fixed tests and added two more in PR w3c/json-ld-api#89.

Note that if you define a @type scoped context that has property terms with their own scoped contexts, those will still be properly applied to deeply nested nodes within a type. This fix will only ensure that terms that are defined for objects with specific @type values won't leak to other nodes that don't have those types.

[gkellogg]

Why is the expectation that type-scoped contexts are limited to the object containing the type different than for property-scoped contexts being limited to the object value of the property?

I haven't looked at your PR, but it would seem that the expansion algorithm needs to maintain two different contexts, that it received (with possible update from property scoping), and those that come from @type. When an embedded context is encountered, it needs to update both the type-scoped copy and the passed in copy. This also needs to be reflected when handling nested properties.

It does dilute the message that property- and type-scoped contexts be have exactly as if they had appeared inline, as the type-scoped context would disappear when going deeper, while the property-scoped and any directly scoped contexts persist.

Also, what happens when a type-scoped contexts defines a term with an scoped context which is then used? As the algorithm is defined, the expansion algorithm won't see that scoped context, as it's not defined in the current context.

[dlongley]

@gkellogg,

Why is the expectation that type-scoped contexts are limited to the object containing the type different than for property-scoped contexts being limited to the object value of the property?

I expect the primary audience for @type-scoped properties to be people that are using OOP modeling. This means defining a type and the properties you expect to see on that type. The "scope" is the object with a matching @type. If you move beyond that scope (into another object of another @type), it's quite unusual for the terms to be defined. This becomes even more obvious as you move into some deeply nested structure that has a variety of other typed objects along the way.

The primary audience for property-term scoped properties is one that is defining properties for different sections of their JSON tree. If you traverse into branch X of the document, then terms A, B, and C will be defined. This is also intuitive for the audience. I think having to redefine them when you're on the same branch (though you've gone deeper into it) would be quite unexpected. This is different from the @type situation because you change the @type scope when move deeper into a JSON branch (because @type itself doesn't persist), whereas the branch does persist, you're just further along the branch.

I haven't looked at your PR, but it would seem that the expansion algorithm needs to maintain two different contexts, that it received (with possible update from property scoping), and those that come from @type. When an embedded context is encountered, it needs to update both the type-scoped copy and the passed in copy. This also needs to be reflected when handling nested properties.

You don't need to maintain two different contexts, you create a new active context (a clone that removes the @type-scoped terms) when you recurse into the typed object (when you follow its properties to other objects).

Also, what happens when a type-scoped contexts defines a term with an scoped context which is then used? As the algorithm is defined, the expansion algorithm won't see that scoped context, as it's not defined in the current context.

I have a test for this and it is seen. In that case, a term scoped context is created prior to recursing into the object (there is no change to the existing algorithm). Since it is a property-term-scoped context, it functions as expected (defining terms anywhere along the tree branch).

[dlongley]

With the above changes, I was able to update the VC context to use type-scoped contexts with @protected terms:

https://github.com/raw/dlongley/vc-data-model/flatten-context/contexts/credentials/v1

[gkellogg]

Okay, that looks like a good approach. I'll work on my own implementation.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: 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

View the transcript

3.1. Type-scoped contexts: #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

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Un-defer #108 with propogation as the use case

View the transcript

3.1. Type scoped context continued; property wildcard
Rob Sanderson: link - #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: #108 with a syntax possibility at: #108 (comment)
… 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