- From: Liddy Nevile <liddy@sunriseresearch.org>
- Date: Thu, 26 Sep 2013 22:43:55 +1000
- To: Gerardo Capiel <gerardoc@benetech.org>
- Cc: Charles McCathie Nevile <chaals@yandex-team.ru>, Charles Myers <charlesm@benetech.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, Alexander Shubin <ajax@yandex-team.ru>, Andy Heath <andyheath@axelrod.plus.com>, Dan Scott <dan@coffeecode.net>, Dan Brickley <danbri@google.com>, Egor Antonov <elderos@yandex-team.ru>, Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>, Jason Johnson <jasjoh@microsoft.com>, George Kerscher <kerscher@montana.com>, Madeleine Rothberg <madeleine_rothberg@wgbh.org>, Matt Garrish <matt.garrish@bell.net>, "public-vocabs@w3.org" <public-vocabs@w3.org>
A thought-line from me. I am not keen to go on working with what we think we have inherited because I don't believe it is going to work. I have tried to think out what we need again, building on previous experience, and taking into account what I have been learning about schema.org. I think it is worth thinking about what I have here. I think this might work for schema.org - see below ----------------------- The requirement is a set of terms with values that allow for the description of both a user's needs and a resource's characteristics. I think that for any resource, we could ask for terms to describe: * accessHazards * accessModes and * accessFeatures. So a resource description might be: Resource: -[Type]-> video -[accessHazard]-> flashing -[accessMode]-> audio+visual -[accessMode]-> visual+text -[accessMode]-> audio -[mediaFeature]-> audioDescription -[mediaFeature]-> captions -[mediaFeature]-> highContrastCaptions (or -[mediaFeature]-> captions -[subType]-> highContrastCaptions ) AccessModes list the possible combinations of accessModes that provide complete perception of a resource. A user who for some reason can't use audio might be really happy with this resource. They would be satisfied with the 'visual + text' version and take advantage of the accessFeatures. A user 'X' who is looking for a suitable resource will need to specify their needs. User X wanting to avoid audio and have highContrastCaptions might say: accessMode: visual, text accessFeatures: audioDescription, captions, highContrastCaptions and it might be inferred that they do not want audio - even though this is not stated specifically. This means that the user is not necessarily going to not get audio but what they will get is sufficient for their perception of the resource. Another user 'Y' with reasons for not wanting visual might say: accessHazard: flashing accessMode: audio In this case, they do not say they don't want visual but they make it clear they want all content to be available to them via audio and to not get any flashing hazards.... --------------------------------------- If we have a suitable ontology, when a user states that they want captions, and does not state that they want audio, can we assume they want a resource in a form that does not have audio as a dependent mode for perception? ie they would not want to be given something that has accessMode audio + text but they would be happy with a resource that has video + text as one form even if it also happens to have some audio.
Received on Thursday, 26 September 2013 14:56:51 UTC