Dan Scott,
I really like your idea for idea for an AccessibilityMode subtype. I tested your code in Google rich snippets tool:
http://www.google.com/webmasters/tools/richsnippets?q=uploaded:8004e5e7c0b2bada99617ef9b8cc4798
And I noticed that in case of Google Custom Search, it will also simplify searching, because the properties are attached to the subtype in your query string. So instead of having to know whether to use the search operator more:p:movie-mediaFeature:captions or more:p:videoobject-mediaFeature:captions you aways do more:p:accessibilitymode-mediafeature:captions.
I think also encasing mediaFeature under this subtype may reduce the desire for it to be renamed and it means that in the future it could be applied to broader non-accessibility related applications.
Gerardo
On Sep 8, 2013, at 6:15 PM, Dan Scott <dan@coffeecode.net>
wrote:
> 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.