RE: [model] Proposal: Allow motivatedBy on SpecificResource

+1.  I think Tim’s suggestions make the model much more flexible.




Thanks for having me on as an invited expert for this working group.  I was asked this morning to introduce myself on this thread. 




My name is Chris Birk and I am the lead developer at the OpenGov Foundation based in Washington, DC.  I know many of the members of this group from the iAnnotate conference over the past few years.  My interest in this group is looking at annotations from a government and legal perspective.  I’ve also volunteered to help with the testing side of things.




I look forward to working with you all!



- Chris @cmbirk

(317) 418-9384









On Wednesday, Jun 17, 2015 at 12:48 PM, Timothy Cole <t-cole3@illinois.edu>, wrote:


Rob-







 



Consistent with Ray’s comments on today’s call about the copy-edit use case, I think your use cases are better addressed by separate annotations rather than by the added complications of motivations added to annotation bodies.  







 



As you correctly point out, at the very least to allow motivation on the body you would have to create your bodies as SpecificResources which is an additional complication. I would argue that this is true even if the body is textual, i.e., since the text string is not inherently a replacement except in the context of the annotation (though I accept this is a nuance we could probably ignore without much harm).  







 



To Doug’s point about keeping simple use cases simple, it is much simpler from a modeling perspective to have one annotation which is the correction itself and another annotation (as needed) that explains the rationale for the correction. In simple copy-edit cases, the second annotation would rarely be needed (more specific motivations on the annotation might be needed – e.g., edit-insertion, edit-deletion, edit-replacement, edit-transpose, …). When the second annotation is needed, e.g., a comment about supporting the edit, keeping it separate from the copy-edit annotation would allow for the use a multi-target annotations, e.g., “these 10 proposed edits (each its own annotation) were all needed because….” – that’s a single annotation targeting the ten copy-edit annotations. 







 



And of course that copy-edit annotations are modeled as individual annotation is easily hidden from the human editor by the interface when appropriate – e.g., change all occurrences of Rbb to Rob looks to the human editor like a single copy-edit in the interface. The fact that there is a Rbb to Rob copy-edit annotation for each of the 10 occurrences of Rbb in the document is handled by the software behind the interface. 







 



As for the other use cases you mention, I think the same logic applies:





* A single annotation that has both tags and a comment about the target is really a tagging annotation and commenting annotation or a tagging annotation and comment annotation on the tagging annotation. (Note in this case that there is a nuanced distinction possible by keeping the annotations separate that is not possible when you conflate.)







 



* A single annotation that has a moderation up-vote, and a comment explaining why the moderation should be considered is an up-vote annotation and an explanation annotation on the up-vote annotation (note, not an explanation annotation targeting what is being voted on). 







 



Finally, my reason for mentioning more complex copy editing use cases was meant to invoke the slippery slope argument, if we make a model change to allow annotations on bodies to make our annotations more human-readable and to save on the number of annotations minted in order to address simple use cases, we can anticipate that users will abuse this capacity to handle arbitrarily complex use cases conflating what should be distinct annotations.  There’s no reasonable way to preclude this and I just don’t yet see the carrot for introducing motivation at the body level – but I’m willing to be convinced if someone can come up with the use case that can only be handled by motivation on the body (rather than separation into separate annotations with motivation on the annotation). 







 



-Tim Cole





  







 





 





 



From: Robert Sanderson [mailto:azaroth42@gmail.com] 
Sent: Tuesday, June 16, 2015 3:55 PM
To: Web Annotation
Subject: [model] Proposal: Allow motivatedBy on SpecificResource







 





 




Currently the motivation for an Annotation is associated only with the Annotation, however the different bodies of a single Annotation may have different motivations for their inclusion.








 




The current model:  http://www.w3.org/TR/annotation-model/#motivations








 




Use cases that have come up include:






* A single annotation that has a body that is the replacement edit for the target, and a body that is a comment about the change






* 








 




Motivations cannot be associated directly with the body resource, as the body may be used in multiple annotations, with different motivations.  They might also be the target of a different Annotation, and motivation is exclusively tied to the Annotation that asserts it.








 




Therefore, a SpecificResource is needed to stand for the resource in the context of the Annotation.






By associating the Motivation with the SpecificResource we would be clear regarding which resource the motivation applies to.








 




If the Annotation and a SpecificResource both assert a motivation, the SpecificResource's motivation would take precedence for its source resource.. 








 




This would allow, for example:








 




<> a oa:Annotation ;






  oa:hasBody _:tag1sr, _:comment1sr ;






  oa:hasTarget <http://example.org/paris.jpg> .








 




_:tag1sr a oa:SpecificResource ;






  oa:motivatedBy oa:tagging ;






  oa:hasSource _:tag1 .








 




_:tag1 a oa:EmbeddedContent ;






  rdf:value "paris" .








 




_:comment1sr a oa:SpecificResource ;






  oa:motivatedBy oa:commenting ;






  oa:hasSource _:comment1 .








 




_:comment1 a oa:EmbeddedContent ;






  rdf:value "I think this is photo is of Paris because I can see the Eiffel Tower." 








 






 




Rob













 



-- 




Rob Sanderson




Information Standards Advocate






Digital Library Systems and Services






Stanford, CA 94305