Discussion
i'm not 100% sure about this but i am starting to think that the way #jsonld context declarations propagate by default is generally an anti-pattern
the problem is when you cross a semantic boundary, which happens most often due to naively dereferencing and embedding an entire resource ("inlining", "hydration"). it's especially likely to be an issue when you are using one or more protected contexts (where terms can't be redefined later).
1/?
say you have a generic property whose range is relatively unbounded -- a grab-bag where anything goes. something like how attachment or tag are used in #activitystreams. using multiple contexts at the top-level introduces a potential conflict in terms. you could reconcile any conflicts with a custom context, but that prevents reuse / understanding a more well-known context.
unfortunately, due to context propagation, terms defined earlier on can "leak" into the naively merged subgraph.
2/?
let's demo this with a simple case. say you want to tag something that is a Movie described by schema.org. the Movie declares that it has an actor who performed in it.
this is redefining the term actor as defined at the top-level by #activitystreams -- where actor means who performed an Activity, not who performed in a Movie.
if the activitystreams context was protected, then this would be a fatal error for any #jsonld validator. you cannot be sure which actor was meant!
3/?
we have some tools to deal with this in #jsonld. we can "type-scope" so that an Activity.actor uses a certain definition, and a Movie.actor uses a certain definition, but this requires us to say ahead-of-time that Movie will always mean a schema.org Movie. it also won't help us redefine protected terms, since "type-scoped" terms don't override protection. only "property-scoped" terms do. but we can't use "property-scoped" terms because that requires an explicit semantic range.
4/?
in "property-scoped" terms, we would have to say that tag.*.actor always means either Activity.actor or Movie.actor. in effect, we are saying that every tag MUST be an Activity, or MUST be a Movie. in other words, our semantic range is no longer unbounded.
now, remember this problem only happened because we naively merged in a JSON resource into another JSON resource, leading to a conflict between the two contexts. what's a better way to handle graph merges while maintaining context?
5/?
one approach is to just say "well, plain JSON consumers should just stop being so naive". a valid approach, but not very robust!
our goal is to preserve the semantic boundary between different resources but still allow merging those resources naively (as JSON objects rather than as #JSONLD graphs).
instead of saying that a term will always mean the same thing in the entire document, we want to allow the same term to be used in different contexts across semantic boundaries (resources)...
6/?
A space for Bonfire maintainers and contributors to communicate
