Appendix 9 - Notes for the AGLS Committee

Liddy - July 2003 - for AGLS????? note the text is in the code - fix!!!

I have been working on what might be useful in DC metadata (see http://dublincore.org/groups/access/). DC metadata is arguably the most common, international metadata anywhere. In the DCMES, we have an architecture and practices that ensure that DC metadata will be transportable, interoperable, easily developed, language independent and internationally deployed. It is also easily and consistently expanded to include locally specific information.

DC metadata is formally expanded, i.e. the number of elements and the qualifications for them, when it is clear that this is going to work well for a large community and not break or damage any existing systems or metadata schemas. The DCMI Usage Board works hard on this and has worked to provide suitable specifications for implementations of DC metadata in HTML, XML and RDF - so it is fairly versatile.

Well, what does it make sense for DC metadata users to do about accessibility?

After a lot of work, I have come to think the answer is fairly simple and should work for a lot of people. I think that metadata about accessibility will be used for compliance purposes and for discovery purposes but also for repair purposes.

With existing DC structures:

Using some of the more 'obvious' DC elements such as dc:audience is not advisable, in my opinion. That element, e.g., is about the content or purpose of the resource, not its accessibility and it is not appropriate or useful, in my understanding, to refer to audiences by their accessibility needs or capacities. My explanations for this are already on the DCMI site at http://dublincore.org/groups/access/.

All of this information is useful and human readable, as well as machine readable, but it falls short of the very precise and rich information that can be conveyed within an EARL statement. The foregoing information is also fairly easily made available by people.

So my proposal is likely to be for one more recommended DC element - dc:access.

For this element, I am thinking that it should do exactly what most of us want, and not pay attention to what disability a user may have, but be an open element about the accessibility of some resource (and BTW, I am including services etc when I say resource). This element would, if I were Queen, be used to draw attention to the user in the Web world, to encourage Web providers to think about their audience and how they are providing for them, to encourage governments and organisations to think about compliance, etc etc. And the value for this element would be a comprehensive EARL statement, pointed to by a URI.

Following this line, I am working on what should be in that EARL statement so that application developers can make the very most of it.

I am also keen to raise the profile of the user and to that end am arguing that there should be more specific DC metadata profiles for people. We change our access needs according to where we are, what we are doing, etc, and for this, we need a set of profiles, I think. We are also affected by what devices we are using to make the access and what it is that we are trying to do - setting the timer on a microwave oven, getting money from an ATM, reading a newspaper. For this we need profiles of contexts, devices, etc. I believe that if we have more specific metadata profiles, we can mix and match them better. See http://ausweb.scu.edu.au/aw03/papers/nevile/index.html for our first pass at this.

At the Dublin Core conference in Seattle in late September, we will be working on these issues. I urge you to send me comments or come if you can (see http://www.ischool.washington.edu/dc2003/).

Liddy

The value of this correspondence at this time is that it establishes the desire, on the part of the author, to shift from a focus on conformance assertions for universal accessibility to qualitative statements about the resource that can be evaluated by the user.