-
Notifications
You must be signed in to change notification settings - Fork 30
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intended Audience for Annotation #8
Comments
Related to this are the accessibility features of content, either in the body or target. Schema.org has a good vocabulary for these as well. |
Motion to adopt the proposal in the next iteration of the WD :) |
Guessing we'll be supporting (if this is adopted...) multiple audiences as well? From IPDF:
So... {
"@id": "http://example.org/epub/annotation/1.json",
"@type": "oa:Annotation",
"audience" : [{
"@type" : "schema:EducationalAudience",
"schema:educationalRole" : "teacher"
},
{
"@type" : "schema:ParentAudience",
"schema:childMinAge" : "12",
"schema:childMaxAge" : "14"
}],
"hasTarget": { … },
"hasBody": { … }
} For...middle school PTA meetings...or something. 😄 That look correct? |
Yes, that's correct :) Any predicate can have multiple values like this, but in the IDPF we explicitly called it out so that a JSON Schema could be written. |
+1 for me |
Why do we need to add the property to our model? If people are going linked data well, and schema becomes a typical vocabulary for describing the target audience of any arbitrary resource, I don't see particular value in putting anything about it in an annotation spec. Seems like a great thing to include in a rich example, but I don't see a need for any language for it. It's not really special or particular to annotations. |
I guess maybe the proposal isn't actually clear insofar as I can't tell what the substantive change to any spec language would be. |
I guess, from the model and spec point of view, what is needed to include the "audience" property in the model. I think that is the only change that is required; I do not think our document should define anything as for the content of the "audience", except than, possibly, relate in a non-normative way to, e.g., the schema properties. However, Rob also referred to accessibility, etc, which may mean that, instead of "audience" we would need a more general "hook" for that type of additional metadata. But it should really be only a single such hook, and we should not get bogged down (in my opinion) to an enumeration of all possible such features... |
TPAC decision: Should continue to discuss. A facet for filtering the display, not a permissions system. Can always look at any annotation that you have real permission to access. |
I think there should be a single model for audience and groups (see #119 ). |
In order to be consistent with our approach to issue #18 I'd like to suggest we also include a mapping between schema:audience [1] and dc:audience [2]. [1] https://schema.org/audience |
Some annotations are generated with an intended audience or class of consumer in mind. That could be a role (teacher vs student), or other property of the consumer (age range, human vs machine, vision impaired vs sighted, etc.)
Justification
This is important for accessibility and ensuring the best user experience by filtering or presenting the most appropriate content for the audience.
Proposal
The proposed solution is to use schema.org's set of audiences and roles, applied to the annotation or resource. This is the solution adopted by the IDPF's Open Annotation in EPUB specification.
Background
Audience was discussed at rollout events but not during the CG's work.
Links
The text was updated successfully, but these errors were encountered: