Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Circular imports: Abort, Retry, Fail? #645

Closed
azaroth42 opened this issue Apr 23, 2018 · 3 comments
Closed

Circular imports: Abort, Retry, Fail? #645

azaroth42 opened this issue Apr 23, 2018 · 3 comments
Labels
api best-practices defer Issue deferred to future Working Group

Comments

@azaroth42
Copy link
Contributor

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:

{
  "@context": "activities-context",
  "type": "Processing",
  "target": {
    "@context": objects-context",
    "type": "Thing",
    "generated_by": {
      "@context": "activities-context",
      "type": "Generation",
      "actor": "person"
    }
  }
}

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!

@gkellogg gkellogg added api best-practices defer Issue deferred to future Working Group labels Apr 25, 2018
@iherman
Copy link
Contributor

iherman commented May 7, 2018

There is analogy to #include in C: the 'closest' dominates. We could do something similar.

@azaroth42
Copy link
Contributor Author

Discussion on 2018-05-07 CG call: Consider a useful issue to solve in WG.

@gkellogg
Copy link
Member

gkellogg commented Aug 1, 2018

Closed in favor of w3c/json-ld-api#14.

@gkellogg gkellogg closed this as completed Aug 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api best-practices defer Issue deferred to future Working Group
Projects
None yet
Development

No branches or pull requests

3 participants