Abstract

Multiple Constraints may be needed for various Annotation use cases. This document discusses the various approaches for how to enable this, while maintaining the simplicity, scalability and usability of the Open Annotation data model. It is expected that the discussion and experimentation during the Beta phase of the model will enable a final and well understood decision for the 1.0 release.


Table of Contents

1. Introduction
2. Constraint Precedence
     2.1 Chaining Model
     2.2 RDF List/Bag Model
     2.3 Alternative Only Model
     2.4 Single Constraint Model
     2.5 Offset RDF List/Bag Model

Appendices

A. Acknowledgements
B. Change Log


1. Introduction

It is possible that multiple constraints need to be used in order to ensure that the Annotation's body or target are fully and correctly described. There are several use cases for when this is important, that fall under two broad areas:

  1. Express the equivalence between two constraints.
    For example, this would enable cross-community interoperability when there are multiple Constraint classes that express the same information. In this case, an implementation might use any of the Constraints and arrive at the correct interpretation of the Annotation's body or target.
  2. Express a further constraints on an already constrained resource.
    For example, an image might change over time and the annotation involves a non-rectangular segment of a particular version of that image. In this case, implementations must process all of the Constraints in order to arrive at the correct interpretation of the Annotation's body or target.

There is a lack of consensus within the community as to the most appropriate method to convey this information given the requirements. The solution should follow the principles of the Open Annotation data model, notably:

The purpose of this document is to describe the various options and allow a process of experimentation and use to decide on the most appropriate solution. Feedback on the different suggested models is sought.

2. Constraint Precedence

There are several different possible approaches to solving the issues raised by the requirements. These are explored below, and feedback welcomed.

The abstract example used in the discussions below is that either of Constraint C-1 or C-2 is needed, followed by C-3, followed by C-4.

2.1 Chaining Model

The approach taken by the Chaining Model is to introduce two new relationships that explicitly link alternative constraints, and further, mandatory constraints. This allows all of the Constraints to be discoverable within the graph using traversal techniques, and is only part of the graph when necessary. All of the requirements are met, and through more complex chains multiple alternatives and alternatives that involve more than one constraint are possible. Implementations that do not process the new relationships will gracefully degrade to simply processing the first constraint.

The processing rules are:

  1. Try to apply the current constraint, starting with the object of the oac:constrainedBy relationship
  2. If the constraint is successfully applied, then follow the nextConstraint relationship if it exists and return to step 1
  3. If the constraint cannot be successfully applied, then follow the altConstraint relationship if it exists and return to step 1
  4. Otherwise, stop processing

Figure 1: Chaining Model

Issues Raised

Ontology

This solution defines the following relationships:

oac:nextConstraint
The object constraint must be processed after the subject constraint
oac:altConstraint
The object constraint may be processed instead of the subject constraint

2.2 RDF List/Bag Model

The List/Bag model follows the same approach as the Chaining Model, but instead of using special purpose relationships, it makes use of the ordering available in rdf:Lists and the alternatives semantics of rdf:Bag. If there are alternatives for a particular Constraint, then all of the alternatives would be placed inside an rdf:Bag. If there is more than one Constraint required, then they are placed inside an rdf:List, thus also encoding the order of processing. The unique identify for the Lists and Bags mean that the order is local to the Annotation, unlike in the Chaining Model.

Figure 2: RDF List/Bag Model

Issues Raised

Ontology

This solution does not require any new classes or relationships.

2.3 Alternative Only Model

The Alternative Only Model is simpler than the previous models by leaving the ordering of processing for multiple Constraints up to the implementation to determine and relaxing the (unenforcable) single constraint per constrained target rule. This model is very easy to query using SPARQL, as multiple constraints are simply added to the Constrained Body or Target directly, and alternatives are chained from those. The use cases where order is important are very limited, and likely more easily solved at the implementation level rather than at the model level. It gracefully degrades, as the implementation that can only handle one Constraint will pick one to process, and the objects of relationships do not change.

Figure 3: Alternative Only Model

Issues Raised

Ontology

This solution (optionally) defines the following relationships:

oac:altConstraint
The object constraint may be processed instead of the subject constraint

2.4 Single Constraint Model

Following from the objection to the previous models that RDF is not a suitable location for expressing what amounts to a programming language for constraints, the Single Constraint Model shifts the responsibility to the implementation to interpret a real programming language. This solution allows only a single constraint that may then encode further constraints in a full workflow environment. Subtyping of the constraint would allow for different environments, for example a PythonWorkflowConstraint versus a JavascriptWorkflowConstraint.

This option is not inconsistent with the previous model of altConstraints.

Figure 4: Single Constraint Model

Issues Raised

Ontology

This solution defines the following class:

oac:WorkflowConstraint
A type of Constraint which encodes the workflow necessary to correctly constrain the Body or Target

2.5 Offset RDF List/Bag Model

Various use cases were discovered that strengthened the requirements for ordering and for the re-usability of constraints. The solution devised for the Offset Model is to have both the constrainedBy predicates and a new predicate from the ConstrainedTarget that has either a Bag or a List as the object. The Bag or List then uses the solution from option 2 to encode the ordering and alternatives.

At the minimal expense of one new predicate, this option seems to solve all of the issues:

Figure 5: Offset RDF List/Bag Model

Issues Raised

Ontology

This solution defines the following class:

oac:ordering
A predicate with a subject of either a ConstrainedBody or ConstrainedTarget, and a range of either an rdf:Bag or an rdf:List. The object resource expresses a nested set of instructions as to the order of the Constraints.

A. Acknowledgements

The editors would like to thank the following for their valuable contributions:

B. Change Log

Date Editor Description
2011-08-10 rsanderson Initial (beta) release
2011-10-03 rsanderson Added section 2.5
 
Creative Commons LicenseThis work by the Open Annotation Collaboration is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.