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:

• Simplicity: The model should be as simple as possible, and no simpler. It should reuse existing well-known ontologies when possible.
• Scalability: The model should be easy to use for easy requirements, while still enabling more complex use cases.
• Usability: Graphs following the model should be able to be queried with appropriate tools, such as SPARQL.

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

• The model assumes that Constraints are unique to Annotations. If a Constraint instance were to be re-used in another Annotation with a different set of processing rules, the graphs would merge in a combined triplestore and become unprocessable.
• The model can be traversed, but is difficult to query. For example, the query to find all Annotations which use a particular class of Constraint is very difficult to perform as the graph structure below the first Constraint is not deterministic according to the model
• It is, perhaps, overly complex, and seems like writing a programming language in RDF. Is this really necessary?

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

• The List and Bag constructions are not able to be queried at all using SPARQL. While the Chaining Model requires some complicated queries, in the List/Bag model it is simply impossible.
• It does not gracefully degrade and is not backwards compatible, as an implementation will expect the object of oac:constrainedBy to always be a Constraint, not a List or Bag.
• The value of reusing the List/Bag constructions is uncertain, especially considering recent objections to them in the standards arena.
• Again, it seems like writing a programming language in RDF.

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

• It doesn't encode order, which may be very important to correct interpretation. For example TimeConstraints should be processed before Segmentation types of constraint: the implementation must discover the correct version before it can then find the desired part of that version.
• Possibility: dcterms:hasFormat could be used in place of oac:altConstraint?

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

• This is much more difficult to implement without a solution for multiple different workflow environments, which is the base of the problem trying to be addressed. For example, if an Annotation has a PythonWorkflowConstraint but the consuming application only understands JavascriptWorkflowConstraints, then there is no graceful degradation and no possibility for alternative representations.
• It doesn't really address the issue, as Constraints still somehow need to be processed from within the workflow environment.

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:

• Ordering of multiple Constraints is possible
• The Constraints are re-useable in different configurations of alternatives and ordering in different Annotations
• As the oac:constrainedBy is still present, the model is searchable via SPARQL
• The range of oac:constrainedBy is consistent, as the ordering Bag/List has a new predicate
• Only minimal (one) new terms are invented for the ontology.
• It relatively gracefully degrades if processors do not understand the ordering instruction.

Figure 5: Offset RDF List/Bag Model

Issues Raised

• No issues have been raised so far

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.

 
This work by the Open Annotation Collaboration is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.