Promoting accessibility by using metadata in the framework of a semantic-web driven CMS

·Abstract: Fernando Díaz del Río Robotics and Computer Technology for Rehabilitation Lab. University of Seville (SPAIN) Tel: +34 95 4556144 Fax:+ 34 95 4556449 [email protected] Antón Civit Robotics and Computer Technology for Rehabilitation Lab. University of Seville (SPAIN) Tel: +34 95 4556470 Fax:+ 34 95 4556449 [email protected] Juan Antonio Prieto XimetriX network thoughts SL Tel: +34 91 3645475 [email protected] Web content accessibility for impaired people has been mainly addressed by the Web Content Accessibility Guidelines (WCAG) developed by the Web Accessibility Initiative (WAI) of the W3C Consortium. Those guidelines have proved to be good diagnostic means for testing accessibility for different types of impairments, as well as for guiding the development of accessible content. A further step would be to promote discovery of material having appropriate accessibility support, as well as the adjustment of control and display of resources to meet user accessibility needs and preferences [5]. The last two challenges have been addressed by the IMS Global Learning Consortium in the IMS-AccessForAll (ACCMD) and the IMS Learner Information Profile (ACCLIP) specifications. Although IMS has approached both goals in a learning framework, both accessibility specifications pay a special attention to impaired users’ needs. As a first step, in this paper we survey how far IMS accessibility specifications cover WCAG, and discuss the convenience of extending it to the whole WAI guidelines. Secondly, we argue how accessibility could be considered as a key issue for promoting reusability. We continue explaining why using a semantic framework (such as the MPEG-7 semantic tool, RDF or OWL) for describing textual and contextual information in a standardized manner could promote both, accessibility and reusability. Finally, we explain how some accessibility issues have been already addressed by XimetriX’s ximDEX, a semantic-web Content Management System (CMS). We conclude proposing a plan to better integrate the accessibility specifications and contextual description tools into that CMS. Keywords: Metadata, Accessibility, Reusability, CMS, Dublin Core, IEEE-LOM, IMS-AccessForAll, ACCMD, IMS-Learner-Information-Profile, ACCLIP, Semantic Web, MPEG-7, RDF, OWL. 1 Introduction In the ACCMD and ACCLIP specifications, the term disability has been re-defined as a mismatch between the needs of the learner and the education offered, i.e. the ability of the learning environment to adjust to the needs of all learners [5]. Nevertheless, the needs and preferences of a user may arise from the context or environment the user is in, the tools Promoting accessibility by using metadata in the framework of a semantic-web driven CMS Rocío García-Robles Robotics and Computer Technology for Rehabilitation Lab. University of Seville (SPAIN) Tel: +34 95 4556144 Fax:+ 34 95 4556449 [email protected] Fernando Díaz del Río Robotics and Computer Technology for Rehabilitation Lab. University of Seville (SPAIN) Tel: +34 95 4556144 Fax:+ 34 95 4556449 [email protected] Antón Civit Robotics and Computer Technology for Rehabilitation Lab. University of Seville (SPAIN) Tel: +34 95 4556470 Fax:+ 34 95 4556449 [email protected] Juan Antonio Prieto XimetriX network thoughts SL Tel: +34 91 3645475 [email protected] DC-2005: Proc. Int. Conf. on Dublin Core and Metadata Applications 2005 ~71 ·This work has been partially supported by the SIC (Servicio de Informática y Comunicaciones) of the University of Seville. available (e.g., mobile devices, assistive technologies such as Braille devices, voice recognition systems, or alternative keyboards, etc.), their background, or a disability in the traditional sense [5]. Accessible systems adjust the user interface of the learning environment, locate needed resources and adjust the properties of the resources to match the needs and preferences of the user. Therefore, accessibility notion has been enlarged in the IMS scope, for addressing not only impaired people needs, but also other users’ (learners’) preferences. On the other hand, there are two sides of the match needed to address the users’ needs and preferences. One specifies what the user needs or prefers, and it is currently described by the ACCLIP. [5] The other labels resources using the same terms, and it is currently described by the ACCMD. Resource accessibility description is also being addressed by the DC-Accessibility Element and IEEE-LOM, as it is further explained in next subsections. 1.1. The IMS AccessForAll Information Model The final goal of this IMS specification is to provide functional interoperability to support the substitution or augmentation of one resource with another when this is required for accessibility purposes, as prescribed in the user’s profile (e.g., the addition of caption text for a hearing-impaired context), thus allowing interoperating systems to work together to serve the needs of learners with disabilities and others who have ACCMD profiles. The IMS overall accessibility data model [6] consists of the description of one primary resource, and the description of the features of none, one or more resource(s) that are equivalents for a particular primary resource. A primary resource is allowed to point to zero or more equivalent resources. An equivalent resource is allowed to point to a single primary resource only. In this way, circular references are avoided and the relationship model is greatly simplified with no loss of functionality. The primary resource metadata describes: -Access Modality: It includes four attributes such as hasVisual, hasAuditory, hasText, and hasTactile, which are boolean values to indicate whether or not the resource contains visual, auditory, textual or tactile equivalent content information. -Adaptability: How amenable the resource is to transform the display and whether the method of control is flexible (display transformability and control flexibility). -Equivalent: Whether there is a known equivalent alternative. It is a pointer to an equivalent resource (meta-data) of the described resource or parts thereof. The equivalent resource data model contains three elements that are containers for content presented in a different modality: alternativesToVisual (colour avoidance such as red, orange, red/green,…… or the use of maximum contrast monochrome); alternativesToText (e.g. graphic alternative or sign language alternatives to text in the primary resource); alternativesToAuditory (captions, reduced reading level, reduced speed, or the availability of sign languages alternatives). The other element attributes are the learnerScaffold, and the content, both of them directly related to the learning approach of the IMS specifications. Nevertheless, the other three elements describe the accessibility requirements related to impairments, and therefore are related to the WCAG developed by the W3C. To apply an accessibility approach according to ACCMD, the normal workflow would be: A-Ask user, (at least first time using a new application), for his/her preferences. The most likely way is through an interactive form (‘wizard’) that presents a number of questions to the user and, given responses to the questions, generates the profile. The profile should be acted on each time the user uses that application, and the implementers should ensure that their interface makes it easy to act them off, or to modify the profiles by the user. B- When a user searches for content, the user’s profile should be taken into account when displaying the search results. Therefore, once resources matching the search criteria are found, the metadata for these resources should be examined to determine if the resource matches the preferences in the user’s profile. The resources should be ranked according to how well they match each preference and any partial matches should be flagged as such. The usage elements in the user’s profile should be used to rank the resources. Users should be given the option of requesting that partial or non-matches be omitted from the search results. C-If the requested resource has no ACCMD, the system should warn the user. If the requested resource has ACCMD, the system should match the user preferences. This process would be normally automated, but best practice recommends that user control over the automation behaviour be an implementation feature of the system 1.2. The DC Accessibility Element The DC-Accessibility Working group (DCA-WG) is producing a set of documents that could lead to the creation of a new DC element to be called DC:Accessibility. The description of the term should be simplified and some possible text values for the term should be specified [9]. The underlying information model for the new term could be closely related to the ACCMD that describes people’s accessibility needs and preferences. Both specifications, for people and for resources, were developed in collaboration with the IMS Global 72 DC-2005, September 12-15 - Madrid, Spain Project and they are maintained by that body. To complete the work, DC needs an application profile or element set that describes people in which their accessibility needs can be included. Therefore, this approach to accessibility, as the one adopted by the IMS, depends upon not just accessible content1 (WCAG conformant), but also that responsibility for accessible content delivery be taken by the server. This is a shift from earlier approaches which depended solely on WCAG/ATAG/UAAG conformance. It is consistent with other works that aims to provide more device flexibility for users. Further information on the DC:Accessibility element could be published in the DCMI website2. 1.3. The IEEE LOM and CEN-ISSS The European Standardization body, CEN-ISSS has started a Learning Technology Workshop on Accessibility Properties for Learning Resources (CEN-ISSS LTW APLR). The main objectives of that workshop are [10]: -To demonstrate formative ways that the IEEE LOM can be used to document information about the accessibility properties of learning content (learning objects) in standard ways. - To develop a basic vocabulary and framework around which software vendors, tool producers and content authors can work in order to provide a greater level of interoperability and applicability of tools. The results of that on-going project will be [10] -Accessibility application profile of the IEEE LOM to describe accessibility requirements (CWA); -Recommendations for further work in the light of global accessibility architecture and meta-data developments and potentials for user-trials. Part of those results will be [10]: -Metadata Vocabularies, containing accessibility vocabularies for description of accessibility characteristics of learning resources. -IEEE LOM Application Profile and Binding, containing the information model of the Accessibility application profile of the IEEE LOM and the corresponding RDF Binding. -Accessibility Conformance Testing Plan, a conformance testing plan with the Accessibility application profile of the IEEE LOM. The activity of the CEN-ISSS LTW APLR is being coordinated and harmonized with other international standards organizations such as IMS, ISO, DC and W3C/WAI [8]. There is no single universally accepted taxonomy of functional metadata that suits the purpose of content adaptation to the individual for accessibility. It is the recommendation of this group that such a taxonomy be developed and kept in a public meta-data registry offering multilingual and cultural-context transparency and be referenced for content-related values [10]. A step towards this work is provided by the extensions to LOM, which include [10]: -Required new vocabulary values for Relation:Kind displayTransformability controlFlexibility equivalentResource alternativeFor supplementaryFor -New element within Relation:Identifier Part Catalog Entry Therefore, after this brief introduction to the work under development by the CEN-ISSS LTW APLR, we can conclude that it is also a learning oriented accessibility specification, whose main goal has been basically to adapt the IMS ACCMD specification to the IEEE-LOM standard. The underlying accessibility information model is exactly the same, but using different label names. Some issues still need refinement because the work is still in progress. 2. The IMS accessibility specifications and the WCAG Web Content Accessibility Guidelines (WCAG) are currently a de facto standard to check Web content accessibility for impaired people. WCAG contains an exhaustive list of checkpoints or guidelines that a page should fulfill if it is to be considered as accessible by everybody. The first version [1] of that list (WCAG 1.0, 1999) was somewhat technology or application dependent: many checkpoints were addressed to an html implementation of pages. This fact was censured many times by web community. Nevertheless the feedback and dissatisfaction around version 1.0 has driven WAI Working Group to produce a more “robust” (technology independent) WCAG 2.0 guidelines. Those are currently in progress, but draft version [2] is clear enough to understand this trend. Another problem still remains: automatic checking of accessibility of a page is a challenge. Some tools have been developed to address that issue, but a web programmer can mislead those tools. For example, if a page includes an empty tag as “alternative” description to a non-textual element, most of checking tools will assume that alternative description is correctly covered. In fact, actually, a CMS must guarantee that all the properties to verify accessibility to a desired level are provided either directly from the content creator (policy-1) or indirectly using rules to extract them from the context or from previous elements of DC-2005: Proc. Int. Conf. on Dublin Core and Metadata Applications 2005 73 1Being created with good authoring tools for use with good user agents (ATAG and UAAG compliant). 2Nevertheless, it is important to remark that due to the fact that there is a proposal pending in the DCMI in relation to a possible accessibility element, it can not assume that the official publication is a pro forma step. information in the hierarchy (policy-2). The CMS presented in this paper, ximDEX, has implemented both policies. On the other hand, a further step following WAI Group initiative would be to promote discovery of material having appropriate accessibility support, as well as the adjustment of control and display of resources to meet user accessibility needs and preferences [8], (as explained in section 1.1 of the current document). This is partially addressed by the IMS ACCMD and ACCLIP specifications. The underlying Information Models of both of them are not exhaustive, but the addressed accessibility issues are suitably structured in a hierarchically manner. So, although the concept of accessibility is mainly aimed to the field of electronic learning in IMS specifications, we consider it is just a promising starting point. We suggest that it is a key issue to extend the IMS Information Models for including all WAI guidelines. Nevertheless, that is not a trivial work, nor an easy task. First of all, IMS defines a model (ACCLIP) which describes and records user preferences, i.e. the user profile. This model is the base to later adapt page elements to the user. Then, this model should be augmented to take into consideration all the abilities of every potential Web user (so that it covers all features encountered in WCAG guidelines). So every user and Web device (user agent in WAI terminology) will have to value the parameters of the user profile before displaying content. Moreover, those parameters may be tuned along the new accesses to record more exactly the characteristics of the user. From the content display point of view, it will be necessary to define the accessibility properties for each element of a page. With respect to accessibility, Web elements can be classified into some few groups: textual, links, audio, video, pictures, tables, charts and few more. Each one has different properties that will define its accessibility features. For example, audio content has two important properties: containing relevant information, or playing the role of entertainment elements. On the second level of the hierarchical properties, the audio elements that contain relevant information will have an important property: being textual (e.g. lyrics for a song, caption for an audio conference,……). Then, an element with this last property will inherit the normal textual properties. Considering the properties of all elements of a page, the user disabilities and preferences and device features, the browser would display the page information in the most appropriate manner. Obviously, there is too much work to do in relation with the previous proposal. The conversion of WCAG 1.0 checkpoints into WCAG 2.0 guidelines has increased accessibility abstraction, which can help as a first step to model content accessibility properties in a technology independent way. But it is necessary to go on. 2.1 Overview on current trends in relation to the development of a complete accessibility specification IMS has already developed the accessibility specifications they needed for learning and learners purposes. But IMS does not intend to do the ACCLIP and ACCMD completely to resemble the WCAG, as it can be inferred by the following statement: “Meta-data to assert compliance to an accessibility specification or standard is not within the scope of this specification.” [5] Simultaneously, the DC Metadata Initiative (DCMI) is currently working on the DC Accessibility Element. DCMI usually tends to get the minimum set of tagging elements, while IMS usually develops very detailed and huge specifications, whose information models are usually very hierarchical. Concerning the work under development by the CEN/ISSS in relation to the IEEE LOM specification, that is also a horizontal specification and taxonomy oriented, as the DC Metadata Set. IEEE LOM and IMS specifications are very learning oriented, while DC is much more generic. Taking into account all these factors, it is more likely that the DCMI and the CEN/ISSS are interested in enlarging its specification for complying with the ACCMD than completing the ACCMD for covering the whole WCAG and other WAI guidelines. Nevertheless, it would very convenient to continue enlarging and refining the IMS accessibility specifications to cover all the WCAG, because IMS, DC and IEEE have initiated the standardization process which logically follows the previous work undertaken by the W3C, but not all the accessibility guidelines are addressed yet. 2.2 WCAG 1.0 vs. WCAG 2.0 Although WCAG 2.0 are nowadays only a working draft, it is important to take into account the main differences related to version 1.0, before comparing WCAG with the ACCMD. Some of the main differences between both are the following ones [8]: 1-WCAG 2.0 represents broad concepts that apply to all Web-based content. They are not specific to HTML, XML, or any other technology vs. version 1.0 which was highly technology dependent. 2-Where WCAG 1.0 uses guidelines to group checkpoints, WCAG 2.0 uses guidelines to group success criteria. Where WCAG 1.0 assigns a priority to a checkpoint, WCAG 2.0 categorizes a success criterion into one of three levels. Therefore, newest version is more efficiently organized. 3-WCAG 2.0 may adjust the priority of some checkpoints. We conclude that because WCAG 2.0 is more abstract, it is easier to 74 DC-2005, September 12-15 - Madrid, Spain compare it with the ACCMD, as we will see in next section. 2.3 IMS AccessForAll vs. WCAG 2.0 Comparing WCAG 2.0 Design Guidelines (top layer) with the ACCMD information model, we can observe that WCAG principles 1, 2 and 4 are partially covered: -Principle 1: Content must be perceivable. This means (1.1) there must be text alternatives for all non-text content; (1.2) providing synchronized alternatives for multimedia (captions and audio descriptions); (1.3) ensuring that functionality and structure are separable from presentation. -Principle 2: Interface elements in the content must be operable. This means (2.1) Making all functionality operable via a keyboard interface; (2.2) allowing users to control time limits on their reading or interaction; (2.3) allowing users to avoid content that could cause photosensitive epileptic seizures; (2.4) providing mechanisms to help users find content, orient themselves within it, and navigate through it. -Principle 4: Content must be robust enough to work with current and future technologies. This means (4.1) using technologies according to specification; (4.2) ensuring that user interfaces are accessible or provide an accessible alternative(s). Most of the above mentioned design principles are only partially supported by the ACCMD. For example, some of the uncovered design principles are listed below: -Principle 1.4: Making it easy to distinguish foreground information from background images or sounds. -Principle 2.5: Helping users avoid mistakes and make it easy to correct them. -Principle 3: Content and controls must be understandable. That means (3.1) ensuring that the meaning of content can be determined; (3.2) organizing content consistently from “page to page” and making interactive components 5 behave in predictable ways. The aforementioned design principle 3 may be managed by using other IMS specifications such as IMS Simple Sequencing or IMS Learning Design, but both of them are learning oriented. In our opinion, one of the next steps would be finding the information model that relates as much as possible the WCAG guidelines, by enlarging the current specification, and making it less dependent on the learning approach. There is also a need for developing tools to display content in an accessible way. For example, the above mentioned principle 1.4 could be managed by using the suitable tools. But at the same time, it would be interesting to have a metadata element for describing for a concrete content resource if the foreground information is easily distinguishable from background image or sound, (that label could be filled up by a person, or automatically by a diagnostic tool). 2.4 Textual Information is the linking format between accessible and not accessible content According to the first design principle of the WCAG 2.0 “content must be perceivable”. This means (1.1) there must be text alternatives for all non-text content; (1.2) providing synchronized alternatives for multimedia (captions and audio descriptions); (1.3) ensuring that functionality and structure are separable from presentation. If we analyze the implications of that design principle, we can infer that textual format acts as a middleware for accessibility purposes. On one hand, visual information needs textual description in order to be translated to other formats (e.g. auditive, sign language). On the other hand, information in audio format also needs to be captioned as a previous step to its translation to other accessible formats, for example for a hearing-impaired context. Sometimes non-text format can be captioned, but sometimes it must be just described, i.e. it must be contextualized. Therefore, as we will explain in next section, there should be proper support for describing textual and contextual information. 3. A further step: Standardization on the description of textual and contextual information As explained in the previous section, textual information is the linking format between nonaccessible and accessible content. In our opinion, accessibility can be considered one key issue for promoting reusability (understood as the capacity of content to be reused in intra and inter contextual scenarios). On one hand, the wider the potential user community is, including disabled people, the wider the chances for reusing content. On the other hand, as explained in previous section, in order to support accessibility it is useful to organize the information in a textual format and, as a consequence, once the information is in that format it is easier to reuse it further on. Therefore, accessibility meta-information contributes to enlarging the reusability capacity of content. So, to make content more accessible is also to make it more reusable. It is a powerful advantage if we take into account that the human resources currently needed for developing content binding IMS, DC, IEEE and other specifications is enormous. Due to that reason, reusability could even be considered a real goal, better than just a desirable. If we think in terms of reusability, according to [13], there are three key factors promoting it: (a) granularity (the lowest the better for reusability purposes); (b) localization (metadata is mainly supporting that aim); and (c) selfcontained-ness, (understood as the capacity of content to be context independent). Concerning the last factor, DC-2005: Proc. Int. Conf. on Dublin Core and Metadata Applications 2005 75 developing neutral content is against the usual content authoring workflow, because human beings normally contextualize when authoring content. So, decontextualization and re-contextualization are requested stages normally when trying to reuse content. Therefore, we can conclude that describing context (normally expressed as textual information), could promote content reusability, as well as accessibility. It could act as a facilitator for finding contextual issues in a specific content, in a previous step to the de-contextualization and recontextualization of content. Consequently, it could be interesting to describe textual and contextual information using a specification 3 , e.g. a semantic framework. In order to support context description, several approaches are possible. If we want to describe small pieces of information, e.g. question items, a domain ontology supported by OWL or RDF could be a solution. On the other hand, if we want to describe higher granularity pieces of information (both data and processes), other types of narrative oriented solutions could be better used. Indeed, there are some standard specifications for the description of context. In IMS learning oriented specifications, as well as the DC Element Set and the IEEE LOM, context is currently mainly described in terms of domain vocabularies used in the metadata tags. The Description and Text elements of the DC Metadata Set, IMS-Metadata and the IEEE-LOM can also be used for textual description. RDF and OWL are also very powerful tools for describing context in an ontological oriented manner. Another specification which may support the description of context is the IMS-Learning Design (IMS-LD) [11]. It does it using an underlying narrative syntax (expressed in terms of roles playing activities using resources). The main disadvantage of using this specification for context description is that it is oriented to the pedagogical description of learning experiences. So, it can be very good, for example for describing a unit of learning or learning scenario, but it could be not suitable for general purposes. Another specification for context description is the MPEG-7, [14] being much more generic than the IMS-LD. It supports the description of both: the structure (video segments, moving regions, etc) and the semantic. The MPEG-7 semantic entity tools describe semantic entities (such as narrative worlds, objects, events, concepts, states, places and times), as well as semantic relationships between them. In MPEG-7 events are understood as occasions when something happens. Objects, people and places can populate such occasions and the times at which they occur. Furthermore, these entities can have properties and states through which they pass as what is being described transpires. Finally, there is the world in which all of this is going on, the background, the other events and other entities, which provide context for the description. [14] The main advantage of using MPEG-7 would be to give semantic structure to the description. That semantic structure could be very useful for supporting design principles 3 and 2.5 of the WCAG 2.0. Another additional advantage of using MPEG-7 specification is that it is a generic specification developed for describing multimedia content and, as explained in previous sections, we are discussing the convenience of describing non-textual information for accessibility as well as for reusability purposes. Therefore, we can conclude that the main advantage of the aforementioned explained solutions (OWL/RDF, DC Element Set, IEEE-LOM, IMS- Metadata4), is that they are natural language oriented, and probably they are less costly in terms of human and machine resources. IMS-LD and MPEG-7 are more complex and narrative oriented solutions, but maybe too costly in practice if they are used for describing context. 4. XimDex: A Semantic CMS The semantic Content Management System ximDEX [3] is a visual framework developed by XimetriX for the creation of web contents under the paradigm of the Semantic Web. The main focus of the platform is the abstraction of contents and services, offering a distributed and visual environment for the annotation and parameterisation of elements of information that are aggregated into a hierarchy of documents in a classic web portal approach and into nodes and relationships conforming semantic repositories of information for the management of Semantic portals. Elements of information representing contents and services are grouped into documents represented via a neutral semantic format [4]. During the transcoding (converting from one format to another) stage [15, 16], a profiling of these elements of information is made to create final exploitable formats. 4.1 Accessibility built in ximDEX Every element of information composing a document or service has metadata provided by the creators and/or calculated from inferences using the instantaneous context of the element of information (ancestor’s properties for instance) in order to provide additional functionalities and to guarantee the accomplishment of targets (where accessibility is 76 DC-2005, September 12-15 - Madrid, Spain 3A pro-standard specification. 4Except for the IMS-LD, which has a narrative approach in the context of the description of pedagogical scenarios. considered a main one). That explained transformation is encoded into rules and templates using the semantic abstraction of the elements of information, conceptually at a higher level than the syntactic transformation provided by XSLT, allowing ximDEX to make assumptions and inferences to guarantee the correct adaptation of contents considering accessibility specifications. 5. Conclusions We can conclude that is a key issue to extend the IMS specifications for binding all WAI guidelines. The conversion of WCAG 1.0 checkpoints into WCAG 2.0 guidelines has increased accessibility abstraction, which can help as a first step to model those content accessibility properties and learner profile in a technology independent way. It is also interesting to keep in mind that textual information is the linking format between accessible and not accessible content, acting as a middleware for accessibility purposes. Sometimes information in a non-text format can be captioned, but sometimes it must be just described, i.e. it must be contextualized. So, there should be proper support for describing textual and contextual information. One main benefit of that approach would be that describing context using standard semantic specifications, could promote content reusability, as well as accessibility. It could act as a facilitator for finding contextual issues in a specific content, in a previous step to the de-contextualization and re-contextualization of content. Therefore, next steps in ximDEX, in order to support semantic description of context, will be to use the semantic content management system ximDEX for testing the best solution between those discussed in previous section, promoting also the interoperability with other content description specifications: -Using DC Metadata Set and IMS Metadata. -Using the MPEG-7 Semantic Tool. - Applying an ontology oriented approach described in RDF [17]. The Semantic CMS ximDEX is already prepared for testing that solution via the description of the context for every element of information through an ontology. Also, the presentation layer can be managed via a visualization ontology. We will also test the feasibility of using ACCMD (or an extended specification developed by us for trying to cover WCAG). References 1. http://www.w3.org/TR/1999/WAI-WEBC ONTENT-19990505/full-checklist N. 2. http://www.w3.org/TR/2004/WD-WCAG 20- 20041119 3. http://www.ximetrix.com/productos/ximD EX 4. J. A. Prieto, J. Villar, D. Gómez, M. Estellés, “Semantic Management of Web Contents using ximDEX” (in Spanish), Proc. I Open Source World Conference, Málaga, Spain, Feb. 2004. 5. IMS AccessForAll Metadata Overview, www.imsproject.org 6. IMS AccessForAll Information Model, www.imsproject.org 7. IMS AccessForAll Best Practice and Implementation Guide, www.imsproject.org 8. Web Content Accessibility Guidelines 2.0 www.w3c.org 9. Dublin Core Metadata Initiative, dublincore.org 10. CEN-ISSS LTW APLR, www.cen-aplr.org 11. IMS Learning Design www.imsproject.org 12. IMS Simple Sequencing, www.imsproject.org 13. Duncan, C: Granularisation, Reusing online resources: A sustainable approach to e-learning, 2003, Chapter 2, ISBN: 0749439491 14. Manjunath, B.S.(ed): Introduction to MPEG 7: Multimedia Content Description Language, John Wiley & Sons, ISBN: 0471486787 15. R. Mohan, J. Smith, C.-S. Li: Adapting Multimedia Internet Content For Universal Access, IEEE Transactions on Multimedia, March 1999, pp. 104-114. 16. White Paper: IBM Transcoding Solution and Services 17. http://www.w3.org/RDF/ DC-2005: Proc. Int. Conf. on Dublin Core and Metadata Applications 2005 77