More specific motivations than describing

[gsergiu]

There are initiatives for transcribing handwriten texts (see https://transcribathon.com/en/documents/id-20841/item-235882/) and translating poems (http://www.mptmagazine.com/page/translate/?tid=776) to different languages.
In order to link the new created reources with the original resources using web annotations, it would be important to add the translating (https://en.wikipedia.org/wiki/Translation) and transcribing (https://en.wikipedia.org/wiki/Transcription_(linguistics)) terms to the motivations.

[azaroth42]

There are many possible motivations. You should feel free to create narrower or brand new concepts as appropriate, but please also include at least one of the main ones, if possible.

[gsergiu]

I think that there are a couple of tickets which asked for extentions and mapping of motivation vocabulary. In one of then there was even proposed to have a living document that can be used by the community to extend this vocabulary and ensure introperability between systems, even if this is not normatively enforced.

I would propose to link the related and not solved issues together for being addressed in V2.

I'm not sure if there is a convention that allows the creator of the ticket to indicate directly if the ticket is an issue for V1, or an enhancement that should be addressed in V2...

[azaroth42]

Hence postpone

[gsergiu]

You should feel free to create narrower or brand new concepts as appropriate, but please also include at least one of the main ones, if possible.

Just for the record, the previous recommendation goes against the definition of the motivation. Even if this case seems as an exception for the current specifications, I still don't see it that exceptional that it would require usage of two motivations.

There SHOULD be exactly 1 motivation for each Annotation, and MAY be 0 or more than 1.

https://www.w3.org/TR/annotation-model/#motivation-and-purpose

According to my understanding of the TR specifications, for the given example, the best solution would be to extend the describing motivation with a norrower term transcribing as described in
https://www.w3.org/TR/annotation-vocab/#extending-motivations

[arelra]

Hi @azaroth42

RE: https://www.w3.org/TR/annotation-vocab/#extending-motivations

Aiui purpose has the same range as motivation.

My team has a very unique body purpose that we would like to describe.

It's hard to find concrete examples of extending motivation. Could you give a practical example of how you would define a custom purpose using JSON please?

[gsergiu]

Hi arelra,

I hope that my answer is correct, and I recognize that the section of extending the list of motivations is quite generic and non normative.

I think that the solution is to create your own json-ld context and to add it into the @context field in the serialization of the annotations.

Your context file should include the definitions of the new motivations similar to the ones that already exist in the web annotations context (see json-ld representation):
https://www.w3.org/ns/oa#Motivation

Br,
Sergiu

[arelra]

Hi @gsergiu

Thanks for your response. Whilst I understand the concepts its hard to work from there to a valid concrete example.

Would you be kind enough to describe what the custom json-ld motivation would look like?

Assuming I'm using a custom namespace 'my'

{
  "comment": "My custom motivation",
  "definedBy": "my:",
  "id": "my:customEdit",
  "label": "customEdit",
  "type": "oa:Motivation",
  "skos:broader": "editing",
}

As the skos namespace exists in the anno json-ld representation https://www.w3.org/ns/anno.jsonld could I not simply define my custom purpose/motivation in the body element with a sibling skos:broader property?

e.g.:

body: {
  "purpose": "newPurpose",
  "skos:broader": "editing"
}

Thanks in advance

[gsergiu]

Hi Arela,

1. The first approach is the correct one, it uses the proper meaning of ontologies. If you add this definition into a json-ld context file, add this to @context, that you are allowed to use body: { "purpose" : "customEdit"}.

2. The second example is semantically incorrect, as the "skos:broader" applies to body and not to "porpose" property of the body. (i.e. the meaning is that the motivation:editing is the borader concept for your body, which is obviously wrong).
   Also, the WA conventions/recommendations indicate that one should avoid the usage of namespaces (i.e. use "broader":"editing", not "skos:broader":"editing") in json-ld output, so that the serialization looks exactly like common json serialization, which is mone convenient for third party application developers.

Technically and sintactically, you could use something "purpose":{"label":"customEdit", "skos:broader" : "editing"} but this is not the recommended way to do it.

Br,
Sergiu

[gsergiu]

@arelra do you have a concrete usecase to share with the community? I'm thinking that your example might be relevant for the related ticket: #256

[arelra]

@gsergiu Thanks for taking the time to explain

Our case is a little 'odd' I would say.

We use annotations to allow users to quote text, add a comment and navigate back to source documents. This is all nicely captured by W3C annotations.

However we have a edge case where the users would like to edit the quoted text in order to tidy up erroneous characters or formatting issues.

Ideally we would like some way to describe a 'display' representation of the quoted text but this doesn't exist in the spec.

However using multiple bodies with purposes a) 'commenting' for the comment b) 'correcting' for the edit gets us close to the desired semantics.

[gsergiu]

@arelra
Well, I'm not sure if I would say that your use case is 'odd'. An indeed I would say that "correcting" is one of the missing motivations (this is just my personal opinion that was also expressed within the ticket: #248 ). I think that it is a significant different between following kinds of edits: add text, change text without changing the meaning, correcting text because the existing version is wrong or becasue the the statement is discovered to be false.

In the current version of the standard only the "editing" is available with the definition: "The motivation for when the user intends to request a change or edit to the Target resource."

However, in order to better understand you use case, I would need to understand the meaning or "quote text":

1. Is this meant to be a selection of the existing text? (e.g. one sentence in a web page, fo which the user doesn't actually have the permissions to edit the text)
2. Does you annotation has the meaning that the user proposes to replace an existing text (e.g. one sentence) with a new one? (i.e. similar to the use of "suggesting" in google docs)

Br,
Sergiu

[arelra]

@gsergiu

I agree with you we need more nuance and a straightforward way for annotation creators to express custom purpose / motivation.

I meant 1) the selected text of the annotation target selection

However the 'correction' is not a correction of the target selection. It is a correction for display of the annotation ie a user edit of the selected text for minor editing or formatting purposes.

Do you mind me asking are your recommendations 'official' or suggestions. I just want to be clear on whether the method you suggested has official approval.

Thanks for all your help

[gsergiu]

@arelra
yes, the correction here has the meaning, from the annotations perspective, that the user proposes a correction of the text (otherwise the text would be edited directly and no annotation would be needed).

So for this use case it is likely that you would need a Selector for the target (e.g. TextPositionSelector) and a body with motivation "correcting" and the value defining the new text that should replace the selected one. How this get's displayed, is the business of the application and not of the annotation model.

In the comment of the "correcting" motivation you may indicate that this is used to replace a falty text (or part of text) with the corrected version of it.

This is how I would model it ... but let's hear the other opinions: @azaroth42 @iherman @BigBlueHat

PS: There were long discutions on justifying motivations with an expected system behaviour, but the conclusion was to avoid restrictions in the data model, and leave this for the business logic of applications see #113