W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2013

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

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sat, 07 Sep 2013 19:46:48 +0100
Message-ID: <522B7498.1030706@kcoyle.net>
To: public-vocabs@w3.org, Martin Hepp <martin.hepp@ebusiness-unibw.org>

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? ;-)


> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:30 UTC