DC 2002Florence, October, 2002
Meetings of Interest Group members took place on a number of occasions, starting the first day and continuing until the last day.
There were a number of interested people and the following organisations, at least, were represented at the meetings:
Unfortunately, and without it being realised initially, some attendees were in the wrong place!
One person reported that she thought we were, at last, making the Dublin Core™ accessible, simple. Others were concerned with what turned out to be rights of access rather than 'accessibility' as the Interest Group has defined it - according to the W3C definition: access for all to the content of the web, by designing and implementing for device independence, including the devices used by people with disabilities. This confusion points to one of the problems with this field of endeavour!
For those not working on accessibility issues, it is often hard to know why it is important or why it is not just a simple problem. A poster for the DC 2002 Conference may help in this respect.
The DC.Accessibility Interest Group members have worked in many contexts during the last year and some of the original questions have been refined. The meeting in Florence, however, attempted to first review the original goals.
There has been little progress in this regard by the Interest Group. A resolution to work on the accessibility of the Dublin Core™ documents and the implications of Dublin Core™ recommendations has still to be worked on. Meanwhile the documents available on the Dublin Core™ web site have been organised in a structured way by the Usage Board Chairman Tom Baker, and navigation should be much more logical and useful.
The Dublin Core™ web site has been significantly improved in its accessibility, thanks to the good work of DCMI and the web master Beth Marsh.
Meeting Recommendation: the preparation of use cases to identify typical problems would help where problems are noted.
DC 2002 keynote speaker Herbert van de Sompel reminded attendees that many of us currently work to mantras like "[digital] libraries are there to make information accessible". If this is so, accessibility is an issue for the DCMI community. Given the prevasiveness of the accessibility effort, discovery should provide for all users and demonstrate awareness of the need discoverers might have in terms of accessibility of the content to which they are being pointed.
In general, the answer depends upon what we want to do/say in metadata for the benefit of users. There are many types of users, some of whom are concerned with gaining access to content that is relevant to their content needs, some of whom have found the content to which they want access but are concerned about their access to this content using particular devices, and a third group of people want to discover the qualities of the content, including how it complies to particular accessibility standards. Typical questions from the users include:
In the UK, the European Union, the US, in Australia/NZ, and a number of other countries and circumstances, there are regulations about the accessibility of web content. In almost all cases, the standards are derived from the guidelines of the W3C WAI effort.
For example, in the US there is a legislative section ( s.508 ) that requires compliance with a subset of W3C WAI recommendations in certain circumstances. This has led to a need for many content providers to know if their content is compliant with this standard. As the providers are not all expert in accessibility, and many do not know how to or do not bother to comply, third parties often want to determine and register, or know about, the accessibility of these resources.
Dublin Core™ metadata is very pervasive, and encouraging the use of DC elements to record the accessibility of resources could achieve two goals:
But it should be remembered that DC elements are successful because they are easily deployed, suitable for a very wide range of uses, and inter-operable. The DCMI principles that have led the DCMES development in the past should be observed: as many as possible of the relevant communities need to be involved in the recommendation of an accessibility metadata profile.
During the year, the DC.Accessibility interest group has held a face-to-face meeting at the WWW 2002 Conference in Hawaii, and contact has been made with other standards bodies that are similarly working on accessibility metadata problems. In particular, work being done by W3C, CEN-ISSS, IMS Project, and INCITS V2 has been considered. There are many standards relevant to the work. At DC 2002, it was discovered that important work is also being done in Japan at JTT (see DC 2002 Poster by Masatoshi Kawarasaki and Junichi Kishigami at http://www.bncf.net/dc2002/program/ft/poster9.pdf ).
Meeting Recommendation: to continue to work with those who are concerned with metadata in this field, so that a single, harmonised solution can be adopted by all groups. The other important reason for working together is so that those who are working in a particular area within the general field can be supported to do their work, for the benefit of others.
A brief description of some of the relevant standards and how they are relevant was written in mid-2002. This paper was designed to stimulate discussion and comments are invited. Since this paper was written, it has become more clear what is being done and what is relevant (see below).
The following elements seem relevant:
<dd>not relevant</dd> <dt>identifier</dt> <dd>not relevant</dd> <dt>creator</dt> <dd>not relevant</dd> <dt>contributor</dt> <dd>not relevant</dd> <dt>publisher</dt> <dd>not relevant</dd> <dt>date</dt> <dd>not relevant</dd> <dt>language</dt> <dd>might be a place in which to indicate Braille or a sign language ????</dd> <dt>rights</dt> <dd>see notes below about the dc:government 'access' qualifier for rights</dd> <dt>subject</dt> <dd>this is used to describe the 'aboutness' of the content, not its form</dd> </dl>
The DC.Education Working Group has introduced some qualifiers:
The education community likes to be able to identify the resource's target audience and the role that might be played by a mediating person, e.g. a teacher might be a mediator for a 3-year old who is going to play a game discovered on the web. In the case of people with special needs, possibly using a device without a screen for instance, a software agent might be a mediator, or in another case, a style sheet or some other form of additional content, might be. So this element and its qualifier are of interest.
Issues related to these terms include those that deal with whether their use is to do with content or form of that content.
Meeting Recommendation: Examine the implications and value of the use of, or extension of, dc:audience and dc:audience:mediator.
DC.Education also has introduced a qualifier for the dc:type
dc;type;extent is used to provide information about the duration of use of a resource. For example, a video might run for twenty minutes but prompt work for a class of 30 children for two days. Teachers like to know both these things about videos.
The DC.Government Working Group has introduced a qualifier for dc:rights
The use of the term 'access' is clearly going to cause confusion in many contexts. Above it was noted how it causes access with respect to its meaning and context. DC.Government's proposed use is to do with who is allowed to have access to the content of the resource.
The DC.Government Working Group has also introduced a qualifier that is used in several contexts.
dc:coverage:jurisdiction and dc:creator:jurisdiction...
This qualifier led to some discussion.
* Questions that were raised during the meeting:
This has qualifiers that might be of interest in the accessibility context.
dc:relation qualifiers include: replaces, is required by, is part of, is referenced by,
The main concerns for the accessibility community are;
There was some discussion about the need for a way of identifying what is alternative and what is equivalent alternative content. Comments were made about the following qualifiers that might be relevant:
<dd>* expects changes in format but not in content</dd> <dt>'is version of'</dt> <dd>* expects changes over time, perhaps not in types or form of content</dd> <dt>'conforms to'</dt> <dd>* relates to a standard</dd> <dt>'replaces'</dt> <dd>* implies one version has been replaced by another, not that they are equivalent</dd> <dd> <p>The meeting then considered the possibility of qualifiers 'is-equivalent-to' and 'has-equivalent'. With respect to these as possible qualifiers, the meeting had some questions.</p> <p>Questions raised and discussed</p> </dd> </dl>
<dd>* this will obviously be useful with respect to compliance to guidelines and standards but not so obviously useful when looking for an accessible alternative</dd> </dl>
EARL is a W3C recommended language for describing conformance (see http://www.w3.org/WAI/ER/ ). It uses a constrained form of RDF that allows for an assertion and information about who made the assertion and when. Typical examples are;
EARL is not only useful for conformance reporting in the accessibility context, but that is a good use of it.
EARL statements might not do more than make it evident how a resource complies of fails to comply with a given standard, but other applications might be able to use this information to repair the resource. Knowing how a resource complies does not make any difference to its ability to be accessed by all users. EARL might be used to describe usability information as well. An EARL statement may be thought of as a review, in which case it might be referred to in dc:relation:is-review-of.
These, and similar issues, occupied the minds of the meeting participants for some time.
It is well-known that there are a number of activities relating to accessibility metadata. In the last year, a number of these have started to work together. Some of those who have already worked on collaboration have found it hard to understand who is doing what and what the outcome will be. At DC 2002 it was discovered, for instance, that NTT in Japan is working on reuseable resources that can be sent effectively to any device. The meeting discussed some of the different efforts and decided that it would be good to develop a structured way to talk about these activities. After more discussion, the participants developed a simple first matrix, and tried it with some of the activities to see how well it worked.
Meeting Recommendation: to work a little on the matrix and then to ask those conducting activities in the field if they could complete it with respect to their activity.
It was also considered relevant that activities using diagrams and models should be able to determine how to engage with one another. The exemplary diagram from NTT suggested one way of doing this. Another way of sharing understanding that was proposed was the contribution of use case scenarios form the various organisations.
Meeting Recommendation: that a DC Accessibility Working Group be chartered to develop a road map of relevant activities, with the help of any groups interested in collaborating.
This recommendation was followed by some discussion of the best way to achieve this goal and a time frame for it.
Meeting recommendation: that the Working Group be formed of a small number of representatives who are willing to commit to regular work on the task and to meet face to face in January 2003 to finalise a road map for general distribution. This work would be in anticipation of a Working Group being formed to develop the relevant DC metadata profile for accessibility.
Future work should include a metadata profile for accessibility, examples, and guidelines for accessibility metadata.