Skip to content
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

Closed
azaroth42 opened this issue Oct 7, 2014 · 11 comments
Closed

Intended Audience for Annotation #8

azaroth42 opened this issue Oct 7, 2014 · 11 comments

Comments

@azaroth42
Copy link
Collaborator

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.

{
  "@id": "http://example.org/epub/annotation/1.json",
  "@type": "oa:Annotation",
  "audience" : {
    "@type" : "schema:EducationalAudience",
    "schema:educationalRole" : "teacher"
   }
  "hasTarget": { },
  "hasBody": { }
}

Background

Audience was discussed at rollout events but not during the CG's work.

Links

@azaroth42
Copy link
Collaborator Author

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.

@azaroth42
Copy link
Collaborator Author

Motion to adopt the proposal in the next iteration of the WD :)

@BigBlueHat
Copy link
Member

Guessing we'll be supporting (if this is adopted...) multiple audiences as well?

From IPDF:

The audience property may identify a single audience or an array of audiences.

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?

@azaroth42 azaroth42 self-assigned this Apr 9, 2015
@azaroth42
Copy link
Collaborator Author

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.

@iherman
Copy link
Member

iherman commented Apr 10, 2015

+1 for me

@tilgovi
Copy link
Contributor

tilgovi commented Apr 12, 2015

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.

@tilgovi
Copy link
Contributor

tilgovi commented Apr 12, 2015

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.

@iherman
Copy link
Member

iherman commented Apr 12, 2015

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

@azaroth42 azaroth42 added the tpac label Oct 21, 2015
@azaroth42
Copy link
Collaborator Author

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.

@shepazu
Copy link
Member

shepazu commented Dec 2, 2015

I think there should be a single model for audience and groups (see #119 ).

@jjett
Copy link

jjett commented Dec 2, 2015

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
[2] http://dublincore.org/documents/dcmi-terms/#terms-audience

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants