Re: Help needed: EPUB 3.01 revision referencing a11y metadata spec

On 9/6/13 2:41 PM, Dan Scott wrote:

>
> Change "Text" to new Enumerations
> ---------------------------------
> In general, those properties with an expected type of "Text" that
> have a list of expected values (such as accessMode, mediaFeature,
> accessHazard, accessAPI, and controlFlexibility) should be redefined to have
> new enumerations as their expected type. And, ideally, the valid values
> for those new enumerations would be maintained externally (perhaps by
> the IMS Global Learning Consortium itself). I'm not the first to mention
> a concern over how these values will be maintained going forward, but I
> firmly believe that delegating this responsibility to an external entity
> with expertise in the area is the best plan for long-term success.
>
> For an existing example in schema.org, the http://schema.org/Offer type
> has the http://schema.org/businessFunction property, which in turn has
> an expected value of http://schema.org/BusinessFunction - an enumeration
> that points to the Good Relations vocabulary for its valid set of values.


Which makes me wonder if it wouldn't be appropriate to have these values 
as part of the GoodRelations vocabulary... their use is not limited to 
commerce, but I presume that other aspects of GoodRelations are useful 
outside of that context.

Martin? ;-)

kc

>
> Rename "ATCompatible"
> ---------------------
> Whether it continues to be defined as a Boolean or it evolves into an
> enumeration, "ATCompatible" is an extremely opaque property name.
> Despite the additional length, I think it would be helpful to spell
> it out as assistiveTechnologyCompatible (or accessTechnologyCompatible,
> or accessTechnology if it evolves into an enumeration).
>
> Adopt standard "access" prefix
> ------------------------------
> I believe that implementers of schema.org would benefit from having
> the accessibility properties co-located as much as possible in the
> schema.org documentation, and therefore would recommend that the new
> primarily accessibility-oriented properties be renamed with "access" as
> a standard prefix; for example:
>
> * accessMode
> * mediaFeature -> accessMediaFeature (or just accessFeature?)
> * ATCompatible -> accessTechnologyCompatible (or just accessTechnology?)
> * accessHazard
> * accessAPI
> * controlFlexibility -> accessControlFlexibility (or just accessControl?)
>
> Thanks,
> Dan Scott
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Saturday, 7 September 2013 18:47:21 UTC