Re: [web-annotation] Allow >1 role per resource

While I'm sympathetic to the rationale, this seems like it would make 
the model more complex, less efficient for processing, introduce 
possible conflicting behaviors, and decrease interoperability.

1) Structurally, this is explicitly more complex. Complexity's not 
necessarily bad, but it's a tradeoff that doesn't seem to be worth it 
(at least without more concrete and pressing use cases).

2) If the UA is treating different `role`s/`motive`s with different 
presentations or functionality (e.g. the copy-edit use case), it's 
already a burden to have to dig into each body to get the `role`; 
forcing them to treat each `role` as an unstructured array in which 
different values can be in any order, and to scan for each type of 
role value in each body is going to be inherently hard (e.g. 
computationally expensive) to process.

3) If there are multiple role values, where different UAs may process 
and present them each uniquely, there is a strong chance that some 
combinations of roles may conflict with each other. For example, if a 
client presents `commenting` and `editing` and `tagging' in 3 distinct
 ways, how should it present a single body that had all 3 role values?

4) Sometimes, the best thing a spec can do for interoperability is to 
*limit* options, leaving only a single clear way to **do it right**. 
If we increase the options on what role value to add to single the 
intent for any particular body, there is likely to be a profusion of 
different combinations, meaning different UAs will have to deal with 
non-specified combinations that each generator arbitrarily assigns. 
There should be a single minimally-ambiguous role value for each type 
of body, such that interoperability emerges between different 
annotation systems.  

We are still in the early phases of this annotation model, and there 
is very little real-world experience for UI presentation for these 
different role values; to the extent that they are backed by 
real-world examples (e.g. in Hypothesis, Twitter, Facebook, MS Word, 
etc.), many of these role values already have distinct presentations. 
I expect that over time, patterns for presenting many of these role 
values would emerge, improving the user experience. But if we let UAs 
mix different role values, there won't be an opportunity to find how 
each is best presented (or just processed) on its own.

If real-world experience doesn't bear out this distinct processing, 
there could be an opportunity to allow multiple role values in some 
future version of the spec, but I suggest we defer this to a later 
version, even if we don't close it outright.

If we find common combinations of role values that would elicit 
specific processing and presentation behavior, then we can mint new 
role values that address both sets of needs simultaneously. 

-- 
GitHub Notification of comment by shepazu
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/104#issuecomment-158463032
 using your GitHub account

Received on Friday, 20 November 2015 17:13:18 UTC