Re: Proposal to keep motivatedBy as a property of Annotation

Rob 

Not sure you need this sentence:

"A body or target can play exactly one Role within an Annotation. "

I think you mean

there can only be one role for any body or target

But this is per the definition, so not sure why you restated. Am I missing something?

regards, frederick

> On Sep 8, 2015, at 4:59 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> +1 overall, with 3.2 being the most convincing and 3.1a being a reasonable use case, ... with some caveats:
> 
> * The risk of implementers using motivatedBy for unintended purposes is very, very high.  In a current project, two developers built tagging systems from the current OA spec. One built their code around motivatedBy tagging, and the other around the (current) classes of Tag and SemanticTag.  When these assumptions were reflected into the serialization of tags, it resulted in non-interoperable systems *built within the same project*.  We must be *very* clear as to the usage of motivatedBy versus hasRole and stick to the semantics consistently.  
> 
> * 3.1 suggests that there could be two separate vocabularies (motivations and roles).  I think this would result in utter confusion as to which to use in which situation, and would require extensions to double the number of things created.  Or, if there were some motivations that weren't roles, there would be a lot of discussion about where individual entries belong.  Freedom from choice is better for progress and adoption, in this case.  So I'm -1 to the second example in 3.1.
> 
> * 3.3 crosses the line (for me) in the semantics, and I would prefer it on the rejected pile.  It is the same use case as the rejected 4.2 default motivation:  there is a body, which does not have a role. In 3.3 it doesn't have a role because it's a literal and can't have any properties at all.  In 4.2 it just doesn't have one.  If 4.2 is out, then 3.3 should be out too.  So I'm -1 to 3.3 being in scope, as it brings 4.2 in scope and makes the semantic distinction between role and motivation so blurred as to be impenetrable.
> 
> 
> In other words, I would prefer something along the lines of:
> 
> An Annotation can be motivated by one or more Motivations that express the reason why the annotation was created.  A body or target can play exactly one Role within an Annotation.  The motivation of an Annotation is completely unrelated to the Role of body or target, regardless of whether they are explicitly included in the graph or not.
> 
> Then there is a clear separation of concerns, and implementers can check for body.role  (or body.content.role) without worrying about the motivation.
> 
> 
> Rob
> 
> 
> On Tue, Sep 8, 2015 at 12:36 PM, Paolo Ciccarese <paolo.ciccarese@gmail.com> wrote:
> +1 I also support to keep motivatedBy
> 
> On Tue, Sep 8, 2015 at 3:13 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> (not as chair)
> 
> +1 to proposal to keep motivatedBy for oa:Annotation in addition to roles, with support for adding clarification text to the model specification.
> 
> Bookmarking without body and other examples are compelling.
> 
> Thanks for the clear write-up. We need to coalesce the non-valid use cases into a paragraph of warning if the proposal is adopted.
> 
> regards, Frederick
> 
> Frederick Hirsch
> 
> www.fjhirsch.com
> @fjhirsch
> 
> 
> > On Sep 6, 2015, at 6:41 PM, Timothy Cole <t-cole3@illinois.edu> wrote:
> >
> > You'll recall from the results of the CFC and the discussions we had on the WG's 2 September call (http://www.w3.org/2015/09/02-annotation-minutes.html), that we decided to go forward with the approach for adding role to SpecificResource and EmbeddedContent objects as outlined in Section 3.1 of http://w3c.github.io/web-annotation/model/wd/roles.html#proposed-model-revision.  However, 1 or 2 of the issues outlined in section 3.2 (Further Considerations) of that document remain to be resolved before model can be updated.
> >
> > Ivan, Ray and I took a look at one of these open issues, 3.2.5 Remove motivatedBy [as a property of oa:Annotation] completely.  In the end we created an additional page providing use cases / illustrations of why we think we need to retain the Annotation-level motivatedBy property:
> >
> >   http://w3c.github.io/web-annotation/model/wd/AnnoLevelMotive.html
> >
> > Please take a look at this page and offer comments, counter-point arguments, agreement, etc. as appropriate. Feel free to respond directly on this thread if that makes most sense.
> >
> > In summary, we concluded that Annotation-level motivatedBy property should be retained in order to support 3 relatively common, intuitive and compelling use cases:
> >
> > ·         Needing to express Motivation of the Annotation as a Whole (as distinct from expressing the role of an individual body or target)
> > ·         Needing to express Motivation in the Absence of a Body
> > ·         Needing to express Motivation for an Annotation having a Single, Simple Textual Body (and thereby obviate the need to transform Simple Textual Body into SpecificResource or EmbeddedContent)
> >
> > Key to this discussion are the questions of
> > 1.       whether these uses are important or minimal now that we can express the role of individual SpecificResource and EmbeddedContent objects, and
> > 2.       whether there is a high or low risk of developers confusing Annotation motivatedBy and SpecificResource hasRole and as a result create Annotations that are difficult to understand / process when aggregated.
> >
> > Thanks,
> >
> > Tim Cole
> > University of Illinois at UC
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Dr. Paolo Ciccarese                     
> Principal Knowledge and Software Engineer at PerkinElmer Innovation Lab
> Assistant Professor of Neurology at Harvard Medical School                      
> Assistant in Neuroscience at Mass General Hospital  
> ORCID: http://orcid.org/0000-0002-5156-2703
> 
> 
> 
> -- 
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

Received on Tuesday, 8 September 2015 21:36:42 UTC