Re: [model] Proposal: Allow motivatedBy on SpecificResource

I personally think the problem is originated by the overloaded meaning that
‘motivatedBy’ gained with time. Originally we were using types and we were
subclassing Annotation to specify the desire annotation type (for instance
Comment). To avoid the types proliferation and potential incompatibility,
we move away from that construct and we introduced ‘motivatedBy’.

"The Motivation for an Annotation is a reason for its creation”, why we
created an annotation is not necessarily describing how the annotation is
shaped. The ‘motivatedBy’ for an edit is “oa:editing” weather or not one or
more description, tags, link to existing documents are provided. I always
thought that assuming that given a ‘motivatedBy’ I should know exactly how
to ‘read' the annotation is a bit of a stretch… it never worked for me and
as the current discussion proves, it does not work for other use cases.

I’ve always considered the bookmark in Firefox as a good example. A
bookmark consists of a URL, a description and tags. The motivation is still
‘bookmarking’ and the multiple bodies allow to connect all of that in one
single annotation. It is true though that in this specific case we don’t
have interpretation issues as the Tags are modeled with a specific
construct and we have only one textual body.

Any time I needed to model something more complex, in Domeo, I resorted to
structured bodies and named graphs as I get all the flexibility I need by
defining precisely the role of each item of the body. However, that
increases the complexity of the resulting artifact.

If we had to play with the current rules and introduce a role for each body
of the annotation, one way would be to add a node like we did for Semantic
Tags. But that will be verbose.

 Another way would be to change the rules and have a JSON format that is a
compact version of the JSON-LD format, so that what Doug proposed - using
something like hasRole in place of motivatedBy - makes sense in JSON and
would be shaped with an intermediate node in JSON-LD. I am not sure
somebody mentioned this already (many threads of emails went by on this
topic) and I am not sure this would be a good idea for interoperability
reasons.

Yet another way I could think of, forgetting for a second JSON-LD, is to
create a map of bodies so that in simple cases I would just look at the
values of the map… and when I need to define roles I could attach that to
the keys. Like a "bodies map".

Paolo

On Sun, Jun 21, 2015 at 6:02 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> Ivan, Jacob,
>
> Yes, the pre-CG models only allowed for one body and multiple targets.
> The discussion in the CG was similar to the current one (one comment with
> several tags, edit text with reason, etc) and the desire to keep them as a
> single annotation, which led to multiple bodies and multiple targets.
>
> While it would be a departure from the CG's model, if there's a
> consistent, acceptable and simpler model that supports the same use cases,
> it would be good to go with that :)
>
> Rob
>
>
>
> On Sun, Jun 21, 2015 at 2:52 PM, Jacob Jett <jjett2@illinois.edu> wrote:
>
>> Hi Ivan,
>>
>> As memory serves multiple bodies and multiple targets were never
>> restricted by the CG. In fact, as I recall it was designed to allow a
>> number of bodies that apply equally to a number of targets within the
>> context of the same motivation. This might have been a variety of the
>> tagging use case that got spun out as a "needed" alternative to choices and
>> composites.
>>
>> Regards,
>>
>> Jacob
>>
>>
>>
>> _____________________________________________________
>> Jacob Jett
>> Research Assistant
>> Center for Informatics Research in Science and Scholarship
>> The Graduate School of Library and Information Science
>> University of Illinois at Urbana-Champaign
>> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
>> (217) 244-2164
>> jjett2@illinois.edu
>>
>>
>> On Sun, Jun 21, 2015 at 8:47 AM, Ivan Herman <ivan@w3.org> wrote:
>>
>>> Rob,
>>>
>>> I am sympathetic to your proposal. However, we owe to ourselves to look
>>> at the reasons why we departed from the
>>> restriction of the Annotation CG's document and introduced multiple
>>> bodies. Shame on me, but I do not remember the
>>> reasons we made the change, and I did not find the traces in the mailing
>>> list. Can you remind me/us (or point at the
>>> relevant mails) of the issues we thought of solving by allowing multiple
>>> bodies?
>>>
>>> Thanks
>>>
>>> Ivan
>>>
>>>
>>> On Fri, June 19, 2015 4:16 pm, Robert Sanderson wrote:
>>> > Tim, all,
>>> >
>>> > On Fri, Jun 19, 2015 at 9:06 AM, Timothy Cole <t-cole3@illinois.edu>
>>> wrote:
>>> >
>>> >> In my mind, allowing body-level motivations, at least for the use
>>> cases so
>>> >> far proposed, is simply a way to conflate what should be separate
>>> >> annotation graphs.
>>> >>
>>> >
>>> >
>>> >
>>> >> For example, should the protocol have a way of allowing posting of
>>> >> multiple (related or chained) annotations in a single transaction?
>>> (Does it
>>> >> already?)
>>> >>
>>> >
>>> > It does not.  LDP does not have a notion of transactions at all.  And
>>> (as
>>> > you know) we don't have a notion of sets/lists of annotations beyond
>>> the
>>> > unordered containership.
>>> >
>>> >
>>> >> Anyway, I don’t want to flog a dead horse, but since Doug asked
>>> directly
>>> >> about slippery slopes, I did want to elaborate on the trouble we
>>> might get
>>> >> ourselves into if we allow multiple bodies that relate to multiple
>>> targets
>>> >> and to each other in substantively different ways.  I still do think
>>> there
>>> >> is a slippery slope potential here.
>>> >>
>>> >
>>> > This seems like a good opportunity to re-evaluate multiple bodies as a
>>> > feature at all.  To my knowledge, all multiple body use cases have
>>> been for
>>> > different motivations.  Most frequently it has been comment plus tags
>>> that
>>> > are all really about the same target.  If we went to a multiple
>>> annotation
>>> > model for edit + comment, we could more reliably also go to a multiple
>>> > annotation model for tag(s) + comment as well.  Then the individual
>>> > annotations could be addressed individually, for example to moderate a
>>> tag
>>> > without at the same time moderating the comment, or vice versa.
>>> >
>>> > Rob
>>> >
>>> > --
>>> > Rob Sanderson
>>> > Information Standards Advocate
>>> > Digital Library Systems and Services
>>> > Stanford, CA 94305
>>> >
>>>
>>>
>>> --
>>> Ivan Herman, W3C Team
>>> URL: http://www.w3.org/People/Ivan/
>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>
>>>
>>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>



-- 
Dr. Paolo Ciccarese
Principal Knowledge and Software Engineer at PerkinElmer Innovation Lab
Assistant Professor in Neurology at Harvard Medical School

Assistant in Neuroscience at Mass General Hospital
ORCID: http://orcid.org/0000-0002-5156-2703