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