RE: CFC: Basic Roles Proposal

Sorry if this is a dumb question, I’m behind trying to catch up.

Doug inquired about the relationship between motivation and role.   Doesn’t motivation apply to the annotation (only) and roles to the bodies?

Ray

From: Robert Sanderson [mailto:azaroth42@gmail.com]
Sent: Thursday, August 27, 2015 8:55 PM
To: Doug Schepers
Cc: Web Annotation; Chris Birk; Bill Hunt; Benjamin Young
Subject: Re: CFC: Basic Roles Proposal



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