Versioning

Introduction

We recognize three different models of versioning of annotation:

• none: every time a change is performed on an annotation, the old instance is swapped with the new one. The new one replaces entirely the previous annotation and shares the same URI.
  • Pros: simple to manage.
  • Cons: no history is preserved.
• hybrid: this methodology is very similar to the one adopted by wikis. We recognize major updates that motivate the creation of a new version of an resource and minor updates that don't justify the creation of a new version and simply update the existing annotation instance.
• total: every time an updated is performed on an annotation instance, a new version of the annotation is created.
  • Pros: the full history is preserved and therefore possibility of referring to one specific version of the annotation in time.
  • Cons: lots of triples also for trivial changes and 'dynamic' URIs as the same annotation keeps changing URI as it evolves.

Ideally, it would be good for the Open Annotation Model to support all the above levels.

Possible solutions

1. Annotation Versioning in Domeo

The following approach for keeping track of annotation versions has been implemented by Paolo Ciccarese in the Domeo Annotation Toolkit (http://www.annotationframework.org). The methodology has been partially introduced in the paper: An open annotation ontology for science on web 3.0 (http://www.jbiomedsem.com/content/2/S2/S4).

Domeo and Annotation Ontology have been used for eliciting scientific knowledge. One of the requirements often associated with scientific knowledge representation, is the capability of tracking the state of science in time or knowledge evolution. In many scientific applications is essential to be able to observe the annotation at different moments in time.

Methodology

The approach makes use of the following properties defined in the Provenance, Authoring and Versioning (PAV) ontology (http://code.google.com/p/pav-ontology/) and used in conjunction with the Annotation Ontology (http://code.google.com/p/annotation-ontology/):

The methodology mimics the methodology adopted by Wikis. If the change is evaluated as minor by the user, new pav:lastUpdatedOn and pav:lastUpdatedBy will be defined. If the change is evaluated as substantial, a completely new version of the object is created - with pav:createdBy, pav:createdOn and pav:versionNumber - and it will point to the previous version. The same methodology, as we will see in the next sections, extends to annotation containers.

Figure 1 - Example of versioning with no minor modifications and using some of the Open Annotation Model classes/properties in place of the Annotation Ontology ones. The URI of the annotation is different in the two different versions. In this case the semantic tag has been completely replaced in the second version of the annotation. (FIGURE JUST A ROUGH DRAFT)

In figure 1 we represent an example of versioning. We depicted the same annotation in two different moments in time. As the goal is to keep track of the old version of the annotation, a new annotation - with a new URI - has been created to accommodate the updates.

Figure 2 - Example of versioning with minor modifications. As the modification of the annotation body is considered minor by the user, the body is changed and the lastUpdate* properties are defined. It is important to notice that the annotation is still the same entity and the URI did not change. (FIGURE JUST A ROUGH DRAFT)

When no versioning is needed, it is always possible to use pav:createdOn and pav:createdBy for the first creation together with pav:lastUpdatedOn and pav:lastUpdatedBy for the last update.

Note: It is possible to define a URI that refers always to the most recent version of the annotation, however, things can get complicated when the evolution of the annotation includes branching. For implementing branching pav:derivedFrom is used.

Porting to Open Annotation

After discussion with Randall Leeds and Tom Habing we agreed on naming the properties in a simpler way:

As provenance is already partially defined in the Open Annotation model through the properties: oa:generator, oa:annotator, oa:generated, oa:annotated. We can follow the same approach and we could define (not very happy with the names updated and updater):