Multiple Bodies

Synopsis

Methods are needed to address alternative and composite body use cases.

Proposed Solutions

• Allow multiple bodies for alternative body use cases, use Composite Annotation (see below) for use cases that need to aggregate multiple bodies together.

 Anno oa:hasBody X ;
   oa:hasBody Y 

• Choice - use a structured body to represent the choice between alternative bodies

 Anno oa:hasBody uuid1
  .
 uuid1 sc:default X ;
   sc:option Y .

• alternate / equivalency relationships -- There is an alternate relationship between equivalent resources

 Anno oa:hasBody X ;
 X :alternate Y .

Composite Annotation (proposed by Rob Sanderson)

See also Rob's Proposal for Integrated Multiple Resources Solution

Attached is a diagram with a CompositeAnnotation (which could be a subClass of rdf:Bag or ore:Aggregation) that groups together two other annotations, a tag and a comment, that should be kept together. It's also available at http://www.openannotation.org/spec/proposals/composite_annotation.png

The thinking behind this approach:

• In a group of (say) 5 annotations rather than just 2, you could need 20 relationships (each of the five should link to all of the

others) to ensure they were all tied together. This seems clumsy, to say the least

• The group gets an identity, and thus can be referred to.
• The group can have all of the properties of an Annotation for provenance, allowing a different agent to create the collection

compared to creating the individual annotations

• It follows the CompositeSpecifier pattern that we already have
• It would allow us to get rid of the hasSemanticTag "shortcut"

It does mean minting yet another identifier, but that's what you get when you use RDF.

Use Cases

Alternate Bodies

Many use cases exist for alternatives for the Body resource, for example the same text in different languages or in different formats. For the purposes of the annotation there may be multiple resources that would fill the role of Body equally well, such as a multiple photographs of an object taken with different lighting conditions.

Tag(s) + Discussion

It is convenient to have a single annotation express both a textual body and semantic tags, however the current hasSemanticTag is not a "real" body.

XML Document Use Case (via Lutz Suhrbier)

In our use case, we have domain specific XML documents, which shall be annotated under some predefined topics, which may include multiple elements within a dedicated XML document. For example, a more general topic would be the correction of geographic locations, which may include longitude, latitude, country, city, region, timezone etc.. In that case, it makes no sense to have 5 non-related annotations for that kind of annotations, because the annotation is only valuable, if all of the related elements can be expressed within a single annotation !

Any of these elements can be identified by XPath expressions related to the XML document. But, to each of these XPath expressions, a different value must be assignable since longitude value is different from latitude value, e.g. With the current OA version, using fragment selectors it is possible to create a "list" of XPath expressions, which permits to capture any annotated XML elements within a single annotation. But, due to the restriction to max. one body per annotation, it is not possible to relate the new (annotated)XML element values with their corresponding fragment selectors.

That was my problem using OA, and I think, several other applications dealing with annotations of XML documents will have the same problem ?

XML Document Use Case Example

Discussion Summary

• The model only allows one Body currently for exactly this reason; that people would simply put all of the bodies and all of the targets in one big blob of uninterpretable RDF, even though some Bodies relate only to some of the Targets. It also shows the danger of workarounds like hasSemanticTag which side step this issue.
• Tag(s) plus Discussion - This is explicitly allowed under the current version of the oax extensions document (see http://www.openannotation.org/spec/extension/#SemanticTag).
• The proposed Composite Annotation model seems to work very well as an alternative for compound bodies. It does not address the alternate bodies issue.

• Pros
  • Model Symmetry
  • Allows tags to be represented as bodies rather than requiring extension property

• Cons
  • Multiple Bodies (and by extension Semantic Tags) may result (or even promote) misuse of the data model, causing the creation of annotations where undefined portions of the annotation content (the bodies) apply to undefined portions of the annotated resources (the targets).

Recommended Action(s)