Re: CFC: Basic Roles Proposal

That depends a bit on the outcome of 3.2.5:

http://w3c.github.io/web-annotation/model/wd/roles.html#remove-motivatedby-completely-rename-motivation-to-role

For the mean time, towards the CfC, please try to evaluate 3.1 separately
as a set of changes against the current model.

Thanks!

Rob



On Mon, Aug 31, 2015 at 1:36 PM, Denenberg, Ray <rden@loc.gov> wrote:

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



-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305