{"action":"created","issue":{"url":"https://api.github.com/repos/schemaorg/schemaorg/issues/1100","repository_url":"https://api.github.com/repos/schemaorg/schemaorg","labels_url":"https://api.github.com/repos/schemaorg/schemaorg/issues/1100/labels{/name}","comments_url":"https://api.github.com/repos/schemaorg/schemaorg/issues/1100/comments","events_url":"https://api.github.com/repos/schemaorg/schemaorg/issues/1100/events","html_url":"https://github.com/schemaorg/schemaorg/issues/1100","id":147915067,"number":1100,"title":"Proposal of accessMode, accessModeSufficient, and accessibilitySummary properties for e.g. epubs","user":{"login":"madeleinerothberg","id":11875605,"avatar_url":"https://avatars.githubusercontent.com/u/11875605?v=3","gravatar_id":"","url":"https://api.github.com/users/madeleinerothberg","html_url":"https://github.com/madeleinerothberg","followers_url":"https://api.github.com/users/madeleinerothberg/followers","following_url":"https://api.github.com/users/madeleinerothberg/following{/other_user}","gists_url":"https://api.github.com/users/madeleinerothberg/gists{/gist_id}","starred_url":"https://api.github.com/users/madeleinerothberg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/madeleinerothberg/subscriptions","organizations_url":"https://api.github.com/users/madeleinerothberg/orgs","repos_url":"https://api.github.com/users/madeleinerothberg/repos","events_url":"https://api.github.com/users/madeleinerothberg/events{/privacy}","received_events_url":"https://api.github.com/users/madeleinerothberg/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/schemaorg/schemaorg/labels/schema.org%20vocab","name":"schema.org vocab","color":"fbca04"},{"url":"https://api.github.com/repos/schemaorg/schemaorg/labels/type:exact%20proposal","name":"type:exact proposal","color":"bfe5bf"}],"state":"open","locked":false,"assignee":{"login":"danbri","id":170265,"avatar_url":"https://avatars.githubusercontent.com/u/170265?v=3","gravatar_id":"","url":"https://api.github.com/users/danbri","html_url":"https://github.com/danbri","followers_url":"https://api.github.com/users/danbri/followers","following_url":"https://api.github.com/users/danbri/following{/other_user}","gists_url":"https://api.github.com/users/danbri/gists{/gist_id}","starred_url":"https://api.github.com/users/danbri/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danbri/subscriptions","organizations_url":"https://api.github.com/users/danbri/orgs","repos_url":"https://api.github.com/users/danbri/repos","events_url":"https://api.github.com/users/danbri/events{/privacy}","received_events_url":"https://api.github.com/users/danbri/received_events","type":"User","site_admin":false},"milestone":{"url":"https://api.github.com/repos/schemaorg/schemaorg/milestones/5","html_url":"https://github.com/schemaorg/schemaorg/milestones/The%20distant,%20hazy%20future%20(or%20possibly%20never)","labels_url":"https://api.github.com/repos/schemaorg/schemaorg/milestones/5/labels","id":945050,"number":5,"title":"The distant, hazy future (or possibly never)","description":"Milestone representing non-nearterm goals, or that the issue may not ever be directly resolved to the satisfaction of its raiser. The \"won't fix\" label makes the latter clearer. \r\n\r\nWe use this milestone so that each issue is filed under a milestone unless it hasn't been classified yet.","creator":{"login":"danbri","id":170265,"avatar_url":"https://avatars.githubusercontent.com/u/170265?v=3","gravatar_id":"","url":"https://api.github.com/users/danbri","html_url":"https://github.com/danbri","followers_url":"https://api.github.com/users/danbri/followers","following_url":"https://api.github.com/users/danbri/following{/other_user}","gists_url":"https://api.github.com/users/danbri/gists{/gist_id}","starred_url":"https://api.github.com/users/danbri/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danbri/subscriptions","organizations_url":"https://api.github.com/users/danbri/orgs","repos_url":"https://api.github.com/users/danbri/repos","events_url":"https://api.github.com/users/danbri/events{/privacy}","received_events_url":"https://api.github.com/users/danbri/received_events","type":"User","site_admin":false},"open_issues":24,"closed_issues":15,"state":"open","created_at":"2015-01-21T10:23:13Z","updated_at":"2016-04-21T13:30:13Z","due_on":null,"closed_at":null},"comments":9,"created_at":"2016-04-13T00:57:39Z","updated_at":"2016-04-29T13:04:57Z","closed_at":null,"body":"This proposal comes from the digital publishing community, and specifically from the Epub 3.1 Accessibility Working Group (with support from the whole Epub 3.1 group).\r\n\r\nThis proposal addresses use cases in digital publishing for accessible ebooks for which current metadata is not sufficient. These use cases require distinguishing between an ebook which has the complete text and audio of the work, one with the complete text and partial audio, and one with the complete audio and partial text. Additional permutations of this sort arise as multimedia in ebooks is factored in, requiring an access mode-based solution rather than a vocabulary of types of books.\r\n\r\nLike the existing accessibility properties, these new properties can apply to any CreativeWork. They might apply to physical books in some cases (particularly braille books and audio books on physical media) but this work is probably separate from the bibliographic extension.\r\n\r\nWe are proposing three properties: \r\naccessMode: The human sensory perceptual system or cognitive faculty through which a person may process or perceive information.\r\n\r\naccessModeSufficient: A list of single or combined accessModes that are sufficient to understand all the intellectual content of a resource.\r\n\r\naccessibilitySummary: A human-readable summary of specific accessibility features or deficiencies, consistent with the other accessibility metadata but expressing subtleties such as \"short descriptions are present but long descriptions will be needed for non-visual users\" or \"short descriptions are present and no long descriptions are needed.\"\r\n\r\naccessMode is important for defining the basic contents of a file. Is this an ebook with audio or plain text? Are there visuals? Having this information allows a more personalized search process because tools can support users who are looking for materials that meet their needs with or without accessibilityFeatures.\r\n\r\naccessModeSufficient is important for distinguishing the various ebook types described above. The use cases in our proposal show in detail why this is necessary to permit fine-grained description of accessible ebooks. It permits a metadata author to be specific about what combinations of access modes will give full access to a resource. Some metadata authors may not wish to author this property; they will still be able to make use of accessMode, which is simpler. Publishers working intensively on accessible ebooks will be motivated to understand and use both properties. \r\n\r\naccessModeSufficient may also be useful to search engines seeking to filter resources for users. In some cases, it serves as an encoding of the combination of accessModes and accessibilityFeatures, revealing, for example, that a silent video is accessible even though it lacks captions, because there is no audio to be captioned, or that a web page that has images is accessible to a non-visual user because the images have been described.\r\n\r\naccessibilitySummary offers a backup for subtle information that is hard to communicate with structured metadata but might be important to readers searching for a suitable ebook or other resource. \r\n\r\nThese properties are suitable for non-ebook use as well. Any multimedia resource can be better described with these properties.\r\n\r\nThe proposal is detailed at the following page, including use cases:\r\n<https://github.com/daisy/epub-revision-a11y/wiki/ePub-3.1-Accessibility--Proposal-To-Schema.org>"},"comment":{"url":"https://api.github.com/repos/schemaorg/schemaorg/issues/comments/215705715","html_url":"https://github.com/schemaorg/schemaorg/issues/1100#issuecomment-215705715","issue_url":"https://api.github.com/repos/schemaorg/schemaorg/issues/1100","id":215705715,"user":{"login":"madeleinerothberg","id":11875605,"avatar_url":"https://avatars.githubusercontent.com/u/11875605?v=3","gravatar_id":"","url":"https://api.github.com/users/madeleinerothberg","html_url":"https://github.com/madeleinerothberg","followers_url":"https://api.github.com/users/madeleinerothberg/followers","following_url":"https://api.github.com/users/madeleinerothberg/following{/other_user}","gists_url":"https://api.github.com/users/madeleinerothberg/gists{/gist_id}","starred_url":"https://api.github.com/users/madeleinerothberg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/madeleinerothberg/subscriptions","organizations_url":"https://api.github.com/users/madeleinerothberg/orgs","repos_url":"https://api.github.com/users/madeleinerothberg/repos","events_url":"https://api.github.com/users/madeleinerothberg/events{/privacy}","received_events_url":"https://api.github.com/users/madeleinerothberg/received_events","type":"User","site_admin":false},"created_at":"2016-04-29T13:04:56Z","updated_at":"2016-04-29T13:04:56Z","body":"I'd be happy to move forward with accessibilitySummary and accessMode (which does not require complicated modeling), but let's not delay figuring out the model for accessModeSufficient. Having summary without the others would encourage use of less structured data when more structure is ultimately going to provide better results. The EPUB community is also eager to get this metadata in place and is moving toward a version 3.1. How can we work this out? Would a synchronous call for interested participants be helpful?"}}