Sub-classing

Problem: Sub-classing presents two problems.

(1) Without both a strong set of Core sub-classes and well developed best practices, there is a strong risk of proliferation of annotation sub-types being created to fulfill domain specific use cases.

(2) There seems to be some conflation between the intension(1) of an annotation and intention(2) of the agent creating the annotation.

Use Cases

There are several relevant use cases where it is more useful to decouple motivation and expectation from the annotation's sub-class in order to make both properties actionable independently of both one another and the annotation's sub-class/class. These use cases include:

• Document editing / galley proofing - separate motivations and expectations to provide explanations and expected courses of action
• Change management - explicit communication of expectation very important
• Scholarly discourse - explicit communication of motivation very important

Sub-class Use Case

With the addition of motivation and expectation it might seem like we no longer need sub-classing; however, sub-classing annotations can still be useful for retrieving sets of annotations. While the current specification talks about classes in terms of motivations and expectations (reasons why the annotation was made) some of us are still using sub-classes to retrieve annotations much as we did with the OAC specifications, see here.

There is still a need for this type of functionality in the specification. Consider the following use case.

I'm a scholar working with a medieval manuscript in a large repository of manuscripts. As I work I frequently highlight passages that I intend to come back to and annotate further (or at least consider for further annotation, or to use as a body for an annotation, or etc.). Highlighting is not the only type of annotation activity I perform in the repository. It is useful to me to go back and retrieve my highlight annotations to carry out further work with the highlighted passages. It is easier to retrieve all of my highlight annotations if they are a specific type of annotation, e.g., oax:highlight rather than going to the trouble of using a query that searches for all of my annotations which do not have an oa:hasBody.

Potential Solutions

(1) An additional annotation property 'Motivation' could be introduced. Details on what this could look like can be seen in earlier drafts of the OA Core specification. This would not replace the annotation class but rather supplement it by providing a node to record and communicate annotator purpose.

(1a) Related to this, an expectation property could also be introduced. Details on what this could look like can also be seen in earlier drafts of the OA Core specification; however, this property does seem to overlap very heavily with Annotation typing.

• it was suggested at one point that some of specific data-typing functions of expectation could be carried out via hasStyle, with specific styles for machines, IIRC, this is probably no longer the case as XSL is not something that can be communicated via oa:hasStyle (JGJ)

Related Discussion

Some of the sub-types discussed during OAC's July Project Review Meeting can be found in the Incubator.

Proposed Solution

Sub-classing as it is currently used to type annotations conflates to many competing properties. This multi-part solution recommends the creation of two additional annotation properties and modification of the definition of sub-classing in the spec to more narrowly scope its use.

(1) Additional properties for oax:hasMotivation and oax:hasExpectation are added to the oax extensions specification. These are needed because there are multiple use cases where conflation of these properties into the annotation's sub-class presents serious problems because the properties being conflated are not actionable when bound to the sub-class.

(2) The definition for sub-class is modified such that it qualifies the scope of oa:annotation. Sub-classes of oa:annotation MUST be limited to structural variations of an oa:annotation that (1) disallow certain properties (e.g., oax:highlight - oa:hasBody MUST be 0), (2) require certain properties (e.g., oax:tag - oa:hasSemanticTag MUST be 1 or more) and (3) require a specific cardinality for certain properties (e.g. oax:comparison -- oa:hasTarget / oa:hasSpecificTarget MUST be 2 or more)