## 2 Case Studies
### Migrating Annotations across Multiple Representations of Museum Artefacts
* _Bodies and Targets can be any media type and can be located on any server._ This flexibility means that we can directly annotate digital resources that have been made available through online collections, such as those digitized and published by archives, museums, libraries and

Figure 9: Technical components of the lorestore annotation repository. publishers. It also allows us to create Bodies that are RDF, so that metadata properties associated with the Body can be stored separately rather than included in the annotation graph, making the provenance of the Body, the Target and the Annotation clear and explicit. * _Because the OAC model is RDF-based, it is a trivial exercise to extend the model and include properties from existing domain-specific ontologies within the annotation graph._ For example, for the scholarly editions case study, we use custom properties to link target documents to FRBR entities, allowing us to query and retrieve annotations across multiple versions of the same FRBR expression or work. The main weaknesses of the OA model that we have identified are:

* _The relative complexity of the OA model_ for basic use cases. It is possible that many developers who want to implement simple tagging of Web pages or whole digital resources, will find the OA model too complex for their needs and hence it will not be widely adopted. (On the other hand it is the flexibility afforded by such complexity that enables the OA model to represent complex scholarly annotation use cases, that simpler models like Annotea are not capable of supporting.) * _The ambiguity that exists within the model_. For example, there are multiple ways to represent resource segments. Such ambiguity increases the development effort required to produce tools that fully implement the model. For example, for annotations on part of an image, the image segment could be specified: using an _SVGSelector_ (with a _constrains_ relationship to the image URI); using a media fragment identifier in the target URI (with an is_PartOf_ relationship to the image URI); or using a media fragment expressed as a oa:_FragmentSelector_. In all three cases there is no direct link from the annotation object to the image URI, so a query to retrieve all annotations on a given image must examine the target URI (for \"whole of image\" annotations), as well as URIs related via properties. * _The explosion of URIs_. The Semantic Web/Linked Open Data approach adopted by OA, recommends that every resource (Bodies, Annotations, Targets, Selectors, States, Styles) is accessible on the Web via a persistent URI. Annotation authoring and management tools will need to create, track and manage large numbers of URIs. * _The current OA model does not support multiple Bodies_--only multiple Targets. A common situation that we found in our case studies is the need to attach both multiple semantic tags (or keywords), as well as a textual description to a resource, within a single annotation event. The current model recommends that you create multiple separate annotations. But this creates redundancy and also does not accurately reflect the annotation event. An alternative approach is to attach the textual description as an inline Body and to use the \"hasSemanticTag\" property to attach the semantic tags. As discussed in the next bullet point, we don't support the \"hasSemanticTag\" property that is currently included in the Extension ontology as it is inconsistent with the existing class and property hierarchy. * _Lack of Support for multiple Semantic Tags_. A _SemanticTag_ should ideally be defined as a subClass of the _oa:Annotation_ class in the Extensions ontology. In addition, the Core OA ontology should allow multiple Bodies to be defined. These two changes would enable the model to support the use case that we describe above, and simultaneously maintain a well-structured and consistent ontology.