- From: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Date: Wed, 24 Jun 2015 15:52:29 -0400
- To: Doug Schepers <schepers@w3.org>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Ivan Herman <ivan@w3.org>, Chris Birk <cmbirk@gmail.com>, Jacob Jett <jjett2@illinois.edu>, W3C Public Annotation List <public-annotation@w3.org>
- Message-ID: <CAFPX2kARWo-nXhhT8bQ69mLjgu=7rSVuBzDDRuYaTp+S6nR8Hw@mail.gmail.com>
In other words, this (figure 3 of the specs):
"body": {
"@id":"http://example.org/body1",
"@type":"dctypes:Sound"
}
Would become
body" : [
{
"role" : "soundtrack",
"content" : {
"@id":"http://example.org/body1",
"@type":"dctypes:Sound"
}
}
…
On Wed, Jun 24, 2015 at 3:49 PM, Doug Schepers <schepers@w3.org> wrote:
> Hey, folks–
>
> FWIW, this is what I assumed would be the case… add the level of
> abstraction/indirection only when needed, allow literals otherwise.
>
> Regards–
> –Doug
>
> On 6/24/15 3:46 PM, Paolo Ciccarese wrote:
>
>> Rob,
>> could these two cases co-exist?
>>
>> {
>> "body" : [
>> {
>> "role" : "edit",
>> "content" : "literalcontent"
>> }
>> …
>> ]
>> }
>>
>> {
>> "body" : [
>> {
>> "role" : "edit",
>> "content" : {
>> "@id": "http://youtube.com/somevideo"
>> }
>> }
>> …
>> ]
>> }
>>
>> In other words, we use the shortcut for the literals (that cannot be
>> reused anyway) and the verbose way with resources?
>>
>> Paolo
>>
>>
>> On Wed, Jun 24, 2015 at 3:44 PM, Robert Sanderson <azaroth42@gmail.com
>> <mailto:azaroth42@gmail.com>> wrote:
>>
>>
>> For once I disagree with Paolo! (Put it in your calendars!)
>>
>> If every body had a role, I think there would be no need for
>> motivation. And the motivation would potentially be both confusing
>> and unactionable. For example:
>>
>> {
>> motivation: tagging,
>> body: {
>> role: commenting,
>> resource: http://youtube.com/somevideo
>> }
>> }
>>
>> In that case, it seems like the motivation and the role of the body
>> are completely at odds and the client has no way to understand the
>> intent?
>>
>>
>> On Wed, Jun 24, 2015 at 5:03 AM, Paolo Ciccarese
>> <paolo.ciccarese@gmail.com <mailto:paolo.ciccarese@gmail.com>> wrote:
>>
>> I guess that is true if we allow the range of "content" to be
>> either a Literal or another Resource as we do now for 'body' and
>> 'Simple Textual Bodies'.
>> I was assuming the range of content to be always a Resource, but
>> you are right, that is unnecessary.
>>
>> I would just recommend to stick to 'role' for Bodies and
>> 'motivation' for the Annotation as I strongly believe those are
>> different things.
>> in Doug example the motivation is 'editing' and within that
>> motivation we have bodies with different roles.
>>
>> Best,
>> Paolo
>>
>> On Wed, Jun 24, 2015 at 5:19 AM, Ivan Herman <ivan@w3.org
>> <mailto:ivan@w3.org>> wrote:
>>
>> Actually… In the example below, I would expect that
>>
>> {
>> "body" : [
>> {
>> "role" : "edit",
>> "content" : "newcontent"
>> }
>> …
>> ]
>> }
>>
>> which is analogous to the fact that we may have a string as
>> a body. So, in fact, this is pretty much the same as what
>> Doug had in mind a while ago, and also analogous to what Rob
>> proposed. Ie, aren't you all in a wild agreement?
>>
>> Ivan
>>
>> P.S. Except that Doug, without realizing, invented the
>> concept of a blank node, ie, a resource whose identifier is
>> not explicit:-)
>>
>>
>>
>> > On 23 Jun 2015, at 22:07 , Paolo Ciccarese
>> <paolo.ciccarese@gmail.com
>> <mailto:paolo.ciccarese@gmail.com>> wrote:
>> >
>> > Doug,
>> > I am assuming this is not acceptable compromise as
>> already too verbose?
>> >
>> > {
>> > "body": [
>> > {
>> > "role": "edit",
>> > "content": {
>> > "value": "newcontent"
>> > }
>> > },
>> > {
>> > "role": "comment",
>> > "content": {
>> > "value": "This needed changing"
>> > }
>> > }
>> > ]
>> > }
>> >
>> > On Tue, Jun 23, 2015 at 2:32 PM, Robert Sanderson
>> <azaroth42@gmail.com <mailto:azaroth42@gmail.com>> wrote:
>> >
>> > The issue is the inability to have community specific
>> motivations be processable without RDF level inferencing
>> (e.g. that hasEdit is a sub property of hasBody)
>> >
>> > Rob
>> >
>> > On Tue, Jun 23, 2015 at 11:31 AM, Chris Birk
>> <cmbirk@gmail.com <mailto:cmbirk@gmail.com>> wrote:
>> > I agree with keeping the model flexible, and I agree with
>> having multiple bodies. The concern with having motivation
>> on a body level is query complexity.
>> >
>> > If I want to grab all annotations that are editing
>> content, I have to first grab *all* annotations, and then
>> iterate through their bodies to check for the ‘editing’
>> motivation. If the motivation is on an annotation level,
>> this is much simpler.
>> >
>> > I wasn’t present for the original model decisions, so I
>> apologize if I’m re-hashing a previous issue here, but one
>> solution would be simply moving the motivations to a
>> top-level annotation attribute key. For example, instead of
>> having
>> > --
>> > {
>> > "body": [
>> > {
>> > “motivation”: “edit”,
>> > “value”: “new content"
>> > },
>> > {
>> > “motivation”: “comment”,
>> > “value”: “This needed changing"
>> > }
>> > ]
>> > }
>> > ---
>> > changing to
>> > ---
>> > {
>> > ...
>> > “edits”: [
>> > {
>> > ...
>> > }
>> > ],
>> > “comments”: [
>> > {
>> > …
>> > }
>> > ]
>> > ...
>> > }
>> > —
>> >
>> > Where “edits”, “comments”, etc. are optional elements
>> that coincide with our list of acceptable motivations and
>> take the place of “body”. It would be much simpler to
>> determine what the annotation contains. It would seem to me
>> this would be much simpler for implementers to deal with.
>> >
>> > I’m sure there are drawbacks I’m not thinking of here,
>> but thought I would throw that model out there while we’re
>> discussing motivations.
>> >
>> > Another solution that would fit with the current model is
>> to keep a list of all contained motivations at the top-level
>> ( and keep the individual motivations attached to the bodies
>> ). This method seems pretty “hacky”, but at least you would
>> have an idea of what the annotation contained. Grabbing all
>> annotations with motivation:edit would still be relatively
>> costly.
>> >
>> >
>> > - Chris
>> > @cmbirk
>> > (317) 418-9384 <tel:%28317%29%20418-9384>
>> >
>> > On Tuesday, Jun 23, 2015 at 12:56 PM, Doug Schepers
>> <schepers@w3.org <mailto:schepers@w3.org>>, wrote:
>> > Hi, folks–
>> >
>> > Forgive me for (still) not understanding some of the
>> subtleties of the
>> > issues here; I'll try to make a cogent argument anyway.
>> >
>> > I'm strongly against the notion of restricting the number
>> of bodies (or
>> > targets) in an annotation.
>> >
>> > I look at it from the perspective of an annotator (that
>> is, the end-user):
>> >
>> > Abby selects some text (the word "Julie"); she selects
>> the "annotate"
>> > option from some menu (e.g. context-menu, sidebar, popup,
>> menu-bar,
>> > keyboard shortcut, whatever). A dialog pops up, giving
>> her the option of
>> > leaving a comment, offering a suggested change, adding
>> tags, and so on.
>> > She types the comment, "Julie should be Julia, as
>> mentioned in paragraph
>> > 2"; she types the suggested change, "Julia"; she adds the
>> tags, "#typo",
>> > and "#personalname", and "#sigh".
>> >
>> > The resulting annotation has a single target (the word
>> "Julie"), and 3
>> > bodies (the comment, the replacement text, and the tags).
>> >
>> > A machine thinks that all these bodies apply to the
>> target; it knows
>> > that the replacement text is meant to substitute for the
>> selection text
>> > (the target); it knows that each of the tags should
>> somehow be indexed
>> > for search with this target and body. But it doesn't know
>> what any of
>> > the content /means/.
>> >
>> > The machine doesn't know that Abby referred both to the
>> target and to
>> > the instance of "Julia" in paragraph 2; it only knows
>> about the explicit
>> > link to the target, "Julie"; a human can use the
>> information in the
>> > content body, but the machine can't (unless it's a
>> smarter machine than
>> > we're talking about today).
>> >
>> > The machine doesn't know that Abby added the tag "#typo"
>> as a signal for
>> > the kind of correction she was offering, or that she
>> added the tag
>> > "#personalname" as a note for herself for a different
>> project she's
>> > working on, or why she added the tag "#sigh"; in fact,
>> another human
>> > probably wouldn't know what the tag "#sigh" means… was
>> she bored? is she
>> > irritated at all the typos, in which case the tag "#sigh"
>> is actually
>> > kind of an annotation on the tag "#typo"? was it a
>> wistful sigh because
>> > she loves Julia?
>> >
>> > None of this matters to the machine, which only needs to
>> perform a set
>> > of tasks:
>> > 1) present the human reader/editor with the information,
>> and let the
>> > human decide if they want to accept the change;
>> > 2) provide an affordance (say, a button) to change the
>> selection text
>> > with the replacement text;
>> > 3) if the human decides to make the change, perform the
>> change operation.
>> >
>> > That's it. There are other ancillary tasks, like letting
>> users to
>> > whole-text searches or tagged-index searches, and so on,
>> but for the
>> > core task we're talking about, the machine doesn't need
>> to be any
>> > smarter than that.
>> >
>> > The idea of separating out this annotation into its
>> constituent parts
>> > seems like overkill. I think it would surprise Abby to
>> find that once
>> > she's published what she saw as a single annotation, that
>> it's broken up
>> > into multiple annotations that have to be shared or used
>> separately, and
>> > she can't find her suggested change because the tag body
>> wasn't indexed
>> > with the replacement-text body or the comment body, and
>> so on. To her,
>> > it was a single act of creation, and it should be modeled
>> that way; the
>> > only thing we know about her intent was that she made a
>> single
>> > annotation, and that should be preserved.
>> >
>> > Maybe another annotation interface might offer different,
>> discrete
>> > options that elicit a different act of creation from the
>> user, but the
>> > data model shouldn't constrain that.
>> >
>> >
>> > As argued before, there is ambiguity in this kind of
>> annotation…
>> >
>> > The ambiguity arises in part because we have made a data
>> structure that
>> > is easy to generate and manipulate, so it is "lossy" with
>> regards to all
>> > the expressiveness and inter- and intra-linkages it could
>> have, but
>> > those would come at the price of complexity of format and
>> stringent
>> > requirements on the user to disambiguate intent via the UI.
>> >
>> > The ambiguity mainly arises because of the nature of
>> humans, who
>> > generate and detect complex patterns of behavior, and who
>> have limited
>> > means to express their thoughts or intents.
>> >
>> > We can't solve either of these issues. We can only
>> decrease the
>> > ambiguity a bit.
>> >
>> > Maybe another annotator, Beth, is far more precise in her
>> annotations,
>> > such that there is almost no ambiguity; she separates out
>> her
>> > annotations and is always exactly on point, she replies
>> to her own
>> > annotations if there is any potential ambiguity; that's
>> even easier for
>> > machines to "understand". But maybe another annotator,
>> Chuck, is far
>> > more ambiguous in his annotations, suggesting irrelevant
>> and irreverent
>> > changes, and adding comments and tags that are unhelpful
>> or even
>> > contradictory.
>> >
>> > Web Annotations should allow for this full range of
>> expression, even at
>> > the expense of machine comprehension.
>> >
>> > Please, let's try to keep the model simple by default,
>> and slightly more
>> > complex for more complicated scenarios, and limit the
>> concessions we
>> > make for machines when humans are the real end-users.
>> >
>> >
>> > To Paolo's points about motivations vs roles, or how we
>> structure the
>> > annotations, or having different serializations for JSON
>> and JSON-LD,
>> > I'm open to any of these suggestions; I suggested
>> "motivation" because
>> > it seemed like it met a need, but if it has to be modeled
>> a different
>> > way, that's okay, too.
>> >
>> >
>> > Finally, I want to suggest that if we go down a path of
>> architectural
>> > purity and complexity, the data model is far less likely
>> to be adopted
>> > by authoring tools, so let's keep that in mind.
>> >
>> > Regards–
>> > –Doug
>> >
>> > On 6/21/15 9:17 PM, Paolo Ciccarese wrote:
>> > > 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 <mailto:azaroth42@gmail.com>
>> > > <mailto:azaroth42@gmail.com
>> <mailto: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 <mailto:jjett2@illinois.edu>
>> > > <mailto:jjett2@illinois.edu
>> <mailto: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 <tel:%28217%29%20244-2164>
>> <tel:%28217%29%20244-2164>
>> > > jjett2@illinois.edu <mailto:jjett2@illinois.edu>
>> <mailto:jjett2@illinois.edu <mailto:jjett2@illinois.edu>>
>> > >
>> > >
>> > > On Sun, Jun 21, 2015 at 8:47 AM, Ivan Herman
>> <ivan@w3.org <mailto:ivan@w3.org>
>> > > <mailto:ivan@w3.org <mailto: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 <mailto:t-cole3@illinois.edu>
>> <mailto:t-cole3@illinois.edu <mailto: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
>> >
>> >
>> >
>> >
>> > --
>> > 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
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153 <tel:%2B31-641044153>
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>> --
>> 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
>>
>
--
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
Received on Wednesday, 24 June 2015 19:53:09 UTC