Re: CFC: Basic Roles Proposal

I've been following and had hoped to do a more extensive response, but
after an application release and a week of firefighting, my reply will be
shorter than I would like.

For the purposes of edit/copy-edit; this makes sense, and I would agree
that it appears to be the simplest viable solution.

- Kyrce

On Mon, Aug 31, 2015 at 6:30 PM, Salisbury, Davis - Hoboken <
dsalisbury@wiley.com> wrote:

> Hi Doug,
>
> Thanks for following up on this. I have been reviewing and catching up on
> everything (I was unfortunately on vacation for that big meeting itself),
> but I am through it all well enough and going by the last two meeting
> minutes/discussions and the Wiki page run-down (
> https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations)
> of the options I feel comfortable.
>
> Essentially, it seems to be a +1 to the changes from me.
>
> I actually don’t think this is overly complicated, and agree that for the
> Copy-edit use cases, which to me are a very important aspect to consider,
> they are pretty essential. When I considered how this would be done
> initially whilst considering similar use cases, something close to this
> seemed to be the intuitive choice (and I think it makes plenty of sense),
> but I was not sure how quite to get there. For me the logic of it seems
> pretty sound and easy to follow, but I am talking strictly from a modeling
> perspective, which is where I am approaching it from mostly.
>
> I will dig in deeper and pipe up if anything occurs to me, but again this
> all looks like a good direction to me.
>
> Regards,
> Davis
>
> -----Original Message-----
> From: Doug Schepers [mailto:schepers@w3.org]
> Sent: Sunday, August 30, 2015 8:08 AM
> To: Robert Sanderson
> Cc: Web Annotation; Kyrce Swenson; Salisbury, Davis - Hoboken
> Subject: Re: CFC: Basic Roles Proposal
>
> Hi, Rob, Kyrce, Davis–
>
> On 8/27/15 8:54 PM, Robert Sanderson wrote:
> > On Thu, Aug 27, 2015 at 3:09 PM, Doug Schepers wrote:
> >
> >     As I understand it, the CFC is just for section 3.1. I'll do so in
> >     the context of the Requirements (on which I have some comments as
> well).
>
> I apologize; because you said we were only reviewing section 3.1, I only
> skimmed section 3.2; I've now read the whole document more closely.
>
>
> >     | 1. MUST allow the addition of roles to individual bodies
> >     Great. I would add a requirement that roles (or motivations) MUST be
> >     allowed on the Annotation as well, not just individual bodies.
> >
> > That wouldn't be a requirement of the proposal, because it's already
> > allowed :)  And we certainly don't have consensus around that as a
> > requirement, particularly given 3.2.5 which would -remove- that ability.
>
> Your rationale seems sensible on 3.2.5., and it has the advantage that
> it slightly simplifies the Annotation object, and reduces possible
> confusion (as you note).
>
> It does mean that you'll have to go looking for "motivation" on
> different bodies and targets, but maybe that will be handled during
> normal processing.
>
>
> During the telcon, Kyrce explained that she thought delegating
> motivation/role from Annotation to Body and Target made it more
> complicated; I hoped we could simplify their use case by also allowing
> "motivation" on the Annotation, but your rationale in 3.2.5. makes that
> seem less appealing, and more complicated.
>
> Kyrce, Davis, I want to make sure that you are comfortable with this
> change, since you voiced concerns.
>
> Kyrce, your rationale was that since Pearson will be using "motivation"
> a lot in your annotations, this would introduce additional complexity
> and/or verbosity; I think the case is actually not so bad as that.
>
> Here are a few points for consideration:
>
> 1) Without having the "motivation" on the body, you can't distinguish
> between comments and suggested text-changes in the copy-edit use case
> [1], so this change is in your interest there.
>
> 2) It's never required to have a "motivation", so if you have a simple
> annotation, you don't necessarily have to include a "motivation".
>
> 3) In cases where you do what to have a "motivation", but only a single
> one for the whole annotation (for example, highlighting or commenting),
> you still only have to make a single "motivation", you just move it from
> the Annotation to the Body or Target. So, it's not more complex, just
> slightly different.
>
> If you still have questions or concerns about this, we're happy to
> discuss it further; we could even have a call to make things clearer.
>
>
> >     I'm confused, by the way, by the mixed use of "role" and
> >     "motivation". Are they the same thing? If so, why did we switch from
> >     "motivation" to "role"? ("motivation" seems clearer to me, and is a
> >     less overloaded term, though longer… if brevity is the goal, maybe
> >     "motive"?) It probably doesn't matter, but I want to make sure I
> >     understand the reason for the change.
> >
> >
> > Because the original request was formulated in terms of roles, and we
> > mapped that to the current motivation system.  We could recast role to
> > motivation with no loss of fidelity.
>
> Okay. While "role" does make sense (it's a functional operator), the
> term "role" is overloaded across the Web Platform, so I'd suggest
> "motive" or "motivation" instead, or any other reasonable suggestion
> anyone has.
>
>
> >     | 3. SHOULD allow the addition of roles to individual targets
> >
> >     What's the use case here? As far as I can tell, a motivation only
> >     makes sense when it's applied to an action of the annotator… that
> >     is, the act of annotation itself (in which case it's on the
> >     Annotation), or on the individual bodies (when there's multiple
> >     motivations, like commenting, tagging, and proposing edits).
> >
> >     You answer is likely to be "example 3.1.7", which I understand and
> >     acknowledge. But it should be explicit when a target would have a
> role.
> >
> > And 3.1.6 for highlighting and bookmarking, when there is potentially no
> > body at all.  The body will never be "highlighting", that's what the
> > annotation is doing for the target.
>
> That makes sense, thanks.
>
>
> > Perhaps these just shouldn't be motivations at all.
>
> I'm not sure what you mean, but to me, they're all the same sort of
> thing, and they still make sense to use the same means of expressing them.
>
>
> >     If role/motivation is allowed on targets, when does the UA decide to
> >     put a motivation on the target versus the annotation? If we allow
> >     this, we should also provide guidance about how a UA should apply it.
> >
> > Sure.
>
> Great.
>
> At some point, we should decide if this belongs in the Data Model spec,
> or in another place; I'm inclined to it should be in the Data Model
> spec, because then we can include normative requirements that can be
> tested, and we'll have better interop.
>
>
> >     | 5. SHOULD use the existing motivation structure
> >     I'm not sure what this means.
> >
> > We shouldn't invent a new construct that would mirror motivations,
> > forcing implementers to understand and develop two separate systems.
>
> Okay, sounds good, thanks.
>
>
> >     | 8. MUST produce a JSON-LD serialization that is easy to use
> >     Nice sentiment, but again, it's not clear what constraint this
> >     really implies, or who it should be "easy to use" for.
> >
> > I'm happy to remove the requirement, but it was one that you added :)
>
> I think I'd have been more explicit about saying something like,
>
> "MUST produce a JSON-LD serialization that is easy to use in a pure JSON
> context".
>
>
> >     | 10. SHOULD allow for graceful degradation when a particular
> >     |    role is not recognized by a client application
> >
> >     +1
> >     But I haven't seen an example where this wouldn't be the case…
> >
> > The option of using subProperties does not degrade gracefully without
> > inferencing.
>
> I don't know how onerous RDF inferencing is, so I guess I can't speak
> well to that requirement, then. (Though it does seem to possibly be in
> conflict with the "easy to use" requirement, depending on who you ask.)
>
>
> >     [...] Since we do have some specific use cases that we want to make
> >     sure work interoperably, we can provide some additional guidance on
> >     how to express those use cases within our generic framework, so that
> >     different UAs can works smoothly together.
> >
> > In an implementation guidelines note, or cookbook, for example. If so, I
> > completely agree.  I'd also like to see the use case written up as a
> > first step towards that.
>
> As I mentioned above, I'd prefer something normative, but that's
> probably a decision that can be deferred until we are enter Candidate
> Recommendation.
>
> I've written the copy-edit use case up in the wiki [1]; I hope this is
> the sort of thing you were looking for, and that it captures Pearson's
> intent in raising this in the first place.
>
>
> >     I was surprised that the Roles Note didn't contain an example for
> >     the copy-edit use case,
> >     [snip]
>
> With the copy-edit use case documented, I'd like to see an example of it
> in the Data Model spec when you have a chance (hopefully before
> republication).
>
>
> [1] https://www.w3.org/annotation/wiki/Use_Cases/Copy-editing
>
> Regards–
> –Doug
>



-- 

*Kyrce Swenson*Manager, Systems Product Support
PXE Enabling Services
Pearson Content Platforms
221 River Street, Second Floor
Hoboken, NJ 07030
T: 201.236.5611


*Pearson *Always Learning
Learn more at www.pearson.com