Re: CFC: Basic Roles Proposal

Hi, Rob–

(CCing Bill Hunt, Chris Birk, and Benjamin Young)


Thanks for putting this document together.

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.


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.


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

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

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?


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

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.


| 4. MUST allow for domain-specific extension of the set of roles

+1


| 5. SHOULD use the existing motivation structure

I'm not sure what this means.


| 6. MUST be usable in a Linked Data environment
| 7. SHOULD follow Linked Data best practices

+1

But I'm still not sure what the practical constraints this implies. From 
what Ivan and Tim have said, it seems that most constructs could be 
mapped, somehow, to a Linked Data environment.


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


| 9. MUST NOT require clients to use any part of the RDF stack
|    to accomplish common tasks

+1


| 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… which 
leads me to my final point…

As we all agree, we cannot possibly know all the kinds of uses 
annotations will be put to, or all the roles/motivations that might be 
used, so we need to have a generic framework with clear extension 
points. The challenge with a generic framework is that if there are 
multiple ways to express the same thing, you will likely get 
non-interoperability on specific tasks (just look at all the ways you 
can encode a structured document in HTML). 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 that context, defining some "behaviors" for the motivations seems 
like a useful goal, since UA behavior will be driven by user intent as 
expressed in motivations. (I'm using the term "motivation" here, but it 
could be "role".)

I was surprised that the Roles Note didn't contain an example for the 
copy-edit use case, since that was what sparked this whole discussion: 
the need to distinguish between different kinds of bodies for different 
purposes. I've written 2 different formulations for the copy-edit use 
case; I don't know what the Turtle would look like, and maybe that's 
part of my problem with understanding some of the complexities of the 
issue; I'd appreciate clarification; I probably got even some of the 
JSON-LD structure wrong, so I'd appreciate corrections there, too.

Here's the scenario:e we have the text "The process of tying two items 
together is the important thing." in the document at 
http://example.com/as-we-may-think.html; the annotator is suggesting 
changing the string "item" to "idea", along with a rationale, some tags, 
and some other motivations, including custom motivations specific to 
their annotation client (UA1); these annotations are read and processed 
in the editor-in-chief's different annotation client (UA2), which has 
different capabilities (denoted as comments on the different bodies)… 
this is to illustrate extensibility and interoperability.

Here is (something like) the current proposal:

   {
     "@context": "http://www.w3.org/ns/anno.jsonld",
     "type": "Annotation",
     "target": {
       "source": "http://example.com/as-we-may-think.html",
       "selector": {
         "type": "oa:TextQuoteSelector",
         "exact": "items",
         "prefix": "The process of tying two ",
         "suffix": " together is the important thing."
       }
     },
     "body": [
       {
         "role": "editing", // UA2 uses
         "content": "items"
       },
       {
         "role": "commenting", // UA2 uses
         "content": "This should be about concepts, not mechanical 
artifacts."
       },
       {
         "role": "tagging", // UA2 uses
         "content": [
           {
             "value": "correction"
           },
           {
             "value": "memex"
           }
         ]
       },
       {
         "role": "bookmarking", // standard, UA2 doesn't use
         "content": "folder:thesis" //BS value, don't know what would go 
here…
       },
       { // UA2 uses
         "role": "versioning", // vendor-specific, UA2 doesn't use
         "content": "4th draft"
       }
     }
   }

Here is an alternate proposal based on Bill Hunt's suggestion [1], which 
I'm putting forward as a strawman; Bill has suggested that this may be a 
better performance optimization for clients (which is important, if it's 
correct), while others have said that it makes other aspects of the 
model more difficult.

   {
     "@context": "http://www.w3.org/ns/anno.jsonld",
     "type": "Annotation",
     "target": {
       "source": "http://example.com/as-we-may-think.html",
       "selector": {
         "type": "oa:TextQuoteSelector",
         "exact": "items",
         "prefix": "The process of tying two ",
         "suffix": " together is the important thing."
       }
     },
     "body": {
       "editing": { // UA2 uses
         "content": "items"
       },
       "commenting": { // UA2 uses
         "content": "This should be about concepts, not mechanical 
artifacts."
       },
       "tagging": [ // UA2 uses
         {
           "content": "correction"
         },
         {
           "content": "memex"
         }
       ],
       "bookmarking": { // standard, UA2 doesn't use
         "content": "folder:thesis" //BS value, don't know what would go 
here…
       },
       "versioning": { // vendor-specific, UA2 doesn't use
         "content": "4th draft"
       }
     }
   }

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?

In an offlist conversation, Benjamin suggested that Bill's example 
represents a pattern that has been used but deprecated by Twitter, 
Github, and others. I'd like to hear more about that.

I'd also like to hear more from Bill about what this solves that first 
approach wouldn't solve; he mentioned templates, but Benjamin suggested 
those templates could be written another way.


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, so we meet the needs of both the RDF/LD community and the 
JSON/JavaScript community (and those in both).



[1] https://lists.w3.org/Archives/Public/public-annotation/2015Jul/0017.html

Regards–
–Doug


On 8/23/15 6:37 PM, Robert Sanderson wrote:
>
> Dear all,
>
> This is a Call for Consensus (CfC) to update the working group's
> Annotation Model deliverable according to the changes specified in
> section 3.1 of this document:
> http://w3c.github.io/web-annotation/model/wd/roles.html
>
> Please respond to this CfC by the 1st of September 2015.  Any response
> is valuable, even just a simple +1.  Silence will be considered as
> agreement.  This CfC will complete the process discussed in last week's
> teleconference.
>
> Thanks in advance,
>
> Rob
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

Received on Thursday, 27 August 2015 22:09:59 UTC