You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Terms MUST NOT be used in a circular manner. That is, the definition of a term cannot depend on the definition of another term if that other term also depends on the first term.
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: IIIF/api#1571
The 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!
The text was updated successfully, but these errors were encountered:
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: IIIF/api#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!
The text was updated successfully, but these errors were encountered: