Justify each Motivation with a behavior

[shepazu]

Currently, we have 13 motivations (to be used as a set of values for the Motivation and role/motive properties):
bookmarking, classifying, commenting, describing, editing, highlighting, identifying, linking, moderating, questioning, replying, reviewing, tagging.

I have no problem with any of these values, but at least some of them seem arbitrary… that is, what distinguishes them from any other perfectly reasonable value (or rough synonym for any of the existing values)?

My suggestion is that we establish a core set of motivations that are distinguished by their expected behavior in UAs, either in terms of processing or presentation, and that other values are considered as subsets of those core motivations.

For example, commenting, tagging, replying, highlighting, and editing have each been described, in some conversations (though not in the spec) as having a unique presentation style, and in some cases, unique action options for end users. I'm not suggesting we mandate those behaviors, but we could describe examples that a UA might use as inspiration.

This makes it easier for implementations to know how to apply a motivation to each body or target, and how to process each of them; by describing concrete behaviors, it also helps users to understand these motivations.

It also lets communities that have a specific set of motivation terms use those, and simply map them to ones that the UA "understands"… since we can't serve every community (or language), we simply define behaviors and actions, and not shades of meaning. If some particular motivation is not understood by a UA, it could default to treating it like a commenting body.

[jjett]

-1

We discussed this kind of normative work with @tilgovi at length back in October. The primary problem that I can see is producing the requisite user warrant to adequately interpret each motivation in a consistent way. Some of the motivations are so vague we have no way to determine if they are the same or different (e.g., What is the difference between commenting and replying? Why say 'commenting' instead of 'remarking'?).

This will also inevitably cause collisions when other communities extend with their own motivations.

I am sympathetic to your goal though. Good ontologies require that both the writers and the software agents make certain ontological commitments which then shape behavior. One of the problems with our work here (and work all across the W3C from what I can see) is that we avoid commitments like the plague. Which of course begs the questions of what we expect servers to do with annotations and how can be possibly build a useful API is the goalposts are obfuscated behind waving hands.

Nevertheless, developing normative behavior based on motivations isn't a good idea. However, we might reexamine an alternative approach that was suggested by Bob (and Phil) Morris (not related) specifically for the editing use case years ago. You won't like it though. It makes a complex model even more complex.

Bob's (and Phil Morris's) suggestion was an additional property on annotation called "expectation" that worked in conjunction with motivation by specifying what kind of behavior the user expected to be taken. (E.g., execute my edit.) We could "normalize" the behavior of motivations by using this one-two combination of motivation and expectation (which roughly interprets to 'by A I mean do B'). This is a really ugly solution (and was voted down almost instantly by the community group) but it does sidestep the user warrant problem for interpreting motivations.

Regards,

Jacob

---

Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

[azaroth42]

👎 to requiring explicit UA functionality for every motivation. Behaviors of different clients could be very very different with the same data, and we don't want to inhibit innovation and progress.

Also 👎 to spending time debating in the WG which motivation is "core" and which is somehow not. This set is based on research done over several years, by participants in the OA CG, the WG and beyond. That research was done by looking at existing clients and their use, observing people's interactions, and looking at existing models. Unless someone is willing to re-do that work?

[BigBlueHat]

Agreed. 👎

I'm not sure it's within scope of the Model spec (certainly) to define (even non-normatively) prescriptions of use for motivations.

Certainly the world of implementors can and should blog (et al) about how they're using them in (and out) of their UI, and it is perhaps (and perhaps intentionally) the place where the widest array of variation will be found...but again...that's why it's written the way it is (citing Jacob's mention of October's similar chat from the other perspective).

[iherman]

On 20 Nov 2015, at 19:43, Jacob notifications@github.com wrote:

-1

We discussed this kind of normative work with @tilgovi https://github.com/tilgovi at length back in October. The primary problem that I can see is producing the requisite user warrant to adequately interpret each motivation in a consistent way. Some of the motivations are so vague we have no way to determine if they are the same or different (e.g., What is the difference between commenting and replying? Why say 'commenting' instead of 'remarking'?).

This will also inevitably cause collisions when other communities extend with their own motivations.

I am sympathetic to your goal though. Good ontologies require that both the writers and the software agents make certain ontological commitments which then shape behavior. One of the problems with our work here (and work all across the W3C from what I can see) is that we avoid commitments like the plague. Which of course begs the questions of what we expect servers to do with annotations and how can be possibly build a useful API is the goalposts are obfuscated behind waving hands.

Nevertheless, developing normative behavior based on motivations isn't a good idea. However, we might reexamine an alternative approach that was suggested by Bob (and Phil) Morris (not related) specifically for the editing use case years ago. You won't like it though. It makes a complex model even more complex.

Although your comment was for @shepazu, I would not like it either;-) Exactly for the reason you quote: let us not add an extra complication to the model...

Bob's (and Phil Morris's) suggestion was an additional property on annotation called "expectation" that worked in conjunction with motivation by specifying what kind of behavior the user expected to be taken. (E.g., execute my edit.) We could "normalize" the behavior of motivations by using this one-two combination of motivation and expectation (which roughly interprets to 'by A I mean do B'). This is a really ugly solution (and was voted down almost instantly by the community group) but it does sidestep the user warrant problem for interpreting motivations.

Regards,

Jacob

Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu mailto:jjett2@illinois.edu
—
Reply to this email directly or view it on GitHub #113 (comment).

[iherman]

Agreed.

I'm not sure it's within scope of the Model spec (certainly) to define (even non-normatively) prescriptions of use for motivations.

I agree with that. It can lead to endless discussions and would be almost impossible to get a consensus by everyone.

The model allows the end user or specific communities to add their own motivations (in RDF terms, by adding a new instance of a specific type; in JSON-LD term by adding an extra, community specific @context with the mapping). But without having a core we end up by an increased incompatibility, so we need such a core. Not having been part of earlier discussion I yield to the discussion that did happen over several years (as mentioned by @azaroth42) on what such a core could be, and I would prefer to leave things as they are.

(Beware of the danger of bikeshedding…)

Certainly the world of implementors can and should blog (et al) about how they're using them in (and out) of their UI, and it is perhaps (and perhaps intentionally) the place where the widest array of variation will be found...but again...that's why it's written the way it is (citing Jacob's mention of October's similar chat from the other perspective).

[shepazu]

👎 to requiring explicit UA functionality for every motivation.
Behaviors of different clients could be very very different with
the same data, and we don't want to inhibit innovation and progress.

I didn't suggest that we created normative requirements on UAs to exhibit specific behaviors.

What I'm suggesting is that as a best practice for adding a motivation value to the list, we create a concrete use case (or set of use cases) that show how a UA behavior for each motivation value might be distinct from any of the other motivation values.

If a motivation value isn't behaviorally distinct, that wouldn't mean it's not valuable or useful, just that it should be left up to each user community to define which behavior is the best match for its intended use.

Using this methodology, most custom motivation values would probably map to the simple "display" behavior of a commenting motivation. For example, @jjett's preference of remark could be a subset of commenting… distinct to the terminology of his user community and his toolchain, but still defined in a way that any generic annotation UA would know what to do with it (e.g. treat it like a commenting body.

You could look on the "core" as a set of exemplars, with extensions as a loose typing (isKindOf) mechanism.

This doesn't inhibit innovation and progress, it enables it in a responsible and interoperable way.

Also 👎 to spending time debating in the WG which motivation
is "core" and which is somehow not.

I also don't us want to debate terms… I want us to establish a methodology to determine the motivation value list.

At TPAC, @azaroth42 suggested adding another motivation value, but we had no basis for deciding whether to add it, other than the wholly subjective, "Does it seem common enough to add it?", a point on which the participants were divided.

Having a methodology would put less guesswork and subjective judgment into the process of adding new values, and having the bahavior-backed core would provide a clear extension mechanism that empowers each community to use its own terms.

This set is based on research done over several years, by
participants in the OA CG, the WG and beyond. That research
was done by looking at existing clients and their use,
observing people's interactions, and looking at existing
models. Unless someone is willing to re-do that work?

There's no need to redo the work… we could look at the existing research and apply a new set of criteria on each one. Where is the research collected? I couldn't find it in the Open Annotation CG wiki.

I hope this additional context helps explain my reasoning.

[iherman]

In any of these documents the list of such values is based on rough consensus, because it is very difficult (and/or time consuming) to make a very systematic case for every term that is added or not. My proposal (also motivated by the priorities we have to set for our own time and work) is:

1. We keep the current set intact as part of the document. As I said before, we should give the benefit of the doubt for a group of people who have already discussed this in the OA Community Group.
2. There will be a Candidate Recommendation phase, which is the time when developer and/or users would, among other things, use those terms and possibly come up with new ones. We can explicitly call out, when going to CR, that we expect implementers to propose new terms (for motivations as well as for roles). The methodology described by @shepazu, i.e., to ask for a clear use case for a new value, would be guiding and we can then decide whether we agree in adding those or not.

That being said, in @shepazu's approach, it says:

What I'm suggesting is that as a best practice for adding a motivation value to the list, we create a concrete use case (or set of use cases) that show how a UA behavior for each motivation value might be distinct from any of the other motivation values.

I am not sure what "OA behavior" means in this respect. I can very well imagine that two different motivations may not need to any difference in OA behavior, it simply helps the user of an application to categorize his/her annotations. I do not see these values as defining, necessarily, a behavior for an application. Ie, I would prefer to ask for a clear use case for a new term that is clearly different than what is already there and is not very application specific before adding it to our list.

However, I do not think we should discuss this criterium in detail right now. If and when a proposal comes up during Candidate Recommendation phase, we will discuss it on its individual merit and establish a (rough) consensus. Let us defer this when we face real proposals.

This allows us to move on right now.

[fhirsch]

+1 to Ivan

[tilgovi]

I don't think the purpose of this group is to rubber stamp what the community group has done. If work was done to achieve consensus on the use of motivations and the set of values we should re-articulate it, link to it, and offer support or refutation of it. Giving the community group the benefit of the doubt means that we should expect that their decisions were justified, but if those justifications can't be easily found and presented we should consider the existing motivations suspect.

[gsergiu]

I give a +1 to @shepazu 's proposal. basin on my comment in #112

By now ... motivation has near 0 value for the computer and a vague clue for to the user, indicating why another user chose to create the annotation... (by now ... motivation seems to be nothing more than a simple tag ...)

In my opinion motivation values should come from a controlled vocabulary, which define clear meanings for the machines (e.g. see for example the simple embedded tagging vs. semantic tagging problem).

I do support the idea that the Motivation should encapsulate the concrete relationships between body, target and external resources.
In my opinion, the old definition/explanation of annotation stating 'the body is most frequently somehow "about" the target' starts to get deprecated.

With the introduction of "roles", the specification starts to emphasize that: "The exact nature of this relationship changes according to the intention of the annotation". (in which I suppose that the intention is what we store in the motivation field)....

Br,
Sergiu

[gsergiu]

Another modeling argument/question.
In the specifications Motivation is a class, but there is no more that 1 attribute for the class, its name.
Why is Motivation a Class and not a String in this case? Isn't it because motivation is expected to be more than what is specified now?

Br,
Sergiu

[rtroncy]

@gsergiu, I also commented #112 but I have a different conclusion than you. I think you're confused. Motivation values are controlled terms with a well-defined semantics. Practically, there are skos:Concept defined in a concept scheme, see http://www.w3.org/ns/oa#namedindividuals for the formal definition. Motivations are not tags! How did you come to this conclusion?
I think the problem lies in using motivation and role at the same time with possible values that are potentially contradictory.