Re: CFC: Basic Roles Proposal

Hi, Ray, Rob–

If one of our goals is simplicity of understanding (and making it harder 
for implementors or authors to make mistakes), we really should also 
accept Rob's proposal that we drop "motivation" on Annotation, and only 
allow it on Bodies and Targets. Otherwise, we get the potential 
conflicts you mention.


I think the term "role" is too broad and overloaded, and is likely to 
cause confusion about what it's for (it seems already to have confused 
Takeshi).

I don't think there's any meaningful difference between an annotator's 
motivation in creating a particular body or target, and the functional 
role that body or target plays. To be concrete, here are the currently 
defined motivations:

* bookmarking
* classifying
* commenting
* describing
* editing
* highlighting
* identifying
* linking
* moderating
* questioning
* replying
* tagging

I don't see any of those that would have a functional expectation in a 
client (that is, some behavior the client is likely to exhibit) that 
would be different than the annotation author's intent (or "motivation") 
in making the annotation; obviously, whether that behavior is invoked 
(e.g. an editor decides to accept a suggested change) is situational, 
but the motivation is the same.


So, I suggest that to keep things simple and clear, we keep the term 
"motivation" (or "motive"), and simply move it from Annotation to Bodies 
or Targets; in other words, it would not longer be valid on Annotation, 
but would be valid (but not required) on Body or Target.


Regarding "motivation" versus "motive". I suggest using the shorter of 
the two terms, which are effectively synonymous, and are the same part 
of speech. (In certain circumstances, like when someone's committed a 
crime, "motive" can have negative connotations, but not as a general 
rule.) Here's some definitions from the Free Dictionary:

Motivation:
1. Something that encourages.
2. Something that causes and encourages a given response.
3. A basis for an action or a decision.

Motive:
1. Something that causes a person to act in a certain way, do a certain 
thing, etc.; incentive.
2. The goal or object of a person's actions.


Why do I care if it's shorter?
* less likely to produce spelling mistakes
* fewer bits over the wire, fewer bits to store (4 characters * x bodies 
* x annotations)

(This is the same reason I'd prefer to use the verb form of motivations 
rather than the gerund form, but that's another conversation entirely.)


Regards–
–Doug

On 9/1/15 11:06 AM, Robert Sanderson wrote:
>
>
> On Tue, Sep 1, 2015 at 7:04 AM, Benjamin Young <bigbluehat@hypothes.is
> <mailto:bigbluehat@hypothes.is>> wrote:
>
>     On Tue, Sep 1, 2015 at 9:27 AM, Denenberg, Ray <rden@loc.gov
>     <mailto:rden@loc.gov>> wrote:
>
>         Rob – My thoughts on 3.1 really have to do with  the question I
>         asked yesterday.  It seems to me that we do not have a clear
>         understanding of the distinction between a motivation and role.
>
>
> To try and provide some spec-like text, assuming that motivations are
> only allowed on SpecificResources:
>
> A motivation is a resource that identifies the intent behind the
> inclusion of the source resource in the annotation.
>
>
>
>         None of the examples in 3.1 shows a motivation and of course
>         that’s because it’s about roles.  But I think there should be
>         examples that show both a motivation and one or more roles so we
>         can better understand the semantic relationship.
>
>
> Except that as per 3.2.5, we might want to remove motivation from
> annotation completely.  Hence I left them off the examples.  Also the
> motivation on the Annotation would just be the set of motivations on the
> specific resources.
>
>
>
>         ____
>
>         __ For example in 3.1.7 there are three roles (1) comparing (2)
>         antecedent (3)  subsequent
>
>         Clearly “comparing” is semantically the same as a motivation and
>         “antecedent” and “subsequent” are not.  So the annotation would
>         have the same meaning if “comparing” were to be listed as the
>         motivation with no role assigned to the body.
>
>
> I couldn't come up with a gerund for antecedent and subsequent :)  But
> the usage is the same -- the intent of the inclusion of the first target
> is that it is the thing being compared to the second target.  It's not a
> great example, I know, and would be happy to replace it with something else.
>
>         When this whole business came up (motivations on individual
>         bodies) it was to support the ability to, in a sense, combine a
>         lot of annotations into a single annotation, for efficiency.  I
>         think that idea was rejected, but the idea morphed into the
>         ability for  bodies to have “roles” in support of the
>         (annotation-level) motivation.   Is this an accurate
>         characterization?
>
>
> It's to provide more information on a per-body level, in the same spirit
> as Motivation does for single body annotations (and Tag/SemanticTag
> classes do in a hacky way for tags).
>
>
>         Take 3.1.1 for example.  The role is “commenting”.  That could
>         be expressed with commenting as the motivation, with no role on
>         the body.   I’m afraid that when people read this they are going
>         to wonder what is the semantic difference between these two
>         annotations, when there is none.
>
>
> Indeed! And hence I support 3.2.5 (though it should be split up to avoid
> conflating the renaming with removing motivation from the annotation)
>
>         So I would say, for one thing, if there is only one body, it
>         should not have a role, but that role should instead be
>         expressed as a motivation. I would say further that there should
>         be no roles expressed unless there is an annotation-level
>         motivation that the roles support.
>
>
>     I think this highlights the confusion that having both annotation
>     and body level motivation/roles is bound to create. It's quite
>     likely that if we put these in both places, there could be conflict:
>     an annotation marked as "editing" with bodies for "replying",
>     "tagging", and "highlighting."
>
>     We'd end up with scenarios where we'll need to enforce (somehow)
>     which bodies are available when the annotation uses a certain
>     motivation--which trends us back towards classes of
>     annotations...which I think has been dropped as an option a few times.
>
>
> Yes.  But regardless, none of the above is about the changes in section
> 3.1.  3.1 is intentionally silent about all of the changes in 3.2, and I
> tried to be as minimal in the examples as possible (causing some
> confusion, apologies, re language and format) to highlight only the role
> aspect.
>
> R
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

Received on Tuesday, 1 September 2015 16:14:00 UTC