- From: Liddy Nevile <liddy@sunriseresearch.org>
- Date: Tue, 10 Sep 2013 16:27:48 +1000
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: Charles Myers <charlesm@benetech.org>, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, Alexander Shubin <ajax@yandex-team.ru>, Andy Heath <andyheath@axelrod.plus.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, Dan Scott <dan@coffeecode.net>, Dan Brickley <danbri@google.com>, Egor Antonov <elderos@yandex-team.ru>, Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>, Gerardo Capiel <gerardoc@benetech.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>
mmm .. the discussion seems again to focus on the name for the set of possibilities. My problem is with having this set and the other set. I prefer a model where the details are related to the more general ie where there is a clear connection between audio and captions etc. I will try to show what I mean in a diagram asap, putting all we have together into a map... Liddy On 09/09/2013, at 11:42 PM, Richard Schwerdtfeger wrote: > I agree with mediaFeature for extensibility and because we should > not limit to accessibility. We should not be limited to > accessibility. We could express a media alternative but we need to > be able to quickly that it supports certain access features to > achieve a match. AccessAlternative on its own is not enough as we > would need to know what accessfeatures it supports. > > Rich > > > > Rich Schwerdtfeger > > <graycol.gif>Charles Myers ---09/09/2013 05:58:40 AM---This property > has had three names over the editorial history of the spec. > hasFeature was the start ( > > From: Charles Myers <charlesm@benetech.org> > To: Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org>, > Cc: Dan Scott <dan@coffeecode.net>, Madeleine Rothberg <madeleine_rothberg@wgbh.org > >, Charles McCathie Nevile <chaals@yandex-team.ru>, Andy Heath <andyheath@axelrod.plus.com > >, "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com > >, "<public-vocabs@w3.org>" <public-vocabs@w3.org>, Gerardo Capiel <gerardoc@benetech.org > >, Dan Brickley <danbri@google.com>, Alexander Shubin <ajax@yandex-team.ru > >, Egor Antonov <elderos@yandex-team.ru>, Liddy Nevile <liddy@sunriseresearch.org > >, Richard Schwerdtfeger/Austin/IBM@IBMUS, George Kerscher <kerscher@montana.com > >, Jason Johnson <jasjoh@microsoft.com>, Matt Garrish <matt.garrish@bell.net > > > Date: 09/09/2013 05:58 AM > Subject: Re: [a11y-metadata-project] Schema.org accessibility > proposal Review... > > > > > This property has had three names over the editorial history of the > spec. > > hasFeature was the start (going fro AfA, I believe). That was too > generic to fit into creating work (it would confuse almost anyone) > accessibilityFeature was next, which at least told the use > adaptationFeature followed that, which told was it was useful for. > > However, there were three items that were neither just for > accessibility or adaptations. These were MathML, ChemML and Latex. > > mediaFeature followed that That caused us to say that the features > were not limited to just accessibility. And they are not > alternatives. > > Now we propose mediaAlternative and AccessAlternative. Or even > AccessFeature. These all have the same problem. As someone pointed > out, mediaFeature has the advantage of being extensible for > expressing semantics beyond just accessibility, which may improve > the chance of widespread adoption. > > > > > All that history aside, I do like the lumping of accessMode and the > features/alternatives (whatever name you use). But note that many > of the features, like tactilegraphic and ChemML defy that a bit. > > I'd want to work it out in a chart, much like the practical > properties guide https://wiki.benetech.org/display/a11ymetadata/Practical+Properties+Guide > does for the current method. > > On Sep 8, 2013, at 3:48 PM, Emmanuelle Gutiérrez y Restrepo <emmanuelle@sidar.org > > wrote: > Hi all, > > What about "mediaAlternative", or "accesAlternative"? > > Because, for me, the captions or audiodescription, etc. are not a > "feature" of the media nor a description. > > In the example given by Dan, appears "accesFeature" which also seems > appropriate, to me. I get the feeling that he did not mean to write > it that way, but in that case it's a happy accident. > > Best, > Emmanuelle > > > 2013/9/9 Dan Scott <dan@coffeecode.net> On Sun, Sep 08, 2013 at > 02:36:22PM +0000, Madeleine Rothberg wrote: > > (Gerardo's reply, which arrived when I was almost done writing this, > > covers some of the same issues, but I will send this anyway in > case a > > differently worded explanation is helpful to anyone.) > > > > The solution to knowing which of the accessModes listed for a given > > resource are required for understanding the resource and which are > not has > > traditionally (in Access for All usage) been that the matching > system > > analyzes several pieces of metadata together to draw a conclusion. > Here's > > the example of a video with captions and audio description, which > Charles > > McN correctly marks up as: > > > > <div itemscope=²² itemtype=²http://schema.org/Movie²> > > <meta itemprop=²accessMode² content=²visual²/> > > <meta itemprop=²accessMode² content=²auditory²/> > > <meta itemprop=²mediaFeature² content=²audioDescription²/> > > <meta itemprop=²mediaFeature² content=²captions²/> > > </div> > > > > > > We have resources like this in Teachers' Domain. And the solution > there to > > deciding which resources are well-suited a particular user's > requirements > > is to analyze the whole of the metadata in comparison to the user's > > preferences. If a user cannot see, then if a resource contains > "visual" > > media we look to see if there is a mediaFeature that can > substitute for > > visual. "audioDescription" is an auditory substitute for visual > material, > > so this resource taken as a whole meets this user's needs. > > Perhaps, instead of having repeated accessMode and mediaFeature > properties repeating directly under http://schema.org/Movie, which > (if I > understand correctly) makes it hard to correlate accessMode=visual > with > mediaFeature=audioDescription, these properties should be subsumed > under > a new Type. > > For example, let's call this new type AccessibilityMode and propose > that > the associated property name be accessDescription, just as a > placeholder: > > <div itemscope itemtype="http://schema.org/Movie"> > <div itemprop="accessDescription" itemscope itemtype="http://schema.org/AccessibilityMode > "> > Accessible to sighted users > <meta itemprop="accessMode" content="visual"/> > <meta itemprop="accessFeature" content="audioDescription"/> > </div> > <div itemprop="accessDescription" itemscope itemtype="http://schema.org/AccessibilityMode > "> > Accessible to hearing users > <meta itemprop="accessMode" content="auditory"/> > <meta itemprop="mediaFeature" content="captions"/> > </div> > </div> > > This would enable you to keep the mode & feature meaningfully > connected, > which is I think what you're looking for. And now that we're > distinguishing the accessibility mode as a separate Type, all of the > standard Thing properties are available to us without being associated > with the Movie itself, so you could go also use the "description" > property to note any particular restrictions, etc, for each access > mode. > > -- > You received this message because you are subscribed to the Google > Groups "Accessibility Metadata Project" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to a11y-metadata-project+unsubscribe@googlegroups.com. > To post to this group, send email to a11y-metadata-project@googlegroups.com > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > Emmanuelle Gutiérrez y Restrepo > Fundación y Seminario SIDAR > URL: www.sidar.org > email: emmanuelle@sidar.org
Received on Tuesday, 10 September 2013 06:35:13 UTC