## 1 Introduction and Background
### The Merged Open Annotation Model (OA)
\begin{table}
\begin{tabular}{c c c} \hline \hline \multirow{2}{*}{**Feature**} & \multicolumn{2}{c}{**Model**} \\ \cline{2-3}  & \multicolumn{2}{c}{**OAC**} & \multicolumn{2}{c}{**OA**} \\ \hline Provenance & Recommendations use of Dublin Core _creator, created_ _etc._ & \begin{tabular}{c} Defines provenance properties, distinguishing between annotator and generator \\ \end{tabular} \\ \hline Annotation types & \begin{tabular}{c} Defines two subtypes of _oac:Annotation_: \\ (1) _oac:Reply_ and (2) _oac:DataAnnotation_. \\ OAC encourages subtyping. \\ \end{tabular} & \begin{tabular}{c} Common subtypes described in OAX rather than the core model. Provides guidelines for subtyping. \\ OA recommends explicitly including _oa:Annotation_ type for all annotations. \\ \end{tabular} \\ \hline \begin{tabular}{c} Equivalent serializations \\ \end{tabular} & No equivalent concept in OAC. & \begin{tabular}{c} Defines _equivalent_ property for maintaining a relationship between re-published copies of an annotation \\ \end{tabular} \\ \hline Body & Does not specify cardinality of annotation bodies. & \begin{tabular}{c} Explicitly allows annotations without a body, does not allow multiple bodies. \\ \end{tabular} \\ \hline Resource segments & \begin{tabular}{c} Recommends use of Fragment URIs for target and body resources, with a _dcterms:isPartOf_ \\ relationship to base resource. \\ \end{tabular} \\ \hline State & \begin{tabular}{c} _ConstrainedTarget_ and _ConstrainedBody_ with \\ _oac:constrains_ allow other types of segment \\ descriptions to be specified via the _oac:constrainedBy_ property. \\ \end{tabular} \\ \hline State & No equivalent concept in OAC. & \begin{tabular}{c} Defines a number of constraint types including _oac:OffsetRangeConstraint_, \\ _oac:PrefixPostfixConstraint_, \\ _oac:SysConstraint_, _oac:WebTimeConstraint_ \\ and _oac:ContextConstraint_. \\ \end{tabular} \\ \hline State & No equivalent concept in OAC. & \begin{tabular}{c} Defines _oa:hasState_ which associates an _oa:State_ with an _oa:SpecificResource_ to allow clients to retrieve the correct representation of the resource (e.g., version, format, language etc). \\ \end{tabular} \\ \hline Style & No equivalent concept in OAC. & \
\begin{tabular}{c} Defines _oa:hasStyle_ which associates an _oa:Style_ with an _oa:SpecificResource_ to enable hints to be provided to the client recommending how to display the _Annotation_ and/or _Selector_. \\ \end{tabular} \\ \hline Extensions & No equivalent concept in OAC. &
\begin{tabular}{c} Splits the model into a stable core (OA), and extension (OAX), which may change. OAX includes subtypes of _Annotation_, _Selector_, _State_ and _Style_, _hasSemanticTag_ and support for Named Graphs for structured data. \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison of Open Annotation Collaboration (OAC) and OA models. including HTML/XML IDs, XPointers, or W3C Media Fragments, and _SVGSelector_ for describing image regions. _State_ captures contextual information about a Target resource when the annotation was attached, to assist clients in retrieving the correct version or representation of the Target resource as it existed at the time of annotation. For example, the _State_ information ensures the appropriate MIME type is retrieved, if the same URI can return different representations via HTTP content negotiation. _Style_ is used to provide hints to an annotation client about how an annotation should be displayed, which is useful in applications where color or formatting of the annotation markers needs to be persistent. _Selectors_, _States_ and _Styles_ can be specified inline (as for the body of this annotation), or by reference using a URI or URN. _Selectors, States and Styles_ can also be applied to a _SpecificResource_ representing the _Body_ of an _Annotation_.