Re: CFC: Basic Roles Proposal

Thanks, Kyrce, Davis.

Kyrce, if you have any further thoughts once you're out of the weeds, 
please don't hesitate.

Regards–
–Doug

On 8/31/15 7:57 PM, Swenson, Kyrce wrote:
> 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 <mailto: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 <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 <http://www.pearson.com>

Received on Tuesday, 1 September 2015 01:56:24 UTC