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]

:-1: 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 :-1: 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. :-1:

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 https://github.com/w3c/web-annotation/issues/113#issuecomment-158487144.

[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]

:-1: 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 :-1: 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.

[gsergiu]

@rtroncy

Well ... I'm not sure how much I'm confused or not ... There are the proposed values for motivation: bookmarking, classifying, commenting, describing, editing, highlighting, identifying, linking, moderating, questioning, replying, reviewing, tagging.

These look for me very like tag labels ... especially when used in JSON-LD serialization. Yes, you are right, you have now definitions for all these lables. The most of these definitions follow the same pattern: "The motivation for when the user intends to the Target". I'm sorry if I'm to picky ... but these kind of definitions doesn't improve much the real semantic. The difference is more technical than semantic.

my real point is ... that the motivation and the "roles" should be consistent, not all combinations of motivation+target "role" + body "role" are valid. And this should be ensured through the model ... we shouldn't expect that any client defines which combinations are valid and which not!

In order to ensure this, it would be be better that this information is packaged in the same object (class). However, this has the drawback of imposing restrictions on multiple tags + multiple bodies kind of annotations (which I don't find to be a very useful usecase, however I have to admit that some stakeholders will chose to use them).

So .. given these, I think that an alternative solution would be to add targetRole and bodyRole attributes to the Motivation class, and to allow individual targets and bodies to declare a more specific term (i.e. norrower from a controlled vocabulary)

concretely the existing example: { "@id": "http://example.org/anno28", "@type": "Annotation", "body": [ { "role": "describing", "source": "http://example.org/description1" }, { "role": "tagging", "text": "tag1" } ], "target": [ "http://example.org/image1", "http://example.org/image2" ] }

should become: { "@id": "http://example.org/anno28", "@type": "Annotation", "motivation":{ "@id": "http://example.org/motivation/describing", "bodyRole": "describing", "targetRole": "depiction" }, "body": [ { "source": "http://example.org/description1" }, { "role": "tagging", "text": "tag1" } ], "target": [ "http://example.org/image1", "http://example.org/image2" ] }

[gsergiu]

@rtroncy if motivation is defined a skosConcept, I would expect to be able to visualize a skos xml representation, I would expect to see a hierarchical structure, with broader/norrower concepts, I would expect to see disjoint Concepts at each level in hierarchy ....

I'm sorry ... but for now I see the Motivation as being a simple list of labels and nothing more ...

PS: Is not my intention to say that Motivation is useless, quite the opposite, the motivation should be extended and get more attention ... for makinf clear and consistent speficitation for the purpose of annotations as a whole, and also for bodies and targets

[rtroncy]

I'm not sure why do you want an xml representation (any other machine readable format is fine), but it is anyway already available at http://www.w3.org/ns/oa.rdf. The current list of 12 motivations is indeed a flat list without skos:broader / skos:narrower axioms, but this is exactly an extension point for the ones who would like to extend this list and mint their own motivation, see also http://www.w3.org/TR/annotation-model/#extending-motivations that describes how the skos relationships properties should be used. SKOS concepts are not tags ... they can have definitions, usage notes, version, etc.

[gsergiu]

well .. I would expect to have a controlled vocabulary for Motivation that can be accessed in a machine readable format (skos.xml is one possible, or the preffered option).

Yes .. I saw the mechanism for extending Motivations, which indeeed recommends to create norrower terms and I appreciate that.

Still the question about the current list remains. Are these disjoint Concepts? For example: commenting, editing, describing, questioning, reviewing ... If they are not disjoint, and there is a relathipnship between them, why is this not represented in the model? (especially where they are defined as SkosConcepts)

[rtroncy]

There are skos:Concept ... how do you express disjointness in SKOS? You cannot ... on purpose.

[gsergiu]

I actually mean that there are relationships between Motivation entries (as they are not logically disjoint). These relationships should be expressed though SKOS broader/norrower properties.

BR, Sergiu

From: Raphael Troncy [mailto:notifications@github.com] Sent: Donnerstag, 17. Dezember 2015 13:34 To: w3c/web-annotation Cc: Gordea Sergiu Subject: Re: [web-annotation] Justify each Motivation with a behavior (#113)

There are skos:Concept ... how do you express disjointness in SKOS? You cannot ... on purpose.

— Reply to this email directly or view it on GitHubhttps://github.com/w3c/web-annotation/issues/113#issuecomment-165440732.

[gsergiu]

regarding the relationship between motivation .. see also the Bookmarking-Tagging example in #112

[azaroth42]

Unless someone is volunteering to do the work, I propose close wontfix

[gsergiu]

well ... if it is the scope of this ticket or not ... I do support the initiative of this ticket and I would like to help solving it. Only as I pointed out above, there are some related issues that should be solved before or together with this ticket. If we reject this ticket we will loose the interoperability between systems and ... this is a requirement in my case! (we have a centralized annotation backend that will integrate annotations collected by 4-5 different platforms).

We are doing some efforts in this direction map different internal representations to a "standardized" representation for each type of annotaion, and for reacing a common "understanding" of the serialized annotation.

I think that in the next days we can share some documents and examples with you.

Br,

Sergiu

[gsergiu]

By the way, it seems that the schema.org defines an Action Vocabulary, which is really a hierachical one (in oposition to the Motivation list). The motivation represents an intention to perform an Action, and the vocabulary covers the most of the motivations if not all. I think we should think of relationships between Motivations and Actions... https://schema.org/docs/full.html

The action vocabulary is maintained trough W3C and it is supported by the big search engines. So ... there will be also an advantage for standardizing search .. and searching through google&co. https://schema.org/docs/about.html

Br, Sergiu

[BigBlueHat]

@gsergiu in what ways would we loose interoperability? Motivations--afaik--are more like expressions of intent, not declarations of requirements. Such that an Annotation with the Motivation "bookmarking" is still the same annotation with the Motivation "identifying" (all other bits of the data being the same).

If you're UI makes a different distinction or provides additional experience based on the motivation, how does that cause interop problems?

We're not specifying a UX for annotation, just a data model that can support as many "annotation" concepts as is possible--which I think we already have here, and if we limit it by requiring a certain behavioral treatment on top of these "hints" then...we'd loose that.

[iherman]

+1 to @BigBlueHat. I have the impression that we are discussing a much deeper semantics around motivations than they were ever intended. I am in favour closing this issue.

[BigBlueHat]

:+1: to closing. Does this need confirmation on a call? or can we just close it?

[gsergiu]

I know that I brought a lot of confusion in this thread and there is no consensus at all .. on the provided topic. Still I would like to ask is this ticket should be closed, or deffered or splitt is several smaller issues?

The main critisism that I see on this ticket is that it is a too complex problem and we don't want to go into details of complexity/implementation. I can agree on this, at least for now ... but this still doesn't mean that the issue is a valid one... If the solution of creating smaller related issues is accepted I would like to address the relationship between Motivations and Actions, as there is already a good (real) vocabulary of Actions under the schema.org As motivation is the intent to perform an action and the currently proposed motivations seem to have all a coresponding Action in this vocabulary..

https://schema.org/docs/full.html