Now that we will have a way (hasRole) to express roles for instances of EmbeddedContent and SpecificResource (at least), the question has arisen as to whether the Annotation-level motivatedBy property needs to be retained. For additional background and context regarding this question see [annotation-roles], in particular Section 3.2.5 Remove motivatedBy completely. This proposal also has implications for the resolution of the proposal raised in Section 3.2.6 Use motivation instead of role.
This position paper proposes that the Annotation-level motivatedBy property be retained in order to support certain common, intuitive and compelling use cases, enumerated and illustrated in Section 3 below. The consensus of the Editors of this position paper is that these use cases provide sufficient reason to retain the Annotation-level motivatedBy property. To be clear, as the illustrations in Section 3 show, we see the Annotation-level motivatedBy property as useful for expressing information that is distinct from (albeit typically complementary to) the information expressed using the hasRole property of a SpecificResource or EmbeddedContent object/resource within an Annotation.
The trade-off in retaining this property is modest. To the extent that the Annotation-level motivatedBy property can express information related to the information expressed via the SpecificResource / EmbeddedContent hasRole property, there is a risk that some implementers will conflate the two properties resulting in assertions that are misplaced, potentially redundant, or worse yet contradicatory. There could also be some performance impact for agents (in certain use cases) having to check for both Annotation-level motivations and Body/Target-level roles. Strategies are available to help mitigate such risks, for example, by maintaining separate property labels and possibly separate ontologies we can emphasize the distinctions in semantic meaning between motivatedBy (Annotation-level property) and hasRole (Body/Target-level property). It is also worth noting that many specific use cases (e.g., 3.2 and 3.3 below) may lend themselves to using one or the other of these two properties alone (rather than needing both). Retaining both properties retains important flexibility and supports keeping simplest Annotations simple.
In developing this proposal paper additional use cases were identified and rejected as justifications for retaining the Annotation-level motivatedBy property. These other possible uses of motivatedBy at the Annotation-level are enumerated and illustrated in Section 4 below. These use cases were rejected because for each of these use cases one or more of the Editors felt the use case semantically unsound, semantically inconsistent with the other use cases identified, and/or having the potential for negative semantic consequences if allowed. These use cases are not proposed or recommended, and should not be relied on to justify retaining the Annotation-level motivatedBy property. They are included only for completeness and in case others want to argue their validity.
The December 2014 First Public Working Draft (FPWD) of the Web Annotation Data Model
[annotation-model]
defines the motivatedBy property as follows:
"In many cases it is important to understand the reasons why the Annotation was created,
not just the agents involved.... Each Annotation should have at least one oa:motivatedBy
relationship to an instance of oa:Motivation, which is a subClass of skos:Concept."
In the FPWD motivatedBy is a property of the Annotation (only). An extensible ontology of
Motivations s provided in the FPWD, including terms such as, "oa:commenting - The
motivation that represents a commentary about or review of the Target resource(s). For
example to provide a commentary about a particular PDF."
If retained, the definition of motivatedBy given in the Data Model will need to be revised slightly to align / differentiate its use as compared to the hasRole property as used on EmbeddedContent and SpecificResource and to clarify when it is not applicable. A determination will need to be made whether potential values for the Annotation-level motivatedBy property are coincident with, overlapping with, or distinct from values appropriate for expressing the role of EmbeddedContent and SpecificResource objects used as Annotation bodies and targets. Further discussion is required before a new definition can be written and ontological constraints decided.
Expressing the motivation for the annotation as a whole is distinct from expressing the role played by bodies and targets within the annotation. motivatedBy on the Annotation is an *additional* feature to the uses of hasRole on bodies and targets, which serves a different purpose than, or may be orthogonal to or complementary to the use of hasRole on a Body or Target resource. The two properties have different semantic meanings. The two properties can in some cases be applied independently -- i.e., it is not required to use both predicates in an annotation. Or, they may both appear within the same annotation. In the latter case they can provide useful, complementary information.
In this first illustration the annotation as a whole is motivated by reviewing (a possible new Motivation) while the role of each body is different, in this case more granular, e.g., commenting and describing. Compare to illustration 3.1.6 Multiple Bodies Example from the annotation-roles document.
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"motivation": "reviewing",
"type": "Annotation",
"target": "http://example.org/target1" ,
"body": [
{
"role": "commenting",
"source": "http://example.org/body1"
},
{
"role": "describing",
"source": "http://example.org/body2"
}
]
}
<http://example.org/anno1> a oa:Annotation ;
oa:motivatedBy oa:reviewing ;
oa:hasTarget <http://example.org/target1> ;
oa:hasBody
[oa:hasRole oa:commenting ;
oa:hasSource <http://example.org/body1> ],
[oa:hasRole oa:describing ;
oa:hasSource <http://example.org/body2> ] .
This second illustration highlights the distinction between motivatedBy (Annotation) and hasRole (Body/Target) through the part of speech of the values chosen, suggesting the potential to use different ontologies to help distinguish these properties. Compare to illustration 3.1.7 Multiple Bodies Example (2) from the annotation-roles document.
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"type": "Annotation",
"motivation": "editing",
"body": [
{"role": "tag", "text": "correction"},
{"role": "tag", "text":"typo"},
{"role": "comment", "text": "wow...I should learn to type..."},
{"role": "replacement", "text": "itinerary"}
],
"target": "http://example.org/doc1#fragid"
}
<http://example.org/anno1> a oa:Annotation ;
oa:motivatedBy oa:editing ;
oa:hasTarget <http://example.org/doc1#fragid> ;
oa:hasBody
[oa:hasRole oa:tag;
oa:text "correction"] ,
[oa:hasRole oa:tag;
oa:text "typo"] ,
[oa:hasRole oa:comment;
oa:text "wow...I should learn to type..."] ,
[oa:hasRole oa:replacement;
oa:text "itinerary"] .
Benefits: Provides maximum flexibility and expressiveness; the annotator can express motivation of the annotation only, the role/motivation of the body/target only, or both as appropriate.
Caveat: As discussed above it is important that motivatedBy and hasRole not be conflated or seen as two ways to make the same assertion.
Bodies are not required. In the absence of a Body, the affordances of an Annotation-level motivatedBy property helps offset the sparseness of the Annotation description. Compare to illustration 3.1.8 Target with Role Example from the annotation-roles document.
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"type": "Annotation",
"target": "http://example.org/target1" ,
"motivation": "bookmarking"
}
<http://example.org/anno1> a oa:Annotation ;
oa:hasTarget <http://example.org/target1> ;
oa:motivatedBy oa:bookmarking .
Benefits: Preserves ability to express motivations in absence of a Body.
Caveat: May not be necessary if a suitable role can always be associated with the Target in all use use cases lacking a Body.
As in 3.2 above, the expressiveness of an Annotation motivatedBy property is a counterpoint to the sparseness of the Annotation and avoids the need to resort to EmbeddedContent in order to provide additional information. Keeps the serialization of this Annotation simple. Compare to illustrations 3.1.2 Text Example and 3.1.10 Literal Bodies Cannot Have Roles from the annotation-roles document.
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"type": "Annotation",
"motivation": "commenting" ,
"target": "http://example.org/target1" ,
"body": "A literal string comment."
}
<http://example.org/anno1> a oa:Annotation ; oa:hasTarget <http://example.org/target1> ; oa:motivatedBy oa:commenting ; oa:hasBody "A literal string comment" .
Benefits: The single literal body (Simple Textual Body) annotation is a common use case; this keeps the modeling and serialization extremely lightweight while still allowing the annotator to express motivation.
Caveat: Expressing a motivation for the annotation as a whole is semantically not the same as expressing the role of the Body; implementers may tend to gloss over this distinction and conflate motivatedBy and hasRole (as they do now in absence of the Body hasRole property in the current data model).
A use case identified but considered unsound with the potential for negative semantic consequences if allowed is to use Annotation-level motivatedBy as a simple way (from serialization perspective) to express Body role when it is the same for all Bodies in a multi-body annotation. This avoids having to turn each Body into a SpecificResource or EmbeddedContent. In essence this is an attempt to inheriet motivation / role. The Editors do not recommend this use case.
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"type": "Annotation",
"motivation": "commenting" ,
"target": "http://example.org/target1" ,
"body": [
"Literal string comment 1.",
"Literal string comment 2.",
"Literal string comment 3."
]
}
<http://example.org/anno1> a oa:Annotation ; oa:hasTarget <http://example.org/target1> ; oa:motivatedBy oa:commenting ; oa:hasBody "Literal string comment 1" ; oa:hasBody "Literal string comment 3" ; oa:hasBody "Literal string comment 3" .
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"type": "Annotation",
"motivation": "describing" ,
"target": "http://example.org/target1" ,
"body": [
{"id": "http://example.org/body1"},
{"id": "http://example.org/body1"},
{"id": "http://example.org/body1"}
]
}
<http://example.org/anno1> a oa:Annotation ; oa:hasTarget <http://example.org/target1> ; oa:motivatedBy oa:commenting ; oa:hasBody <http://example.org/body1> ; oa:hasBody <http://example.org/body2> ; oa:hasBody <http://example.org/body3> .
The use case of having an Annotation-scoped default motivation was identified but seen as semantically different than other use cases identified with the potential for negative semantic consequences if allowed. This use case attempts to leverage Annotation-level motivatedBy as a way to express the default role / motivation of any Body (and Target?) in the Annotation not having an explicit role / motivation. This reduces verbosity. In the illustration it is intended that the role of bodies 1 and 3 is commenting.
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"type": "Annotation",
"motivation": "commenting" ,
"target": "http://example.org/target1" ,
"body": [
"Literal string comment (body 1).",
{ "role": "questioning",
"text": "I have a question about this example (body 2)."},
{ "id": "http://example.org/body3"},
{ "role": "describing",
"source": "http://example.org/body4" }
]
}
<http://example.org/anno1> a oa:Annotation ;
oa:hasTarget <http://example.org/target1> ;
oa:motivatedBy oa:commenting ;
oa:hasBody "Literal string comment 1" ;
oa:hasBody [ oa:hasRole oa:questioning ;
oa:hasText "I have a question about this example (body 2)."] ;
oa:hasBody <http://example.org/body3>;
oa:hasBody [ oa:hasRole oa:questioning ;
oa:hasSource <http://example.org/body4>] .
The use case of having an Annotation-scoped fallback motivation was identified but seen as semantically different than other use cases identified with the potential for negative semantic consequences if allowed. This use case attempts to leverage Annotation-level motivatedBy as a way to express the fallback role / motivation of all Bodies (and Targets?) in the Annotation. This would be used when associating community-defined (not in oa namespace) roles with Bodies and Targets. Consuming agents unfamiliar with the community-specific roles would assume the Annotation-level motivatedBy as fallback motivation for all Bodies (and Targets?).
{
"@context": "http://www.w3.org/ns/anno.jsonld",
"id": "http://example.org/anno1",
"type": "Annotation",
"motivation": "commenting" ,
"target": "http://example.org/target1" ,
"body": [
{ "role": "ex:copyEditorRemark",
"text": "I have a question about this example (body 1)."} ,
{ "role": "ex:seriesEditorReview",
"source": "http://example.org/body2" }
]
}
<http://example.org/anno1> a oa:Annotation ;
oa:hasTarget <http://example.org/target1> ;
oa:motivatedBy oa:commenting ;
oa:hasBody [ oa:hasRole ex:copyEditorRemark ;
oa:hasText "I have a question about this example (body 2)."] ;
oa:hasBody [ oa:hasRole ex:seriesEditorReview ;
oa:hasSource <http://example.org/body2>] .