Re: [a11y-metadata-project] Re: clearing the logic...

Charles

I am not sure EXACTLY what you are saying.

First, accessHazard is not an accessMode - we all agree and I believe  
your argument about stating it as a negative rather than a positive is  
accepted. So let's set that aside for now.

I started the taxonomy but have not been careful about the next  
details - which I think are the accessFeatures - ie - I think  
accessMode is the very first, unqualified term (closest to the  
resource) and then the others will be accessFeatures - does that make  
sense?

As for legacy problems - I am very keen to make sure we sort this for  
schema.org and for ISO and then I think the legacy problem will still  
exist but is OK - better to get it right than be constrained for  
ever---already we are moving away from ISO 24751, for example...

Liddy


On 29/09/2013, at 2:05 AM, Charles McCathie Nevile 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.

Received on Sunday, 29 September 2013 23:25:45 UTC