RE: CFC: Basic Roles Proposal

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

Received on Monday, 31 August 2015 22:31:26 UTC