Multiple Resources

Proposal for Integrated Multiple Resources Solution

The issue of how to interpret multiple resources exists for all of the main classes in the OA ontology, eg Body, Target, Style, State, Selector and so forth. The current approach is not consistent:

• Style: Every style should be interpreted, following HTML semantics of repeated <style>
• Body: Only a single body is allowed, multiple is an error
• Target: Multiple targets are allowed, but the semantics are unspecified
• Specifiers: Multiple means explicitly any one should be used, and a special CompositeSpecifier class is used to say that all specifiers to be interpreted.

This proposal creates a single coherent method of determining the intent of the repeated predicates within the Open Annotation ontology.

Method

We introduce a set of resources that explicitly describe the intended composition of the bodies, targets or specifiers, whether they should be:

• Alternatives: Only one of the resources should be used, as they are all alternatives. For example, all of the targets are different PDFs for the same article, or all of the Bodies are translations of the same comment. This is an Exclusive OR.
• Individuals: All of the resources apply individually. Thus multiple Bodies could be a comment, a review and two tags. Each of these resources are somehow about the target(s). This is an Inclusive OR.
• Composite: All of the resources apply together as a set. For example, the annotation might be about three images together, rather than each image individually or only one of the images. This is an AND between the resources.

Each of these options is expressed as a resource within the Open Annotation namespace, currently oa:XOR, oa:OR and oa:AND respectively.

Each main class within the ontology has a composition predicate that links to one of these resources. Currently these are called:

• bodyComposition
• targetComposition
• styleComposition
• selectorComposition
• stateComposition

Discussion

Pros:

• Doesn't make the model more complicated, unlike introducing new nodes.
• Consistent model for all classes in the ontology
• Allows explicit declaration, but doesn't require it
• Allows multiple bodies, without losing semantics of their meaning

Cons:

• Not a common pattern to have a predicate modify the interpretation of the graph.
• Can't model nested structures like: (A and B) or (C and D)
• No identifier for the choice/set/bag/list itself

Use Case Examples

• Body, XOR: The multiple bodies are translations of the comment, thus only one should be displayed
• Body, OR: The multiple bodies are a comment and two different semantic tags, all of which apply individually
• Body, AND: The multiple bodies are a textual review and a score, both of which apply and should be displayed

• Target, XOR: The multiple targets are copies in PDF format of the same article in different repositories, thus any one is appropriate, but multiple should not be displayed.
• Target, OR: The multiple targets are individual images and the annotation is associating a tag with each of them.
• Target, AND: The multiple targets are two parts of a video that are related, as expressed in the body, thus both parts are required to make sense of the annotation. The body is about the set of two segments, not each individually.

• Style, XOR: Any one style should be applied, but only one. The Styles are thus alternatives, perhaps for rendering in different media.
• Style, OR: ???
• Style, AND: All of the styles should be applied together, in the same way as if they were stylesheet links in HTML.

• Selector, XOR: The selectors are different ways of expressing the same thing, such as a xywh FragmentSelector and a rect SvgSelector. Only one should be applied.
• Selector, OR: ???
• Selector, AND: All of the selectors should be applied in an order determined by the client. For example, a time range in a video and then a non rectangular area within that time.

• State, XOR: The states are different ways of expressing the same thing, perhaps multiple ways of describing the necessary HTTP headers to retrieve the correct representation.
• State, OR: ???
• State, AND: Two states are required to retrieve the correct representation. One expresses the datetime of the resource, and the other expresses the required HTTP request headers.

Model Examples

There are three alternatives for the Body of an annotation, each is a translation of the same text.

  _:Anno a oax:Comment ;
      oa:hasBody _:Body1 ;
      oa:hasBody _:Body2 ;
      oa:hasBody _:Body3 ;
      oa:hasTarget _:Target1 ;
      oa:bodyComposition oa:XOR .

The annotation links two texts, one derived from the other, and thus requires both targets:

  _:Anno a oax:Comment ;
      oa:hasBody _:Body1 ;
      oa:hasTarget _:Target1 ;
      oa:hasTarget _:Target2 ;
      oa:targetComposition oa:AND .

And so forth.

Diagrams