Re: CFC: Basic Roles Proposal

Thanks, Ray, for the helpful clarification, which seems to be the 
distinction.

FWIW, I now concur with Rob's writeup on 3.2.5 (I initially had some 
reservations), and think that we should move motivation/role from 
Annotation to Body and Target, not simply have it available at either level.

Regards–
–Doug

On 8/31/15 4:46 PM, Robert Sanderson wrote:
> 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
> <mailto: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
>     <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____
>
>     __ __
>
>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

Received on Monday, 31 August 2015 21:24:59 UTC