Post
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/?
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
