- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 24 Jun 2015 15:49:04 -0400
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>, Robert Sanderson <azaroth42@gmail.com>
- CC: Ivan Herman <ivan@w3.org>, Chris Birk <cmbirk@gmail.com>, Jacob Jett <jjett2@illinois.edu>, W3C Public Annotation List <public-annotation@w3.org>
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
Received on Wednesday, 24 June 2015 19:49:09 UTC