Re: Proposal to keep motivatedBy as a property of Annotation

Sorry, yes.  I mean: Each body or target may have at most one role.

And the restating was to contrast with the ability to have multiple
motivatedBy relationships for the same annotation.

e.g.

{
  "motivation": [ "commenting", "tagging" ]
}
 is fine

but
{
  "role": [ "commenting", "tagging" ]
}

is not.

R


On Tue, Sep 8, 2015 at 2:36 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:

> 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
>
>
>
>
>
>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305