- From: Ivan Herman via GitHub <sysbot+gh@w3.org>
- Date: Fri, 04 Dec 2015 09:55:01 +0000
- To: public-annotation@w3.org
@tcole said: > The schema.org audience property and Audience class is generally adequate as is to describe a Group as the audience of an annotation, allowing annotation authors to point to a further description of a Group when needed, and as necessary allows communities to offer their own extended models of audience-related attributes of a Group. Using schema.org annotation agents can name the Group that is the target of an annotation (schema:audienceType), and for certain existing sub-types of Audience (e.g., PeopleAudience), annotation agents can provide additional audience-relevant attributes of the Group, e.g., gender, min. age, max age. And of course through schema:url, schema:sameAs, additional rdfa typeOf, annotation creators can link to further information about a Group relevant to its other (non-audience) roles in the annotation ecosystem. This seems to reinforce what I claimed: > We agreed to use the schema.org/Audience class. It has a bunch of subclasses defined by schema.org[…] an instance can use the `audienceType` property whose value is any text, and that can be used to model any collection of users, a.k.a. groups in this sense. What this tells me is that the non-authorization and non-access-control aspect of a group can be modeled by Audience, ie, by what we have accepted to use. That part is done. And I keep to my opinion: that is covered, and we should not introduce a new concept for a "group" in our terminology and into our model. My proposal is to close down that aspect of the issue. (As @tcole said, there may be a more complex concept of a group, but I would object to get into a complex set of description to characterize those entities; I am not even sure what would really be what we described. Leave that for either future releases or for other groups (sic!) out there.) --- On the "authorization" aspect, @shepazu also said: > […] if we want interoperability, we may wish to add a normative requirement that a UA SHOULD honor a stated restriction, whether that is group or some other well-defined "audience" (I can imagine that students might not have access to instructor annotations on a textbook, for example). and also added: > To be clear, I'm not suggesting we define those access-restricted categories, just that we enable communities to do so The way I read these lines is to add something saying: > “User Agents should honor any access restrictions that may be specified for a given audience, although this specification does not define how to express those access restrictions.” (or something similar after suitable wordsmithing.) I am fine with such a statement being added which probably reflects what we all think (and covers the example @shepazu gave). This can be added to the text about audiences (as a note, for example, not to disrupt that flow of the text). This may allow to close this issue and move on. -- GitHub Notification of comment by iherman Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/119#issuecomment-161924827 using your GitHub account
Received on Friday, 4 December 2015 09:55:03 UTC