Re: CFC: Basic Roles Proposal

On Thu, Aug 27, 2015 at 3:09 PM, Doug Schepers <schepers@w3.org> 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).
>
> | 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.

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.


> | 2. SHOULD use the same construction for tags as other roles
>
> You seemed to allude that this means we have the same construction for
> Semantic Tags and Tags; is that right? That consistency would be good.
>

Yes.



> But your examples seems to show pretty much the opposite of what I'd
> suggested last week, having the text value be the default (which I thought
> we'd agreed on):
>
> Tag
>   "body": {
>     "role": "tagging",
>     "content": {"text": "tag1"}
>   }
>
> Semantic Tag
>   "body": {
>     "role": "tagging",
>     "content": "http://example.org/tag1"
>   }
>

This is using the same role construction for tags (SpecificResource with a
role of oa:tagging) compared to the existing construction of special Tag
and SemanticTag objects.



> Whereas I'd have expected something like this:
>
> Tag
>   "body": {
>     "role": "tagging",
>     "content": "tag1"
>   }
>
> Semantic Tag
>   "body": {
>     "role": "tagging",
>     "content": {"url": "http://example.org/tag1"}
>   }
>
> Clearly, I'm missing something… can you explain?
>

I don't think I can explain this any more clearly than I already have in
the past. Apologies, and I do hope someone else will have more success.



> | 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. Perhaps these just shouldn't be
motivations at all.



> 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.



> | 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.



> | 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 :)


| 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.



> [...] 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.



> I was surprised that the Roles Note didn't contain an example for the
> copy-edit use case,
> [snip]

Here is an alternate proposal based on Bill Hunt's suggestion [1], which
> I'm putting forward as a strawman; [snip]


This was discussed and discarded in the most recent call. You'll see in the
minutes of that call ( http://www.w3.org/2015/08/19-annotation-minutes.html
) albiet slightly confusedly due to some of the irc lag that of the people
that gave an opinion:

Rob, Benjamin, Jacob, Tim, Ivan: -1
Chris: +1

It's mentioned in the document as bullet three of the options that were
considered and discarded in the intro of section 3.


Compared to the proposal that we gathered consensus around, as described in
the document:

Rob, Benjamin, Tim, Jacob, Ivan: +1
Kyrce: -1

And the option for adding to both embedded content and specific resource
which was a very mixed bag.


 Both seem to allow for extending the motivations, and would gracefully
> degrade; a UA can just ignore values it doesn't understand. Both make
> reasonable sense to me. The second one (Bill's) feels a bit more like it's
> an analog of element-property syntax, which works well with my brain, and
> it's a bit less verbose, but maybe there are deeper problems with it?


Again, I'm afraid I don't know how else to explain the problems in ways
other than the discussions that have already happened several times already.


Like others, I'd like to close this issue and move on. But I do want to
> make sure that we're thoughtfully considering our options and our
> rationales,


We have and we are :)

Rob