W3C home > Mailing lists > Public > public-annotation@w3.org > December 2015

Re: [web-annotation] How do we model "groups" in the Annotation model?

From: Nick Stenning via GitHub <sysbot+gh@w3.org>
Date: Fri, 04 Dec 2015 11:06:23 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-161938933-1449227182-sysbot+gh@w3.org>
This is a tricky topic, so let's not be surprised that there's 
miscommunication going on. As has already pointed out elsewhere, 
"groups" is a heavily overloaded word, so let's try and be clear about
 what we want to achieve.

> Sometimes you want to have an annotation published only to a 
particular group, and you may wish to let only those people see it.

As written, this is absolutely an access control requirement. You a 
want the ability to give certain collections of 
people/machines/whatever the ability to perform certain actions on 
certain resources. To my mind this doesn't place any requirements on 
the model, but it does (as @BigBlueHat) and others have suggested, 
have implications for the protocol.

@BigBlueHat and @azaroth42: are you imagining that 
 will be one important unit of access control granularity? That is, a 
container could represent a group's annotations, and I will be able to
 see and/or modify specific containers dependent on membership of that

>  What about annotations that are stored locally, or exchanged 
offline, or otherwise not accessed via the protocol (which not every 
UA may use)? How is a client supposed to know how to treat those, if 
there's no property contained in the annotation itself?

If I have the serialised content of an annotation, no matter how I 
received it, then *by definition* I have the ability to view the 
abstract entity represented by that data. Trying to enforce anything 
else through model properties doesn't make any sense. They're just 
bits on a computer I control...

If I have the serialised content of an annotation, but no idea where 
it lives in an annotation store, then I'm not sure what it even means 
to ask "do I have permission to edit this annotation"? Again, it's 
just some bits on a computer I control. I can edit them, but that's 
not "editing" in any meaningful sense. Without an annotation service 
(even a private one for my own use) I can't republish those edits.

So, overall, I think yes, this is an access control issue.


**But**, there is one important aspect in which I think this does 
touch on the model, and I suspect that @shepazu may be thinking in 
these terms.  A potential user interface for annotating:

1. May need to be able to signal to a user that an annotation comes 
from a particular group. 
2. May need to know whether a user can create annotations in the group
 in order to correctly display or hide editing controls.
3. May need to know what permissions the user has on specific 
annotations within the group as a result of a role conferred within 
that group (such as "moderator", "administrator", "teacher", etc.)

It's not immediately clear to me that any of these considerations 
place hard requirements on the model, as all of them could in 
principle be achieved by other means (the client maintains state about
 where each annotation came from, and identity/permissions information
 also could come from elsewhere). But I think there is one very 
important scenario that we're not yet really considering: federation.

If a client retrieves an annotation from its "canonical" data store 
(whatever that means) then I can maintain state about where it came 
from and who's allowed to do what with it.

But what if a client retrieves an annotation from a data store which 
is republishing that annotation? What if a client retrieves 
annotations through an "aggregator" API that exposes annotations from 
multiple underlying containers through one set of endpoints?

AIUI there is at the moment no support in the model for specifying the
 provenance of such annotations, or for including any kind of 
reference to where changes to such annotations need to be submitted 
(because I would guess the answer would probably not be "back to the 


In summary, then:

- There is an access control component to this which (IMO) 
doesn't/shouldn't form part of the model
- There are, however, considerations around display which 
fundamentally boil down to support within the model for discovering an
 annotation's provenance. Perhaps we should open an issue to discuss 
this if we don't have one already?
- I don't think the "audience" field discussed in #8 has anything to 
do with groups. It seems to me that independent of any discussion of 
groups, an "audience" field for hinting display intent to a potential 
user agent is a useful thing to pursue.

GitHub Notification of comment by nickstenning
Please view or discuss this issue at 
 using your GitHub account
Received on Friday, 4 December 2015 11:06:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:43 UTC