Re: CFC: Basic Roles Proposal

On Tue, Sep 1, 2015 at 9:27 AM, Denenberg, Ray <rden@loc.gov> wrote:

> Rob – My thoughts on 3.1 really have to do with  the question I asked
> yesterday.  It seems to me that we do not have a clear understanding of the
> distinction between a motivation and role.  (**semantic** distinction,
> that is. We understand that a  motivation applies at the annotation level
> and a role at the body level.)
>
>
>
> It seems on the surface that you can have any of the following for a given
> annotation:
>
> 1.      a motivation on the annotation. and no roles on bodies
>
> 2.      a motivation on the annotation and roles for the bodies
>
> 3.      no motivation, roles on the bodies
>
> 4.      no nothing
>
>
>
> None of the examples in 3.1 shows a motivation and of course that’s
> because it’s about roles.  But I think there should be examples that show
> both a motivation and one or more roles so we can better understand the
> semantic relationship.
>
>
>
> For example in 3.1.7 there are three roles (1) comparing (2) antecedent
> (3)  subsequent
>
>
>
> Clearly “comparing” is semantically the same as a motivation and
> “antecedent” and “subsequent” are not.  So the annotation would have the
> same meaning if “comparing” were to be listed as the motivation with no
> role assigned to the body.
>
>
>
> When this whole business came up (motivations on individual bodies) it was
> to support the ability to, in a sense, combine a lot of annotations into a
> single annotation, for efficiency.  I think that idea was rejected, but the
> idea morphed into the ability for  bodies to have “roles” in support of the
> (annotation-level) motivation.   Is this an accurate characterization?
>
>
>
> So that’s  my mental model, only one motivation (in the semantic sense)
> and the roles are in support of the motivation.  Of course the examples
> don’t  support my mental model.
>
>
>
> Take 3.1.1 for example.  The role is “commenting”.  That could be
> expressed with commenting as the motivation, with no role on the body.
> I’m afraid that when people read this they are going to wonder what is the
> semantic difference between these two annotations, when there is none.
>
>
>
> So I would say, for one thing, if there is only one body, it should not
> have a role, but that role should instead be expressed as a motivation. I
> would say further that there should be no roles expressed unless there is
> an annotation-level motivation that the roles support.
>

I think this highlights the confusion that having both annotation and body
level motivation/roles is bound to create. It's quite likely that if we put
these in both places, there could be conflict: an annotation marked as
"editing" with bodies for "replying", "tagging", and "highlighting."

We'd end up with scenarios where we'll need to enforce (somehow) which
bodies are available when the annotation uses a certain motivation--which
trends us back towards classes of annotations...which I think has been
dropped as an option a few times.

Where this is trending now in my head is that we *keep* motivation on the
annotation, but create classes for bodies. What this *might* look like in
JSON-LD is something like:

```
{
  "type": "Annotation"
  "motivation": "editing",
  "bodies": {
    "tags": ["correction", "typo"],
    "comment": "wow...I should learn to type...",
    "edit": {
      "original": "itinirary",
      "replacement": "itinerary"
    },
    "related": ["http://dictionary.reference.com/browse/itinerary"]
  },
  "target": "http://example.com/doc1"
}
```

Obviously, this is pretty loverly JSON, but unlikely to be accurate (or
terribly extensible) JSON-LD in its current form.

However, I do think this addresses the potential tangle we'll have by using
the SKOS concept-based motivations as Roles on bodies, it likely deals with
Bill's concern about performance, and MAY still provide extensiblity
without too much pain...I hope.

The summary would be:
 - keep `motivation` on Annotation
 - create a `bodies` JSON-LD @set object (which would differ from `body` in
its use)
 - craft custom classes (/me ducks) for things in the `bodies` set for our
currently known use cases
 - create a pattern for extending these classes and the creation of new ones

I'm honestly not sure any of this is even possible. :) However, this seems
to be what Bill was getting at, it matches an "expected" format style in
the JSON world, and MAY be map-able to JSON-LD (granted with some
effort...and likely some shift in the names and shape above).

Regardless of the "body class" idea, I do feel having motivation and roles
together will run us into a wall, and we should avoid that either by a)
dropping `motivation` from Annotation or changing what a `role` is on
bodies (as proposed here).


>
>
> I apologize if my idea seems a bit radical at this late stage but I do
> think this is worth some discussion. At the very least, there should be
> examples that show these various relationships among motivations and roles.
>

+1 on seeing examples.

Also, let's not hope it's too late. I don't think we're done yet (surprise,
surprise). ;)

Thanks for grappling with all these issues everyone,
Benjamin
--
Developer Advocate
http://hypothes.is/


>
>
> Ray
>
>
>
>
>
>
>
> *From:* Robert Sanderson [mailto:azaroth42@gmail.com]
> *Sent:* Sunday, August 23, 2015 6:38 PM
> *To:* Web Annotation
> *Subject:* Re: CFC: Basic Roles Proposal
>
>
>
>
>
> +1.
>
>
>
> The proposal fixes many issues in the model, in a consistent and rational
> manner.
>
>
>
> On Sun, Aug 23, 2015 at 3:37 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>
>
> Dear all,
>
>
>
> This is a Call for Consensus (CfC) to update the working group's
> Annotation Model deliverable according to the changes specified in section
> 3.1 of this document:
>
>     http://w3c.github.io/web-annotation/model/wd/roles.html
>
>
>
> Please respond to this CfC by the 1st of September 2015.  Any response is
> valuable, even just a simple +1.  Silence will be considered as agreement.
> This CfC will complete the process discussed in last week's teleconference.
>
>
>
> Thanks in advance,
>
>
>
> Rob
>
>
>
> --
>
> 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
>