Rename `role` to `motive`

[shepazu]

The term role is extremely overloaded in the Web Platform, and the dominant use is for the HTML role attribute commonly used in ARIA, where the role values are from a constrained list that does not overlap with the annotation usage.

Not only does this introduce confusion when talking about annotations (e.g. "Each body or target can have a role... no, no, it's a different kind of role than you use in ARIA or HTML"), but it risks causing concrete conflicts when serializing an annotation into HTML.

Additionally, not every value on the list of Motivations actually has a clear processing or presentation role for the UA, so the term is a misnomer.

(An alternative suggestion might be the term intent, but that evokes Web Intents, and might cause a different set of associations.)

[jjett]

+1

[azaroth42]

:-1: We discussed naming, and the argument doesn't bring any new evidence, nor do the suggestions capture that the role is the role that the body (or target) plays in the Annotation. It would be internally confusing with motivation, which is worse than being externally confusing with a mostly unrelated specification.

We don't have an HTML serialization, and so the risk of conflict is zero ... we simply wouldn't use the role attribute.

The role is not intended to strictly be used for specific processing or presentation requirements. That is not stated in the specification anywhere.

[jjett]

I don't know Rob. We don't have an HTML serialization today. Do we want to preclude having one tomorrow?

Of course it may be moot. Anyone clever enough to build their own HTML serialization for our standard is going to find a mapping workaround.

I do wish we'd use a different word than 'role' but I wish for a lot of things...

---

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]

I agree that we don't want to preclude an HTML serialization, and I don't see that using a JSON-LD key of "role", that maps to a predicate of "oa:hasRole" precludes it in any way. We have a 'target' key, and that's an attribute on the a tag, and also in no way precludes an HTML mapping.

I'm fine with having a different name for it, just neither of the proposed. It could be the "function" that the resource plays, but function is also overloaded, and implies a specific outcome (re #113). "purpose"? "use"? That said, we discussed this in great detail and at great length while coming to the current accepted proposal. And communities who don't like our JSON-LD keys can trivially create a new context.

[shepazu]

I'm fine with some other name besides motive… role is the one that I have a problem with.

I think I'd even prefer intent, even with the possible association with Web Intents. (For reference, see http://www.webintents.org/ and http://www.w3.org/TR/web-intents/. Their initial list of intents was Share, Edit, View, Pick, Subscribe, and Save… mostly different than ours.)

Alternately, we could change both Motivation and role to motive, and have consistency throughout. Or, drop Motivation from the Annotation root. (I'm not trying to raise controversy, but I'm not sure that there was strong consensus on having both Motivation and role… it was rolled in as part of a larger decision. I'm also not saying we necessarily should drop Motivation, just that a short discussion to validate that decision would be useful.)

So, more generally, I'm saying we have some options here; I'd prefer we not use the term role because it's both overloaded and a misnomer (as motivations are currently defined).

[iherman]

I can see the problems raised by @shepazu; we indeed use a slightly overloaded terms which may backfire on us at some point. I am not sure what to replace it with, though. None of the ones in this thread seems to be a good alternative either. Maybe purpose, raised by @azaroth42, is a good alternative and not a term widely used in Web technologies.

(We should be careful not make a big deal out of this, though, because it is not a central issue. If we find a proper name that everybody is happy with soon, let us take it, otherwise just move on...)

[azaroth42]

I'm fine with s/hasRole/hasPurpose/g if that would close the issue?

[jjett]

Works for me. Doug?

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

[BigBlueHat]

@shepazu any objections to the term purpose? Seems to have :+1:'s all 'round otherwise.

[shepazu]

I can't say I care much for purpose (since again, it seems like a bit of a misnomer, just like role), and I'd prefer motive, intent, or even mode, but I can live with purpose if it means that we don't use the word role.

Maybe this is a difference in how we're thinking about the Model. I see this property as doing either of 2 things: 1) signalling the intention of the user (which may admittedly be hard to discern based only on their UI decisions); or 2) indicating what behavior the UA should have in processing or presenting the body/target (e.g. #113 ); since #113 isn't getting traction, I don't think it's appropriate to use terms that seem to imply behavior (like role or purpose).

Finally, I still think it seems extremely strange (and hard to describe) to have the same list of motivations be used for 2 seemingly entirely different purposes (e.g. as the value for Motivation on the annotation root and as a value on the role/purpose/motive/whatever). Either they're the same thing, and should have the same processing rules and property name, or they're different and should be treated as such (with their own use cases). Along with allowing multiple values as per #104, this seems like an arbitrary choice towards complexity, which is likely to bite us in the end.

But I seem to be in the minority here, so as I said, I can live with purpose.

[tilgovi]

I'm with Doug in that I also think having the same values for role and motivation is strange.

[gobengo]

intent (+1) is good for this, and my vote. It is intuitive and, in my opinion, the least ambiguous of the options presented so far.

IMO it's good that it's similar to Web Intents. In fact, the Web Intents API would actually be a pretty good inspiration for a Client Side API for some annotation use cases (e.g. 'leave a comment' or 'correct this article' buttons).

Regardless of whether you agree with that last paragraph, the Web Intents document is just a Note that that task force (not WG) decided not to advance anyway. It's essentially abandoned by w3, so I don't think we should avoid this particular six-character word just because some other folks also thought it was relevant to interacting with the web.

[BigBlueHat]

Word choice not withstanding, the core issues seem to be:

• bodies can be anything (not just embedded text content)
• bodies can be reused (anywhere...not just in an Annotation; they could be remote text, images, etc)
• UA's need to know why this particular body is included in this Annotation (hence reason, purpose, role, intent, and even motive or motivation).

So, we're trying to craft a way to say "this body is in this annotation because" without saying "this body is a..."

Whatever we discuss here, keep those two things in mind, and I think we'll not end up repainting this bike shed again. :smile:

[iherman]

Can we just try to run a quick vote in the group and accept whatever the majority says? This is a bike shedding.

I have seen purpose, intent. As far as I am concerned, I can live with both. To be really honest: at this point I do not care. Maybe running a email around the group who chooses which one of the two is enough, and let us move on!

[gsergiu]

Well ... I'm working on providing an implementation of the standard, and reading this thread is not clear at all what the ticket is about. So I searched in the documentation and I assume you are talking about this section: http://www.w3.org/TR/annotation-model/#roles-for-external-resources

I'm not a native speaker, but I strongly agree that "role" is the wrong naming, as roles are attributes to persons, not to artifacts. see http://www.w3.org/TR/annotation-model/#roles-for-external-resources

1. So before voting on a name, I think that we should have a clear and correct definition, the existing one is not a convincing one: "As well as Textual Bodies, roles can be associated with External Resources. This is done using the Specific Resource pattern, as the role specifies the way in which the resource is used in the context of the Annotation in the same way as a Selector describes the segment or a State describes the representation"

So ... if I understand correctly, the "roles" should define the relationship between the External Resource identified by an URI and the current Target or Body (as external resources can be used both in Body and Target). At the first glance ... I would say that the intention is to say that the ExternalResource "serves as" .... to the target or body.

"intent" is a consequence of a "motivation" .. so I don't find it to be a good name, even if this is close to the "purpose".

1. I would have another modeling question, if this "role" is an extension of the motivation, shouldn't we consider extending the motivation, by adding the "targetRole" and "bodyRole", instead of placing the roles to Body and Target? This will have the advantage that the motivation will have a clear representation of kind of message.

As I see in the examples .. the tagging is invoked very often. So ... we have the motivation "tagging" and the role "tagging". Isn't this redundant information? Shoudn't the "role" depend on the Motivation? e.g. Shouldn't we prevent by design to use motivation "bookmarking" with body role "tagging"?

1. I suppose that the roles should come from controlled vocabularies, but I was able to find only "tagging" and "describing" as examples in the specifications, which are in fact motivations. So ... once again what is this "role" about? Souldn't we try to build first a decent/representative controlled vocabulary for roles, before trying to find a proper name? (the contolled vocabulary will contain examples that must be consistent with the definition)

Sorry .. about the criticism and bringing a complete different view, but I think it is worth to take it in consideration, an think of consistency of annotations, now that the model is quite complex.

Br,

Sergiu Gordea

[rtroncy]

In the context of the NexGen-TV project, I'm also working with web developers in implementing the Web Annotation Model. While those web developers understand clearly the target - body - motivation pattern, they also have hard time to understand what role means and how it should be used. We will probably ignore it for now as I also feel I'm not able to clearly explain the use case it serves.

[gandreini]

Actually what is happening adding the "role" is that we are adding a semantic description to the relation between the target and the body (at least in the example here: http://www.w3.org/TR/annotation-model/#roles-for-external-resources).

In our project we are facing more complex situations (i.e. semantic annotations with more triples) and for this reason we have a different structure (you can see it here: https://docs.google.com/spreadsheets/d/10XXQ5KrFZbFqKxiFhuVBQrWdSxbXd85cCYYmrXE23QQ/edit#gid=1559801208).

If you plan to start building a controlled vocabulary for roles I can suggest you some of the default predicates we use in Pundit Annotator Pro:

• identifies;
• is related to;
• describes;
• has author;
• has type;
• cites;
• quotes;
• replies to;
• represents the date.

These all belongs to standard vocabularies like skos, cito, dc.

[gsergiu]

@gandreini

Thank you for providing these concrete examples. I think they are very useful!

I also think that is needed to define a clear relationship between the body and target .... To say that body is somehow related to target ... is a very weak statement.

Still as this field is meant to express the concrete relationship between target and body, I'm tempted to say that the field should't reside either in body, nor in target!

From my point of view this is a natural extension of the Motivation information, therefore it should be place there....

(I might be biased, but I put the Object Modeling best practices over the Linked Data / triples representations )

BR,

Sergiu

[BigBlueHat]

@gsergiu a few things based on your comments:

I also think that is needed to define a clear relationship between the body and target ....

Relating the body and the target directly is something that @tilgovi is interested in, but it's not what either Motivation or role (or whatever it gets renamed to) is for--quoting from the Model doc about the role:

The reason for including the External Resource in the Annotation.

It's not about relating body and target, but rather body and annotation.

Based on that assumption, you said:

Still as this field is meant to express the concrete relationship between target and body, I'm tempted to say that the field should't reside either in body, nor in target!

And, if that were it's use (to "express the concrete relationship between target and body"), then yes, it'd be in the wrong place...but that's not what it's for, so it's probably fine where it is. :smiley:

And regarding the "Object Modeling best practices" biased, keep in mind that the Web Annotation Data Model is a triple-based, RDF data model and not (nor has it ever been) an Object Model--despite growing confusion to the contrary.

The "triple-ness" of the model can't just be willfully ignored. It can be "hidden" (perhaps with greater cost than we realize presently...), but it can't be eliminated without starting over--which I hope everyone agrees is a Bad Thing.

Let's all get back (if we can) on the main topic of renaming the role and hasRole key/terms. Model reinvention shouldn't (keep...) happening on GitHub issues. If anyone feels it's necessary, put up some wiki pages and mailing list posts--please. :smile:

[gsergiu]

@BigBlueHat

1. I think that the relationship between the body and the annotation is very clear. The Body is the "payload" of the annotation, and that is all. The body is not about annotation but the body is about the target as basic fundament for annotations.
2. Currently the Movitation should say, why I user creates an annotaion, expressing so the relationship between the Body and Target, still they are again very general statements, which (currently) impose no restriction on bodies. So ... they cannot be used for any kind inference (right now)!
3. I think that specifications of a standard should be technology independent, and must represent a conceptual model. ... Yes ... it is a Web Related standard and must be compliant with web technologies. And I think that big improvements where made when the JSON-LD serialization was introduced (which is in fact the bridge between the Object and RDF world, showing that they are not mutually exclusive concepts)
4. I'm sorry, if I sent a lot of text that at the first glace doesn't seems to be relevant for the original question. But now I can conclude my questions:

a) Does the "role" have a clear definition and an clear naming so that a proper name can be found? I find the definition and the example quite ambigous http://w3c.github.io/web-annotation/model/wd/#roles-for-external-resources What I would expect in the annotation is to say that the resource indicated by the given URL is a "place" or a city. Motivation:tagging + role:tagging is redundant and confusing.

b) Shouldn't the "role" indicate types or relationships? As it is written in the definition "as the role specifies the way in which the resource is used in the context of the Annotation"

Through the context of annotation I understand: the BODY saying something about the TARGET driven by the MOTIVATION. What is missing in this content is the "something" , what the body tries to say (as the URL doesn't provide much information, especially when the mime type is not provided)

[iherman]

On 17 Dec 2015, at 18:00, gsergiu notifications@github.com wrote:

@BigBlueHat https://github.com/BigBlueHat

1. I think that the relationship between the body and the annotation is very clear. The Body is the "payload" of the annotation, and that is all. The body is not about annotation but the body is about the target as basic fundament for annotations.

Currently the Movitation should say, why I user creates an annotaion, expressing so the relationship between the Body and Target, still they are again very general statements, which (currently) impose no restriction on bodies. So ... they cannot be used for any kind inference (right now)!

I think that specifications of a standard should be technology independent, and must represent a conceptual model. ... Yes ... it is a Web Related standard and must be compliant with web technologies. And I think that big improvements where made when the JSON-LD serialization was introduced (which is in fact the bridge between the Object and RDF world, showing that they are not mutually exclusive concepts)

I'm sorry, if I sent a lot of text that at the first glace doesn't seems to be relevant for the original question. But now I can conclude my questions:

a) Does the "role" have a clear definition and an clear naming so that a proper name can be found? I find the definition and the example quite ambigous http://w3c.github.io/web-annotation/model/wd/#roles-for-external-resources http://w3c.github.io/web-annotation/model/wd/#roles-for-external-resources What I would expect in the annotation is to say that the resource indicated by the given URL is a "place" or a city. Motivation:tagging + role:tagging is redundant and confusing.

b) Shouldn't the "role" indicate types or relationships? As it is written in the definition "as the role specifies the way in which the resource is used in the context of the Annotation"

Through the context of annotation I understand: the BODY saying something about the TARGET driven by the MOTIVATION. What is missing in this content is the "something" , what the body tries to say (as the URL doesn't provide much information, especially when the mime type is not provided)

I think what I am wary about is to over-formalize things. When you say:

Shouldn't the "role" indicate types or relationships?

what I presume you mean is to have some sort of a formal set of terms, defined maybe through some RDF properties, maybe even OWL to characterize them more strictly (or other formalism), etc, etc. This could be done, specification wise, but I do not think it would be widely used and adopted. The history (to use a big word) of the past few years have shown that the very "loose" set of semantics exemplified by tags, or the semi-loose tags that are done in SKOS have a much bigger chance of usage. So my my answer two that question would be "why?". Why should the role indicate (formal) types of relationships? What does a system really gain by having that?

Both roles and motivations are kind of loose. We do have some (SKOS-like) terms, but the fact that they are loose is actually by design (again, just like SKOS terms often are). I do not really see the use case to do anything more complex than that.

[gsergiu]

Hi Ivan,

Let's be clear, I don't use either RDF not OWL. I build a REST Api for managing Annotations using a JSON-LD serialization (for now the only supported format). My API will get Annotations from 4 different clients, and I want to make sure that all 4 clients are using the same serialiazation for the same type of Annotations.

1. Concretely, I want that (embeded) tags are tags and not comments for example.

The serialization is the same, motivation is different. However, I expect that more tagets get tagged with the same tag label, and I don't expect two find the same comments on more targets. I would expect that the tags don't exceed a given size (e.g. 5 words or 50 chars). Consequently, when I want to search for targets (resources) that are tagged with the same tag I want to get more results, and I expect 100% precision. Which means a search for "New Year" should not return a tag with the lable "New Year's Eve". In contrast, if they are comments, I want to get both results.

I'm not sure if the definition of maximum of the size of tags should be included in the normative part of the specifications, but is for sure not bad to introduce it.

1. I find the bookmarking-tagging example a very confusing thing. How do yout think that a human user will interpret this serialization if he is not reading the text of the "Example Use Case"? { "@context": "http://www.w3.org/ns/anno.jsonld", "id": "http://example.org/anno10", "type":"Annotation", "motivation": "bookmarking", "body": { "text" : "readme", "role" : "tagging" }, "target": "http://example.org/page1" }

What is the purpose of this annotation? Is it bookmarking ... which should be a "mark in a book" and I expect it to be unique. Or is it tagging, for which I expect a quite different behaviour.

"Labeling and tagging are carried out to perform functions such as aiding in classification, marking ownership, noting boundaries, and indicating online identity." as described in .. https://en.wikipedia.org/wiki/Tag_%28metadata%29

If you look at bookmarking functionality in different systems, indeed you have a location, a label (that you also have in tags), and probably some keywords.

If the intention is to say that Bookmarking is a special king of Tagging, than this should be represented in the skos vocabulary for Motivation, and you can simply use motivation:Bookmarking and add the label "text":"readme" in the Body.

That would be a very natural representation for me ... the current one, given the current specifications, seems to be only a merge of 2 Annotations (one for bookmarking and one for tagging ... if that is needed anyway). I remmeber that in the OA was explicitly said that Bookmarks might/should have no Bodies....

1. In my Opinion the Target - Motivation - Body should be understood as a triple. As the predicate imposes a Class for the object, so I expect that the Motivation imposes constraints on Body....

[azaroth42]

Done: http://w3c.github.io/web-annotation/model/wd2/#motivation-and-purpose and http://w3c.github.io/web-annotation/model/wd2/#purpose-for-external-web-resources

[gsergiu]

Hi @azaroth42,

Regarding to the definition of the purpose, I would like to ask an improvement, as the following sentence is not really meaningful: "There MAY be at least 1 purpose for each TextualBody." In the current version .. the implied cardinality is 0 .. n. ("may" and "at least" don't really play together) Was the intention to say "there should be" (regular cardinality 1...n but 0 is also ok), or was it intended to say "There may be 1 purpose or more" (regular cardinality 1, but 0 or n are also ok)?

I hope I'm not too picky ... but this is how I would interpret the text. Apart from the definition, I would suggest adding an explicit paragraph on the cardinality of motivations and purposes for making clear what I wrote above. I think this is a great help for developers, to have a clear interpretation fo the cardinality for these fields.

Br, Sergiu

[hugomanguinhas]

Hi all,

I must say that I was much more comfortable with the way OA was being designed especially for Tags and Semantic Tags where classes were being used to categorize the body... representing a state rather than an action/intent/role... for that we already have motivation expressed at the level of the Annotation, which is where (in my opinion) should stay and remember that it can be repeated. I share the opinion with @gsergiu btw that having tagging in both motivation and role is, say the least confusing.

So, why not just use @type?

For now, we are considering very simple annotations, but more complex annotations will require much more elaborate bodies conveying much more information than just a mere resource.

Best regards, Hugo

[azaroth42]

Agree the wording could be improved, changed it to:

There MAY be 0 or more purposes for each TextualBody.