Closed azaroth42 closed 6 years ago
There is analogy to #include in C: the 'closest' dominates. We could do something similar.
Discussion on 2018-05-07 CG call: Consider a useful issue to solve in WG.
Closed in favor of https://github.com/w3c/json-ld-api/issues/14.
In trying to build several inter-related contexts, we ran into the circular import issue. The current specification says that circular imports are an error condition.
The trouble arises when two contexts need to reference each other, potentially only in particular scopes, and when it's unknown which is the context that's used at the top of the tree.
For example, imagine two contexts. One defines the domain of Activities that are performed on resources. The other defines classes and properties of some subset of those possible resources, and wants to refer to the activities that are performed. From one perspective the Activity context is primary, and it merely talks about the things being acted upon. From the other perspective, the Object context is primary, and it references things that have happened to the resource of interest.
This example (and the equivalent with scoped contexts) is not valid:
However if there are conflicts between the two (one defines
label
as a string, the other as a language map, for example), the simple resolution of pulling them both out and putting them at the top no longer works. If the contexts are maintained by different organizations and are updated at different schedules (schema.org and LDP for example) then managing exceptions is particularly hard. We ran into this issue here: https://github.com/IIIF/api/issues/1571The above JSON (and even nicer with scoped contexts) seems like a reasonable thing to do. Advice (and subsequent recording of best practices) on how to resolve these sorts of issues would be appreciated!