Re: Proposal to keep motivatedBy as a property of Annotation

+1 overall, with 3.2 being the most convincing and 3.1a being a reasonable
use case, ... with some caveats:

* The risk of implementers using motivatedBy for unintended purposes is
very, very high.  In a current project, two developers built tagging
systems from the current OA spec. One built their code around motivatedBy
tagging, and the other around the (current) classes of Tag and
SemanticTag.  When these assumptions were reflected into the serialization
of tags, it resulted in non-interoperable systems *built within the same
project*.  We must be *very* clear as to the usage of motivatedBy versus
hasRole and stick to the semantics consistently.

* 3.1 suggests that there could be two separate vocabularies (motivations
and roles).  I think this would result in utter confusion as to which to
use in which situation, and would require extensions to double the number
of things created.  Or, if there were some motivations that weren't roles,
there would be a lot of discussion about where individual entries belong.
Freedom from choice is better for progress and adoption, in this case.  So
I'm -1 to the second example in 3.1.

* 3.3 crosses the line (for me) in the semantics, and I would prefer it on
the rejected pile.  It is the same use case as the rejected 4.2 default
motivation:  there is a body, which does not have a role. In 3.3 it doesn't
have a role because it's a literal and can't have any properties at all.
In 4.2 it just doesn't have one.  If 4.2 is out, then 3.3 should be out
too.  So I'm -1 to 3.3 being in scope, as it brings 4.2 in scope and makes
the semantic distinction between role and motivation so blurred as to be

In other words, I would prefer something along the lines of:

An Annotation can be motivated by one or more Motivations that express the
reason why the annotation was created.  A body or target can play exactly
one Role within an Annotation.  The motivation of an Annotation is
completely unrelated to the Role of body or target, regardless of whether
they are explicitly included in the graph or not.

Then there is a clear separation of concerns, and implementers can check
for body.role  (or body.content.role) without worrying about the motivation.


On Tue, Sep 8, 2015 at 12:36 PM, Paolo Ciccarese <>

> +1 I also support to keep motivatedBy
> On Tue, Sep 8, 2015 at 3:13 PM, Frederick Hirsch <> wrote:
>> (not as chair)
>> +1 to proposal to keep motivatedBy for oa:Annotation in addition to
>> roles, with support for adding clarification text to the model
>> specification.
>> Bookmarking without body and other examples are compelling.
>> Thanks for the clear write-up. We need to coalesce the non-valid use
>> cases into a paragraph of warning if the proposal is adopted.
>> regards, Frederick
>> Frederick Hirsch
>> @fjhirsch
>> > On Sep 6, 2015, at 6:41 PM, Timothy Cole <> wrote:
>> >
>> > You'll recall from the results of the CFC and the discussions we had on
>> the WG's 2 September call (
>>, that we decided
>> to go forward with the approach for adding role to SpecificResource and
>> EmbeddedContent objects as outlined in Section 3.1 of
>> However, 1 or 2 of the issues outlined in section 3.2 (Further
>> Considerations) of that document remain to be resolved before model can be
>> updated.
>> >
>> > Ivan, Ray and I took a look at one of these open issues, 3.2.5 Remove
>> motivatedBy [as a property of oa:Annotation] completely.  In the end we
>> created an additional page providing use cases / illustrations of why we
>> think we need to retain the Annotation-level motivatedBy property:
>> >
>> >
>> >
>> > Please take a look at this page and offer comments, counter-point
>> arguments, agreement, etc. as appropriate. Feel free to respond directly on
>> this thread if that makes most sense.
>> >
>> > In summary, we concluded that Annotation-level motivatedBy property
>> should be retained in order to support 3 relatively common, intuitive and
>> compelling use cases:
>> >
>> > ·         Needing to express Motivation of the Annotation as a Whole
>> (as distinct from expressing the role of an individual body or target)
>> > ·         Needing to express Motivation in the Absence of a Body
>> > ·         Needing to express Motivation for an Annotation having a
>> Single, Simple Textual Body (and thereby obviate the need to transform
>> Simple Textual Body into SpecificResource or EmbeddedContent)
>> >
>> > Key to this discussion are the questions of
>> > 1.       whether these uses are important or minimal now that we can
>> express the role of individual SpecificResource and EmbeddedContent
>> objects, and
>> > 2.       whether there is a high or low risk of developers confusing
>> Annotation motivatedBy and SpecificResource hasRole and as a result create
>> Annotations that are difficult to understand / process when aggregated.
>> >
>> > Thanks,
>> >
>> > Tim Cole
>> > University of Illinois at UC
> --
> Dr. Paolo Ciccarese
> Principal Knowledge and Software Engineer at PerkinElmer Innovation Lab
> Assistant Professor of Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital

Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305

Received on Tuesday, 8 September 2015 20:59:47 UTC