- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Sat, 28 Sep 2013 18:05:37 +0200
- To: "Gerardo Capiel" <gerardoc@benetech.org>, "Liddy Nevile" <liddy@sunriseresearch.org>
- Cc: "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>
On Fri, 27 Sep 2013 15:30:12 +0200, Liddy Nevile
<liddy@sunriseresearch.org> wrote:
> Guys
> below is an image of my playing with a taxonomy: Sorry, but that is
> the only format I can get to work.
>
> I think that the way I have started to set up the preferences and
> needs might work so that when a user declares a preference, the
> appropriate accessMode can be inferred.
Based on Madeleine explaining the need to something new to make accessMode
actually work, and other people telling me that it doesn't, I believe it
needs to be changed. I think this proposal is much closer to a workable
way of defining accessMode, but I think you have added stuff that doesn't
belong here.
For instance, AccessHazards strike me as seperate.
I don't believe that the model of a matrix of expressed user preferences
and combinations of mediaFeatures is a scalable solution. That said, it
seems extremely valuable to have the information, because it can be used
to improve matching of users and resources. With relationships defined in
a machine-readable way (RDF or some similarly clear model for describing
related terms) I think we can make a lot of use even of existing
mediaFeature metadata.
Which brings me to another problem. Since data exists marked with
accessMode as defined currently, I am concerned about the transition path,
too. We can take the same names in schema.org, and retire the original
name/namespace combination. But for stuff that we want to change, it makes
more sense to me that we change everything at the same time...
I'm happy to keep mediaFeature and accessHazard even though I think both
of them need revision. IMHO mediaFeature needs better definition but the
terms, and therefore the markup we find in the wild, are OK. I think we
want to replace accessHazard with a negatively expressed version
("doesNotHaveAccessHazard") but in the meantime I think adopting the
existing accessHazard would be a good idea.
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Saturday, 28 September 2013 16:06:19 UTC