Chaals,
I think you have misunderstood me. Access mode works perfectly well. Teachers' Domain is built on access mode plus access features a.k.a media feature.
You said in the last meeting that search engines would not make decisions on the Web the way TD does so I was working with Liddy's suggestion of sets of "necessary" access modes on the assumption that it would meet a search engine's needs better. But I think that us better derived from access mode during indexing.
Access mode is the simplest information we can ask for from mainstream metadata authors. I continue to believe that for that reason it should be in vocabulary that we disseminate for broad adoption.
Madeleine
On 2013-09-28, at 12:05 PM, "Charles McCathie Nevile" <chaals@yandex-team.ru> wrote:
> 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
>
> --
> 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.