Relationship between Motivations and Actions (from schema.org)

[gsergiu]

It seems that the list of Motivations in the WA standard can be easilly mappedd to Actions defined by schema.org.
http://schema.org/docs/full.html

However the actions vocabulary seems o be better organized as a hieranchical structure and have better definitions and specifications.

Is there a relationship between them? Can the WA specifications profit of the existing vocabulary?

[tilgovi]

There is no stated relationship, but I agree that there seems to be a lot of overlap even if not all of the annotation motivations map to current actions.

[pciccarese]

True, https://schema.org/AssessAction for instance, seems to be organized as we were discussing during the last call.

However, the motivations are SKOS Concepts and, in fact, are (all) modeled as direct instances of Motivation (which is subclass of SKOS:Concept). The Schema.org Actions are rdfs:Class and they come with all their hierarchies, properties and relationships. So semantically we are talking about different things.

So, aside of discussing/borrowing the existing schema.org definitions and organization, how would that work? Would we use classes as instances?

[gsergiu]

Well ... indeed the motivations and the actions are semantically two different things, however, the motivation represents the "driver" to perform an action, and actually ... the annotation is the result of performing this action. Probably it is not really possible for now to reuse the schema.org in the annotations, but it would be wise to organize the motivations as hierarchical structure following the structure of the schema.org (if possible) and aligning the definitions of the Motivations with the ones of the actions. If we do so, we could also reference the schema.org in some non-normative Note.

Something that is missing in the current Motivation list are the different flavors of Feedback/Review including (like, dislike, agree, disagree, endorse, and even win if you think of stakeOverflow which needs to mark the winning solution to a given Problem ). All these are available as subclasses of ReactAction (see the bottom of the page http://schema.org/ReactAction )

[paolociccarese]

I cannot disagree with the idea of mapping out the overlap and see where we lack expressiveness. In general we always tried to be very high level to avoid slippery slopes of custom/peculiar/arguable motivations.

While I 'like' vs '+1' is a trivial example (in SKOS that would be an easy relationship to express as well), for other terms things might become a little more difficult.

After a quick look, these are the interesting one for me:

• Assess Action
  • React Action
    • AgreeAction
    • DisagreeAction
    • DislikeAction
    • EndorseAction
    • LikeAction
  • Review Action
  • Choose Action
  • Vote Action
• Organize Action
  • Bookmark Action
• Update Action
  • Add
  • Delete
  • Replace
• Achieve Action (not that sure about these)
  • Win
  • Lose
  • Tie
• Interact Action
  • Follow
  • Communicate
    • Ask
    • Comment
    • Inform
    • Reply
    • Share
    • Invite (?)

Any other that make sense?

[iherman]

I must admit I am fairly uneasy about the idea of reorganizing the motivations at this point. As @paolociccarese said, motivations are a set of SKOS concepts, and they are actually a flat structure, not even using the skos terminology to create some form of a hierarchy. Defining some sort of a hierarchy to mirror schema.org is not an obvious thing to do.

Beyond the timing aspect, I am not even that sure that schema.org/Action is a good model. What it says, on the top level:

An action performed by a direct agent and indirect participants upon a direct object. Optionally happens at a location with the help of an inanimate instrument. The execution of the action may produce a result. Specific action sub-type documentation specifies the exact expectation of each argument/role.

What this suggests (although not really clearly said) is that a schema Action is to model an active entity, like a process, widget, or something similar which, as the text says, has an 'execution' that may even produce a result. An annotation is actually a relationship between a target and the body, with a bunch of descriptions of that relationship. It is not a process. An action has an 'agent', has 'participants', etc (worth looking at the examples at the bottom of https://schema.org/Action).

My conclusion is that schema.org/Action and an Annotation are different animals. We should not mix them.

[gsergiu]

Well .... as I said before, schema.org specifies actions, and the execution of an action creates a result.

Logically, the creation of an annotation is an action and the result is the annotation.
I think that the most of the actions named by @paolociccarese would create different types of annotation, but we have the problem that the Annotation has only one type, and the List of Motivations is quite poor in comparison to the Action list.

I see this as an oportunity to improve the Motivations vocabulary, by adding missing Motivations, by starting to organize them hierarchically and by crosschecking definitions with the definitions of the Actions.

PS: I think that the Motivation list should be updated before the CR and I also think that is not much effort to do it, given that the definitions of missing Motivation can be taken from schema.org

[pciccarese]

Yeah, semantically they are different. That is also why some of them don't apply or sound strange.

But we can probably get inspired, for instance we can use schema.org as supporting evidence for introducing 'assessing', which is more generic than 'reviewing' (a formal assessment or examination of something with the possibility or intention of instituting change if necessary). Wasn't that the discussion during the last call?

[gsergiu]

Turning the question the other way around. What speaks against updating the motivation list to the structure selected by Paolo? Are there any inconsistencies between the two lists?
(as Motivations are already defiend as Skos Concepts, there is no problem to model the hierarchy)

[pciccarese]

@gsergiu hierarchies are risky business as we might end up with possible theories on ways to organize things.

But I agree we can get inspired and at least include a few more motivations.

The original design also allows to extend the Motivation system. So another way is to just add high level plugs say 'assessing' and then separately suggest some more specific motivations and see how that works out. However, this approach also opens a can of worms...

[gsergiu]

@pciccarese well ... by proposing a hierarchy one can propopose a "wrong" structure, I agree. However, the implementers will find it more easier to choose a value from a hierarchy than from a flat list.

Why was the class of Motivation chose to be Skos Concept, when they have in fact only label and a definition?

[pciccarese]

We introduced SKOS to allow for light organization of terms. That does not mean we necessarily have to do that in the specification.

I guess the real question is what is best for interoperability....

[jjett]

I am -1 for this idea and +1 to what Ivan said. Part of the whole purpose of using flat and extensible vocabulary for motivations was to allow particular domain communities to make their own extensions in accordance to their particular needs.

Moreover, a motivation was always intended as an explanation of the kind of content that the annotation's body contains. Much like the purpose is intended to provide a basic explanation of what role the body's content plays in annotations with multiple bodies.

This doesn't actually seem to overlap with schema.org's action at all. A closer fit would be the "expectation" property proposed by the Morris's (Bob and Phil) back in the community group's early days. As I recall we elected not to pursue it since "expectations/actions to be taken" are also fairly domain dependent.

IMO, annotations are orthogonal to intentions behind the schema.org vocabulary and we shouldn't align ourselves too closely to it. We're already compatible with it and I think that's good enough.

[pciccarese]

@jjett I would still change 'reviewing' to 'assessing' as it has a more generic and less formal nature. That will allow other to extend with more specific ones. Although, this is a specific issue that should be discussed separately #249

@jjett the motivation is why the Annotation was created, which is very different, in my opinion, from the 'kind of content', that is why we have 'purpose'. I could have a Motivation 'bookmarking' and that could include some tags as well (but the motivation is not tagging). I also don't thing that schema.org is close to 'expectations' which are not actions but follow up actions that are expected to happen following an annotation action with a specific motivation.

That said, I am ok with the flat list of concepts that we have now. However, as soon as we introduce new ones, I would argue it will become increasingly hard to keep all this flat. So I feel it is just a matter of time. I am not expecting us to come up with a hierarchy for the specifications though.

[azaroth42]

That said, I am ok with the flat list of concepts that we have now. However, as soon as we introduce new ones, I would argue it will become increasingly hard to keep all this flat. So I feel it is just a matter of time. I am not expecting us to come up with a hierarchy for the specifications though.

I think the scope of the WG should be to create a reasonable, flat set of top level motivations that other communities can build from. We're not going to come up with the complete list of all things that people want to use annotation for, we've known that since the beginning.

This top level will allow what interoperability is possible between otherwise independent communities, as we can trace xx:critiquing and yy:reviewing both back to oa:assessing to know that they're conceptually related. At this stage, I think we should focus on ensuring that the ones we have should not be in a hierarchy, and if there are some that are conceptually narrower than others, we would instead remove them from the list.

There are also activities specified in ActivityStreams, including Like, Dislike, Flag, Question and so on. I don't think we should pick sides with which to align with, but instead allow the communities that use one or the other (or indeed both, hence skos:Concept) to create the narrower motivations for the alignment.

See: https://www.w3.org/TR/activitystreams-vocabulary/#activity-types

[gsergiu]

@jjett
yes ... I have too the feeling that the Motivation is used by the community as workaround for the missing hierarchy of annotation types and even body types.
as @pciccarese explained .. motivation was not meant for that ... but have the feeling that the motivation and the purpose will be used to replace the lack of standardized types/classes.

I think that especially the hierarchy of Asses Action <=> assessing is omething that is already present with a large coverage in social media and forums. I expect that these will be also intensively use by implementors of the standard.

[gsergiu]

@azaroth42

This top level will allow what interoperability is possible between otherwise independent communities, as we can trace xx:critiquing and yy:reviewing both back to oa:assessing to know that they're conceptually related.

On which basis can you do that? For sure, one cannot do it automatically, except if you have skos:closeMatch, skos:exactMatch, skos:broadMatch, skos:narrowMatch evidences.

[pciccarese]

@gsergiu what @azaroth42 is saying is that we provide the high level plug: oa:assessing. Then community A defines the more specific terms and they provide, in such definition the means to connect the terms (through skos). That is why Motivation use SKOS in first place. So community A is responsible for those connections.

[azaroth42]

yes ... I have too the feeling that the Motivation is used by the community as workaround for the missing hierarchy of annotation types and even body types.

Which is completely intentional. We started out with subClasses and ran in to all sorts of problems:

• Multiple bodies and/or targets mean for multiple subClasses
• Lack of a way to determine that the resource is an Annotation without inference on community specific ontologies
• Harder to align between communities with a strict class hierarchy compared to skos, which is designed for conceptual semantic alignment (via close,exact,etc Match)

As this is working as expected and no new information is being brought to the table ... I propose close wontfix.

[jjett]

@gsergiu , @pciccarese is misremembering. As @azaroth42 mentions, motivation was introduced by the community group to explicitly replace the flat class "hierarchy" that one of its predecessors (the open annotation collaboration (OAC)) had previously established. One of it's (many) functions is to provide a hook for searching by annotation kind.

However, it was pointed out that one of the problems with reusing rdfs:Class in this way is that it conflates kind of content with specialization/generalization of kind. Since the OAC class vocabulary was essentially noting the kind of content (along the axis of annotation intentions) and it was decided that formalizing it's metadata as a predicate whose range was mapped to SKOS concepts would be much more flexible than trying to create an overarching class hierarchy that would inevitably expand forever (or bog down with debates about conflicting terminological definitions).

If you look at the community group's archives the pertinent discussions, especially at the final face-to-face meeting (somewhere there are slides on this topic by Bob Morris and myself) can be found.

+1 to Rob's close wontfix.

[gsergiu]

@pciccarese

Then community A defines the more specific terms and they provide, in such definition the means to connect the terms (through skos).

Well .. this implies that community 1 extends the assessing with like/dislike, and community 2 extends the assessing with agree/disagree/endorse.

If the systems start sometime later to communicate with each other, how should be the annotations interpreted?

Like/dislike shold get the meaning of agree/disagree? Or should the community 2 map like to endorse?

Of course it is wrong to do this, and as much as we want to claim that "general" things are interoperable, the thruth is that extensions are not interoperable by default! Therefore I think that a rich list of motivations is important in this context, especially for the purpose of supporting the interoperability!

[gsergiu]

@jjett I do agree with the statement

(or bog down with debates about conflicting terminological definitions).

But the conclusion is the less we specify, the more ambiguity + conflicts and the less interoperability will exists between the implementations.

When we have evidences of good/standardized classifications, why are we so reluctant to reuse them (in a way or another).

Let's say, if we don't want to extend the "asessing" motivation. What speaks against writing a note that possible extensions could include like/dislike/agree/disagree/endorse?

[azaroth42]

Semantic alignment between (hypothetical) communities is not our problem to solve, it's our problem to enable where possible. Which we have done by the use of SKOS and documenting how to express the alignment (in the appendix in vocab).

We have a reasonable set of motivations that can be extended and aligned as needed.

Please propose an in scope problem and a solution to the problem, otherwise lets close the issue.

[pciccarese]

I am ok with close wontfix for this round.

@gsergiu as I said above "I guess the real question is what is best for interoperability....". I don't feel as confident as you that we could easily, and in a short amount of time, provide a comprehensive list of terms. As @azaroth42 mentioned there are other communities working on some aspects of that. As you can see the Activitystreams list of Action already has a different approach than schema.org. That said, I keep wondering what is going to be the impact of the current approach on interoperability and I believe it is something we should evaluate carefully.

@jjett that is not what the spec currently says: "The Motivation for an Annotation is a reason for its creation" or "In many cases it is important to understand the reasons why the Annotation was created". This definition is more inline with the framework you mentioned motivations/expectations. But we can chat about this in separate venue.

[gsergiu]

@pciccarese
well ... if we don't want to extend the motivation list, and create a hierarchical structure for it.
Wouldn't it be usefull to give examples of possible extensions for individual motivations?

[iherman]

On 31 May 2016, at 17:40, Paolo Ciccarese notifications@github.com wrote:

@jjett https://github.com/jjett I would still change 'reviewing' to 'assessing' as it has a more generic and less formal nature. That will allow other to extend with more specific ones. Although, this is a specific issue that should be discussed separately #249 #249
@jjett https://github.com/jjett the motivation is why the Annotation was created, which is very different, in my opinion, from the 'kind of content', that is why we have 'role'. I could have a Motivation 'bookmarking' and that could include some tags as well (but the motivation is not tagging). I also don't thing that schema.org is close to 'expectations' which are not actions but follow up actions that are expected to happen following an annotation action with a specific motivation.

That said, I am ok with the flat list of concepts that we have now. However, as soon as we introduce new ones, I would argue it will become increasingly hard to keep all this flat. So I feel it is just a matter of time. I am not expecting us to come up with a hierarchy for the specifications though.

… and I am not sure we would have a hierarchy in the RDF Class sense or in the SKOS sense. I am tempted to say the latter…

[pciccarese]

@gsergiu like this one http://w3c.github.io/web-annotation/vocab/wd/#extending-motivations ?

[iherman]

I am ok with close wontfix for this round.

Same here.

@gsergiu https://github.com/gsergiu as I said above "I guess the real question is what is best for interoperability....". I don't feel as confident as you that we could easily, and in a short amount of time, provide a comprehensive list of terms. As @azaroth42 https://github.com/azaroth42 mentioned there are other communities working on some aspects of that. As you can see the Activitystreams list of Action already has a different approach than schema.org. That said, I keep wondering what is going to be the impact of the current approach on interoperability and I believe it is something we should evaluate carefully.

@jjett https://github.com/jjett that is not what the spec currently says: "The Motivation for an Annotation is a reason for its creation" or "In many cases it is important to understand the reasons why the Annotation was created". This definition is more inline with the framework you mentioned motivations/expectations. But we can chat about this in separate venue.

[gsergiu]

@pciccarese yes the document explains the mechanism of extending Motivations, and the depiction suggests two extensions for editing, namely the fixing and correcting.

Would is be possible to add a non-normative table of possible extentions?
I think this will still be helpful for the implementations, even if we provide just labels and no definitions.

for example I think that the meaning of like/dislike/agreeing/disagreeing/endosing is quite clear due to intensive usage in social media.

Also .. for moderation, something like reporting, and disabling/hiding annotations are for sure needed.

[azaroth42]

Please feel free to propose an alignment table between the existing motivations and other ontologies. We can either write a Note with it, or add it into the vocab document for each Motivation.

[pciccarese]

@gsergiu to echo @azaroth42 I believe a Note would be the best place to do that.

[jjett]

@paolociccarese Agree 100%. The definition and scope of motivation has changed over the years but it is still pretty close. I think it is important to surface where some of @gsergiu's concerns have previously been discussed and remind ourselves about the predicate's origins.

Moving forward, the standard we have in hand is very flexible and strong. We should table this discussion. These are the kinds of rough edges we can knock off in a future round of effort.

+1 for Note

Happy to discuss these issues in other venues (i.e., via email) so as not to distract from the closing of issues.

[gsergiu]

given the feedback, I do think that creating a living document, in which we allow communities to share and align extension of motivations is a good thing. This can be referenced as non normative note, which will not stop the releasing process of the standard.

[azaroth42]

And given "living document" ... that shouldn't be a Note (which will be finalized), but just a wiki page so it can be updated?

So a proposal:

• Close this issue.
• Create a new, postpone issue to document motivation alignment with other vocabularies in the wiki
• And during CR, populate that page with alignments using the skos *Match predicates

[pciccarese]

+1

[iherman]

If it is a long term living document, we can also use the github wiki. But +1 to the general idea.

[akuckartz]

👍

[jjett]

+1

[azaroth42]

Closing and will open new issue.