Andy
thanks for your comments. Shadi - Andy has perhaps helped me better
answer some of your queries? See below, please.
On 12/10/2009, at 9:14 PM, Andy Powell wrote:
> Some comments on the proposal at http://dublincore.org/accessibilitywiki/NewElementProposal
> .
>
> Firstly, it strikes me that Shadi's comment:
>
> "Unfortunately I still have trouble understanding the model and
> concept of this proposal despite substantial research of the wiki
> resources."
>
> endorses what I take to be the UB position on this proposal, i.e.
> that more work is required.
>
Oh, I am sorry, I misunderstood Shadi's comments about the missing
links. Those links are not there - that's correct, and so it might be
muddling. The vocab is, however, referred to on the proposed term page
and missing from the links because they were to be supplied by the
Australian AGLS - hence my comments about confusion surrounding what
has been considered and, for example, that the UB has said both that
it does not want to know about the property values and that it cannot
proceed without them???? The formal submission form does not ask for
the vocab. but only examples (as supplied). The set has been stable
for a year or more and is on the wiki, low down on the page at http://dublincore.org/accessibilitywiki/ElementsVocabularies
(and below in this email)
(Please note that I have not fiddled with the wiki for a while,
deliberately, so it is clear what has been there since last year - I
would like to fix bits now.)
For what follows here, remember that the UB was not considering the
submission as amended but the earlier version of it, without regard
for the amendments made last year with the help of the UB. So the UB
did not pronounce on what you are looking at.
> Looking at the proposed definition:
>
> "A characteristic of a resource that relates to the human capacity
> to perceive, operate, understand or otherwise engage with the
> resource."
>
> one assumes that the range of the property is something like
> AccessibilityCharacteristic ?
yes
> The trouble is, I don't actually know what one of those is! The
> example values - 'auditoryOnly', 'allTextual' and 'visualOnly' -
> appear to relate to sensory modes or something? Would it not be
> better to focus on specific aspects of 'accessibility', creating new
> properties for those as needed, rather than trying to create a
> single catch-all property covering everything related to
> accessibility?
>
I would have thought that the DC ay of doing 'business' is to have a
general term and then, when greater detail is required, an application
profile that gives refined elements and values? Because asking
everyone to complete detailed APs is not going to work, we suggested
one term that could be used easily and also have an AP for those who
specialise in accessibility and know bout all the details.
> There are two problems with the "single braod accessibility
> property" approach...
>
> Firstly, it becomes very hard to judge whether the solution
> addresses the stated problem area (Why needed) because the latter is
> so broad.
>
Th value of the term is that even with just a single term and the few
attributes suggested, a lot of low-hanging fruit is caught.
> Secondly, the definition of the property itself becomes very broad.
> In this case, the wording used above appears to include
> 'language' (because language is a "characteristic of a resource that
> relates to the human capacity to perceive ...) within the definition
> - i.e. dc:language would become a refinement of this new property.
> Whilst there is nothing inherently wrong with making existing DC
> properties into refinements of new properties I'm not 100% sure that
> is what was intended?
>
And yes, exactly, the language is important but there is a difference
between language as it is used in normal DC metadata, eg en-au etc,
and the language as it relates often to accessibility - e.g. for
people with dyslexia, the language should not have certain
characteristics such as metaphors....
> Looking at the IMS work (sorry, I haven't really be following this
> so I might be looking at the wrong thing), specifically section 3.1
> of http://www.imsglobal.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html
> , one can imagine 3 possible new properties as follows:
>
> dc:accessModality - a new property with a newly defined range of
> dc:AccessModality having initially 4 values 'am:Textual',
> 'am:Auditory', 'am:Visual', 'am:Touch' (assigned URIs using some
> appropriate namespace)
>
> dc:adaptability - a new property with a range of
> dc:AdaptabilityStatement (which would probably be horribly vague and
> not worth having IMHO)
>
> dc:equivalent - a new refinement of dc:relation
>
> but note that I'm not actually proposing any of this... just
> brainstorming an alternative strategic scenario in this space!
>
Yes, there are endless possibilities but after 5 years of working on
them and implementing them, it has been found that the ones so far
recommended are the most appropriate. I am amazed that the advice of
those who know the field and work in it and actually provide resources
for people with disabilities should not have their recommendations
respected????
The other thing is that there are many aspects that need to be
considered and so the list you have started would actually get quite
long - hence the need for APs. (The IMS work was published some time
ago and is probably due for review in the light of the further work
done in the ISO context, which is itself growing as other aspects of
accessibility are considered.)
> Again, I'd prefer to see some coherent statement of what
> functionality is intended to be supported by anything new in this
> area (i.e. what kinds of actions do we expect software to perform)
> before making a judgement about what is sensible as a way forward.
>
The functionality - that has actually been implemented and running for
a number of years now has been described as being:
1. discovery of resources that are 'accessible' or otherwise
(according to W3C guidelines) but currently are not described in any
way that makes this fact available;
2. discovery of resources that may not be 'accessible' or otherwise
(according to W3C guidelines) but nevertheless are suitable for the
particular user;
3. discovery of resource components that can be substituted or used to
complement inaccessible (for the user) components, and
4. to automatically match resources to a user's profile of
accessibility needs and preferences.
(BTW, the UB has said it is not relevant how the metadata is to be
used but I don't agree.)
Finally - all advice offered has been welcomed. Many of the things are
tricky, as I have tried to indicate above, and have been chosen, not
at random, but in the light of experience. So sadly the advice is not
always useful given the context involved, namely accessibility. Advice
about satisfying the technical DC requirements was incredibly useful
in years past, but I don't think they are the issues any more. The
problems are more substantive now, and it seems they are often caused
by people trying to work out what they think might be good ways to do
the work, not always with experience and full knowledge of the area. I
am one of the people who defers to the accessibility experts, and we
have many of them working on this so we are not just guessing what
might work. We are also very aware that very many countries have now
signed the UN Convention and so are required to cater for their
population who need the help but we need the metadata to do this to
get the full benefit of adherence to the W3C guidelines.
I have answered here as best I can. I am not defending so much as
trying to explain what we have done. It may not be right.
Andy, and Shadi, please don't hesitate to come back on things I have
said. I really appreciate the contribution, and am just trying to get
it right.
... and anybody else who wants to comment - please do!
Liddy
-------------------
auditoryOnly: Resource contains some significant content available
as sounds only.
E.G.: there is a significant content component with recorded speech
with no alternative format.
allTextual: Resource contains all significant content as transformable
text.
E.G.: although there is visual content, it is also available as
transformable text.
visualOnly: Resource contains some significant content available as
images only.
E.G.: there is some significant content that is available as an image
with no alternative format.
brailleOnly: Resource provides all significant content in Braille.
E.G.: all the significant content of the resource, in whatever format,
is also available as Braille or transformable text.
tactileOnly: Resource contains some significant content as touchable
components only.
E.G.: there is a component of significant content that needs to be
touched and has no alternative format.
hapticOnly: Resource contains some significant content as kinesthetic
components only.
E.G.: there is a component of significant content that requires
kinesthetic interaction with no alternative format.
olfactoryOnly: Resource contains some significant content as smells
only.
E.G.: there is a component of significant content that offers odours
that are not available in any alternative format.
hazard: Resource contains potentially harmful content.
E.G.: there is brief repetitive light or sound, or an odour, or motion
simulation, that may be harmful to some people.
---------------
> Best,
>
> Andy
>
> ________________________________
>
> Andy Powell
> Research Programme Director
> Eduserv
>
> [log in to unmask]
> 01225 474319 / 07989 476710
> www.eduserv.org.uk
> efoundations.typepad.com
> twitter.com/andypowe11
>
>> -----Original Message-----
>> From: DCMI Accessibility Community [mailto:DC-
>> [log in to unmask]] On Behalf Of Liddy Nevile
>> Sent: 07 October 2009 18:53
>> To: [log in to unmask]
>> Subject: Re: Proposed property "accessibility" - formal decision from
>> the Usage Board
>>
>> Tom
>> thank you for this posting.
>>
>> I point out to the community that after the meeting with the Usage
>> Board in Berlin in 2008, the definition for the term was changed to
>> match that in the Web Content Accessibility Guidelines version 2.0 so
>> the UB's decision was a formal decision related to a term that was no
>> longer being proposed by the community.
>>
>> Little has been done publicly in the DC Accessibility Community
>> because we have been waiting for a decision from the Usage Board,
>> expecting it to be based on the proposed term as set out on the wiki
>> at http://dublincore.org/accessibilitywiki/NewElementProposal. It
>> seems there has been some confusion with respect to what is proposed
>> and what is being considered.
>>
>> In the meantime, ISO/IEC has finally published ISO/IEC N24751:2009
>> Parts 1, 2 and 3. Perhaps more interestingly, the ISO/IEC group
>> responsible, JTC1 SC36, have worked to redefine metadata for learning
>> resources (MLR) and are close to finalising with a new model that is
>> almost identical to the Dublin Core Abstract Model. This probably
>> means a revision for the ISO/IEC N24751 to be fully MLR (and
>> therefore
>> DC) compliant,
>>
>> There will not be a meeting of the DC Accessibility Community in
>> Korea
>> at DC 2009 but hopefully there will be some fruitful discussions that
>> will advance the needs of those trying to work with metadata to
>> enable
>> people with disabilities to discover resources they can use.
>>
>> If you are not familiar with the DC Accessibility wiki, you might
>> like
>> to have a look at it as that is where most of the work is reported.
>> See http://dublincore.org/accessibilitywiki
>>
>> Liddy
>>
>>
>>
>> On 07/10/2009, at 7:18 PM, Thomas Baker wrote:
>>
>>> Dear all,
>>>
>>> The Usage Board has taken a formal decision on a proposed
>>> "accessibility" property. In the decision text below, we
>>> outline our reasons for not accepting the proposal as submitted.
>>>
>>> We hope that this summary may prove useful as input to the
>>> ongoing search for robust metadata solutions for accessibility.
>>>
>>> Tom
>>>
>>> --
>>> Tom Baker, Chair
>>> DCMI Usage Board
>>>
>>> As proposed in [1,2], pp. 32-34:
>>>
>>> Property: accessibility
>>> Definition: Characteristics of the resource that affect how
>>> it can be modified for users or agents.
>>> Comment: An Accessibility statement might be used to match
>>> a (digital or physical) resource to a
>>> description of user or user agent needs and
>>> preferences.
>>>
>>> Decision: Reject
>>>
>>> Reasons:
>>>
>>> -- The proposed definition defines the property by how it can used;
>>> rather, a definition should directly say what the property means.
>>> The proposal does not explicitly say what it means to "modify" a
>>> resource, nor does the proposal explain how the use of the
>>> proposed property will enable such modification.
>>>
>>> -- The proposal says that the property has "been carefully
>>> re-modelled from the ISO/IEC version". However, the proposal
>>> does not provide a reference to or explanation of the
>>> ISO/IEC property of which the proposed property is a
>>> re-modelled version (other than a general reference to
>>> ISO/IEC N24751); the reasons or experience that led to the
>>> re-modelling, i.e., what problems were identified; the
>>> process that was applied in the re-modelling and how
>>> the identified problems are resolved by the proposed
>>> property.
>>>
>>> -- The proposal refers to the "use of the new term in
>>> combination with other descriptive information" as enabling an
>>> "AccessForAll process". However, the proposal does not
>>> explain or illustrate the AccessForAll process, so the Usage
>>> Board has no basis for judging whether the proposed term can
>>> lead to useful results.
>>>
>>> -- The proposal does not specify the range of the property. At
>>> a minimum, the description of a property should specify whether the
>>> intention is that the property is to be used with literal
>>> values or non-literal values, or both.
>>>
>>> -- The proposal describes the discussion of a "stand-alone
>>> new term" since 2001. However, it does not say who was
>>> involved in developing the term as now proposed, nor does it
>>> document any support or endorsement of the term, as proposed,
>>> from experts in the cited ISO/IEC and W3C communities.
>>>
>>> For the sake of completeness, it should be mentioned that a
>>> subsequent version of this proposal was discussed by the Usage
>>> Board in 2009 [3] though never formally submitted for
>>> a decision.
>>>
>>> [1] http://dublincore.org/usage/meetings/2008/09/berlin/2008-09-
>> 18.berlin-packet-revised.pdf
>>> [2] http://dublincore.org/usage/meetings/2008/09/berlin/2008-09-
>> 18.accessibility-proposal.pdf
>>> [3] http://dublincore.org/usage/meetings/2008/09/berlin/2009-10-
>> 04.accessibility-proposal-revised.pdf
|
