Re: Proposal to keep motivatedBy as a property of Annotation

In regards to 3.3, I have a question as my feeling is to allow being able
to express motivation for a single, simple textual body.

I could say:

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "id": "http://example.org/anno1",
  "type": "Annotation",
  "motivation": ["commenting","disagreeing"] ,
  "target": "http://example.org/target1" ,
  "body": "I don't really like the conclusion."}


where "disagreeing" can be a community specific motivation. That encodes
the reason why I've created the annotation.
I am not specifying any role. I am assuming that is still ok.

Then sure I could expand that to include "commenting" as a role for the
body like in 3.1.

Rob, what is exactly the part you don't like? The risk of interpreting both
"motivations"  as roles for the simple textual body?





On Wed, Sep 9, 2015 at 1:24 AM, Ivan Herman <ivan@w3.org> wrote:

>
> On 08 Sep 2015, at 22:59 , 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.
>
>
> I am fine having only one vocabulary. Actually, I would probably prefer
> it; I do not really think we have given any thought to this issue in this
> note (I certainly did not…)
>
>
> * 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.
>
>
> I understand your unease. To be clear, I was/am uneasy about that one,
> too, and for the same reasons. There is, however, a level of pragmatism
> that makes me accept a slight semantic abuse, which is primarily motivated
> by finding the simplest possible description for the possibly widest use
> case, again from the point of view of a simple JSON viewpoint; that
> example, for me, wins over purity.
>
>
> 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.
>
>
> I do not mind formulating it this way in the spec. It is like many such
> things: we can be sure that some level of abuse will happen, and we cannot
> really forbid it, and it is good to have it nailed down. The 'dangers' of
> doing something semantically unsound (examples in 4.*) is there, but I
> believe we should be liberal in what we allow.
>
> (A typical example is the usage of the @data-* attribute in HTML5. There
> is a clear text saying when that attribute should or shouldn't be used, but
> we can be sure that there are usages out there that do not abide to those
> rules.)
>
> Thanks
>
> Ivan
>
> 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
>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>


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