EU4ALL Deliverable Template
Transcription
EU4ALL Deliverable Template
EU4ALL WP2-1 Technological Infrastructure Baseline D2.1.1. Technological infrastructure for Open and Accessible Service Architecture Deliverable: D2.1.1 Work Package: WP2.1 Partners: UNED, ATOS, UKOU, FIT, SOL Workpackage WP2-1: Technological infrastructure baseline Task T2.1.1: Technological infrastructure analysis T2.1.2: Open Service architectures, accessibility and communitybuilding systems Date of delivery Contractual 31/01/2007 Actual 25/04/2007 Code name FINAL_EU4ALL_D2.1.1_TechInfrOASA Version Type of deliverable Report Security (distribution level) Public (PU) Contributors UNED, ATOS, UKOU, FIT, SOL Authors (Partner) Olga C. Santos, Emmanuelle Raffenne, Jesús G. Boticario, Jorge Granado (UNED), Ángel Sáez (ATOS), Andy Heath, Chris Douce (OUUK), Carlos Velasco, Yehya Mohamad, Stefan Carmien (FIT), Santiago P. de la Cámara (SOL) Contact Person Olga C. Santos (UNED) WP/Task responsible Spanish National University for Distance Education (UNED) Final EC Project Officer Katarzyna Balucka Abstract This report describes the results of the study into the state of the art of the technological infrastructures, standards and specifications, open services architectures, and guidelines and legislation regarding accessibility in web-based developments to be considered in EU4ALL. It also compiles existing open systems and R&D projects. It provides an initial base for the design of the framework of the open service oriented architecture for accessible life long learning to be designed and implemented in EU4ALL project. 5 topics were studied, which in turn are broken down into related subtopics. Each of them is described in detail in an appendix to the document. A summary of the results of each subtopic, including the applicability and conclusions for the development of the EU4ALL architecture is included in the document. The document presents also an introduction, overview and final conclusions. Keywords List State of the art, open architectures, technological infrastructures and standards, educational standards, guidelines and legislation for design for all, open systems, community building, R&D projects. EU4ALL Project Coordinator: Lydia Montandon (Atos Origin) Tel: +34 91214 8616; fax: +34 91754 3252; mobile: +34 680 647 915 email: Lydia.montandon@atosorigin.com D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Table of contents Table of contents................................................................................3 List of Illustrations..............................................................................5 List of Tables......................................................................................6 List of abbreviations ...........................................................................7 Executive summary.............................................................................8 Introduction....................................................................................8 Description of conclusions/results......................................................9 1. Introduction...................................................................................10 1.1. Situation..................................................................................10 1.2. Purpose...................................................................................11 1.3. Scope......................................................................................13 2. Overview.......................................................................................14 2.1. Initial considerations for EU4ALL architecture ..............................14 3. Outcomes of the state of the art study and applicability in EU4ALL.......19 3.1. Review of Existing Technological Support.....................................19 3.1.1. Semantic web.....................................................................19 3.1.2. Web Services Technologies..................................................20 3.1.3. Open Communication Protocols............................................21 3.1.4. Frameworks, Open Architectures and Reference Architectures. .21 3.1.5. Device Modelling.................................................................22 3.2. Educational Technology Standards and Technologies.....................22 3.2.1. Educational Technology Standards........................................22 3.2.2. Technologies for Federated eLearning....................................23 3.2.3. Metadata Repositories.........................................................24 3.3. Review of Accessibility Guidelines for Design For ALL....................24 3.3.1. Web Accessibility Initiative...................................................24 3.3.2. National Legislations to Assure Technological Accessibility.......25 3.4. Open Systems..........................................................................26 3.4.1. Existing open systems.........................................................26 Page 3 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 3.5. R&D Projects............................................................................26 3.5.1. Related R&D projects..........................................................26 4. Final Conclusions............................................................................28 4.1. Implications in EU4ALL Work Packages........................................29 Annex A Review of existing technological support...................................31 Annex B Educational Technology Standards and Technologies..................63 Annex D Review of Accessibility Guidelines for Design For ALL.................90 Annex E Open Systems.....................................................................127 Annex F R&D Projects.......................................................................134 Page 4 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture List of Illustrations Services from EU4ALL subprojects in the architecture approach 16 EU4ALL architecture perspective from SP3, SP4 and PS5 18 Web service architecture 43 Soap Description 46 SOA Description 57 Page 5 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture List of Tables List of related R&D projects...............................................................144 Page 6 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture List of abbreviations DoW: Document of Work EU4ALL: European Unified Approach for Accessible Lifelong Learning. LLL: Life Long Learning. LOMR: Learning Object Metadata Repository. SOA: Service Oriented Architecture. WP: Work Package. Page 7 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Executive summary Introduction This report describes the results of the study into the State-of-the-art of existing technologies, open architectures and R&D related to the EU4ALL project in order to provide the Technological Infrastructure Baseline. The report includes also the experience of the project partners in previous developments so it is taken into account when designing and building the open architecture of services for ALL. In particular, it is foreseen to consider service models at European level, open service architectures providing semantic web services, ontologies and knowledge management techniques, community-oriented web applications and adaptive learning management systems. The aim of the study was to identify existing technologies, standards, guidelines and systems that could be applied in EU4ALL architecture and select the technological infrastructure for the open architecture. For this reason, each item is described in terms of its motivation, applicability and consequences of inclusion in EU4ALL. In selecting standards and specifications for inclusion in the report those that are obviously outdated or never gained community support have not been included. Where it has been possible to identify a particular piece of standards work as being of potential relevance but the work is at an early stage of its development and so its future direction, precise relevance, actual development schedule and adoption are unknown then it has been listed here along with a statement of its youth. Despite that, as standards work is a moving target some decisions on whether to include a particular piece of work here have necessarily taken a strategic approach. Chapter 1 provides a brief introduction to the EU4ALL project and describes its scope. Chapter 2 provides an overview of the preliminary open service oriented architecture and allocates the technologies that are studied. In order to facilitate the tasks of WP2-2 regarding the Open Architecture Design, the information provided in the DoW has been included and further worked taking into account the structure of SP3, SP4 and SP5, which describe services that have to be implemented in EU4ALL framework. Chapter 3 summarizes the outcomes of the evaluations of the different topics in terms of the applicability and consequences of inclusion in EU4ALL for each item. Page 8 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Chapter 4 draws some preliminary conclusions for the further development of the EU4ALL architecture considering the review done. Attached to this document are 5 annexes in which the topics analyzed are described in more detail. Description of conclusions/results The study resulted in the identification of existing technologies, open architectures and R&D that can be considered in the Technological Infrastructure Baseline. Several principles were stated that can serve as starting points for discussions and decisions about the design of the EU4ALL architecture, which are the following: 1. EU4ALL should adhere to semantic web technologies to facilitate the semantic processing 2. EU4ALL architecture should be based on web services in order to facilitate the interoperability with external services 3. EU4ALL architecture should comply to educational standards to support reusability of authors’ work and portfolio management by learners 4. Existing accessibility guidelines and national legislations to develop web-based systems should be covered 5. Federated learning repositories integrated within the architecture and frameworks have to be 6. OpenACS toolkit can be used as the basis for the development of EU4ALL basic core services, which support the essential features of the EU4ALL open architecture, such as authentication, security, tracking, collaboration services, ... External technical services and technical services developed within EU4ALL (from SP3, SP4 and SP5) can be integrated via web services. 7. EU4ALL architecture should interoperate, in terms of educational standards and services that can be integrated via web services, with open and standard-based learning management systems. Page 9 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 1. Introduction 1.1. Situation The present document describes the results of the activities T2.1.1 Technological infrastructure analysis and T2.1.2 Open service architectures, accessibility and community building systems of WP2.1 Technological Infrastructure Baseline from SP2 Open and Accessible Services Architecture. This study was carried out to identify relevant existing technologies, standards, guidelines and systems that could be applied in EU4ALL architecture and select the technological infrastructure for the open architecture. The aim of EU4ALL is to improve the efficiency and efficacy of implementing accessible Lifelong Learning (ALL) by developing an open service architecture for ALL. Three strategies are to be followed: 1. The technology that mediates lifelong learning does so by accommodating the diversity of ways people interact with technology and the content and services it delivers 2. This technology is used to bring support services to disabled learners 3. It provides support services and a technical infrastructure that enable teaching, technical and administrative staff of educational institutions to offer their teaching and services in a way that is accessible to disabled learners To achieve a wide impact the approach taken is not to develop a single EU4ALL system but a standards-based framework that facilitates the integration of the approach with a wide range of eLearning systems. More specifically the goals of EU4ALL are to: • Design an open service-oriented architecture for ALL • Develop the software infrastructure for ALL services (including content, support and access services) • Provide technical standards/specifications for ALL applications integrated with current and emerging eLearning standards • Validate the results in large-scale higher education settings Two broad user groups benefit from the EU4ALL project: 1. End-users: Adult learners with disabilities, teachers, and tutors Page 10 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 2. System-users: Providers of eLearning systems, content and services 1.2. Purpose The purpose of this report is to provide an overview of existing technologies, open architectures and R&D that are relevant for the development of the EU4ALL Technological Infrastructure Baseline. This report should also include the experience of the project partners in previous developments so it is taken into account when designing and building the open architecture of services for ALL. In particular, it requires us to consider service models at European level, open service architectures providing semantic web services, ontologies and knowledge management techniques, community-oriented web applications and adaptive learning management systems. Moreover, this architecture has to guarantee that the provided services are open, secure, standard-based, accessible and interoperable. This document addresses the second scientific objective of EU4ALL which relates to the Open Architecture for ALL. Its purpose is to define practical specifications and implement in terms of standards an open and extensible architecture of services for ALL which is designed to both assist learners and support service providers. Technical criteria for measurement are, on one hand, the architecture standards coverage (i.e., ratio of standards utilised in the architecture compared to those available for covering the different services) i, and on the other, the number of learning management systems integrated. These measurements will show the flexibility and openness of the architecture. In particular, this objective sets out for the EU4ALL architecture the following two main basic assumptions at the start of the project. • Establishment of principles of integration and interoperability • Integration of standards, both educational and technological. These requirements allow the integration of several learning management systems, such as Moodle, dotLRN, LearnXact and ATENEA. Moreover, EU4ALL architecture considers end-user services (i.e. consultancy services for professionals and support services for disabled students) and core services (i.e. technical services). The later are to be provided by the technological infrastructure baseline and comprise the following: • Supporting the interaction (between the student and the technology), • Adaptation of interface • Searching of alternative content • Management of users profiles and models • Management of device models Page 11 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • Management of learning design It should also be possible for different organisations to use the system and architecture and therefore the specifications, software modules/components, technical interface, documentation, and metadata (for search engines) should be provided. As a technological and scientific result, EU4ALL will deliver products including procedures, tools, norms, standards, and specifications and prototypes implementing them; which will enable them to be validated in real world contexts. All these constraints have been considered when producing this study of the state-of-the-art of EU4ALL related technology. In the light of these requirements the main objectives for WP2.1 is to: 1. Avoid reinventing the wheel and waste time and effort, identify existing open systems that could be readily used or adapted to fulfil the basic requirements of the EU4ALL architecture. 2. Identify technologies and approaches that could form the basis for the design of the EU4ALL architecture in order to fulfil the main functional requirements. 3. Identify standards and specifications that the EU4ALL architecture should adhere to. 4. Identify systems that the EU4ALL architecture should be able to interface or integrate with. In identifying relevant standards and specifications the following criteria have been used: 1. Technological and Pedagogic relevance. It is necessary for inclusion here that a standard or specification addresses technology of potential relevance to achievement of the aims of EU4ALL 2. Level of community support and stage of development. For a standard to succeed in the marketplace it is necessary that it is taken up by relevant communities – being technically good is not sufficient. 3. Timeliness and state of development. This is not independent from 2. above because a successful standard will at some point in its lifecycle have an appropriate level of community support. Standards that are clearly out of date and obsolete or that did not achieve community support and are not now active have not been included in the report. In some cases it has been possible to identify standards work underway that is at too early a stage of development to know or specify its precise relevance. In such cases it has been described here with a note that it is immature. However, as standards are a moving target it some decisions on whether to report particular works here have inevitably had to be made on a strategic basis. Page 12 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture This document is intended to be read by designers and developers of the EU4ALL system, as well as external designers and developers who want to deepen in the technologies to develop open accessible service architectures. This document provides input for WP2.2 Open Architecture Design in SP2 Open and Accessible Services Architecture. 1.3. Scope In order to achieve the objectives for WP 2.1 as stated in the previous section possible relevant topics for study were identified and grouped in 5 main topics. Each topic was then divided into more specific subtopics or items. The resulting list is the following: Annex A Review of existing technological support A.1 Semantic Web A.2 Web Services technologies A.3 Open communication protocols A.4 Frameworks, open architectures, and reference architectures A.5 Device Modelling Annex B Educational Technologies standards and technologies B.1 Educational Technologies standards B.2 Technologies for federated eLearning B.3 Metadata Repositories Annex C Review of accessibility guidelines for design for ALL C.1 Web Accessibility Initiative C.2 National legislations to assure technological accessibility Annex D Open systems Annex E R&D Projects The state of the art of these five topics is attached as annexes to this document. Next chapter provides an overview of the preliminary open service oriented architecture and denotes the technologies that have been studied. Chapter 3 summarizes the outcomes of the evaluations of the different topics in terms of the applicability and consequences of inclusion in EU4ALL for each item. Finally, chapter 4 draws some preliminary conclusions for the further development of the EU4ALL architecture considering the review done. Page 13 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 2. Overview The main purpose of this project is to develop a flexible, open, standardbased architecture to support the LLL paradigm in higher education institutions, providing ALL services for people with special needs, with special attention to people with disabilities and the elderly. In pursuing that goal, the proposed architecture is aimed at the following more concrete objectives: • Define and construct an architecture which is prepared to provide ALL services to assist different types of users on the demand side (students with special needs) and different existing roles on the supply side (administrators, faculty staff or specialised support people involved in the provision of services). • The architecture will be open and extensible, both from the user point of view (new services can be added) and from the technological standpoint (built in terms of technological and educational standards). • It will cover services to users (like functionalities provided to them), but also services from one component of the service chain to another. • It will support a smooth interaction and service discovery to find the right service at the right moment. • The user is central to the service provision and the architecture will support an adaptive behaviour based on users’ interactions. To do this, according to the “full lifecycle of adaptation” it will manage the “user with disabilities” profile (in terms of standards) and will apply an automatic adaptive approach to update user models based on data mining and user modelling techniques. • To support reusability functionalities and services will be defined in terms of standards, integrating workflow design for their specification and management. Thus, services will follow the pedagogical conditions established at design time. • Finally, to evaluate services provided by the architecture, quantitative and qualitative indicators will be applied, and the scope of the evaluation will cover end-users and service providers as well. 2.1. Initial considerations for EU4ALL architecture In order to facilitate the tasks of WP2-2 regarding the Open Architecture Design, the information provided in the DoW has been included and further worked taking into account the structure of SP3, SP4 and SP5, which describe services that have to be implemented in EU4ALL framework. These Page 14 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture issues were discussed in the 2nd Consortium Meeting held in Madrid, March 2007. The EU4ALL architecture will support effective ways to integrate existing and new components, providing an open and extensible framework. In this way, development efforts can be used for improving the adaptation functionality, and not for developing basic functionality such as security, collaborative tools, tracking, already provided by existing open systems. The architecture has to provide the required support to allow the functionality and adaptations coming from SP3, SP4 and SP5 take place. Following the typical layer approach for architecture descriptions already used in the DoW description, to support this integration the architecture can consist of the following layers (the exact architecture is to be defined in WP2.2): • The Server Layer, in charge of the user front-end (where end-user services are to be offered such as exam adaptation, pedagogical and psychological guidelines, dynamic recommendations, ...). The server layer manages the application security, showing user interface and tracing user interactions. It comprises the security layer (users’ permissions, security control), dispatcher (it distributes requests to different modules, although modules can also talk to each other in a distributed way), presentation layer (it collects responses from service components and generates application outputs), tracker (it stores and manages users’ interactions to provide required inputs to adaptation modules). • The Services Layer, made up of different types of technological services which support the end-user functionality. It provides the application functionality and main logic. There will be different types of services with respect to alternative criteria: information support, adaptation types, pedagogical issues, community-building and collaborative work, devices, etc. • The Data Layer, comprises the data management and storage. This layer includes two main components. The object model constitutes the common model that will be agreed by the different components in order to allow the communications, although each module may keep an internal repository for internal use. It will provide the needed functionality to access the data repositories allowing to the rest of components to use it. Common repositories comprise the data to be shared by all components. Moreover, the Authoring Tools as independent components will allow users (authors and service providers) to create the service contents. Page 15 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The architecture approach will allow the integration of any kind of services following the open specifications defined in the service specification framework. Service integration will cover the consecutive development phases: first development (basic core services to support other technical services), end-user services (content transformation, navigation adaptation, collaborative services, pedagogical and psychological guidance, etc.) and eventual new end-user services (those coming from the validation cycles). In particular, the following figure further works the above figure by including the technical services already identified in the EU4ALL subprojects (which are to be implemented along the project) plus some example of enduser services coming from SP1 (which will be considered in the framework, but may not be implemented). Moreover, some standards already identified in the DoW are mentioned in the corresponding service. Illustration 1: Services from EU4ALL subprojects in the architecture approach The figure differentiates end-user services (at the top) from technical services (at the bottom). In between there is the Security layer, Presentation Layer, Tracker and Dispatcher. End-user services include Dynamic Recommendations, Psychological and Pedagogical guidelines, eTutor guidance, ePortfolio, learning management system (LMS), enrolment, exam adaptation, etc. Technical services include the engines that support those end-user services. Technical services can communicate to each other via web services, but also receive request from the dispatcher. Moreover, there is a content repositoriy where external authoring tools produce contents for the services. Page 16 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture In any case, the design of the architecture is to be developed in WP2.2. By the moment, we make some considerations to help focus that forthcoming task. As stated in the DoW, the open architecture will provide different types of services that can be grouped in the layers depicted in the above figure: • End-users’ services: following the analysis of the functional specifications and the specific requirements, this layer includes the services defined for ALL, namely those that are provided by third-parties (e.g., a particular application to transform text into Braille) and those defined to fulfil specific users’ needs (e.g., to guide the user to take full advantage of special equipment and facilities for disabled students interested in the European mobility programmes). • Technical services: can be basic core services that cover the different types of basic functionalities that support the essential features of the open architecture such as tracking facilities, which will “feed” various modules (e.g. the audit module), collaboration services, etc. plus those that provide different types of adaptations (contents, devices, users’ profiles, etc.). • Network support services: they comprise the most basic functionalities to support connectivity, interoperability and multiple processes running on one or more machines to interact across a network. In particular, open communication protocols and Web services. In addition, there will be the standard platform support services such as discovery, transactions, security, authentication, etc. Moreover, the design of the overall architecture should include content management, media streaming and data-base back-end, scalability, load balancing, reliability, hardware selection and planning. This Deliverable provides feedback for the deployment of the basic technical services and the corresponding infrastructure. In order to show that EU4ALL's architecture is not necessarily heterogeneous nor monolithic, here we introduce the architecture perspective from SP3, SP4 and SP5 points of view. For these subprojects, the system consists of an engine which acts in concert with a plug-in for an existing kernel with basic functionality such as collaboration, authentication, security, tracking, .... As the figure and legend below illustrate, the EU4ALL system uses the main engine and supporting web services that provide the functionality to assist the kernel to serve up the web content that best fits the user and their device. In this context, the web content does not necessarily need to be a learning object, but some content that is demanded by the service being provided. Page 17 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Illustration 2: EU4ALL architecture perspective from SP3, SP4 and PS5 Legend : 1) The user makes a request for a specific content via a user agent in the process of interacting with a EU4ALL system 2) The system passes the request and strips out the user and device model references and queries user (UM) and device model (DM) repositories which return user & device model specifics 3) The EU4ALL then strips out the identifier of the specific content that is requested and together with the user and device information queries the content personalization (CP) model repository for a content that will satisfy the users needs and be appropriate to the device 4) If a content is identified, the EU4ALL engine and plug-in then passes this back to the system which then requests it from a learning object repository (which may be in side or outside the system) 5) The EU4ALL system then sends it to the user agent on the device for interaction with the user 6) A tracking module keeps records of requests and replies. The engine (the dispatcher in the layered architecture) acts as a router for requests, sending web service requests to a repository of user models, device models and content personalization services that allow the engine to pass through to the underlying system the identity of the appropriate content. Page 18 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 3. Outcomes of the state of the art study and applicability in EU4ALL This section summarizes the result of the 5 topics and corresponding subtopics compiled in the annexes. Next a summary of the results of each subtopic is presented, focusing on the applicability and the conclusions for the development of the EU4ALL architecture. 3.1. Review of Existing Technological Support 3.1.1. Semantic web 3.1.1.1. Applicability in EU4ALL Semantic Web technologies involve a lot of standards: some more related to resource description and some more related to Semantic Web Services (functional and non functional information). Work in both areas is foreseen in the project: • Resource description will be used for learning objects in LOMR. XML, RDF, OWL and Dublin Core will be the most applicable in this part. • Service definition will be used when formalizing the processes of a training institution. OWL-S and WSMO would be applicable here. • Device capabilities descriptions are given by companies in RDF specification. This information should be dealt with in order to adapt the user interface to the device 3.1.1.2. Consequences in EU4ALL Some consequences for EU4ALL are the following: • Provide tools that allow authors specify the characteristics of the content (semantic annotation). • Provide the infrastructure to manage the device information • Base service communications in XML and RDF to facilitate semantic interoperability Page 19 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 3.1.2. Web Services Technologies 3.1.2.1. Applicability in EU4ALL In EU4ALL we distinguish between "services" to the users and services from one entity to another to build the final service to the user. More properly the web services could be seen as supporting functionality in a user agent. Where appropriate “personalized assistants” or Agents (which “know” about the users stated needs and learn about preferences and procedures) will be supported with the use of an appropriate set of Web Services. The goal of EU4ALL is to adopt commonly used standards, leveraging our abilities, but where the existing standard is not widely adopted we should consider modification or replacement of the standard with one that fits precisely our requirements. By using Web Services in conjunction with various kinds of user agents (e.g. Web browsers etc.), end-user services can become appropriately contextualized, allowing generic information (i.e. text, email services, testing) to be presented in the best way for any given user and device (in conjunction with some user / device modelling information). 3.1.2.2. Consequences in EU4ALL On the positive side, using existing Web Services standards leverage existing, well understood, and well fitted technology allowing EU4ALL to focus on its higher-level goals. However use of generic standards can often force solutions to take specific forms that may not be worth the trade-off. In particular, for EU4ALL the usage of web services will require implementation web service coverage to those services used in EU4ALL which do not provide it yet. We have also to be aware of the main two drawbacks of web services, namely overhead and lack of versatility. On the one hand, transmitting all data in XML is obviously not as efficient as using a proprietary binary code. What you win in portability, you lose in efficiency. Even so, this overhead is usually acceptable for most applications, but you will probably never find a critical real-time application that uses Web Services. Regarding EU4ALL purpose about defining a generic framework for the services architecture, portability is more important than efficiency. On the other hand, although currently, web services are not very versatile and they only allow for some very basic forms of service invocation (others, e.g. CORBA, offer programmers a lot of supporting services such as persistency, notifications, lifecycle management, transactions, etc.) there are a lot of emerging web Page 20 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture services specifications (including WSRF) that are helping to make web services more and more versatile. 3.1.3. Open Communication Protocols 3.1.3.1. Applicability in EU4ALL The detailed design of the EU4ALL architecture is an upcoming milestone that will be described in deliverable D2.2.2 due by month 10. The protocols identified in this section are to be considered at design time, namely WebDAV to provide a mean to distribute documents for their edition from a client device, SRU/SRW to allow a remote device or system to search for resources, e.g. in content repositories, RPC to allow SOAP messages to be transmitted via HTTP or RPC calls, IIOP to enables browsers to exchange complex objects and FIPA-ACL to allows multi-agent communication for decoupled software developments. 3.1.3.2. Consequences in EU4ALL Choosing the accurate protocols to be used in the architecture have to take into account all its components, their requirements and design. Most of the educational and accessibility standards to be used already considered in their specification the transport and protocol layer. However, detailed requirements and use-cases of how those components will interact should be provided. 3.1.4. Frameworks, Open Architectures and Reference Architectures 3.1.4.1. Applicability in EU4ALL Service-Oriented Architecture (SOA) is the most suitable architecture for EU4ALL given the fact that from the proposal the aim of the project was to develop an open service-oriented architecture (plus infrastructure for services, plus technical standards/specifications). Other major software open architectures are not service-oriented. As SOA is not limited to any technology, one of the set able to implement SOA principles should be chosen. Web Services is the first candidate. 3.1.4.2. Consequences in EU4ALL SOA will make EU4ALL have the following advantages over traditional approach: Page 21 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • Loosely coupled approach • The search and connectivity to other services is dynamic • Services need not be at a particular system or particular network • Services provide location independence 3.1.5. Device Modelling 3.1.5.1. Applicability in EU4ALL EU4ALL's goal of developing a flexible, open, standard-based architecture of services to support the LLL paradigm in higher education institutions for people with special needs, with special attention to people with disabilities and elderly people (page 6 DoW) requires an approach that can adapt content and content presentation to the needs of the end users and the capabilities of their user agents. Toward this goal a device modelling framework will be required. Whether the details of the model will be an instance of one of the above, an extension of them or a new standard will be determined by the results of the other tasks in this project. 3.1.5.2. Consequences in EU4ALL In determining the form that device modelling takes in EU4ALL, care must be taken in balancing the specificity of creating a new 'proprietary' standard versus using (and perhaps extending) an existing standard. The word 'proprietary' is used here not so much to denote intellectual property rights as to underline the importance of building on broadly used technologies with the goal of incremental improvement. On the other hand naive incorporation of a 'standard' can force design choices that are not solely derived from the needs of the user and system. 3.2. Educational Technology Standards and Technologies 3.2.1. Educational Technology Standards 3.2.1.1. Applicability in EU4ALL The detailed consideration of the standards implications for EU4ALL will be contained in deliverable D.4.1.1 due Month 06 and D.4.3.1 due Month 15. Below only the major areas of dependency are highlighted. 1. The IMS AccessForAll family of specifications and its development in ISO. Particularly the ACCLIP specification – a data structure that describes end-user content and interaction preferences. Page 22 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 2. IMS Content Packaging 1.2 (in preparation) for its use of Variant Resources 3. The Metadata standards – Dublin Core and LOM/IMS Metadata and ACCMD/Indivdualized Adaptability (part of the IMS AccessForAll family) particularly but much other work is ongoing (e.g. in AICC) – we need an approach to all of these. 4. IMS ePortfolio specification 5. Other relevant IMS specifications in the areas of competencies, digital repositories, enterprise, services and smaller ones that form the glue between them. 3.2.1.2. Consequences in EU4ALL To speed EU4ALL development activities it would be worthwhile to consider the range of educational technology standards that have been published. By considering the standards there are two key consequences: (1) the standards work has the potential to inform the development activities, and (2) the EU4ALL development activities may inform the standards, indicating shortcomings or areas that require attention. In doing so, EU4ALL can influence the wider arena of learning technologies, their adoption and implementation. The significance of IMS-CP 1.2 for EU4ALL is that it has a mechanism for description of “Variant Resources” that can specify alternate resources for selection at delivery time. There are implications for EU4ALL in the areas of assessment/competencies and accessibility of authoring tools/media. 3.2.2. Technologies for Federated eLearning 3.2.2.1. Applicability in EU4ALL Educational institutions often concentrate on particular subjects or topics. Developing educational materials is an expensive and time-consuming process. Providing search interfaces to external parties may expose the possibility of re-use of resources and collaboration between academic partners who have similar subject area interests. Providing search functionality has the potential to increase the dissemination of universally accessible learning materials. Page 23 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 3.2.2.2. Consequences in EU4ALL Implementing a federated eLearning system requires careful consideration of end user search interface, design of search protocols, content indexing strategies, security and the important issue of content licensing and digital rights. Considerations need to be given as to how searches should be performed from client and server perspectives and a set of appropriate usecases constructed. 3.2.3. Metadata Repositories 3.2.3.1. Applicability in EU4ALL Sharing meta-data between different repository systems held at different institutions may allow resources to be shared between different institutions. When considering the need to potentially adapt content, sharing or exposing search meta-data may increase the likelihood of discovering an accessible equivalent of a resource. 3.2.3.2. Consequences in EU4ALL Attempting to adhere to specifications that are either underspecified or undergoing change is likely to be difficult. Any engineering activity should take into account the technology recommendations that a specification provides and EU4ALL should implement solutions with the understanding that full repository and metadata interoperability is likely to be an ideal to aspire to in the long-term rather than an objective to practically aim for in the short-term. 3.3. Review of Accessibility Guidelines for Design For ALL 3.3.1. Web Accessibility Initiative 3.3.1.1. Applicability in EU4ALL All citizens need ongoing access to learning to enable them to work. Technology is playing an increasing role in mediating this learning. However, is this technology is inappropriate and introduced with insufficient support, disabled people will face even further exclusion from the interlinked worlds of education and work. Accessibility recommendations must be applied in order to make EU4ALL accessible and usable by any person, independently of the own limitations of the individual or the derived ones from the context, paying special attention in all those services that are going to interact with the end-user. Page 24 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 3.3.1.2. Consequences in EU4ALL Some consequences for EU4ALL are the following: • WAI accessibility recommendations should be considered in every workpackage that involves development. • Future recommendations should be taken into account • To achieve EU4ALL objectives, accessibility has to be considered as a final requirement for the project. The strategies followed to fulfil EU4ALL objectives include: • To ensure that technology that mediates lifelong learning does so accommodating the diversity of ways people use to interact with technology and the content and services it delivers. • Use technology to bring support services to disabled learners and to technical and administrative staff. • Provide technical infrastructure that enables both technical and administrative staff offer services in an accessible way to disabled learners. 3.3.2. National Legislations to Assure Technological Accessibility 3.3.2.1. Applicability in EU4ALL With respect to Web sites and technology of the information, most of the norms and laws are open and they are limited to recommend an “accessible design” for all. However, these recommendations become mandatory when they refer to Public Administration Web sites. All the laws of the states members adjust to the directives established by the European Union. 3.3.2.2. Consequences in EU4ALL Those more restrictive norms are fitted to follow the recommendations of the WAI published in the WCAG 1.0. EU4ALL must not have problems in being used in the countries of the European Union nor outside it, since it is to fulfil all the effective norms of the WAI on accessibility (to see C.1 appendix). Page 25 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 3.4. Open Systems 3.4.1. Existing open systems Representative open system are analysed in the Annex. Applicability and consequences are summarized next. 3.4.1.1. Applicability in EU4ALL Open systems offer scalable and interoperable environments to develop applications. Given the multi layered architecture that needs to be built to provide technical and end-user services in a distributed manner, open systems fit those requirements as being a layered hierarchical structure, configuration of communications or distributed data processing system. Furthermore, their specifications are public and include approved standards. Several architectures are analysed. OpenACS is a robust, secure framework for building scalable web applications, supports webservices, many technical standards and IMS suite educational standards and should be considered as the framework to implement the development of EU4ALL basic core services, which support the essential features of the EU4ALL open architecture, such as authentication, security, tracking, collaboration services, ... In this way, external technical services and other technical services developed within EU4ALL (from SP3, SP4 and SP5) can be integrated via web services. Moreover, the abstract architecture defined by the Sakai project and the OIDS approach from OKI can provide useful insight for EU4ALL architecture. 3.4.1.2. Consequences in EU4LL The open system to be used to implement EU4ALL services architecture has to meet the requirements of accessibility, modularity, security, interoperability requires for each component. Web services capabilities and technical and educational standards availability should be considered. 3.5. R&D Projects 3.5.1. Related R&D projects A list of related R&D projects is presented in the Annex. Applicability and consequences are summarized next. Page 26 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 3.5.2. Applicability in EU4ALL There exist several R&D projects whose outcomes can be applied to EU4ALL project due to the technological and educational standards or accessibility support. A list is provided in the corresponding annex. 3.5.3. Consequences in EU4ALL In most of these projects, partners or members of EU4ALL have actively participated. Considering the work done in them assures that the experience gathered in previous developments is taken into account when designing and building the open architecture of services for ALL. In particular, it is foreseen to consider service models at European level, open service architectures providing semantic web services, ontologies and knowledge management techniques, community-oriented web applications and adaptive learning management systems. Page 27 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 4. Final Conclusions EU4ALL has the task of developing a flexible standard-based architecture of services to support the Life Long Learning (LLL) paradigm in higher education institutions for people with special needs, with special attention to people with disabilities and elderly people. The main goal of EU4ALL is to design and implement an extensible “architecture” of European-wide services to support assistive life long learning for adult learners with special needs, which guarantees that the provided services are open, secure, standard-based, accessible and interoperable. The overall architecture will consider "core services components", chains of "services components" and procedures, functionalities, tools, norms and standards/specifications. Driving a standards based approach is the need to promote interoperability between services and agents. To address this, the EU4ALL project sets forward the concept of Accessible Lifelong Learning uniting 3 key strategies: 1. That the technology that mediates lifelong learning does so by accommodating the diversity of ways people interact with technology and the content and services it delivers. 2. That this technology is used to bring support services to disabled learners. 3. Providing support services and a technical infrastructure that enable teaching, technical and administrative staff, of educational institutions to offer their teaching and services in a way that is accessible to disabled learners. In this section the conclusions from the different appendices are integrated to provide answers to the original questions that were set out at the beginning of this study, namely: 1. Are there existing open frameworks that can be taken as a starting point for EU4ALL architecture? 2. What are the relevant technologies and approaches that can be applied for the design of the EU4ALL architecture? 3. What are the relevant standards and specifications that the EU4ALL architecture system should adhere to? 4. What are the systems that the EU4ALL architecture should be able to interface with? Possible answers are provided for each question by stating principles that the design of the system should adhere to. These principles can serve as a Page 28 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture starting point for discussions and decisions about the design of the EU4ALL architecture to be performed in WP2.2. Please note that they should not be seen as final design decisions. • EU4ALL should adhere to semantic web technologies to facilitate the semantic processing • EU4ALL architecture should be based on web services in order to facilitate the interoperability with external services • EU4ALL architecture should comply to educational standards to support reusability of authors’ work and portfolio management by learners • Existing accessibility guidelines and national legislations to develop webbased systems should be covered • Federated learning repositories and frameworks have to be integrated within the architecture • OpenACS toolkit can be used as the basis for the development of EU4ALL basic core services, which support the essential features of the EU4ALL open architecture, such as authentication, security, tracking, collaboration services, ... External technical services and technical services developed within EU4ALL (from SP3, SP4 and SP5) can be integrated via web services. 4.1. Implications in EU4ALL Work Packages The following work packages have been directly identified affected by the technologies and standards reviewed in this deliverable. Others no listed may have indirect implications: • WP2.2: Open Architecture Design • WP2.3: Open Architecture services • WP2.4: Integration of standard-based and adaptive components with the architectures • WP3.1: User Modelling • WP3.2: Device Modelling and Adaptive Interfaces • WP3.3: Content Personalization • WP3.4: Accessibility components Integration and Validation • WP4.3: Standards implications for functional specifications • WP4.4: Learning Object Metadata Repositories • WP5.1: Pedagogical Guidelines • WP5.2: Psychological Support Page 29 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • WP5.3: eTutor guidance • WP5.4: ePortfolio and Assessment • WP6.4: Validation and evaluation of service architecture and services • WP6.5: Demonstrator • WP7.1: Project dissemination and valorisation • WP7.2: Repository / Portal and Community building • WP7.4: Staff development and high-level training Page 30 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Annex A Review of existing technological support Page 31 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture A.1 Semantic Web World Wide Web allows people to exchange information to a great extent. But there are still very big limitations that wouldn't be a problem in a human-to-human interaction, and that we would like to achieve in order to have more automation in information use. The Semantic Web is a project to create a universal medium for information exchange by putting documents with computer-processable meaning (semantics) on the World Wide Web. Currently under the direction of the Web's creator, Tim Berners-Lee of the World Wide Web Consortium (W3C), the Semantic Web extends the Web through the use of standards, markup languages and related processing tools. A.1.1 Motivation Firstly, considering the Web as a source of information where we need to dig, Semantic Web will allow better, more suitable searching on it. Use of information in conventional World Wide Web is based on syntax search. Web pages can be found by matching pure textual patterns. Therefore, searches are affected by polysemy and synonymy. If web pages had been formally annotated (inside the pages themselves or elsewhere) according to a model that has been previously agreed by a domain of users, a computer would be able to understand unambiguously what the web page is about and would be able to find the suitable web pages (now resources) when a (semantic) search is done. Secondly, considering the subsequent exploitation of the data that can be found in the Web. Humans are capable of using the Web to carry out tasks. But a computer cannot accomplish the same tasks without human direction because web pages are designed to be read by people, not machines. The semantic web is a vision of web pages that are understandable by computers, so that they can search websites and perform actions in a standardized way. It is an infrastructure where machines can comprehend semantic data and extend the knowledge of humans. Semantic Web applications could make use of that extended knowledge to help in the automation of tasks that are currently performed with heavy user interaction (data combination, decision making, etc.). Knowledge-based systems have two basic components: a knowledge base of facts known by the intelligent system and an inference engine. So will have knowledge-based applications for the Semantic Web. Page 32 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The knowledge base for a Semantic Web application is built from annotations collected by the application as it browses (semantic) web pages. Those annotations cannot be written in already existing knowledge representation languages, that are intended for a certain domain of users that already share a vocabulary. World Wide Web users cannot be assumed to have that shared vocabulary. Different initiatives have been taken in order to have this standard representation of knowledge in Web. In the next web generation, resources will be more accessible to automated processes by the usage of descriptive technologies such as Resource Description Framework (RDF) and Web Ontology Language (OWL), based on the datacentric, customizable Extensible Markup Language (XML). These technologies are combined in order to provide descriptions that supplement or replace the content of Web documents and will be further explained below. If we want a Semantic Web application to be able to take decisions or make conclusions from the annotated information, we will need to supply the application also with a model of the domain it is dealing with. The model would be made of the main concepts in the domain (vocabulary), the properties relating those concepts and some rules that must be followed. Those models are the ontologies. "An ontology is a conceptualization". formal and explicit specification of a shared • Conceptualization refers to an abstract model of some phenomenon in the world by having identified the relevant concepts of that phenomenon. • Explicit means that the types of concepts used and the constraints on their use are explicitly defined. • Formal refers to the fact that the ontology should be machine-readable. • Shared reflects the notion that an ontology captures consensual knowledge; that is, it is not private to some individual but accepted by a group. Several different languages have been developed for ontology creation. They are further explained below. Apart from annotations and ontologies, the third key element in Semantic Web are the inference engines. A deeper study of them is considered to be out of the scope of this document. A.1.2 Standards Page 33 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Next, the big set of standards related with Semantic Web will be presented. A.1.2.1 XHTML XHTML is a family of current and future document types and modules that reproduce, subset, and extend HTML 4. XHTML family document types are XML based, need to be well-formed and ultimately are designed to work in conjunction with XML-based user agents. XHTML has the same depth of expression as HTML, but a stricter syntax. XHTML can be thought of as the intersection of HTML and XML in many respects, since it is a reformulation of HTML in XML. XHTML 1.0 became a World Wide Web Consortium (W3C) Recommendation on January 26, 2000. XHTML 1.1 became a W3C recommendation May 31, 2001. A.1.2.2 XML Extensible Markup Language (XML) is a W3C-recommended generalpurpose markup language that supports a wide variety of applications. It provides a surface syntax for structured documents, but imposes no semantic constraints on the meaning of these documents. XML is a simplified subset of Standard Generalized Markup Language (SGML). Its primary purpose is to facilitate the sharing of data across different information systems, particularly systems connected via the Internet. XML was developed by an XML Working Group (originally known as the SGML Editorial Review Board) formed under the auspices of the World Wide Web Consortium (W3C) in 1996. It was chaired by Jon Bosak of Sun Microsystems with the active participation of an XML Special Interest Group (previously known as the SGML Working Group) also organized by the W3C. The design goals for XML are: 1. XML shall be straightforwardly usable over the Internet. 2. XML shall support a wide variety of applications. 3. XML shall be compatible with SGML. 4. It shall be easy to write programs which process XML documents. 5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. 6. XML documents should be human-legible and reasonably clear. 7. The XML design should be prepared quickly. 8. The design of XML shall be formal and concise. Page 34 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 9. XML documents shall be easy to create. 10.Terseness in XML markup is of minimal importance. Two major API specifications define how XML parsers work: DOM and SAX. The Document Object Model (DOM) is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed for any purpose. The DOM specification defines a treebased approach to navigating an XML document. In other words, a DOM parser processes XML data and creates an object-oriented hierarchical representation of the document that you can navigate at run-time. SAX (Simple API for XML) is a serial access parser API for XML. A parser which implements SAX (ie, a SAX Parser) handles XML information as a single stream of data. This data stream is unidirectional, such that previously accessed data cannot be re-read without reparsing. The SAX parser is implemented as an event-driven model in which the programmer provides callback methods which are invoked by the parser as part of its traversal of the XML document. Hence DOM is likely to be best suited for applications where the document must be accessed repeatedly or out of sequence order. If the application is strictly sequential and one-pass, the SAX model is likely to be faster and use less memory. A.1.2.3 DTD A DTD (Document Type Definition) is a collection of XML markup declarations that define the structure, elements and attributes that can be used in a document that complies with that DTD. By consulting the DTD a parser can work with the tags from the markup language that document uses. Thus, it is a schema specification method for XML documents, as the XML Schema is. As an expression of a schema, a DTD specifies, in effect, the syntax of an "application" of XML (SGML), such as the derivative language HTML or XHTML. This syntax is usually a less general form of the syntax of XML (SGML). In a DTD, the structure of a class of documents is described via element and attribute-list declarations. Element declarations name the allowable set of elements within the document, and specify whether and how declared elements and runs of character data may be contained within each element. Attribute-list declarations name the allowable set of attributes for each Page 35 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture declared element, including the type of each attribute value, if not an explicit set of valid value(s). A.1.2.4 XML Schema XML Schema is a W3C Recommendation defining a schema language for XML. XML Schema provides a way to define constraints on the syntax and structure of an XML document. It defines the elements and attributes that can appear in an XML document including their types. Additionally it can specify the order and number of child elements and define default and fixed values for elements and attributes. This way, XML Schema expresses a set of rules to which an XML document must conform in order to be considered 'valid' according to that schema. However, unlike most other schema languages, XML Schema was also designed with the intent of validation. This results in a collection of information adhering to specific datatypes, which can be useful in the development of XML document processing software. A.1.2.5 RDF The W3C published a specification for RDF's data model and XML syntax as a Recommendation in 1999. Work then began on a new version that was published as a set of related specifications in 2004. RDF is a simple data model for referring to objects ("resources") and how they are related. An RDF-based model can be represented in XML syntax. It is a family of W3C specifications originally designed as a metadata model using XML but which has come to be used as a general method of modelling knowledge, through a variety of syntax formats (XML and non-XML). The RDF metadata model is based upon the idea of making statements about resources in the form of subject-predicate-object expressions, called triples in RDF terminology. The subject denotes the resource, and the predicate denotes traits or aspects of the resource and expresses a relationship between the subject and the object. A.1.2.6 RDF Schema RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a semantics for generalization-hierarchies of such properties and classes. RDFS or RDF Schema is an extensible knowledge representation language, providing basic elements for the definition of ontologies, otherwise called RDF vocabularies, intended to structure RDF resources. The first version Page 36 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture was proposed in March 1999, and the final W3C recommendation was released in February 2004. Main RDFS components are included in the more expressive language OWL. A.1.2.7 SPARQL SPARQL is an RDF query language; its name is a recursive acronym that stands for SPARQL Protocol and RDF Query Language. It is a standardized query language for RDF data with multiple implementations that offers developers and end users a way to write and to consume the results of queries across RDF wide range of information. Used with a common protocol, applications can access and combine information from across the Web. The SPARQL query language consists of the syntax and semantics for asking and answering queries against RDF graphs. SPARQL contains capabilities for querying by triple patterns, conjunctions, disjunctions, and optional patterns. It also supports constraining queries by source RDF graph and extensible value testing. Results of SPARQL queries can be ordered, limited and offset in number, and presented in several different forms. A.1.2.8 OWL Web Ontology Language (OWL) is a markup language for publishing and sharing data using ontologies on the Internet. OWL is a vocabulary extension of the RDF and is derived from the DAML+OIL Web Ontology Language. Together with RDF and other components, these tools make up the Semantic Web project. DAML (DARPA Agent Markup Language) language was developed as an extension to XML and RDF. The Ontology Inference Layer (OIL) was a proposal for a web-based representation and inference layer for ontologies, which combines the widely used modelling primitives from frame-based languages with the formal semantics and reasoning services provided by description logics. It is compatible with RDFS, and includes a precise semantics for describing term meanings (and thus also for describing implied information). DAML+OIL is a successor language to DAML and OIL that combines features of both. The latest release of the language provided a rich set of constructs with which to create ontologies and to markup information so that it is machine readable and understandable. It was superseded by OWL. OWL adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality, richer typing of properties, characteristics of Page 37 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture properties (e.g. symmetry), and enumerated classes. It represents the meanings of terms in vocabularies and the relationships between those terms in a way that is suitable for processing by software. OWL is the next level in the Semantic Web stack. Beyond what is already provided by RDF Schema it provides vocabulary for describing properties and classes: among others, relations between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality, richer typing of properties, characteristics of properties (e.g. symmetry), and enumerated classes. Furthermore, OWL expresses information in ontologies, which can include other ontologies. A.1.2.9 OWL-S OWL-S is a OWL-based Web service ontology, which supplies Web service providers with a core set of markup language constructs for describing the properties and capabilities of their Web services in unambiguous, computerinterpretable form. It is the semantic markup for web services A.1.2.10 SWRL SWRL is a proposal for a Semantic Web rules-language, combining sublanguages of the OWL (OWL DL and Lite) with those of the Rule Markup Language. A.1.2.11 WSMO Web Service Modelling Ontology (WSMO) is an ontology currently developed to support the deployment and interoperability of Semantic Web Services. The WSMO working group, part of the ESSI Cluster aligns the research and development efforts in the areas of Semantic Web Services between several European FP6 research projects. WSMO working group includes the WSML working group, which aims at developing a language called Web Service Modelling Language (WSML) that formalizes the Web Service Modelling Ontology (WSMO). A.1.2.12 Dublin Core The Dublin Core metadata element set is a standard information resource description. Dublin Core is widely digital materials such as video, sound, image, text, and like web pages. Implementations of Dublin Core typically for cross-domain used to describe composite media make use of XML Page 38 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture and are Resource Description Framework based. Dublin Core is defined by NISO Standard Z39.85-2001. The Dublin Core Metadata Initiative started in 1995 and has developed a schema for describing resources that are less specific than LOM. Dublin Core Metadata Element Set (DCMES) comprises 15 metadata elements: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, and Rights. These 15 original elements have been complemented with new elements. The Dublin Core Metadata Initiative (DCMI) provides means for the definition of semantics, both for a general description core and for subjectspecific extensions. But it is not yet defined how those metadata might be put into a functional architecture. Dublin Core metadata can be expressed in HTML, XML, and RDF. RDF builds on the W3C effort to design an architecture for metadata on the Web. Dublin Core provides the building blocks (common and used by many vendors); RDF is the engineering standard that makes possible to put those blocks together into larger, more expressive metadata structures that will work with one another. Moreover, metadata from other semantic standards expressed also in RDF should be possible build with, too. DCMI works as a vendor-neutral forum and aims to ease the finding of resources in the Web by: • Developing metadata standards for cross-subject resource search and retrieval • Defining frameworks for the interoperability of metadata sets • Developing community specific metadata sets A.1.2.13 SMIL The Synchronized Multimedia Integration Language (SMIL) is an XML-based language that allows authors to write interactive multimedia presentations. Authors can describe the temporal behaviour of a multimedia presentation, associate hyperlinks with media objects and describe the layout of the presentation on a screen. It allows reusing SMIL syntax and semantics in other XML-based languages, in particular those who need to represent timing and synchronization. For example, SMIL components are used for integrating timing into XHTML and into SVG. Authors can make SMIL presentations accessible to people with disabilities by observing the guidelines of WCAG (see later in the document) and creating documents that account for the diverse abilities, tools, and software of all Web users, including people with combinations of visual, Page 39 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture auditory, physical, cognitive, and neurological disabilities. This does not mean creating a great number of separate presentations but rather one integrated and accessible presentation. A.1.2.14 SVG SVG (Scalable Vector Graphics) is a language for describing twodimensional graphics in XML. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. The feature set includes nested transformations, clipping paths, alpha masks, filter effects and template objects. SVG drawings can be interactive and dynamic. Animations can be defined and triggered either declaratively (i.e., by embedding SVG animation elements in SVG content) or via scripting. Sophisticated applications of SVG are possible by use of a supplemental scripting language which accesses the SVG Document Object Model (DOM) that provides complete access to all elements, attributes and properties. A rich set of event handlers such as onmouseover and onclick can be assigned to any SVG graphical object. Because of its compatibility and leveraging of other Web standards, features like scripting can be done on XHTML and SVG elements simultaneously within the same Web page. SVG is a language for rich graphical content. For accessibility reasons, if there is an original source document containing higher-level structure and semantics, it is recommended that the higher-level information be made available , either by making the original source document available, or making an alternative version available in an alternative format which conveys the higher-level information, or by using SVG's facilities to include the higher-level information within the SVG content. A.1.2.15 MathML MathML is a low-level specification for describing mathematics and presenting their semantic meaning . It provides a much needed foundation for the inclusion of mathematical expressions in Web pages. A.1.3 References R. Studer, V.R. Benjamins, D. Fensel. "Knowledge Engineering: Principles and Methods". IEEE Transactions on Data and Knowledge Engineering 25(12),pp 161-197, 1998. Page 40 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture W3C Semantic Web Activity. Available on-line at: http://www.w3.org/2001/sw/. Last check: 23 of January, 2007 Extensible Markup Language (XML). Available on-line at: http://www.w3.org/XML/. Last check: 23 of January, 2007 W3C Document Object Model. Available on-line at: http://www.w3.org/DOM. Last check: 23 of January, 2007 SAX. Available at http://www.saxproject.org/. Last check: 23 of January, 2007 W3C XML Schema. Available on-line at: http://www.w3.org/XML/Schema. Last check: 23 of January, 2007 Resource Description Framework, Wikipedia. Available on-line at: http://en.wikipedia.org/wiki/Resource_Description_Framework. Last check: 23 of January, 2007 DAML+OIL (March 2001). Available on-line at: http://www.daml.org/2001/03/daml+oil-index.html. Last check: 23 of January, 2007 OWL-S: Semantic Markup for Web Services. Available on-line at: http://www.w3.org/Submission/OWL-S/. Last check: 23 of January, 2007 OWL-S 1.0 Release. Available on-line at: http://www.daml.org/services/owl-s/1.0/. Last check: 23 of January, 2007 Dublin Core Metadata Initiative (DCMI). Available on-line at http://dublincore.org/. Last check: 23 of January, 2007 An Introduction to Dublin Core. Available on-line at http://www.xml.com/pub/a/2000/10/25/dublincore/index.html. Last check: 23 of January, 2007 http://www.w3.org/TR/SVG/. SPARQL Query Language for RDF. Available on-line at: http://www.w3.org/TR/rdf-sparql-query/. Last check: 23 of January, 2007 SPARQL. Available on-line at: http://en.wikipedia.org/wiki/SPARQL. Last check: 23 of January, 2007. Page 41 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture A.2 Web services technologies Web services [1] are a new breed of Web applications. A web service is a collection of protocols and standards used for exchanging data between applications or systems. Their main characteristic is that they are selfcontained, self-describing, modular applications that can be published, located, and invoked across the entire Web. Web services are group of technologies that make up the connection between two services. A service is defined as an endpoint of a connection. Why choose a Web Services approach rather than use older more established technologies as CORBA or DCOM? Both CORBA and DCOM are tightly coupled systems and would force a rigidity to the architecture that the EU4ALL design would not be able to enforce. DCOM is proprietary to Microsoft and enforces design choices in ways that web services does not. Further both CORBA and DCOM present firewall problems that Web Services, which most often uses http as the transport protocol do not. A.2.1 Motivation Web services are software programs based on XML technologies [2] that exchanges information with other software via Internet protocols. XML technologies enables Web Services to communicate with other distributed applications written in different languages and platforms to exchange data over a network. Web services can transfer data using HyperText Transfer Protocol (HTTP) [3] and many other protocols too. The key XML based technologies that distinguishes Web Services among other computing models are WSDL [4], UDDI [5] and SOAP[6]. Web services communicate by passing XML messages. Web services descriptions are written in WSDL (Web Services Description Language) which are located in repositories via UDDI (Universal Description, Discovery and Integration repository ) and the communication with other services are made using SOAP (Simple Object Access Protocol). The W3C defines a Web service as a software system designed to support interoperable machine-to-machine interaction over a network. From this perspective Web Services are not necessarily bound to the conventional notion of a web browser. Web browsers can be then seen as a specific instance of a user agent. The web service workflow can be described as follows: 1. Service provider publishes the service to the directory. Page 42 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 2. Service requester looks up in the registry (UDDI directory) to locate services. 3. Registry refers service requester to WSDL. 4. Service requester accesses WSDL file. 5. WSDL provides data to interact with the service. 6. Service requester sends SOAP message request. 7. Web services returns SOAP message response. Illustration 3: Web service architecture Together WSDL, SOAP, and UDDI define a web service. The Web Services architecture consists of the following components: Service Providers, Service Requesters and the Directory. The service provider initially publishes the service to the public directory. The service providers are the owners of the particular service. The service informations need to be published to the directory in order to be used by the service requesters. The service requester queries the UDDI directory to find out the availability of particular service. The UDDI is the directory which provides a WSDL URL in which the service is being defined. The requester then prepares the soap request message according to the information provided in the WSDL file available at the WSDL URL and the soap call is sent to the service which performs the task and sends the response back to the requester. The WSDL Page 43 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture file provides informations such as the input and output parameters for each input and output messages, operation names, port type, binding etc. The figure shows the architecture of Web Services which is depicted as a combination of WSDL, SOAP and UDDI technologies. In general the benefits of Web services can be summarized as follows: • Provide interoperability between different software's running in various platforms. • Provides reusability of services. • Allows easy integration of two or more software applications into one single integrated service thereby reducing integration costs. • Based on industry standards. • Helps to develop applications easily since developers can avoid rewriting certain modules in an application by just calling the web service for that particular functionality. • Has lower integration costs and more flexibility. So Web Services are used e.g. to integrate one or more web applications over the Internet. Web services can be written and called using any languages such as VC++, VB, C#, TCL, Java and Javascript. A.2.2 Standards Standards are established and promoted by several groups that are listed in the references of this annex. The specifications that define Web services are intentionally modular, and as a result there is no one document that defines it. Instead, there are a few "core" specifications that are supplemented by others as the circumstances and choice of technology dictate. Web Services can be roughly grouped in the following categories: • Directory access • Service Description • Messaging and Function Calls • Basic Profile Specifications • Business Process Specifications • Security Specifications • Reliable Messaging Specifications • Transaction Specifications • Publish-subscribe Messaging Specifications Page 44 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • Basic XML Specifications It can be seen from the listings that the term 'Web Services' can be used very loosely to describe anything from a transport mechanism (SOAP and XML) to a descriptive protocol to define and access Web Services (XML and UDDI) to a specific web service. An important attribute to pay attention to in considering the use of any of the Web Services standards is that many of them had been developed to fit a requirement that either was not widely adopted (and only used proprietarily) or evolved into another standard (e.g. proprietarily) RPC [7]). XML is the basis for all exchange and protocol formats of Web Services. The emergence of the World Wide Web and XML have provided interoperability between many systems and applications that are of different operating systems and are written in different languages respectively. This interoperability of XML has lead to the discovery of Web services. XML and XML based SOAP are the backbone of Web Services which is responsible for encoding all the communications to Web Services. The other standards such as SOAP, WSDL and UDDI that are defined next are based on XML. Apart from these three, other standards such as WS-Security, WSDiscovery and WSRF can also be considered. A.2.2.1 SOAP SOAP (Simple Object Access Protocol) can be defined as a collection of XMLbased technologies, which provide an envelope for Web services communication. The widely used soap specification is SOAP v1.2 standard. SOAP also provides a way to make remote procedure calls using http as the underlying protocol. SOAP is a protocol for exchanging XML-based messages normally using HTTP. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on. SOAP provides the communication mechanism between Web Services and applications. SOAP is the most common standard used to deliver Web Services. The purpose of SOAP is to enable data transfer between systems distributed over a network. SOAP is the underlying technology which helps any two applications to communicate by passing soap messages between those two systems. There are two types of soap messages: soap request and soap response. Soap request are messages that requests the service to perform certain task. It contains the particular task name to invoke along with the information needed to perform such task. Then the service extracts the needed information to perform the requested task and returns the result in the form of another message called a soap response. Page 45 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The following Figure depicts the internal structure of a SOAP message. A message consists of a soap header and soap body. The complete soap message is wrapped up using soap envelope. A soap message consists of four XML elements: an envelope, a header, a body and the fault. The envelope is the root element of a message. The envelope wraps the entire message content. The header part is optional which usually provides the name of the call. The body provides the application specific data and data intended for particular recipient. The developer frames the soap request with messages and parameters that need to be send as part of the request. The fault message provides the error messages. These messages are interpreted by soap servers which in turn triggers the Web Services being called. Recent work on the XML schema by the W3C migrates much of SOAP into the XML schema standard [9] which makes SOAP less implementation dependent. Illustration 4: Soap Description A.2.2.2 WSDL Page 46 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The Web Services Description Language (WSDL) is an XML-based service description on how to communicate using any specific web service to allow a client to interact with it. It describes its name, location and the invocation methods available with the input and output parameters. It has slots for the protocol bindings and message formats required to interact with the Web Services listed in its directory. The supported operations and messages are described abstractly, and then bound to a concrete network protocol and message format. WSDL describes the public interface to the web service. WSDL is a language which is used to describe Web Services. This provides all the information needed for a developer to use that service such as its capabilities, input and output parameters, publicly available operations and functions, data type information for all XML messages, communication protocol used to talk to that service, version, port types, location on the web and how to use it. It also provides the technical information which informs the application how to connect and communicate with a particular web service. The WSDL file can be generated by most of Web Services development environments. The WSDL document structure is defined as follows: The definitions element is the root element. This element consists of the following five elements. • Types: element describes the data type used by a service. • Messages: describes the messages passed between the client and that service along with the datatype of parameters in the functions. • Port type: describes the operations that can be performed. Four basic operations supported by WSDL are :one-way, request-response, solicitresponse and notification. • Bindings: define how an operation will actually be transmitted. • Services: specifies port addresses of each binding and location of the service. All the above elements provide the basic information to the service requester about the service and helps them to call the service using any programming language. A.2.2.3 UDDI UDDI is an acronym for Universal Description, Discovery, and Integration, a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet. UDDI is an open industry initiative, sponsored by OASIS [10], enabling businesses to publish service listings and discover Page 47 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture each other and define how the services or software applications interact over the Internet. UDDI is a specification for information registries of Web services. It defines a registry service for Web services and other electronic and non-electronic services. Businesses publish information about themselves and the services they provide to the UDDI registry. It manages information about service providers, service implementations, and service metadata. UDDI provides a way to create directories which are used to search Web Services. UDDI lists the sets of services available within a network. The informations about the services can be kept as either private to be viewed only within the authorized people or can be made public to be viewed by all. Developers publish and locate services using UDDI [11]. Business and company people describe their own services and locate other company services to integrate them into their service. All these technologies help to develop an application package as a service and publish those services on the web. A.2.2.4 WS-Security WS-Security [12] (Web Services Security) is a communication protocol providing a means for applying security to Web Services. This specification describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies. WS-Security also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible (i.e.. support multiple security token formats). For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification. Originally developed by IBM, Microsoft [13], and VeriSign, the protocol is now officially called WSS and developed via committee in Oasis-Open. The protocol contains specifications on how integrity and confidentiality can be enforced on Web Services messaging. A.2.2.5 WS-Discovery Web Services Dynamic Discovery [14] (WS-Discovery) is a technical specification that defines a multicast discovery protocol to locate services on a local network. The WS-Discovery standard was developed by BEA Systems, Canon, Intel, Microsoft, and webMethods Inc. A.2.2.6 WSRF Page 48 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Web Service Resource Framework [15] (WSRF) provides a set of operations that Web Services may implement to become stateful, i.e. web service clients communicate with resource services that allow data to be stored and retrieved. A.2.3 References [1] Web Services Available on-line at: http://www.w3.org/2002/ws/. Last check: 12.1. 2007 [2] Extensible Markup Language (XML) 1.1 (Second Edition) Available online at:http://www.w3.org/TR/xml11/. Last check: 12.1. 2007 [3] Hypertext Transfer Protocol -- HTTP/1.1 Available on-line at: http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf. Last check: 12.1. 2007 [4] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language Available on-line at: http://www.w3.org/TR/wsdl20/. Last check: 12.1. 2007 [5] OASIS - Committees - OASIS UDDI Specifications TC Available on-line at: http://www.oasis-open.org/committees/uddispec/doc/tcspecs.htm#uddiv3. Last check: 12.1. 2007 [6] SOAP Version 1.2 Part 1: Messaging Framework Available on-line at: http://www.w3.org/TR/soap12-part1/. Last check: 12.1. 2007 [7] XML-RPC Home Page Available on-line at: http://www.xmlrpc.com/. Last check: 12.1. 2007 [8] XML Schema Part 1: Structures Second Edition Available on-line at: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html Last check: 12.1. 2007 and XML Schema Part 2: Datatypes Second Edition Available on-line at: http://www.w3.org/TR/2004/REC-xmlschema-220041028/datatypes.html. Last check: 12.1. 2007 [9] XML Protocol Working Group Available on-line at: http://www.w3.org/2000/xp/Group/. Last check: 12.1. 2007 [10] OASIS Standards and Other Approved Work Available on-line at: http://www.oasis-open.org/specs/index.php Last check: 12.1. 2007 [11] UDDI Version 3.0.2 Available on-line at: http://www.oasisopen.org/committees/uddi-spec/doc/spec/v3/uddi-v3.0.2-20041019.htm. Last check: 12.1. 2007 Page 49 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture [12] Web Services Security: SOAP Message Security 1.1 (WS-Security 2004) Available on-line at: http://www.oasisopen.org/committees/download.php/16790/wss-v1.1-spec-osSOAPMessageSecurity.pdf. Last check: 12.1. 2007 [13] Web Services and Other Distributed Technologies Developer Center: Web Services Specifications Available on-line at: http://msdn.microsoft.com/webservices/webservices/understanding/specs/ default.aspx. Last check: 12.1. 2007 [14] Web Services Dynamic Discovery (WS-Discovery) Available on-line at: http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf. Last check: 12.1. 2007 [15] Web Services Resource 1.2 2 (WS-Resource) Available on-line at: http://docs.oasis-open.org/wsrf/wsrf-ws_resource-1.2-spec-os.pdf. Last check: 12.1. 2007 Page 50 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture A.3 Open Communication Protocols A.3.1 Motivation A communications protocol is the set of standard rules for data representation, signalling, authentication and error detection required to send information over a communications channel. The communication protocols for digital computer network communication have many features intended to ensure reliable interchange of data over an imperfect communication channel. Communication protocol is basically following certain rules so that the system works properly. A.3.2 Standards A.3.2.1 WebDav WebDAV stands for Web-based Distributed Authoring and Versioning. It's an extension to HTTP protocol which allows users to collaboratively edit and manage files on remote web servers. WebDAV is a working group of IETF and is described in the RFC 2518 (February 1999). WebDAV provides functionality to create, change and move documents on a remote server (typically a web server or "web share"). It can also be used for general web-based file storage that can be accessed from anywhere. Important features in WebDAV protocol include locking (overwrite prevention), properties (creation, removal, and querying of information about author, modified date, etc.), name space management (ability to copy and move Web pages within a server's namespace) and collections (creation, removal, and listing of resources). Most modern operating systems provide built-in support for WebDAV. A.3.2.2 SRU/SRW SRU (Search/Retrieve via URL) is a standard search protocol for Internet search queries, utilizing CQL (Common Query Language), a standard query syntax for representing queries. CQL is a formal language for representing queries to information retrieval systems such as web indexes, bibliographic catalogues and museum collection information. The design objective is that queries be human readable and writeable, and that the language be intuitive while maintaining the expressiveness of more complex languages. SRW (Search/Retrieve Web Service) is a variation of SRU. Messages are conveyed from client to server, not by a URL, but instead using XML over Page 51 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture HTTP via SOAP which specifies how to wrap an XML message within an XML envelope. The SRW specification tries to adhere to the Web Services Interoperability recommendations. A.3.2.3 RPC Remote procedure call (RPC) is a protocol that allows a computer program running on one computer to cause a subroutine in another address space, commonly on another computer, to be executed without the programmer explicitly coding the details for this interaction. XML-RPC is a specification and a set of implementations that allow remote procedure calls over the Internet among software running on disparate operating systems and running in different environments. It's remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned. A.3.2.4 IIOP Internet Inter-ORB Protocol, a protocol developed by the Object Management Group (OMG) to implement CORBA solutions over the World Wide Web. IIOP enables browsers and servers to exchange integers, arrays, and more complex objects, unlike HTTP, which only supports transmission of text. GIOP (General Inter-ORB Protocol) is the abstract protocol by which Object request brokers (ORBs) communicate. Standards associated with the protocol are maintained by the Object Management Group (OMG). IIOP (Internet Inter-Orb Protocol) is the implementation of GIOP for TCP/IP. It is a concrete realization of the abstract GIOP definitions. IIOP makes it possible for distributed programs written in different programming languages to communicate over the Internet. A.3.2.5 FIPA-ACL The Foundation for Intelligent Physical Agents (FIPA) is an international organization that is dedicated to promoting the use of intelligent agents by openly developing specifications supporting interoperability among agents and agent-based applications. Page 52 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture FIPA Agent Communication specifications deal with Agent Communication Language (ACL) messages, message exchange interaction protocols, speech act theory-based communicative acts and content language representations. It standardizes the form of a FIPA-compliant ACL message to ensure interoperability by providing a standard set of ACL message structure, and to provide a well-defined process for maintaining this set. The model of agent communication in FIPA is based on the assumption that two agents, who wish to converse, share a common ontology for the domain of discourse. It ensures that the agents ascribe the same meaning to the symbols used in the message. For a given domain, designers may decide to use ontologies that are explicit, declaratively represented (and stored somewhere) or, alternatively, ontologies that are implicitly encoded with the actual software implementation of the agent themselves and thus are not formally published to an ontology service. This FIPA specification deals with technologies enabling agents to manage explicit, declaratively represented ontologies. An ontology service for a community of agents is specified for this purpose. It is required that the service be provided by a dedicated agent, called an Ontology Agent (OA), whose role in the community is to provide some or all of the following services: • Discovery of public ontologies in order to access them, • Maintain (for example, register with the DF, upload, download, and modify) a set of public ontologies, • Translate expressions between different ontologies and/or different content languages, • Respond to queries for relationships between terms or between ontologies, and, • Facilitate the identification of a shared ontology for communication between two agents. This specification deals only with the communicative interface to such a service while internal implementation and capabilities are left to developers. It is not mandated that every OA be able to execute all those tasks (for example, translation between ontologies, and identification of a shared ontology are in general very difficult and not always possible to realize), but every OA must be able to participate into a communication about these tasks (possibly responding that it is not able to execute the translation task). The interface is specified at the agent communication level as opposed to a computational API. Therefore, the specification defines the interaction protocols, the communicative acts and, in general, the vocabulary that agents must adopt when using this service. Page 53 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture This specification enables developers to build: • Agents that access such a service, • Agents that provide it, and, • Agents able to communication. negotiate at run-time a shared ontology for The application of this specification does not prevent the existence of agents that, for a given domain, use ontologies implicitly encoded with the implementation of the agents themselves. In these cases full agent communication and understanding can still be obtained, however the services provided by the OA cannot apply to implicit encoded ontologies. In order to promote interoperability, if one OA exists, then it must comply with this specification. And, if the services here described are required by a specific agent platform implementation, then they must be implemented in compliance with this specification. In order to keep the applicability of the specification as unrestricted as possible, the approach used is platform independent. In particular, this specification does not mandate the storage format of ontologies but only the way agents access an ontology service. However, in order to specify the service, an explicit representation formalism has been specified. It is the FIPA-Meta-Ontology that allows communication of knowledge between agents. As far as possible, care has been taken to integrate existing formalisms, such as Open Knowledge Base Connectivity and RDF. A.3.2.6 ICE The Internet Communications Engine (Ice) is a modern alternative to object middleware such as CORBA™ or COM/DCOM/COM+, with support for C++, C#, Java, Python, Ruby, PHP, and Visual Basic. Ice is easy to learn, yet provides a powerful network infrastructure for demanding technical applications. Ice shines where technologies such a SOAP or XML-RPC are too slow, or do not provide sufficient scalability or security. Ice is free software, available with full source, and released under the terms of GNU General Public License (GPL). A.3.2.7 REST Representational State Transfer (REST) is a software architectural style for distributed hypermedia systems like the world wide web. The term originated in a 2000 doctoral dissertation about the web written by Roy Fielding, one of the principal authors of the HTTP protocol specification, and has quickly passed into widespread use in the networking community. Page 54 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture REST strictly refers to a collection of architectural principles (described below). The term is also often used in a loose sense to describe any simple interface that transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies. These two meanings can conflict as well as overlap. It is possible to design any large software system in accordance with Fielding's REST architectural style without using the HTTP protocol and without interacting with the world wide web. It is also possible to design simple XML+HTTP interfaces that do not conform to REST principles, and instead follow a Remote Procedure Call (RPC) model. The two different uses of the term REST cause some confusion in technical discussions. A.3.3 References WebDAV. Available at: http://www.ietf.org/rfc/rfc2518.txt. Last check: Jan. 4, 2007 SRU. Available at: http://www.loc.gov/standards/sru/. Last check: Jan. 4, 2007 SRW. Available at: http://www.loc.gov/standards/sru/srw/. Last check: Jan. 4, 2007 ICE. Available at: http://www.zeroc.com/. Last check: Jan. 4, 2007 FIPA. Available at: check: Jan. 4, 2007 http://www.fipa.org/repository/aclspecs.html. Last Ontoliguna. Available at: http://ontolingua.stanford.edu/okbc/. Last check: Jan. 4, 2007 Page 55 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture A.4 Frameworks, Open Architectures, and Reference Architectures An open architecture is an architecture whose specifications are public. This includes officially approved standards as well as privately designed architectures whose specifications are made public by the designers. The opposite of open is closed or proprietary. A.4.1 Motivation Open architectures do normally provide some combination of interoperability, portability, and open software standards. It allows adding, upgrading and swapping components. Open architecture allows potential users to see inside all or parts of the architecture without any proprietary constraints. Typically, an open architecture publishes all or parts of its architecture that the developer or integrator wants to share. A.4.2 Frameworks and architectures Here we describe four cases of framework and architectures: SOA, OGSA, SCA and U.S. Navy Open Architecture. A.4.2.1 SOA Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of loosely coupled software services to support the requirements of the business processes and software users. In an SOA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation. A service-oriented architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including REST, RPC, DCOM, CORBA or Web Services. The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the Page 56 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture service consumer and service provider. A service provider can also be a service consumer. Illustration 5: SOA Description The key is that independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having pre-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks. Frameworks related to SOA world include: • ESB: Enterprise Service Bus: An ESB is software infrastructure that simplifies the integration and flexible reuse of business components. ESB does not implement a service-orientated architecture (SOA) but provides the features with which one may be implemented. Although a common belief, ESB is not web-services based. ESB should be standards-based and flexible, supporting many transport mediums. • JBI: Java Business Integration is a specification developed under the Java Community Process (JCP) for an approach to implementing a service-oriented architecture (SOA). The JCP reference is JSR 208. JBI is built on a Web Services model, and provides a pluggable architecture for a container that hosts service producer and consumer components. Services connect to the container via binding components or can be hosted inside the container as part of a service engine. The services model used is WSDL 2.0. A.4.2.2 OGSA Grid computing is a computing model that provides the ability to perform higher throughput computing by taking advantage of many networked computers to model a virtual computer architecture that is able to distribute process execution across a parallel infrastructure. Grids use the resources of many separate computers connected by a network (usually the Internet) to solve large-scale computation problems. Grids provide the ability to perform computations on large data sets, by breaking them down into many smaller ones, or provide the ability to perform many more computations at once Page 57 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture than would be possible on a single computer, by modelling a parallel division of the work between processes. The Open Grid Services Architecture (OGSA) represents an evolution towards a Grid system architecture based on Web services concepts and technologies. Since the release of the Globus Toolkit 3.0, the Globus Project offers an open source collection of Grid services that follow OGSA architectural principles. The Globus Toolkit also offers a development environment for producing new Grid services that follow OGSA principles. OGSA is a product of the Grid community at large, and it has a major focal point in the Global Grid Forum. Members of the Globus Alliance have made significant contributions to the development of OGSA. A.4.2.3 SCA The Software Communications Architecture (SCA) is an open architecture framework that tells designers how elements of hardware and software are to operate in harmony within a software defined radio. SCA is a key element in the U.S. military's Joint Tactical Radio System (JTRS). It governs the structure and operation of the JTRS, enabling programmable radios to load waveforms, run applications, and be networked into an integrated system. A Core Framework, providing a standard operating environment, must be implemented on every hardware set. Interoperability among radio sets is enhanced because the same waveform software can be easily ported to all radio sets. It is a complex specification with several different interfaces The Object Management Group (OMG), a not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications, has established a Domain Special Interest Group for software radios (SWRADIO DSIG). This group, along with the Software Defined Radio Forum (SDRF), is working toward building an international commercial standard based on the SCA. A.4.2.4 U.S. Navy Open Architecture The Navy OA is a systems design approach supported by verifiable governmental testing platforms, such as the OACE, that seeks to implement open specifications for interfaces, services and supporting formats. It enables software components to work across a range of systems and interoperate with other software components on local and remote systems. The Navy OA promotes interaction between designers, suppliers and end users that facilitates portability. Through OA, common standards and products are employed in the areas of frameworks, middleware, resource management and operating systems, utilizing established and evolving industry standards. Page 58 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture OACE is a compatible set of largely standards-based COTS computing infrastructure components (hardware and software) that provides the computational framework upon which tactical and support applications are built under the guidelines of OA. The scope of OACE includes technical architecture, standards and products. A.4.3 References Service orientation. Available at: http://www.serviceorientation.org/p0.asp OASIS Reference Model. Available at: http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=soa-rm SOA Reference Model Definition. Available at: http://www.servicearchitecture.com/web-services/articles/serviceoriented_architecture_soa_definition.html OAC: Available at: http://www.nswc.navy.mil/wwwDL/B/OACE/ Page 59 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture A.5 Device Modelling Device modelling is a technique that abstracts the pertinent qualities of computer devices with the aim of allowing interaction with them to be appropriately tailored to their requirements and capabilities. An example would be modelling a PDA device so that an applications UI would be scaled and designed for the devices 320 X 240 screen size. A.5.1 Motivation By modelling devices and developing systems that use the modelling information in self-configuration, a single application could be seamlessly deployed on many different platforms. A.5.2 Specifications A.5.2.1 CC/PP Composite Capabilities/Preferences Profiles (CC/PP) is a way to specify what exactly a user agent is capable of doing. An example of a user agent are web browsers. A CC/PP profile is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device. CC/PP is designed to be a format that, as part of a framework for content adaptation and contextualization can describe the capabilities of a user agent and preferences of its user. CC/PP is based on the Resource Description Framework (RDF), which was designed by the W3C as a general purpose metadata description language. RDF provides the framework with the basic tools for both vocabulary extensibility and interoperability. RDF was designed to describe the metadata or machine understandable properties of the Web, and as such, RDF is a natural choice for the CC/PP framework since user agent profiles are metadata intended primarily for communication between user agents and resource data providers. A CC/PP profile contains a number of CC/PP attribute names and associated values that are used by a server to determine the most appropriate form of a resource to deliver to a client. A set of CC/PP attribute names, permissible values and associated meanings constitute a CC/PP vocabulary. A.5.2.2 URC, URCC, V2 Another approach to model devices is the family of URC (Universal Remote Console), URCC (Universal Remote Console Communication Protocol) and Page 60 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture V2. Under the URC approach, a manufacturer of a device or service (called "the target", for short), which a user wishes to access, need not devise different UIs for the many types of access devices and users. Instead, the target manufacturer need only supply the "user interface needs" of their product in the standard form. The user brings their own appropriate UI binding with them which may employ graphical user interfaces, voice interfaces, Braille-based interfaces, switch-based input methods, etc., or any combination of these. Common examples of the remote console would be a mobile device like a PDA or cell phone, a home or office computer, or ultimately an inconspicuous wearable computer. For people with disabilities, though, it could also be a special adaptive device such as a note-taker (a pioneering form of PDA) or laptop with a Braille display. Historically the URC initiative became the URCC protocol and has become a standard developed by the V2 Technical Committee of ANSI/INCITS. Many of the participants in the V2 process are associated with universal accessibility and assistive technology. A.5.2.3 OMA Another approach to device independence is OMA Device Management. The Open Mobile Alliance (OMA) has 350 members; mostly information technology companies and service providers brought together with the goal of producing open standards based small device management systems. OMA is primarily focused on remote maintenance, diagnostics and software installation and upgrading with the goal of improving the interoperability between devices and servers with the latest specification. A.5.2.4 Vocabularies There are several vocabularies (e.g. UAProf, IETF Media Feature Registration (plus WAV, MPEG, TIFF), IRIS device Profile) developed that have been based on the above technologies. The User Agent Profile (UAProf) specification is concerned with capturing capability and preference information for wireless devices. This information can be used by content providers to produce content in an appropriate format for the specific device. UAProf is related to the Composite Capabilities/Preference Profiles Specification created by the World Wide Web Consortium. UAProf is based on RDF. A UAProf file describing the capabilities of a cell phone might include Vendor, Model, Screensize, Multimedia Capabilities, and Character Set. IETF media features allow browsers to do client-side configuration of websites by selecting the appropriate feature set from a number of possible display options that a web page and its associated CSS media dependencies. The IRIS device profile, developed by the FIT team, assists in the design and server side configuration of websites using CC/PP. A.5.3 References Page 61 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Composite Capabilities/Preferences Profile Public Home Page Available online at: http://www.w3.org/Mobile/CCPP/CC/PP. Last Check: 16 January 2007 myurc.org - white paperV2 Page Available on-line at:http://myurc.org/whitepaper.php. Last Check: 16 January 2007 OMA home Page Available on-line at: http://www.openmobilealliance.org/. Last Check: 16 January 2007 WAG UAProf Page Available on-line at: http://www.openmobilealliance.org/tech/affiliates/wap/wap-248-uaprof20011020-a.pdf. Last Check: 16 January 2007 Media types Page Available on-line at: http://www.w3.org/TR/RECCSS2/media.html. Last Check: 16 January 2007 Page 62 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Annex B Educational Technology Standards and Technologies Page 63 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture B.1 Educational Technology standards B.1.1 Motivation Educational technology standards describe the structure and content of digital educational materials and sometimes processes. Standards facilitate the platform-independent management/delivery of learning materials and activities to learners and management of enterprise related data. B.1.2 Standards B.1.2.1 SCORM An abbreviation for Sharable Content Object Reference Model. SCORM is a standard originating from Advanced Distributed Learning (ADL), which is a division of the US Department of Defence. SCORM is a standard that allows ‘learning objects’ (called SCOs, or Sharable Content Objects) to be ‘played’ within different learning management systems. It is widely implemented by VLE system vendors. It has two main parts (1) a content aggregation model and, (2) a run time environment. The content aggregation model describes how digital learning resources should be stored within a larger unit (SCO). The run-time interface provides an API to allow a unit of learning to communicate with the system that is presenting it, allowing individual learning sessions to be customised dynamically according to the user that is using it. SCORM uses the IMS Content Packaging specification as a part of the content aggregation model. The latest version is SCORM 2004 3rd edition. B.1.2.2 IMS All IMS specifications are obtainable from the relevant specifications section from the IMS Global website1. It should be noted that all IMS specifications are currently undergoing an accessibility review, the results of which are expected to be available early in 2007 and that some authors of this document are conducting this review. B.1.2.2.1 Learning Design (LD) 1http://www.imsglobal.org Page 64 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The Learning Design specification originated from the Open University of the Netherlands (OUNL) from an earlier initiative called EML, an abbreviation for Educational Modelling Language. IMS Learning Design, or simply IMS LD, (IMS, 2003) is a specification focused on modelling lesson plans and courses, and making them available online as Units of Learning (UoL) (Burgos and Griffins, 2006). A wide variety of pedagogical models can be represented by IMS LD, enabling teacher to adapt their resources and learning scenarios to virtual lessons in a flexible way. Far from only sequencing activities or using repositories of learning objects, IMS LD provides several features to create adaptive, dynamic and personalized learning (Burgos et al, 2005; Koper and Burgos, 2005). Through this description of different roles, activities, environments, methods, properties, conditions and notifications, IMS LD can be used to transform lesson plans into formally specified Units of Learning (UoL). Thus the specification is a flexible way of representing and encoding learning scenarios for multiple or individual learners. It may help to think of it as a way of creating interoperable lesson plans which can be read by an application called a player. The player can take on responsibility for coordinating the learners, teachers, learning resources and activities as the learning process goes forward (Burgos et al, 2005a). Learning Design does not offer a particular pedagogic model or models, but can rather be used to define a practically unlimited range of scenarios and pedagogic models. Because of this it is often referred to as a pedagogic meta-model. Some previous e-learning initiatives have claimed to be pedagogically neutral. Learning Design does not aim for pedagogic neutrality, but seeks to enable pedagogically aware e-learning. There are several toolsets that work with IMS Learning Design including LAMS Learning Activity Management System and Coppercore .2 B.1.2.2.2 Simple Sequencing Simple Sequencing enables a resource designer to describe a path that a learner could follow through a unit of learning. This is achieved by the creation of branching rules that can be used to influence the users experience in response to user actions. Although on the surface Simple Sequencing may resemble the idea behind the learning design specification, there are significant differences between the two specifications. Simple Sequencing applies to a single unit of educational resources which can be used by a single learner at any one time. Learning Design, on the other 2 See: http://www.lamsinternational.com/ and http://coppercore.sourceforge.net/ for more detail. Page 65 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture hand, can be applied to different learning resources and can apply to many different users. B.1.2.2.3 Content Packaging (CP) Content Packaging is a way to aggregate digital resources together in one or more structures to create a composite digital resource. A content package contains a description of resources and (optionally) a structural description of how those resources can be related. It has often been used as an intermediate format for bundling learning resources for transfer between different learning management systems. Content Packaging also allows additional descriptive information (metadata) to be added to individual resources, or the package as a whole. The metadata can facilitate the storage of resources in a repository and allow educators to search for learning material that suits their particular needs. Current released version is 1.1.4. Version 1.2 is in preparation and is expected to be released simultaneously as an IEEE LTSC standard between 12 months and 2 years from January 2007. To support personalisation of content for accessibility and other purposes Content Packaging 1.2 includes a mechanism whereby a resource can have associated alternative resources. B.1.2.2.4 Metadata (MD) Also known as IEEE LOM (Learning Object Metadata), the IMS Metadata specification provides a way to attach a set of descriptive data to a digital resource. The data can include a comprehensible title, description, a set of appropriate keywords and classification under formal taxonomies, such as dewey decimal or library of congress. LOM also supports the specification of concurrent descriptions of resources using different languages. Instances are tree-structured XML. B.1.2.2.5 Learner Information Package (LIP) The LIP data structure provides a way to exchange information about a learner between different systems, such as a learning management system or an institutional-wide enterprise system. The IMS LIP is a very large structure and although modularised it has been argued that it is somewhat monolithic. It has varying support in Europe and it could be argued that smaller interoperable structures are needed. It has eleven data sections, including user activities, affiliations, interests, qualifications, certifications and competencies. B.1.2.2.6 Access For ALL: ACCLIP and ACCMD Learner Information Package Accessibility for LIP (ACCLIP) stores information about the needs and preferences of a learner for how they Page 66 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture might interact with the computer environment. These are functional preferences and requirements not medical information. This information can be used by a computer system such as a LMS or a VLE to meet the needs of disabled learners by selecting content containing appropriate modalities, transforming content appropriate to the individual and tailoring the interface to meet individual student’s needs. The current publicly available version of ACCLIP (which is out of step with the ISO Individualized Adaptability work) has a binding that is closely tied to LIP but which allows ACCLIP to be used with LIP or standalone. IMS AccessForAll Meta-data Specification (ACCMD) specification (and its development in ISO, see below) is a schema for Metadata terms for the description of accessibility properties of content so that content may be located, selected and transformed to match an ACCLIP instance. The model is asymetrical in that it offers ways to describe properties of “original” resources and properties of adaptations to those resources (alternatives). It also contains a way to reference statements that are the outputs of accessibility and analysis repair tools (in the evaluation and report language). Adaptations and the resources that they are for are identified and related using URI’s [This mechanism may not be adequate and relating resources and parts this way needs careful consideration]. In the later ISO work the asymmetry is removed and parts of the structure re-modelled. B.1.2.2.7 Guidelines for Developing Accessible Learning Applications This specification provides advice for the developers of educational technology systems by presenting important issues regarding a number of accessibility topics. Key guidelines concern: • Delivery of text, images and multimedia • Development of synchronous and asynchronous communication and collaboration tools • Development of accessible interfaces and environments • Testing and assessment • Development of content authoring tools In some respects this work resembles the spirit of the WCAG work carried out by W3C, but highlights points in a form that may be more easily understood to developers who are developing learning applications and using the IMS specifications. Page 67 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture B.1.2.2.8 Reusable Definition of Competency or Educational Objective Specification The IMS RDCEO has been adopted as the basis for an IEEE standard. See the section of this document that describes IEEE Learning Technology Standards Committee standards. B.1.2.2.9 Digital Repositories Specification The IMS DRI specifications describes how repository systems can share metadata. More information is given in the following sections that describe Metadata Repositories. B.1.2.2.10 Enterprise and Enterprise Services The Enterprise specifications are concerned with how learner information may be shared between learner management systems and other systems, such as Human Resource (HR), student administration (course scheduling), training administration and library management systems. The IMS Enterprise data structure describes items such as Person (student name and contact details), Group and Membership details. The Enterprise Services specification describes how this data may be transferred between different systems using web service interfaces. B.1.2.2.11 Resource List Interoperability A resources list is a collection of external items that can be used by a student during a period of study. An example of a resource list can be a reading list. The IMS RLI specification describes how a resources list can be represented using XML. B.1.2.2.12 Sharable State Persistence The IMS SSP specification represents a way to transfer data from a learning environment to a content object. By using a learning environment as a medium it is possible to transfer state data between independent learning resources. SSP is considered to be an extension to the existing SCORM runtime API. It is understood to remedy the need to store ‘arbitrarily complex’ data structures to facilitate the use of learning objects (or SCOs, Sharable Content Objects) that may require complex data. For more information about how SSP can be used, please refer to the SCORM section Annex C Page 68 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture C.1.1.1.1 Tools Interoperability Guidelines The Tools Interoperability Guidelines specifies a protocol and method for launching separate learner tools within a Learning Management System (LMS). It is currently under revision to address some reported weaknesses and at the same time the integration of IMS AccessForAll work with it is being tackled. C.1.1.1.2 Vocabularies Definition Exchange The Vocabularies Definition Exchange (VDEX) specification gives a portable way to describe definitions of vocabulary value spaces. In its simplest form, VDEX can represent a set of glossary terms that are relevant to a particular course of study. VDEX also has the capability to represent terms in a hierarchical structure, allowing simple relationships to be expressed. C.1.1.1.3 Question and Test Interoperability (QTI) QTI is an abbreviation for Question and Test Interoperability. The central basis of QTI is an XML data structure called an “item” that is used to describe a simple computer-based assessment question. QTI describes a number of question types, including true/false, matching, multiple-choice, multiple-answer and so on. Items can be assembled into sections, assessments and there are mechanisms for outcome processing and results reporting. The major use case is the support of transfer of item banks across learning and assessment delivery systems. QTI has not addressed accessibility of assessment in depth but some of the mechanisms used in some versions of the QTI specification could be used to facilitate the development of accessible assessments. Assessment presents interesting challenges for accessibility due to the problem of understanding the effect that individual accommodations (adaptations) for users affect the validity of assessments. Such issues have not to date been effectively addressed elsewhere and it may be sensible to put the topic of assessment out of scope for EU4ALL. C.1.1.1.4 IMS ePorfolio An IMS ePortfolio is a collection of digital resources that is assembled by a user as evidence to indicate engagement with learning resources, indicating a record of achievement. The IMS specification is designed to allow the movement of ePortfolio records between institutions and organisations. Three kinds of data entity are involved: • Data about identity (largely drawn from IMS LIP) Page 69 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • Products of learning (such as learner-authored objects) • Assessment products – such as reflections, assertions and grades ePortfolio content production and consumption (authoring and “reading”) is essentially many to many, which probably places large demands on accessibility of authoring tools and interoperability/usability/accessibility of output media for persons with different accessibility requirements. The ePortfolio specification provides a way to package portfolios using IMS CP by packaging objects and relations between them. Development of ePortfolio space may not be mature, as is shown by their being several splinter developments such as UK LEAP 1.0 (some overlap with IMS ePortfolio but not exact, currently (Jan 2007) a LEAP 2.0 is being discussed) and work in the Europortfolio Consortium (http://www.eifel.org/about/europortfolio) which views a portfolio as an aggregation of services and content. C.1.1.1.5 IMS – Current Activities At time of writing various groups in IMS were engaged in the development activities. These are listed below (taken from IMS public information). It should be noted that these activities are very young and that therefore they should be taken as indications of potential direction rather than as permanent perspectives. • Common Cartridge: An integrated profile of some existing IMS specifications (so they work together in this case) to better support some specific content publishing business use cases • Tools Interoperability V2.0: Working on a revision to address limitations in Tools Operability 1.0 and incorportate requirements of AccessForAll • Enterprise Services: Chartering a major revision • Service-Oriented Architecture: A special interest group that focuses on taking a new look at services around business cases in Higher Education Enterprise • Federated Architectures: A special interest group • Question and Test: Version 2.1 is in draft. This better addresses results reporting and assessment sections than 2.0 • Content Packaging 1.2: Being prepared as an IEEE standard for simultaneous release in IEEE and IMS. • Accessibility: Currently undertaking an accessibility review of all IMS specifications, chartering change requests to the AccessForAll work made by ISO and investigating the incorporation of AccessForAll in Rich Media and the other developing IMS work Page 70 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture C.1.1.2 ETSI The activities of European Telecommunication Standards Institute (ETSI) primarily concern telecommunications although some ETSI publications specifically address accessibility and are therefore applicable to EU4ALL. The following documents, presented in numerical order, can be downloaded from the ETSI website (see references). Although the documents labelled EG are guides rather than standards they represent useful bodies of work that complement other publications that have been described within this document. Particular attention should be given to the final document, which contains a review of accessibility related standards. C.1.1.2.1 ETSI EG 202 048 The guidelines on the multimodality of icons, symbols and pictograms explore the use of icons, symbols and pictograms in multimodal interfaces. Special emphasis is given towards accessibility and a clear reference is made to the idea of ‘design for all’. The guidelines are intended to cover all forms of ICT usage and will study the presentation of navigation aids in different perception modalities (audio/visual/haptic). C.1.1.2.2 ETSI EG 202 191 The Multimodal interaction, communication and navigation guidelines explore multimodal interaction and communication from an accessibility perspective. It identifies how simplifications, translations, sensory transpositions (or adaptations) can be used to enhance access to ICT systems. C.1.1.2.3 ETSI SR 001 996 The ETSI Special Report (SR) on An annotated bibliography of documents dealing with Human Factors and disability is a comprehensive review of human factors and disability standards published by ETSI, ISO/IEC and ITUT. It should be noted that only a small number of documents are directly appropriate. This bibliography is included here for completeness. C.1.1.2.4 Other documents As detailed within the bibliography ETSI also publish documents that describe guidelines for the accessibility of telephony equipment. Two notable projects are currently underway. The first explores the standardisation of accessible transport information. The second is entitled ‘access symbols for use with video content and ICT devices’. The objective Page 71 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture of this second project is to produce an ETSI Standard (ES) that specifies families of symbols that denote the availability of services for use with video content and ICT devices. C.1.1.3 ITU The International Telecommunication Union (ITU-T), the standardization section of International Telecommunication Union, operates an Accessibility and Standardization special project within a study group. One of the activities of the project is to ensure that outputs from the ITU-T are applicable to the widest possible audience. Like ETSI, ITU also publishes guidelines alongside technical documents that describe telecommunication systems. ITU-T presents the concept of the ‘total conversation’. This is a published standard that describes a communication system that provides bi-directional real-time transfer of video, text and voice between users. The ITU-T studies are directed by ‘questions’. Question 26/16, for example, explores the ‘accessibility to multimedia systems and Services’. One area of study includes the ‘specification of interfaces on communication equipment to allow various forms of user interface equipment to be attached in order to enable session and device control and media handling by people with varying capabilities and preferences’. Although the specifications presented by ITU-T are not directly relevant to the operation of CBT systems, the availability and usability of generalpurpose communication systems is considered to be a very important issue. They are important because all students will have a requirement to interact with educational institutions. Furthermore, we are undoubtedly going to witness further integration between the telephone and personal computer. C.1.1.4 IEEE LTSC The IEEE Learning Technology Standard Committee (LTSC) is an international body open to membership from any organisation or individual on payment of a nominal membership fee. Its processes are open and follow a democratic governance style. It has produced several important standards. C.1.1.4.1 LOM The IEEE Learning Objects Metadata is an important Metadata specification, with significant adoption in Europe, particularly UK Higher Education. It is a central part of many Joint Information Systems Committee (JISC) projects. LOM describes Metadata that can be associated with learning resources to give a mostly educational perspective. There is a conceptual data model Page 72 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture that describes the structure of an instance and an XSD binding. The model is a hierarchical XML tree. C.1.1.4.2 CMI IEEE Computer Managed Instruction (CMI). The acronym CMI is overloaded. The CMI is about exchange of information between a learning content object, for example a SCORM Shareable Content Object (SCO) and a Learning Management System (LMS) that manages the run time for the object and interfaces with other systems such as back-end enterprise components. It consists of a data model, an API (ECMA-Script) and an XML binding that represents a mapping of the data model to XML (not used in SCORM). The term CMI is often used to refer to both the data model and the API or just the data model itself. There are many technical issues with the CMI but it is widely implemented in learning systems. C.1.1.4.3 DREL A group is working within LTSC gathering requirements for digital rights expression languages. Current status of this group is not clear. See later section on Digital Rights Management. C.1.1.4.4 RCD This description of the status of the IEEE Reusable Competency Definition (RCD) standard was supplied by the chair of the IEEE Reusable Competency Definitions (P1484.20.1) working group Claude Ostyn, in an email to the authors. “The Reusable Competency Definition (RCD) standard originated as an IEEE LTSC project (P1484.20). The spec was passed on to IMS for development into a spec. IMS published it as the IMS Reusable Definition of Competency or Educational Objective (RDCEO) specification set, including an XML binding, and after very long discussions on IPR issues the IEEE LTSC working group took it on again to develop the de jure standard for the Data Model for Reusable Competency Definitions (IEEE project P1484.20.1). The draft for this standard is in the final IEEE balloting stage. The IEEE standard draft does not include the XML binding but is intended to allow data instances that conform to the RDCEO specification to also conform to the IEEE standard. The XML RDCEO XML binding is also compatible with the IEEE standard draft. Various stakeholders have indicated that they intended to propose a future standard for an XML binding. That binding is likely to be different than the IMS XML binding because it would be based on XML best practices that differ from the IMS approach.” – Claude Ostyn, email to Andy Heath, 19.1.07. Page 73 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture C.1.1.4.5 RAMlet IEEE LTSC Resource Aggregation Model for Learning, Education and Training (RAMlet) is a grid of ontologies for the mapping of aggregation formats (e.g. media) to other aggregation formats. The work is not yet published and has a long way to go, but has currently tackled IMS Content Packaging and METS and is looking at MPEG 21 and ATOM. C.1.1.5 ISO IEC JTC1 This overarching committee has a number of sub-committees, two of which have relevance here. C.1.1.5.1 ISO IEC JTC1 SC36 The Information Technology for Learning, Education and Training committee has 7 sub-groups working in the area. Those groups and the areas in which they are working are listed below. All of the groups are very active and it is likely there will be several very good international standards emerge over the next couple of years. The secretariat has currently been taken over by the UK and IT systems are process of handover and at time of writing availability of public information on detail the work of some of the groups is in flux. WG1: Vocabulary WG2: Collaborative Technology WG3: Participant Performance WG4: Metadata for Learning Resources WG5: Quality assurance and descriptive frameworks WG6: International standardized profiles (ISP) WG7: Culture, language and human-functioning activities Individualized Adaptability Education and Training and Accessibility in e-Learning, Individualized Adaptability and Accessibility in e-Learning, Education and Training is an ISO standard in final stages of preparation. It is derived from Page 74 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture the IMS AccessForAll work. The asymmetry of the model in the part of the work that relates to IMS ACCMD is removed and some of the structure changed and flattened so that it is more in the style of a set of definitions of accessibility properties of resources and adaptations and a way to relate them. The content of the properties is changed in minor ways from the IMS work. The standard consists of three parts and the references below are to the most recent draft that is publicly available: • Part 1. Framework (24751-1): http://jtc1sc36.org/doc/36N1139.pdf • Part 2. Access For All Personal Needs and Preferences Statement (24751-2): http://jtc1sc36.org/doc/36N1140.pdf • Part 3. Access For All Digital Resource http://jtc1sc36.org/doc/36N1141.pdf Description (24751-3): Work on the standard is complete and at time of writing publication is awaiting ratification of a rights and maintenance agreement between IMS and ISO. Currently work is being chartered in IMS to update the AccessForAll work with changes suggested by ISO and other improvements. C.1.1.5.2 ISO IEC JTC1 SC35 The section on User Interfaces depends heavily on the source http://www.open-std.org/jtc1/sc35/wg6/. It should be noted that not all details of work underway is publicly available. SC 35 is concerned with, ‘standardization in the field of user-system interfaces between users (including people with special needs)’. The scope of the work also extends to input and output devices. There are 8 working groups and many pieces of work may be relevant at the technological interface level. The working groups and their scopes and work include: WG1: Keyboards and Input Interfaces WG2: User interface interaction WG3: Graphical symbols WG5: Cultural, Linguistic and User Requirements WG6: User Interfaces for People with Special Needs including children, the elderly, the permanently or temporarily disabled and people in constrained usage environments. The group is working on these: Page 75 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • (TR) 19765: Survey of icons and symbols that provide access to functions and facilities to improve the use of IT products by the elderly and disabled • (TR) 19766: Guidelines for the design of icons and symbols to be accessible to all users, including the elderly and persons with disabilities • (IS) 24756: Algorithmic framework for determining accessibility for individual users of interactive systems” • Proposed work item for a multipart IS: Accessible user interface for Accessibility Setting on Information Devices WG7: User interfaces object WG8 User Interfaces for Remote Interaction The working group is developing a 5-part international standard on a Universal Remote Console framework. C.1.1.6 CEN-ISSS The European Committee for Standardisation: Information Society Standardization System standards organisation supports a number of subgroups called Workshops that are formed to meet particular one-time or ongoing needs. These publish standards called Cen Workshop Agreements (CWA’s). Participation is usually open to all European citizens and organisations, sometimes for free and sometimes not. Details of CEN-ISSS can be found at: [http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/ind ex.asp ] The following workshops are of particular relevance: C.1.1.6.1 CEN-ISSS WS-LT CEN-ISSS Learning Technologies Workshop (WS-LT) [http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/act ivity/wslt.asp]. Members of this workshop were responsible for significant work on the IEEE LOM and for ensuring it incorporated European requirements. The workshop has produced a number of CWA’s and other outputs, some of which are listed below. Currently, processes are proceeding to establish a Page 76 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture CEN Technical Committee in the area that the workshop covers and because of this the future of the workshop is in the air. It is likely (not certain) that it will exist in some form and feed results into the new technical committee but the way this will be organised (and “if it will be”) is under discussion. Accordingly, most work is on hold though there are new work items waiting to start. CWA’s include • Description of Language Capabilities • Internationalisation of the IEEE Learning Object Metadata • Quality Assurance Standards • Availability of alternative language versions of a learning resource in IEEE LOM • Controlled Vocabularies for Learning Object Metadata: Typology, impact analysis, guidelines and a web based Vocabularies Registry • Guidelines for the production of learner information standards and specifications • Recommendations on a Model for expressing learner competencies • Review on SIF (Schools Interoperability Framework) Infrastructure, Architecture, Message Processing and Transport Layer • Internationalisation of SIF and harmonisation with other specs/standards • Adaptation of SIF Data • Model for a European context • Harmonisation of Vocabularies of eLearning • A Simple Query Interface Specification for Learning Repositories • A European Model for Learner Competencies • A model for classification of quality approach in elearning • Guidelines and support for building application profiles in e-learning The workshop has also produced a Repository of taxonomies/vocabularies for a European Learning Society and reports on Educational Copyright Licence Conditions (June 2003) and Educational Modeling Languages (October 2002) A CWA for Providing E-Learning Supplies Transparency Profiles”otentially useable to address accessibility aspects of quality, is currently going through final stages of comment and voting for acceptance as a standard. Page 77 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture C.1.1.6.2 DPA CEN-ISSS Document Processing for Accessibility (DPA) [http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/act ivity/ws-dpa.asp] This CWA is tackling integration of processes, methods and formats supporting accessibility within the publishing process, which is partly offline and partly online. The aim is to raise the profile of accessibility with publishers (where it has often so far received scant attention) by recommending process models that can be followed to give more accessible outputs within the publishing business models. Originally intended for publication in Spring 2007, the workshop are currently negotiating an extension. Publication is likely in six or twelve months from January 2007. C.1.1.6.3 WS-WAC European Web Accessibility certification scheme and a Quality Mark (WSWAC) [http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/act ivity/ws-wac.asp ] This published CWA describes a quality scheme similar to ISO-9000. The ways in which technology can be used in processes to determine accessibility properties or resources is not made clear in the CWA and its relation to personalisation by adaptation of resources is unclear. C.1.1.6.4 CEN-CENELEC Guide 6 [http://www.cenorm.be/BOSS/supporting/reference+documents/cclcgd006. pdf ] A very useful guide produced in collaboration with a group working in ISO, that addresses the needs of elderly persons. C.1.1.7 Digital Rights Management A comprehensive report that explores the topics of DRM (Digital Rights Management) and DREL (Digital Rights Expression Language) in the context of higher and further education has been compiled by JISC, a UK government body that supports further and higher education. Page 78 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture DRM is considered to be an issue of increasing importance within higher level education due to a number of reasons. Two simple reasons include the way that learning material can be presented to and stored within a repository, and secondly due to the emergence of new delivery approaches such as mobile learning and podcasting. Other implications are duly outlined in the final chapter of the report. The JISC report clearly presents what DRELs are and the roles they can play. The report reviews the DREL state of the art and concludes with a discussion about the medium and long term implications of DRM. The report presents work carried out by a number of standards bodies. These include IEEE–LTSC, International Digital Publishing Forum (IDPF), JTC1/SC29/WG11, Open Mobile Alliance (OMA) and Oasis. The most significant DRM languages are considered to be ODRL (Open Digital Rights Language) from the Open Mobile Alliance and XACML (eXtensible Access Control Markup Language) from OASIS. C.1.2 References IMS Global Learning Consortium (for all IMS specifications). Available online at: http://www.imsglobal.org/. Last check: 9th January, 2007 E-learning specifications. An introduction. Daniel Burgos, David Griffins. Available on-line at: http://www.elearningeuropa.info/directory/index.php?page=doc&doc_id=71 71&doclng=6. Last check: 9th January, 2007 Advanced Distributed Learning (SCORM). Available on-line at: 9th January, 2007. http://www.adlnet.gov/. Last check: 9th January, 2007 European Committee for Standardization (CEN/ISSS). Available on-line at: http://www.cenorm.be/cenorm/index.htm. Last check: 9th January, 2007 European Telecommunications Standards Institute (ETSI). Available on-line at: http://www.etsi.org/. Last check: 19th January, 2007 ITU-T. Available on-line at: http://www.itu.int/ITUT/studygroups/com16/accessibility/index.html. Last check: 19th January, 2007 JISC Digital Rights Expression Language Report. Available on-line at: http://www.jisc.ac.uk/uploaded_documents/TSW0603.pdf. Last Accessed: 24th January 2007 Page 79 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Open Mobile Alliance. Available on-line at: http://www.openmobilealliance.org/. Last Accessed: 24th January 2007 OASIS. Available on-line at: http://www.oasis-open.org/. Last Accessed: 24th January 2007 Page 80 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture C.2 Technologies for Federated eLearning C.2.1 Motivation A federated eLearning system is the idea that eLearning resources can be held in systems at different geographical locations which can be found and used by different sets of users at different institutions. It is closely allied to the idea of ‘federated search‘. Rather than executing a search for information using a central database (a single library), a federated search takes place using a number of independently controlled data sources or databases (many libraries). C.2.2 Repositories C.2.2.1 CORDRA CORDRA is an abbreviation for Content Object Repository and Resolution Architecture. Originating from the CMU Learning Systems Architecture Lab which is also associated with the SCORM initiative, CODRA aims to develop interoperable federations of learning content repositories. The CORDRA initative seems to be awaiting significant implementations of its architecture proposals and at present represents a 'reference model' rather than a true architecture that describes how repositories can interoperate C.2.2.2 The EUN LRE EUN is a body called the European Schools Network. LRE is an abbreviation for Learning Resource Exchange. The LRE initiative has been established with a number of stakeholders in mind: ministries of education, regional educational authorities, commercial learning content publishers, broadcasters and national ‘cultural institutions’. LRE follows on from an earlier project named FIRE, an abbreviation for Federating the Search of Internet Resources for Education. LRE uses the IEEE LOM metadata standard (described in the earlier section), in combination with SQI, an abbreviation called Simple Query Interface. SQI is a standard API for querying heterogeneous learning resource repositories. Implementation of LRE is carried out by installing a content repository at a user site facilitated by a custom installation of a suite of Java-based software. C.2.2.3 GLOBE Globe is an abbreviation for Global Learning Objects Brokered Exchange. GLOBE is a global alliance of international partners from the US, Australia, Page 81 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Japan and European Union. The intention of the initiative is to share learning resources, develop use cases, specifications, business rules and technologies to enable searches across repositories. In terms of technology, the GLOBE project resource site seems to be a placeholder for forthcoming developments but does offer a demonstration of learning resource searches over the Merlot learning material exchange site. C.2.2.4 UBP UNIVERSAL (http://www.ist-universal.org) is an online brokerage service linking educators and trainers for the exchange and distribution of learning resources. The UBP (UNIVERSAL Brokerage Platform) supports the whole value chain of exchange between providers and consumers, from the learning resource provision to the delivery of the actual learning resources. The UNIVERSAL service is based on the B2B concept, i.e. learning resources are exchanged between instructors, not from instructors to students. The UBP is based on a conceptual separation of content description, content itself, and LR delivery. The UBP interfaces federate commands for associating the geographically dispersed elements: Metadata records storing all the descriptive information for the UNIVERSAL brokerage catalogue are housed on a central UNIVERSAL server; LR content is housed on decentralised servers, and synchronous LRs are provided on the fly via live on-site delivery systems. The metadata interface is fully XML: RDF-based and compliant to standards such as Dublin Core, vCard, and IEEE LOM / IMS. The metadata records can either be created via the user interface of the UBP or automatically provided by the delivery systems, where the content is stored. In the latter case the user does not have to re-enter metadata such as title, author, description, etc. via the UBP’s user interface, because the UBP takes advantage of the metadata, which is stored on the delivery system. C.2.3 Frameworks C.2.3.1 JISC e-Framework Formerly named and building on the Joint Information Systems Committee (JISC) e-Framework, eLearning Framework (ELF) the eFramework aims to build an evolving and sustainable, open standards based service oriented technical framework to support the education and research communities. It provides refererence models of needs, requirements, workflows and processes, service definitions and references to available software that implements the service types. The ELF project, on which it builds was a collaborative research project performed by educational institutions and commercial organisations initiated by the UK government Joint Information Systems Committee (JISC) with the intention of carrying out research into Page 82 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture next generation learning technologies. The ELF initiative was joined by the Australian Department of Education, Science and Training (DEST). The ELF initiative comprises of a high-level model that describes a set of abstract requirements for eLearning systems. The model is divided into a number of discrete blocks. Each block can be implemented as a separate software component or project that can be connected to other blocks using openstandards such as web-services (or equivalent). As a result of the initiative JISC/DEST funded the exploration of a small number of short-term federated educational technology specific research projects which may have the potential to inform future developments. C.2.3.2 GUID Technologies When dealing with objects that may be on a local system or a remote system, its useful for many purposes to be able to identify objects uniquely. Identifiers that can do this are sometimes called GUID’s for Global Unique Identifiers. Unfortunately there is no single technology that the world has settled on and argument about the technologies and their weaknesses continue, alongside co-existing but different definitions of the same thing. So the area is rife with unsolved problems. The technologies that can handle this include, but are not limited to for example handle-based systems. Some technologies for achieving this are listed in the IMS Persistent, Location-Independent Resource Identifier Handbook.: [http://www.imsglobal.org/implementationhandbook/index.html] C.2.3.3 IMS/GLC Specifications for Supporting Federated Architectures The objective of this specification is to address the interoperability issues raised by the construction of federated architectures and : • Compare the approaches (used within the e-learning community and beyond – cultural heritage organizations, museums, libraries, and publishers face similar problems and their digital content is potentially useful as learning objects), • Elicit common issues, and possibly • Specify common ways to solve these issues. Although defining general frameworks is important, given the complexity of deployment of federated architectures, which involve a large number of heterogeneous systems, the optimal approach is to define a set of independent specifications. Each of these specifications would solve a welldefined and limited problem, and must be usable separately as well as in Page 83 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture combination with others, possibly (but not necessarily) according to frameworks. From a technical standpoint, obtaining a learning object is a three-step process consisting of searching and evaluating metadata, resolving the location of the chosen learning object, and consuming the learning object. 1. Searching and evaluating metadata: Selecting a learning object that satisfies user needs on the basis of the description provided in the metadata. It may be necessary to repeat this step in order to refine the search criteria and find the appropriate learning objects; 2. Resolving the learning object location: Under some circumstances, metadata provides references to learning objects rather than their locations and an additional step is necessary to resolve the location of a resource on the basis of its reference. This situation occurs, for example, in LRE federation (http://lre.eun.org) where the additional step, which consists in requesting a learning object location, is used to enforce the digital rights associated with the learning object. The actual location of a learning object is delivered only if the requester is authorized to access the learning object. Another reason (for not storing the location of a learning object in the metadata describing it) is illustrated by the iClass project (http://www.iclass.info) where the adaptive and multimedia nature of the learning objects combined with the peer-to-peer nature of the underlying network of learning object repositories makes difficult to access learning objects directly. This is why, in iClass, the “resolve-location” step is used to retrieve the requested learning object in a peer-to-peer network of repositories and to move it to a streaming server which, combined with a “presenter”, gives access to the learning object using a web browser; 3. Consuming the learning object: Getting the selected learning object at the location —usually a universal resource locator (URL)— obtained during the second step. To support these steps, it is necessary to specify: • The definition of a query exchange format: When searching a federation for resources, it is necessary to transport queries between heterogeneous systems. The exchange format should be rich enough to express meaningful queries and abstract enough to be easily mapped into the concrete query languages supported by the target resource repositories. • The specification of a query interface: This is necessary to transport queries to the federated repositories and get results. Such an interface Page 84 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture must take into account the requirements of federated searches (e.g., asynchronous remote façade). • The definition of a query result format: A common way to express query results is needed. • The global identification of resources: Resources should be uniquely identified so that it is possible to unambiguously refer to them in metadata exchanged between systems. • The global identification of systems and repositories: Similarly, it should be possible to unambiguously refer to the systems that host these resources. The description of learning content repositories or collections using so-called collection level description for Learning Object collections. Metadata may include a subset of the LOM enriched with some new elements such as ‘Quality assurance procedures’. • The specification of a synchronization interface: A synchronization interface is necessary to mirror metadata. Ideally, push and pull scenarios must be supported. • The definition of a user profile: Current specifications, such as IMS LIP, focus on the administrative data of learners. In order to provide more accurate search results it would be interesting to describe the “educational context” of a user (e.g., role: professor/teacher vs student/pupils, topics of interest, etc.) • Integration with federated identity management (single-sign on, user identity, access management): This is necessary (together with the integration with digital rights management systems) to make the rights associated with resources enforceable. • Integration with digital rights management systems. Potentially, these tasks will both benefit from and impact on other activities (e.g., the IMS repository SIG, the e-Framework) that, ideally, should take into account federated architecture requirements. C.2.4 References CORDRA. Available on-line at: 9th January, 2007. http://cordra.net/. Last check: 9th January, 2007 Learning Resource Exchange (LRE). Available on-line at: 9th January, 2007. http://lre.eun.org. Last check: 9th January, 2007 Page 85 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Global Learning Objects Brokered Exchange (GLOBE). Available on-line at: 9th January, 2007. http://globe.edna.edu.au. Last check: 9th January, 2007 JISC E-Learning Framework (ELF). Available on-line at: 9th January, 2007. http://ww.elframework.org. Last check: 9th January, 2007 UNIVERSAL Brokerage Service. Available on-line at: 9th January, 2007. http://www.hi.is/~ebba/publications/summit_5b_universal.pdf. Last check: 9th January, 2007 Page 86 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture C.3 Metadata Repositories C.3.1 Motivation This section contains two sections. The first section presents standards that describe how learning object or educational resource meta-data may be shared between different repository systems. This section extends the work introduced in the earlier section that described technologies for federated eLearning. The second section describes important repository initiatives. C.3.2 Specifications C.3.2.1 IMS DRI DRI is an abbreviation for Digital Repositories Interoperability. The aim of the specification is to provide technical and practical recommendations to enable repositories to interoperate. The specification makes use of the earlier content packaging and metadata specifications. The DRI specification version 1 describes the following key repository functions: • Search/Expose: Searching through the content meta-data that a repository exposes. • Gather/Expose: Gathering refers to the action of obtaining meta-data from other repositories so this meta-data can be used within subsequent searches. A repository may push its meta-data to another repository or may pull meta-data from a known repository. The pull concept follows those described by the Open Archives Initiative (see Others section and references). • Submit/Store: Describes the movement of a learning object from a network location (perhaps a filestore) and how the object will be stored within the repository. This operation is made possible by using content package that contains appropriate metadata which is transferred to a repository using SOAP. The specification does not detail the underlying structure of how the package should be stored. • Request/Deliver: Refers to the delivery of a learning object (or resource) to a user after it has been found through meta-data searches. The result of this request is likely to be a HTTP reference for web pages and streamed materials, or FTP references for documents and executables. The Information Model document describes a number of appropriate use cases. The DRI specification also contains a number of technology recommendations, namely: Z39.50 and SOAP. SOAP is used as a way to deliver XQueries to a repository. Page 87 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture It must be noted that the specification is by no means complete. Additional areas such as the SOAP bindings have yet to be completed. C.3.2.2 OAI-PMH The OAI-PMH metadata harvesting specification has been developed by the Open Archives initiative. The specification, which can also be considered to be a protocol, describes how a repository can be interrogated using a series of HTTP requests. The protocol presents six different requests (or verbs). The verbs allows the user to retrieve metadata records from a repository (whole or in part), ask for details about the repository, list the metadata records that the repository can support and obtain defined sets (groups) of metadata records. The parameters for the requests are presented using a query string and the response is presented in XML. A comprehensive description of OAI-PMH can be found in the tutorial link that is provided in the reference section. The OAI-ORE Object Reuse and Exchange initiative aims to “allow distributed repositories to exchange information about their constituent digital objects” (ORE web-site, see references). The resulting specifications are intended to co-exist with the existing PMH specifications. There seems to be a degree of surface similarity with the IMS DRI initiative. C.3.3 Learning Object and Metadata Repositories C.3.3.1 MERLOT MERLOT, an abbreviation for Multimedia Educational Resources for Learning and Online Teaching, is a searchable collection of peer reviewed higher education on-line learning materials contributed by individual and institutional members. The learning resources are categorized broadly according to discipline (such as Biology, History, Physics etc). The learning materials are in turn grouped into several ‘use categories’, such as simulation, case study, animation and tutorial, for example, to enable educators to quickly seek a resource that fits their needs. The learning resources themselves are not hosted by MERLOT. Instead the user is directed to the appropriate URL. MERLOT also allows user generated metadata to be created, allowing users to group together learning resources into collections. Users can also contribute to peer reviews of resources by assigning ratings and assigning comments. C.3.3.2 CAREO Page 88 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The Campus Alberta Repository of Educational Objects in many ways resembles the MERLOT system. Like MERLOT it also presents users with a broad category of disciplines and directs users to external websites. C.3.3.3 JORUM JORUM is a repository service provided exclusively for UK further and higher educational institutions. Unlike MERLOT and CAREO, JORUM allows publicly funded learning resources to be exchanged between institutions using content packages. C.3.4 References IMS Digital Repositories Specification (DRI). Available on-line at: 9th January, 2007. http://www.imsglobal.org/digitalrepositories/. Last check: 9th January, 2007 MERLOT. Available on-line at: 9th January, 2007. http://www.merlot.org. Last check: 9th January, 2007 Open Archives Initiative. Available on-line at: 9th January, http://www.openarchives.org/. Last check: 9th January, 2007 2007. OAI-PMI Tutorial. Available on-line at: 9th January, http://www.oaforum.org/tutorial/. Last check: 9th January, 2007 2007. OAI-ORE Initiative. Available on-line at: 9th January, http://www.openarchives.org/ore/. Last check: 9th January, 2007 2007. Campus Alberta Repository of Educational Objects. Available on-line at: 9th January, 2007. http://careo.netera.ca/. Last check: 9th January, 2007 JORUM. Available on-line at: 9th January, 2007. http://www.jorum.ac.uk/. Last check: 9th January, 2007 Page 89 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Annex D Review of Accessibility Guidelines for Design For ALL Page 90 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture D.1 Web Accessibility Initiative D.1.1 Motivation Years ago the expression “web accessibility” was unfamiliar` to stranger for the majority of people, with the exception of a few professionals involved with web technologies. But today this has changed and is a clear demonstation of the benefits that the accessibility Web provides the users of Internet. Although the emergence of the World Wide Web, and its later exponential growth, has suported a radical change as far as the diffusion and availability of the information, the limitations produced by the use of web site designers of the some current web page design technologies are making more difficult access to information by users with disabilities. This phenomenon, that worsens info-exclusion of the digital divide, supports the exclusion of a significant percent of the total number of users. Disabled users often have more motivation to use Internet than others because the Web can support doing tasks that would be much more difficult to do in the real world. Consequently, we can define Web accessibility as the ability for a product or service on the Web to be accessed and used by the highest possible number of people, without taking into account the limitations of the individual or limitations imposed by context. It is essential that several different components of Web development and interaction work together in order for the Web to be accessible to people with disabilities. These components include: • Content: the information in a Web page or Web application, including: natural information such as text, images and sounds, and code or markup that defines structure, presentation, etc. • Web browsers, media players, and other "user agents" • Assistive technology, in some cases: screen keyboards, switches, scanning software, etc. • Users' knowledge, experiences, and in some cases, adaptive strategies using the Web • Developers, designers, coders, authors, etc., including developers with disabilities and users who contribute content • Authoring tools: software that creates Web sites readers, alternative Page 91 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • Evaluation tools: Web accessibility evaluation tools, HTML validators, CSS validators, etc. The W3C Web Accessibility Initiative (WAI) develops Web accessibility guidelines for the different components: • Web Content Accessibility Guidelines (WCAG) addresses Web content, and is used by developers, authoring tools, and accessibility evaluation tools • Authoring Tool Accessibility Guidelines (ATAG) addresses authoring tools • User Agent Accessibility Guidelines (UAAG) addresses Web browsers and media players, including some aspects of assistive technologies D.1.1.1 Guidelines D.1.1.1.1 WCAG 1.0 Web Content Accessibility Guidelines 1.0 (WCAG 1.0) explain how to make Web content accessible to people with disabilities. The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. Furthermore, following them will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly. These guidelines do not discourage content developers from using images, video, etc., but rather explain how to make multimedia content more accessible to a wide audience. Many users may be operating in very different contexts: • They may not be able to see, hear, move, or may not be able to process some types of information easily or at all. • They may have difficulty reading or comprehending text. • They may not have or be able to use a keyboard or mouse. • They may have a text-only screen, a small screen, or a slow Internet connection. • They may not speak or understand fluently the language in which the document is written. Page 92 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • They may be in a situation where their eyes, ears, or hands are busy or having restricted use (e.g., driving to work, working in a loud environment, etc.). • They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system. Content developers must consider these different situations during page design. While there are several situations to consider, each accessible design choice generally benefits several disability groups at once and the Web community as a whole. For example, by using style sheets to control font styles and eliminating the FONT element, HTML authors will have more control over their pages, make those pages more accessible to people with low vision, and by sharing the style sheets, will often shorten page download times for all users. The guidelines discuss accessibility issues and provide accessible design solutions. They address typical scenarios that may pose problems for users with certain disabilities. Some users may not be able to see images others may use text-based browsers that do not support images, while others may have turned off support for images (e.g., due to a slow Internet connection). The guidelines do not suggest avoiding images as a way to improve accessibility. Instead, they explain that providing a text equivalent of the image will make it accessible. How does a text equivalent make the image accessible? Both words in "text equivalent" are important: • Text content can be presented to the user as synthesized speech, braille, and visually-displayed text. Each of these three mechanisms uses a different sense -- ears for synthesized speech, tactile for braille, and eyes for visually-displayed text -- making the information accessible to groups representing a variety of sensory and other disabilities. • In order to be useful, the text must convey the same function or purpose as the image. If the text conveys the same function or purpose for the user with a disability as the image does for other users, then it can be considered a text equivalent. Non-text equivalents of text (e.g., icons, pre-recorded speech, or a video of a person translating the text into sign language) can make documents accessible to people who may have difficulty accessing written text, including many individuals with cognitive disabilities, learning disabilities, and deafness. Non-text equivalents of text can also be helpful to nonreaders. An auditory description is an example of a non-text equivalent of visual information. An auditory description of a multimedia presentation's visual track benefits people who cannot see the visual information. Page 93 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The guidelines address two general themes: ensuring graceful transformation, and making content understandable and navigable. D.1.1.1.2 WCAG 2.0 WAI expects WCAG 2.0 to be completed in 2007. When WCAG 2.0 will be finalized depends on many factors, such as how long it takes to address current comments, what additional comments come in, and how long is needed for each remaining stage of the W3C Process. WCAG 2.0 is currently a "Last Call Working Draft," which was announced in April 2006 and the Review Period for comments extended into June 2006. Last Call Working Draft is a middle stage of the W3C Process. Web Content Accessibility Guidelines 2.0 (WCAG 2.0) covers a wide range of issues and recommendations for making Web content more accessible. It contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible. "Accessible" means usable to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, photosensitivity and combinations of these. WCAG 2.0 is a continuation and evolution of WCAG 1.0 and incorporates suggestions received from the publication of WCAG 1.0 in May of 1999. In 2.0 version, the organization and the structure has changed. WCAG 1.0 has a priority scheme that is used to determine the importance of each checkpoint in the guidelines. Instead of using checkpoints, WCAG 2.0 uses success criteria that is organised into three levels of conformance. In addition, the principles have been articulated so that it is easier to understand its application in new technologies as well as already existing ones. The rough draft of work of WCAG 2.0 does not include requirements or specific techniques of implementation of a particular technology. WCAG 2.0 success criteria are written as testable statements that are not technology-specific. Most Web sites that conform to WCAG 1.0 should not require significant changes in order to conform to WCAG 2.0. The fundamental issues of Web accessibility are the same, though there are some differences in the requirements between WCAG 1.0 and WCAG 2.0. WCAG 2.0 is being developed to apply to more advanced Web technologies and be more precisely testable than WCAG 1.0. D.1.1.1.3 ATAG 1.0 Page 94 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0) provides guidelines for Web authoring tool developers. Its purpose is two-fold: to assist developers in designing authoring tools that produce accessible Web content and to assist developers in creating an accessible authoring interface. Authoring tools can enable, encourage, and assist users ("authors") in the creation of accessible Web content through prompts, alerts, checking and repair functions, help files and automated tools. It is just as important that all people be able to author content as it is for all people to have access to it. The tools used to create this information must therefore be accessible themselves. Adoption of these guidelines will contribute to the proliferation of Web content that can be read by a broader range of readers and authoring tools that can be used by a broader range of authors. In these guidelines, the term "authoring tool" refers to the wide range of software used for creating Web content, including: • Editing tools specifically designed to produce Web content (e.g., WYSIWYG HTML and XML editors); • Tools that offer the option of saving material in a Web format (e.g., word processors or desktop publishing packages); • Tools that transform documents into Web formats (e.g., filters to transform desktop publishing formats to HTML); • Tools that produce multimedia, especially where it is intended for use on the Web (e.g., video production and editing suites, SMIL authoring packages); • Tools for site management or site publication, including tools that automatically generate Web sites dynamically from a database, on-thefly conversion tools, and Web site publishing tools; • Tools for management of layout (e.g., CSS formatting tools). The goals of this document can be stated as follows: that the authoring tool be accessible to authors regardless of disability, that it produce accessible content by default, and that it support and encourage the author in creating accessible content. Because most of the content of the Web is created using authoring tools, they play a critical role in ensuring the accessibility of the Web. Since the Web is both a means of receiving information and communicating information, it is important that both the Web content produced and the authoring tool itself be accessible. The principles set forth in these guidelines will benefit many people who do not have a disability but who have similar needs. This includes people who work in noisy or quiet environments where the use of sound is not practical, people who need to use their eyes for another task and are unable to view a Page 95 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture screen, and people who use small mobile devices that have a small screen, no keyboard, and no mouse. D.1.1.1.4 ATAG 2.0 The guiding principle of ATAG 2.0 is that: “Everyone should have the ability to create and access Web content.” This specification provides guidelines for designing Web content authoring tools that are more accessible for people with disabilities. An authoring tool that conforms to these guidelines will promote accessibility by providing an accessible user interface to authors with disabilities as well as enabling, supporting, and promoting the production of accessible Web content by all authors. This document includes recommendations for assisting authoring tool developers to make their tools (and the Web content that the tools generate) more accessible to all people, especially people with disabilities, who may potentially be either authors or end users. These guidelines have been written to address the requirements of many different audiences, including, but not limited to: policy makers, technical administrators, and those who develop or manage content. An attempt has been made to make this document as readable and usable as possible for that diverse audience, while still retaining the accuracy and clarity needed in a technical specification. ATAG 2.0 defines an "authoring tool" as: any software, or collection of software components, that authors use to create or modify Web content for publication, where a "collection of software components" are any software products used together (e.g., base tool and plug-in) or separately (e.g., markup editor, image editor, and validation tool), regardless of whether there has been any formal collaboration between the developers of the products. The following categories are an informative illustration of the range of tools covered by ATAG 2.0. The categories are used primarily in the Techniques document [ATAG20-TECHS] to mark examples that may be of interest to developers of particular types of tools. Note: Many authoring tools include authoring functions from more than one category (e.g., an HTML editor with both code-level and WYSIWYG editing views): • Code-level Authoring Functions: Authors have full control over all aspects of the resulting Web content that have bearing on the final outcome. This covers, but is not limited to plain text editing, as this category also covers the manipulation of symbolic representations that are sufficiently fine-grained to allow the author the same freedom of Page 96 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture control as plain text editing (e.g., graphical tag placeholders). Examples: text editors, text editors enhanced with graphical tags, some wikis, etc. • WYSIWYG ("What-you-see-is-what-you-get") Authoring Functions: Authors have control over entities that closely resemble the final appearance and behavior of the resulting Web content. Examples: rendered document editors, bitmap graphics editors, etc. • Object Oriented Authoring Functions: Authors have control over functional abstractions of the low level aspects of the resulting Web content. Examples: timelines, waveforms, vector-based graphic editors, objects which represent web implementations for graphical widgets (e.g., menu widgets) etc. • Indirect Authoring Functions: Authors have control over only high-level parameters related to the automated production of the resulting Web content. This may include interfaces that assist the author to create and organize Web content without the author having control over the markup, structure, or programming implementation. Examples: content management systems, site building wizards, site management tools, courseware, blogging tools, content aggregators, conversion tools, model-based authoring tools, etc. Authoring tools play a crucial role in achieving this principle because the accessibility of the tool's authoring tool user interface determines who can access the tool as a Web content author and the accessibility of the resulting Web content determines who can be an end user of that Web content. D.1.1.1.5 UAAG 1.0 User Agent Accessibility Guidelines 1.0 recommendation provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological). User agents include HTML browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable. In addition to helping developers of HTML browsers and media players, this recommendation will also benefit developers of assistive technologies because it explains what types of information and control an assistive technology may expect from a conforming user agent. Technologies not addressed directly by this document (e.g., technologies for Braille Page 97 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture rendering) will be essential to ensuring Web access for some users with disabilities. This recommendation specifies requirements that, if satisfied by user agent developers, will lower barriers to accessibility. "User Agent Accessibility Guidelines 1.0" (UAAG 1.0) is part of a series of accessibility guidelines published by the Web Accessibility Initiative. The documents in this series reflect an accessibility model in which Web content authors, format designers, and software developers have roles in ensuring that users with disabilities have access to the Web. UAAG was designed specifically to improve the accessibility of user agents with multimedia capabilities running in the following type of environment (typically that of a desktop computer): • The operating environment includes a keyboard (or keyboard equivalent) • Assistive technologies may be used in the operating environment and may communicate with the conforming user agent The target user agent is one designed for the general public to handle general-purpose content in ordinary operating conditions. This recommendation does not forbid conformance by other types of user agents, but some requirements (e.g., implementation of certain application programming interfaces, or APIs) are not likely to be satisfied in environments (e.g., handheld devices or kiosks) other than the target environment. Future work by the UAWG may address the accessibility of user agents running on handheld devices, for example. Technologies not addressed directly by this recommendation (e.g., those for Braille rendering) will be essential to ensuring Web access for some users with disabilities. D.1.1.1.6 Mobile Web Best Practices 1.0 This recommendation specifies Best Practices for delivering Web content to mobile devices. The principal objective is to improve the user experience of the Web when accessed from such devices. The recommendations refer to delivered content and not to the processes by which it is created, nor to the devices or user agents to which it is delivered. These recommendations are in part derived from the WCAG. As noted above, WCAG guidelines are supplementary to the Mobile Web Best Practices, whose scope is limited to matters that have a specific mobile relevance. Page 98 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Mobile device input is often difficult when compared with use of a desktop device equipped with a keyboard. Mobile devices often have only a very limited keypad, with small keys, and there is frequently no pointing device. One of the difficulties of the mobile Web is that URIs are very difficult to type. Lengthy URIs and those that contain a lot of punctuation are particularly difficult to type correctly. Because of the limitations of screen and input, forms are hard to fill in. This is because navigation between fields may not occur in the expected order and because of the difficulty in typing into the fields. While many modern devices provide back buttons, some do not, and in some cases, where back functionality exists, users may not know how to invoke it. This means that it is often very hard to recover from errors, broken links and so on. The restrictions imposed by the keyboard and the screen typically require a different approach to page design than for desktop devices. Various other limitations may apply and these have an impact on the usability of the Web from a mobile device. Mobile browsers often do not support scripting or plug-ins, which means that the range of contents that they support is limited. In many cases the user has no choice of browser and upgrading it is not possible. Some activities associated with rendering Web pages are computationally intensive - for example re-flowing pages, laying out tables, processing unnecessarily long and complex style sheets and handling invalid mark-up [T-MOB]. Mobile devices typically have quite limited processing power, which means that page rendering may take a noticeable time to complete. As well as introducing a noticeable delay, such processing uses more power as does communication with the server. Many devices have limited memory available for pages and images, and exceeding their memory limitations results in incomplete display and can cause other problems. In summary, this recommendation refers primarily to the extension of Web browsing onto mobile devices. The Best Practice recommendations refer to delivered content. While they are clearly relevant to the processes of content creation and rendering on devices, they are not intended to be Best Practices for those activities. D.1.1.1.7 Multimodal Interaction Activity Page 99 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The Multimodal Interaction Activity seeks to extend the Web to allow users to dynamically select the most appropriate mode of interaction for their current needs, including any disabilities, whilst enabling developers to provide an effective user interface for whichever modes the user selects. Depending upon the device, users will be able to provide input via speech, handwriting, and keystrokes, with output presented via displays, prerecorded and synthetic speech, audio, and tactile mechanisms such as mobile phone vibrators and Braille strips. Multimodal interaction offers significant ease of use benefits over uni-modal interaction, for instance, when hands-free operation is needed, for mobile devices with limited keypads, and for controlling other devices when a traditional desktop computer is unvailable to host the application user interface. This is being driven by advances in embedded and network-based speech processing that are creating opportunities for integrated multimodal Web browsers and for solutions that separate the handling of visual and aural modalities, for example, by coupling a local XHTML user agent with a remote VoiceXML user agent. The suite of specifications is known as the W3C Multimodal Interaction Framework. • Introduction, 6 May 2003. The Multimodal Interaction Framework introduces a general framework for multimodal interaction, and the kinds of markup languages being considered. • Use cases, 4 December 2002. Multimodal Interaction Use Cases describes several use cases that are helping us to better understand the requirements for multimodal interaction. • Core requirements, 8 January 2003. Multimodal Interaction Requirements describes fundamental requirements for the specifications under development in the W3C Multimodal Interaction Activity. The “Multimodal Architecture and Interfaces” document is its third draft, of 11 of 2006. D.1.1.1.8 AccessDL The National Centre on Accessible Distance Learning (AccessDL) is funded by the U.S. Department of Education to share guidance and resources on making distance learning courses accessible to students and instructors with disabilities. This centre is directed by the “Disabilities, Opportunities, Internetworking, and Technology Centre” [DO-IT] that serves to increase the participation of individuals with disabilities in challenging academic programs and careers. Page 100 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture It promotes the use of computer and networking technologies to increase independence, productivity, and participation in education and employment. The AccessDL site contains resources and links for distance learning administrators, educators, web designers and students about how to ensure that distance learning is accessible to students and instructors with disabilities. Categories of resources include discussion lists as well as publications and streaming video for distance learning designers, instructors, trainers, webmasters and editors. D.1.2 References WAI (Web Accessibility Initiative). Available http://www.w3.org/WAI/. Last check: 15th of January 2007 on-line at: WCAG 1.0 (Web Content Accessibility Guidelines). Available on-line at: http://www.w3.org/TR/WCAG10/. Last check: 15th of January 2007 WCAG 2.0 (Web Content Accessibility Guidelines). Available on-line at: http://www.w3.org/TR/WCAG20/. Last check: 15th of January 2007 Mapping between WCAG 1.0 and WCAG 2.0. Available on-line at: http://www.w3.org/WAI/GL/2004/03/11-mapping.html. Last check: 15th of January 2007 ATAG 1.0 (Authoring Tool Accessibility Guidelines). Available on-line at: http://www.w3.org/TR/ATAG10/. Last check: 15th of January 2007 ATAG 2.0 (Authoring Tool Accessibility Guidelines). Available on-line at: http://www.w3.org/TR/ATAG20/. Last check: 15th of January 2007 [ATAG20-TECHS]. Available on-line at: http://www.w3.org/TR/ATAG20TECHS. Last check: 15th January 2007 UAAG 1.0 (User Agent Accessibility Guidelines). Available on-line at: http://www.w3.org/TR/UAAG10/. Last check: 15th January 2007 [T-MOB]Mobile Web Best Practices 1.0. Available on-line at: http://www.w3.org/TR/2006/PR-mobile-bp-20061102/. Last check: 15th January 2007 Mobile Web Initiative. Available on-line at: http://www.w3.org/Mobile/. Last check: 15th January 2007 Foundation SIDAR (Spain). Available on-line at: http://www.sidar.org. Last check: 15th January 2007 Page 101 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture [DO-IT] Disabilities, Opportunities, Internetworking, and Technology Center. Available on-line at: http://www.washington.edu/doit/. Last check: 15th of January 2007 [AcessDL] National Center on Accessible Distance Learning. Available online at: http://www.washington.edu/doit/Resources/accessdl.html. Last check: 15th of January 2007 Page 102 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture D.2 National Legislations to assure technological accessibility D.2.1 Motivation The Web's emergence as a pivotal form of Information and Communications Technology (ICT) raises interesting questions about application of existing laws and policies to this new medium, and the importance of all members of society, including people with disabilities, being able to access this information medium. There is a growing body of national laws and policies, which address accessibility of ICT, including the Internet and the Web. There is also great variety of approaches among these laws and policies: some take the approach of establishing a human or civil right to ICT; others the approach that any ICT purchased by government must be accessible; others that any ICT sold in a given market must be accessible; and there are still other approaches. D.2.2 Regulations D.2.2.1 American Section 508 D.2.2.1.1 Summary On August 7, 1998, President Clinton signed into law the Rehabilitation Act Amendments of 1998 which covers access to federally funded programs and services. The law strengthens section 508 of the Rehabilitation Act and requires access to electronic and information technology provided by the Federal government. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology. Federal agencies must ensure that this technology is accessible to employees and members of the public with disabilities to the extent it does not pose an "undue burden." Section 508 speaks to various means for disseminating information, including computers, software, and electronic office equipment. It applies to, but is not solely focused on, Federal pages on the Internet or the World Wide Web. It does not apply to web pages of private industry. The standards defined in the Section 508 cover technology procured by Federal agencies under contract with a private entity, but apply only to those products directly relevant to the contract and its deliverables. Page 103 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Section 508 provides technical specifications and performance-based requirements, which focus on the functional capabilities of covered technologies. This dual approach recognizes the dynamic and continually evolving nature of the technology involved as well as the need for clear and specific standards to facilitate compliance. Certain provisions are designed to ensure compatibility with adaptive equipment people with disabilities commonly use for information and communication access, such as screen readers, Braille displays, TTYs (TeleTYpes), TDDs (Telecommunications Devices for the Deaf), and TTs (Text Telephones). D.2.2.1.2 Legislation • Rehabilitation Act Amendments of 1998, Section 508 • Americans with Disabilities Act (ADA) - Prohibits discrimination and ensures equal opportunity for persons with disabilities in employment, state and local government services, public accommodations, commercial facilities, and transportation. The ADA requires that reasonable accommodations be provided in meeting the needs of individuals with disabilities. Additional technical assistance regarding the ADA is available through the ADA Technical Assistance Program. • Assistive Technology Act of 1998 - The Assistive Technology Act establishes a grant program, administered by the U.S. Department of Education, to provide Federal funds to support State programs that address the assistive technology needs of individuals with disabilities. • Section 255 of the Telecommunications Act of 1996 - Section 255 of the requires manufacturers of telecommunications equipment and providers of telecommunications services to ensure that such equipment and services are accessible to persons with disabilities, if readily achievable. The Federal Communications Commission's Report and Order Implementing Section 255 was released in September 1999. • Section 501 of the Rehabilitation Act - Section 501 of this act prohibits discrimination on the basis of disability in Federal employment and requires Federal agencies to establish affirmative action plans for the hiring, placement, and advancement of people with disabilities in Federal employment. Additional information and definitions related to Section 501 can be found at theEEOC website. • Section 504 of the Rehabilitation Act - Section 504 prohibits discrimination based on disability in federally funded and federally conducted programs or activities in the United States, including employment programs.Additional information and definitions related to Section 504 can be found at the Department of Labor website. • Section 505 of the Rehabilitation Act - Section 505 establishes the enforcement procedures for title V of the Rehabilitation Act. Section 505 (a) (1) provides that the procedures and rights set forth in Section 717 Page 104 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture of the Civil Rights Act of 1964 shall be available with respect to any complaint under Section 501. Section 505 (a)(2) provides that the remedies, rights and procedures set forth in title VI of the Civil Rights Act of 1964 shall be available to any person alleging a violation of Section 504. Section 508 is also enforced through the procedures established in Section 505 (a)(2). D.2.2.1.3 Who is affected • It covers technology procured by Federal agencies under contract with a private entity, but apply only to those products directly relevant to the contract and its deliverables. • It does not apply to web pages of private industry. D.2.2.1.4 How Section 508 does not only apply to the the accessibility of web pages and web applications , it also applies to Software and therefore to the authoring tools and the browsers. In the W3C web site, there is a comparative study of the norms of the Section the 508 and requirements and priorities of the “User Agent Accessibility Guidelines 1.0 (UAAG)”. The criteria for web-based technology and information are based on access guidelines developed by the Web Accessibility Initiative of the W3C. Many of these provisions ensure access for people with vision impairments who rely on various assistive products to access computer-based information, such as screen readers, which translate what's on a computer screen into automated audible output, and refreshable Braille displays. Certain conventions, such as verbal tags or identification of graphics and format devices, like frames, are necessary so that these devices can "read" them for the user in a sensible way. The standards do not prohibit the use of web site graphics or animation. Instead, the standards aim to ensure that such information is also available in an accessible format. Generally, this means use of text labels or descriptors for graphics and certain format elements (HTML code already provides an "Alt Text" tag for graphics which can serve as a verbal descriptor for graphics). This section also addresses the usability of multimedia presentations, image maps, style sheets, scripting languages, applets and plug-ins, and electronic forms. D.2.2.1.5 Relevant documents General Services Adminstration's Section 508 site. Available on-line at: http://www.section508.gov/. Last check: 15th January 2007 EITAAC Final Report (Report delivered to the Access Board by the Electronic and Information Technology Access Advisory Committee). Available on-line Page 105 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture at: http://www.access-board.gov/sec508/commrept/eitaacrpt.htm. check: 15th January 2007 Last US Department of Education's Requirements for Accessible Software Design. Available on-line at: http://www.ed.gov/fund/contract/apply/clibrary/software.html. Last check: 15th January 2007 D.2.2.1.6 Additional information Assistive Technology Act of 1998. Available on-line at: http://www.section508.gov/docs/AT1998.html. Last check: 15th January 2007 Working space for EITAAC maintained by the Trace Research & Development Center. Available on-line at: http://trace.wisc.edu/docs/eitaac/. Last check: 15th January 2007 Attorney General's speech on Section 508. Available on-line at: http://www.usdoj.gov/archive/ag/speeches/2000/doc3.htm. Last check: 15th January 2007 D.2.2.2 UK DDA & Senda D.2.2.2.1 Summary: DDA The Disability Discrimination Bill was introduced to the House by the Minister for Social Security and Disabled People. This led to the passing of the Disability Discrimination Act 1995 (DDA). The right conferred under Part III on October 1, 1999 is applicable to all providers of goods, facilities, and services to the general public, with the specific exclusions of transport and education, and requires positive action which is reasonable and readily achievable to overcome the physical and communication barriers that impede disabled people's access. The act primarily covers employment issues and the provision of goods, facilities, and services. In September 2002, the exemption of education- related services from the Disability Discrimination Act 1995 (DDA) was removed through the introduction of the Special Educational Needs and Disability Act 2001 (SENDA). This is now embedded within the DDA as Part IV and places a duty on institutions not to discriminate against a disabled person for reasons related to his or her impairment. Certain sections of the DDA Part IV are already in force, while others have yet to come into force. The duty to provide auxiliary aids and services comes into effect from September Page 106 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture 2003. An additional duty to make adjustments to physical features comes into effect from September 2005. Under the Act, anyone who is considered a disabled person can claim protection from alleged discrimination. Section 21 of the Disability Discrimination Act (1995) does apply to web service providers and requires them to make "reasonable adjustments" to their services so that disabled people can access them. The Act has led to the creation of the Disability Rights Commission (DRC). The DRC will play a critical role in drawing up future codes of practice and advising parties of their rights, as well as generally encouraging the advancement of disability rights. SENDA The Special Educational Needs and Disability Act 2001 (SENDA) introduces the right for disabled students not to be discriminated against in education, training and any services provided wholly or mainly for students, and for those enrolled on courses provided by “responsible bodies”, including further and higher education institutions and sixth form colleges. Student services covered by the Act can include a wide range of educational and non-educational services, such as field trips, examinations and assessments, short courses, arrangements for work placements and libraries and learning resources. If a disabled person is at a “substantial disadvantage”, responsible bodies are required to take reasonable steps to prevent that disadvantage. This might include: • changes to policies and practices • changes to course requirements or work placements • changes to the physical features of a building • the provision of interpreters or other support workers • the delivery of courses in alternative ways • the provision of material in other formats D.2.2.2.2 Legislation • The Disability Discrimination Act 1995, Part III Access to Goods and Services • Special Educational Needs and Disability Act 2001 • The Disability Discrimination Act 1995, Part IV Education Page 107 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture D.2.2.2.3 Who is affected • The Disability Discrimination Act applies to public and private entities providers of goods and services to the public, except the Armed Forces. • The Special Educational Needs and Disability Act establishes legal rights for disabled students in pre- and post-16 education. D.2.2.2.4 How DDA Under the Disability Discrimination Act, small to medium sized businesses have to make “reasonable adjustments” so they do not discriminate against disabled customers or employees. The law has been designed so that organizations only have to make reasonable changes, but if they fail to do what is reasonable, a disabled person could take legal action against them for treating them unfairly. SENDA For a website to comply with The Special Educational Needs and Disability Act 2001 (SENDA) must be built to the very latest W3C standards and recommendations from the very outset. The website should be able to pass at least the very minimum W3C recommended Priority 1 standard for websites (so complying with the 1995 DDA) but it should also remember that the UK Government acknowledge and advise that you really should be looking to pass at least Priority 2 and it should still be asking the website development company what extra functionality they have included in your website design to aid disabled visitors to the website. The whole point of this exercise is to make sure the information on your website is accessible to all, regardless of any disability a visitor may have. The only way to ensure this is to follow accepted W3C recommendations for website construction and compliance in UK law and “pro-actively” introduce added functionality to a website where it is deemed it is necessary. D.2.2.2.5 Relevant documents UK SENDA. Available on-line http://www.opsi.gov.uk/acts/acts2001/20010010.htm. Last check: January 2007 at: 15th UK DDA 1995. Available http://www.opsi.gov.uk/acts/acts1995/1995050.htm. January 2007 at: 15th on-line Last check: Page 108 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture UK DDA 2005. Available http://www.opsi.gov.uk/acts/acts2005/20050013.htm. January 2007 on-line Last check: at: 15th Department for Education and Skills, Ministry of Equal Opportunities. Available on-line at: http://www.dfes.gov.uk/. Last check: 15th January 2007 Disability Policy Division of the Department for Work and Pensions. Available on-line at: http://www.direct.gov.uk/DisabledPeople/fs/en. Last check: 15th January 2007 e-Government Unit. Available on-line at: http://www.cabinetoffice.gov.uk/e-government/. Last check: 15th January 2007 Disability Rights Commission. Available on-line at: http://www.drc-gb.org/. Last check: 15th January 2007 D.2.2.2.6 Additional information List of Web guidelines related publications. Available on-line at: http://egovernment.cabinetoffice.gov.uk/Resources/WebGuidelines/fs/en. Last check: 15th January 2007 Disability Rights Commission Formal Investigation report: web accessibility. Available on-line at: http://www.drcgb.org/library/formal_investigation_report_w.aspx. Last check: 15th January 2007 PAS (Publicly Available Specification) 78 Guide to Good Practice in Commissioning Accessible Websites. Available on-line at: http://www.drc.org.uk/library/website_accessibility_guidance/pas_78.aspx. Last check: 15th January 2007 D.2.2.3 German BITV D.2.2.3.1 Summary On the background of the EU recommendation to adopt WAI, in Germany an approach has been made to match it with the requirements and circumstances of politics and legislation. In 1994 the fundamental law of the Federal Republic of Germany (Grundgesetz, GG) was changed in such a way that a sentence was added to article 3 which said, that nobody may be discriminated because of his or her disability. Page 109 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Another important law for the integration of disabled people was launched in October 2000: The law for the prevention of unemployment for severely handicapped people (Gesetz zur Bekämpfung der Arbeitslosigkeit Schwerbehinderter (SchwbBAG)) manifold measurements like better recruitment conditions, the development of in-house prevention, better information, consulting services and co-operation with relevant cost units lead to a welcomed development that the number of unemployed severely handicapped people could be decreased. With the new legislation, social book IX (SGB IX) and the law on the equalization of opportunities for people with disabilities (Bundesbehindertengleichstellungsgesetz - BGG) the issue of barrier free access at the workplace and to public infrastructure has received a new emphasis in Germany. All the legislation process was performed with participation of organisations of end-users. The definition of barrier free access for people with disabilities to human made infrastructure highlights three characteristics: taking the usual way, without extra effort and basically without assistance. For the first time access to information technology was explicitly taken up in the BGG and particularly barrier free access to the Internet. The 23 of 2002 July were published by the german government, to take effect the 24 of July, the decree on barrier-free information technology (Barrierefreie Informationstechnik Verordnung - BITV) according on article 11 of the german Law of Equality of Opportunities (Bundesbehindertengleichstellungsgesetz - BGG) was officially published by the German Federal Government and entered into force. In order to the support of the implementation the "alliance for barrier free information technology" (Aktionsbündnis barrierefreie Informationstechnik – AbI) has been started with support of the federal government (Federal Ministry for Health and Social Security – BMGS). In cooperation with its partners AbI offers education, web-based information, etc. to support the implementation. The need to support the practical implementation has dramatically increased. Hence, user organisations and experts try to join forces in the alliance AbI. AbI creates a reference for barrier free access to the web in Germany based on the expertise and activities of its members, partners and supporters. Internationally AbI creates relations to relevant actions in eAccessibility, EDeAN, WAI, etc. The international exchange is expected to continue stimulating the realisation of barrier free information technology through benchmarking and co-operation on European and international level. This international exchange has not only to focus on a coherent standard for barrier free internet but also on a unified testing of barrier free Page 110 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture internet. The fact, that Germany has issued explicit legislative documents on web standards requires attention in international developments. If European and international developments consider the legislative situation and requirements, there is a good opportunity for common solutions. < this whole section needs to be editied for good english usage as it quite confusing as it is Stefan><also I stopped editing at this point as I ran out of time, the rest of the document has not been checked for writing quality – I did look at content and it is OK> D.2.2.3.2 Legislation • Act on Equal Opportunities for Disabled Persons of 27 April 2002 • ([German] Gesetz zur Gleichstellung behinderter Menschen und zur Änderung anderer Gesetze vom 27. April 2002) D.2.2.3.3 Who is affected • It covers the public sector including state agencies and municipalities. • For the private sector the instrument (Zielvereinbarungen) can be applied. of targeted agreements D.2.2.3.4 How The law completely is based on the Directives of Accessibility for the Content Web of the WAI (WCAG 1.0), gathering each one of its guidelines written up in legal terms. The decree establishes two levels of application priority: PI and PII. PI is obligatory for all the sites of the federal government, whereas PII is demanded additionally to the pages of entrance of the sites. To fulfill level PI corresponds to fulfill the level Doble A (AA) of the WAI and when fulfilling the PI and the PII it is fulfilled Triple A (AAA) of the WAI. This ordinance shall apply to: 1. websites and webpages, 2. websites and webpages which are publicly accessible, and 3. graphic user interfaces created on the basis of information technology which are publicly accessible of authorities of the Federal Administration. The intention of the design of IT and internet facilities (section 1) in accordance with this ordinance shall be to enable disabled persons within the meaning of section 3 of the Act on Equal Opportunities for Disabled Page 111 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Persons, who can only use information technology to a limited extent unless additional conditions are fulfilled, to access it. D.2.2.3.5 Relevant documents Ordinance on Barrier-Free Information Technology ([German] Barrierefreie Informationstechnik-Verordnung – BITV). Available on-line at: (German) http://www.einfach-fuer-alle.de/artikel/bitv/. (English) http://www.einfachfuer-alle.de/artikel/bitv_english/. Last check: 15th January 2007 D.2.2.4 Italian Stanca D.2.2.4.1 Summary In general terms, the National level legislation defines the overall framework of law, while Regional Governments are responsible for enacting detailed rules at local level. The right to participate to society as citizens on equal foot – and receive the same services – is stated in many documents, the most relevant being the Italian Constitution issued in 1948 (art. 3 states that all citizens must be regarded as equal independently on "…sex, race, language, religion, political opinion, personal condition and social condition…"). Although this statement can read as anti-discrimination principle, it took time to be understood in its full implications related to senior citizens or people with disabilities. The Framework Law on Handicap (L 104/92), among other things, commits the Government to undertake initiatives for improving accessibility of television and telephone services to people with sensory impairment, and to facilitate diffusion of ICT among people with disabilities. Concerning Internet access, the Government established (Cabinet Resolution 13/3/2001, Ministry of Public Function) the principle that any website of the Public Administration should be accessible to any person including people with disability. Relevant accessibility specifications have been developed by an inter-departmental working group to prepare national guidelines for usability and accessibility of websites. The 17 of January of 2004, the Italian Parliament approved, unanimously, the “Legge Stanca”. It is a holistic approach that includes training of public employees (technicians and users), the focus is clear on ICT and will include research activities. It is a shared consensus compliant with international rules. The Inter-Ministerial Committee as a permanent instance is built out of seven ministers that focus on ICT for disabled, elderly and disadvantaged people. Page 112 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The Stanca Act establishes that the Republic recognizes the right of the citizens with disabilities to accede to all the sources of intelligence and service public, in agreement with article 3 of the Italian Constitution and that the law is also applied to all the used educative materials in any level of scholastic education. It also defines the modalities of application of the law as far as the observation of the central and local public administration. D.2.2.4.2 Legislation • Provisions to support the access to information technologies for the disabled, Jannuary 2004 • ([Italian] Legge Stanca - "Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici") D.2.2.4.3 Who is affected • The Stanca Act defines the application dominion, with a list of public institutions and concessionary private organizations of services public. • Private entities that they proportionate goods and services or bought and that receive public subventions, if these services go directed to the citizens or workers with disabilities, must be accessible. • It is also applied to all the used educative materials in any level of scholastic education. D.2.2.4.4 How • In any contract of supplying or it buys related to services of technologies of the information and the communication, the accessibility requirements have the highest priority with respect to any other requirement, in individual, will be cancelled all contracts for the creation or modification of Web sites public who do not demand the accessibility. • All the public administrations must include the subject of the accessibility in all the programs of formation of their employees. • The goods and services proportionate or bought by private organizations that receive public subventions must be accessible. • The departments of the Italian Government can make accessibility verifications on the private Web sites and the computer science applications, to emit an accessibility label. D.2.2.4.5 Relevant documents Law Stanca. Available on-line at: (Italian) http://www.camera.it/parlam/leggi/04004l.htm. (English)http://www.pubbliaccesso.it/normative/law_20040109_n4.htm. Last check: 15th January 2007 Page 113 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture D.2.2.4.6 Additional information Act nr. 3486: Norms for the right to access to the services and the resource of public administrations and public utilities for people with disabilities. (Italian). Available on-line at: http://www.senato.it/leg/14/BGT/Schede/Ddliter/18816.htm. Last check: 15th January 2007 D.2.2.5 Australian DDA D.2.2.5.1 Summary There is no specific accessibility legislation in Australia. The current situation is affected by several regulations based on territory or state resources. That legislation includes the Western Australian Equal Opportunity Act 1984, Tasmanian Anti-Discrimination Act 1998 and Australian Capital Territory Discrimination Act 1991. The Disability Discrimination Act (DDA) of 1992 administered by the Human Rights & Equal Opportunity Commission (HREOC) concentrated the focus on web accessibility as a result out of it. The Act was reviewed in detailed by the Productivity Commission in 2004 to guarantee a current and effective status. Regarding Accessibility guidelines Australia uses as a set of guidelines the W3C Web Content Accessibility Guidelines (W3C WCAG). Beyond these the Guidelines for Commonwealth Information Published in Electronic Formats (AusInfo Guidelines) provide details on preparing information in the most accessible format to meet the needs of particular audiences. Throughout these guidelines, particular recommendations are supported by references to original government sources. On educational issue DDA determines that it is unlawful for an educational authority to discriminate against a student on the ground of the student's disability or a disability of any of the student's associates by denying the student access, or limiting the student's access, to any benefit provided by the educational authority, or by expelling the student, or by subjecting the student to any other detriment. Also DDA determines that it is unlawful for an education provider to discriminate against a person on the ground of the person's disability or a disability of any of the person's associates by developing curricula or training courses having a content that will either exclude the person from participation, or subject the person to any other detriment, or by accrediting curricula or training courses having such a content. D.2.2.5.2 Legislation Page 114 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture • Western Australian Equal Opportunity Act 1984 • Tasmanian Anti-Discrimination Act 1998 • Australian Capital Territory Discrimination Act 1991 • Disability Discrimination Act 1992 D.2.2.5.3 Who is affected • All public and private entities providers of goods and services D.2.2.5.4 How • DDA tries to eliminate, as far as possible, discrimination against persons on the ground of disability in the areas of: work, accommodation, education, access to premises, clubs and sport, the provision of goods, facilities, services and land and the administration of Commonwealth laws and programs. • The Accessibility guidelines of Australia uses as a set of guidelines the W3C Web Content Accessibility Guidelines (W3C WCAG). D.2.2.5.5 Relevant documents Disability Discrimination Act 1992. Available on-line at: http://scaletext.law.gov.au/html/pasteact/0/311/top.htm. Last check: 15th January 2007 World Wide Web Access: Disability Discrimination Act Advisory Notes. Available on-line at: http://www.hreoc.gov.au/disability_rights/standards/www_3/www_3.html. Last check: 15th January 2007 Accessibility of electronic commerce and new service information technologies for older Australians and people with a disability. Available online at: http://www.hreoc.gov.au/disability_rights/inquiries/ecom/ecomrep.htm. Last check: 15th January 2007 The Guide to Minimum Website Standards – Accessibility. Available on-line at: http://www.agimo.gov.au/practice/mws/accessibility/. Last check: 15th January 2007 Better Practice Examples – Accessibility. Available on-line at: http://www.agimo.gov.au/practice/delivery/examples/accessibility/. Last check: 15th January 2007 Page 115 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture A Brief Guide to the [Australian] Disability Discrimination Act from the Human Rights Commission. Available on-line at: http://www.hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm. Last check: 15th January 2007 D.2.2.5.6 Additional information Accessible E-Commerce in Australia: A discussion paper about the effects of electronic commerce developments on people with disabilities" by Tim Noonan, for Blind Citizens Australia. Available on-line at: http://www.bca.org.au/ecrep.htm. Last check: 15th January 2007 Decision of HREOC in SOCOG case. Available on-line at: http://www.humanrights.gov.au/disability_rights/decisions/comdec/2000/D D000120.htm. Last check: 15th January 2007 Digital Divide Narrows for People with Disabilities - HREOC Press Release October 2002. Available on-line at: http://www.hreoc.gov.au/media_releases/2002/56_02.html. Last check: 15th January 2007 Internet still covered under Australian Discrimination Law - HREOC Press Release September 2002. Available on-line at: http://www.hreoc.gov.au/media_releases/2002/72_02.html. Last check: 15th January 2007 D.2.2.6 Spanish LSSICE and LIONDAU Summary In Spain two laws exist on the society of the information, the universal accessibility and the attention to disability people: • Law 34/2002, of 11 of July, Services of the information society and electronic commerce (LSSICE) • Law 51/2003, of 2 of December, of equality of opportunities, nondiscrimination and universal accessibility of the people with disabilities (LIONDAU) Plus the law of Promotion of the Personal Autonomy and Attention to people in dependency situation. a) Law LSSICE defines an ample concept of “services of the society of the information”, that it includes, in addition to the hiring of goods and services by electronic way, the provision of information by this means (like which Page 116 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture they carry out the newspapers or magazines that can be in the network), the activities of intermediation relative to the provision of access to the network, to the data transmission by networks of telecommunications, to copy the temporary accomplishment of the pages of Internet asked for by the users, to the lodging in the own servants of information, services or applications facilitated by others or to the provision of instruments search or of connections to other sites of Internet, as well as any other service that is lent to individual request of the users (unloading of archives of audio video or…), whenever it represents an economic activity for the lender. These services are offered by the operators of telecommunications, the suppliers of access to Internet, the vestibules, the engines search or any other subject who have a site in Internet through which he makes some of the indicated activities, including the electronic commerce. Also, a series of oriented forecasts is contemplated in the Law to make the accessibility effective of the people with disability to the information provided by electronic means, and very specially to the information provided by the Public Administrations, commitment to which the resolution of the Council of the European Union of 25 of March of 2002 talks about, on accessibility of the Web sites public and of its content. b) Law LIONDAU is based and puts of relief the concepts Nondiscrimination, positive action and universal accessibility. of: The law anticipates, in addition, the regulation of the effects of the language of signs, the reinforcing of the social dialogue with the representative associations of the people with disability by means of its inclusion in the Real Patronage (Real Patronato) and the creation of the National Council of the Disability (Consejo Nacional de la Discapacidad), and the establishment of a calendar of accessibility by law for all new or already existing environments, products and services. In the law to measures of innovation and development of technical standards are contemplated as well as the Language of signs (final disposition twelfth): The government has approved the Project of Law of Language of Signs and it has sent it to the Cortes. In order to administer the set up of the LIONDAU the elaboration of planning instruments was considered advisable, and to the time of their writing two plans were designed: the “National Plan of Accessibility 20042012” and the “II Plan of Action for the people with disability 2003-2007”. c) Moreover, the law of Promotion of the Personal Autonomy and Attention to people in dependency situation (Law 39/2006, of 14 of December) regulates the basic conditions of promotion of the personal autonomy and attention to the people in situation of dependency by means of the creation Page 117 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture of a System for the Autonomy and Attention to the Dependency, with the collaboration and participation of all the Public Administrations. It serves as channel for the collaboration and participation of the Public Administrations and to optimize the private or public resources available. It is based on the principles of universality, fairness and accessibility. D.2.2.6.1 Legislation • Law 34/2002, of 11 of July, Services of the information society and electronic commerce • ([Spanish] LEY 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico (LSSICE), 2002) • Law 51/2003, of 2 of December, of equality of opportunities, nondiscrimination and universal accessibility of the people with disabilities • ([Spanish] LEY 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad (LIONDAU), 2003) • Law 39/2006 of Promotion of the Personal Autonomy and Attention to people in dependency situation • ([Spanish] LEY 39/2006, de 14 de Diciembre, de Promoción de la Autonomía Personal y Atención a personas en situación de dependencia, 2006) • Norm 139803:2004: “Requisite of Accessibility for Contents in the Web” • ([Spanish] Norma 139803:2004: "Requisitos de Accesibilidad para Contenidos en la Web", 2004) D.2.2.6.2 Who is affected • The law LSSICE is applied to any supplier entity of goods and services by electronic way, the provision of information by this means, the activities of intermediation relative to the provision of access to the network, to the data transmission by networks of telecommunications, to copy the temporary accomplishment of the pages of Internet asked for by the users, to the lodging in the own servants of information, services or applications facilitated by others or to the provision of instruments search or of connections to other sites of Internet, as well as any other service that is lent to individual request of the users (unloading of archives of audio video or…), whenever it represents an economic activity for the lender. • The law LIONDAU is applied to any entity in the scope of the telecommunications and society of the information, spaces urbanized public, infrastructures and construction, transports, goods and services to disposition of the public and Relations with the Public Administrations Page 118 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture D.2.2.6.3 How Law LIONDAU establishes, gradual and progressive the obligation of which all the environments, products and services must be opened, accessible and practicable to all the people and has terms and calendars to accomplishment the necessary adaptations. With respect to products and services of the Society of the Information the law establishes: 1. In the term of two years from the take effect of this law, the Government will approve, as planned in article 10, basic conditions of accessibility and nondiscrimination for the access and use of the technologies, products and services related to the society of the information and any social mass media, that will be obligatory in the term of four to six years from the take effect of this law for all products and new services, and in the term of eight to ten years for all those existing ones that are susceptible of reasonable adjustments. And favoring the formation in design for all: “The Government, in the term of two years from the take effect of this law, will develop a training curricula in “design for all”, all the educative programs, including the college students, for the formation of professionals in the fields of the design and the public construction of the physical environments, construction, infrastructures and works, the transport, the communications and telecommunications and the services of the society of the information”. On accessibility the law says, in its additional dispositions: “Accessibility for the people with disability and of age outpost to the information provided by electronic means”. 1. The Public Administrations will adopt the measures needed so that the information available in its Internet pages can be accessible to people with disability and to elderly people according to the accessibility criteria recognized before the 31 of December of 2005. Also, the Public Administration could require that the Internet pages funded by them follow the criteria of accessibility previously mentioned. 2. Also, the adoption of norms of accessibility by the lenders of services and the manufacturers of equipment and software will be fostered, to facilitate the access of the people with disability or elderly people to the digital contents. Page 119 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The norm 139803:2004 is totally compatible with the Directives of Accessibility for the Content Web 1.0 of the WAI, and it even contains annexed in which equivalence between the points of the Spanish norm appears and those of these directives. D.2.2.6.4 Relevant documents Law LSSICE (Spanish). Available on-line at: http://www.congreso.es/public_oficiales/L7/CONG/BOCG/A/A_068-13.PDF. Last check: 15th January 2007 Law LIONDAU (Spanish). Available http://www.sidar.org/recur/direc/legis/liondaupcd.pdf. January 2007 on-line Last check: at: 15th Law 39/2006 of Promotion of the Personal Autonomy and Attention to people in dependency situation (Spanish). Available on-line at: http://www.imsersomayores.csic.es/documentos/legislacion/normas/doc3383.pdf. Last check: 15th January 2007 D.2.2.6.5 Additional information Spanish legislation about Information Society Accessibility. Available on-line at: http://www.sidar.org/recur/direc/legis/espa.php. Last check: 15th January 2007 D.2.2.7 European Union D.2.2.7.1 Summary At the European Council in Lisbon in March 2000, Heads of State and the Government of the European Union launched a strategy to prepare the EU for the challenges of the new century. This has become known as the "Lisbon Strategy". The objectives set at Lisbon – higher growth, more and better employment and greater social inclusion – were ambitious and Information and communication technologies (ICT) were identified as playing a key role in achieving them. In response to this, the European Commission launched the eEurope initiative in June 2000 with the aim of accelerating Europe's transition towards a knowledge-based economy, and to realize the potential benefits of higher growth, more employment and faster access for all citizens to the new services of the information age. Page 120 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture The first phase of eEurope was the eEurope 2002 Action Plan, which comprised a total of 64 targets to be achieved by end 2002. The majority of these were successfully completed, and in June 2002, the European Council launched a second phase, eEurope 2005, which focuses on exploiting broadband technologies to deliver online services in both the public and private sector. The mid-term review of the eEurope 2005 Action Plan has confirmed that its main targets are valid until end 2005. From the 31 of March of 2004 we had this directive 2004/18/CE of the European Parliament and the Council whom it demands that in all the procedures of contract awarding public of the countries member: “As far as possible, the adjudicators must establish technical specifications in order to consider the accessibility criteria of people with disability or the design for all the users. These technical specifications must be clearly stated, so that all the bidders know what is includes in the requirements established by the adjudicator”. The European Commission's view of the challenges that need to be addressed in a European Information Society strategy up to 2010 are set out in a Commission communication on "Challenges for Europe's Information Society beyond 2005: Starting point for a new EU strategy", adopted on 19 November 2004. This communication highlights the need to step up research and investment in information and communication technologies (ICT), and to promote their take-up throughout the economy. ICT should be more closely tailored to citizens' needs and expectations, to enable them to participate more readily in socially fulfilling and culturally creative virtual communities. The Commission communication identifies a number of challenges that will remain relevant for Europe's future Information Society policy, such as electronic inclusion and citizenship, content and services, public services, skills and work, ICT as a key industry sector, interoperability, trust and dependability and ICT for business processes. The European Commission has launched a public consultation on how best to make information and communication technologies (ICT) available to all, including the disabled and the elderly. This consultation suggests introducing new legislation to remove the technical challenges and difficulties faced by some EU citizens when trying to use electronic products or services such as computers, mobile phones or the Internet. The public consultation focuses on three areas identified by the Commission as key to promoting what it defines as 'e-accessibility': public procurement, certification, and the use of legislation. The results of the consultation and the various inputs will feed into a Commission communication on eaccessibility, to be adopted by June 2005. Page 121 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture D.2.2.7.2 Legislation Resolution of the Council on “electronic Accessibility” - To improve the access of the people with disability to the society of the knowledge: Resolution of the 14 of January of 2003. One is a legislative act by which Member is urged to the States to carry out a series of measures to foment the electronic accessibility. Available on-line at: http://register.consilium.eu.int/pdf/es/03/st05/st05165es03.pdf. Last check: 15th January 2007 Directive 2004/18/CE of the European Parliament and the Council, 31 of March of 2004, on coordination of the procedures of awarding of contracts public of works, provision and services, published in the pages of EuroLex. Available on-line at: http://europa.eu.int/eurlex/lex/LexUriServ/LexUriServ.do?uri=CELEX:32004L0018:EN:HTML. Last check: 15th January 2007 D.2.2.7.3 Who is affected • To all the states member of the European Union • To those companies contract awardees European public D.2.2.7.4 How • The states member will have to adapt their legislations to the European directives in the established terms D.2.2.7.5 Relevant documents 24 April 2002, PE 309.096 A5-0147/2002 on the Commission communication eEurope 2002: Accessibility of Public Web Sites and their Content (COM(2001) 529 – C5:0074/2002 – 2002/2032(COS)). Available on-line at: http://www.europarl.europa.eu/sides/getDoc.do?pubRef=//EP//TEXT+REPORT+A5-2002-0147+0+DOC+XML+V0//EN. Last check: 15th January 2007 eEurope 2000-2001, An Information Society for All, Participation for all in the knowledge-based economy, 2001. Available on-line at: http://europa.eu.int/information_society/eeurope/2005/index_en.htm. Last check: 15th January 2007 Page 122 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Text of HEART Study Horizontal European Activities in Rehabilitation Technology. Available on-line at: http://www.w3.org/WAI/EO/heart.html. Last check: 15th January 2007 Europe's Information Society - eContentplus programme. Available on-line at: http://europa.eu.int/information_society/activities/econtentplus/index_en.h tm. Last check: 15th January 2007 Plan of Action e-Europe 2005 (Spanish). Available http://www.sidar.org/recur/direc/eeuro/eeurope2005_en.pdf. 15th January 2007 on-line at: Last check: Additional information Different performances relative to the initiative e-Europe (Spanish). Available on-line at: http://www.sidar.org/recur/direc/eeuro/index.php D.2.2.8 International D.2.2.8.1 Summary: The United Nations developed the Uniform Norms on the equality of opportunities for the people with disability. Resolution Approved by the General Assembly of the UN, 20 of December of 1993. Although the Uniform Norms were written up before the recent one and significant expansion of the networks and technologies of the information and the communication in many countries, norm 5 provides a useful guide for the design and the defense of policies. Explicitly it says: “Article 5. Possibilities of access The States must recognize the global importance of the possibilities of access within the process of obtaining the equality of opportunities at all the spheres of the society. For the people with disabilities of any nature, the States must a) establish programs of action so that the physical surroundings are accessible and b) to adopt measures to guarantee the access to the information and the communication.” D.2.2.8.2 Legislation The Uniform Norms on the equality of opportunities for the people with disability. Resolution Approved by the General Assembly of the UN, 20 of December of 1993. Page 123 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture D.2.2.8.3 Relevant documents Disability and the United Nations. Available on-line at: http://www.un.org/esa/socdev/enable/disunandpwd.htm. Last check: 15th January 2007 United Nations Documents. Resolutions, decisions and recommendations on persons with disabilities. Available on-line at: http://www.un.org/esa/socdev/enable/disparl.htm. Last check: 15th January 2007 D.2.2.9 Other Countries D.2.2.9.1 Portugal Portugal is the first European country that adopts concrete measures on the accessibility of the pages Web of the Public Administration. “Resolução de Conselho de Ministros Nº 97/99”, tries to assure that of the presented/displayed Public Administration in Internet is able of being collected and being included/understood by the citizens with special necessities, determining that the technical solutions are adopted to reach this objective. Resolução de Conselho de Ministros Nº 97/99. Available on-line at: http://www.acesso.umic.pcm.gov.pt/acesso/res9799_en.htm. Last check: 15th January 2007 D.2.2.9.2 Ireland In Ireland the accessibility of the Technologies of the Information and the Communication is cover by the Act for the Equality in the Use, of 1998, and by the Act for the Equality of States, of 2000. In addition, the public policies specially demand the governmental departments that their Web sites are accessible and agreed with the levels of priority 1 and 2 of the Directives of Accessibility for the Content Web of the WAI (WCAG 1.0). The Irish National Disability Authority offers applicable information and documents on the legislation and norms in Ireland. Ireland legislation. Available on-line at: http://www.accessit.nda.ie/policy_and_legislation.html. Last check: 15th January 2007 D.2.2.9.3 Sweden Page 124 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture At the beginning of the month of June of 2002, the Agency for the Public Management (Statskontoret) presented/displayed the directives for the design of the Web sites public, including the application of the Directives of the WAI, in a called document: “they 24-timmarswebben” (the 24 hours of the Web site). D.2.2.9.4 Brazil The 2 of December of 2004 were published Decree 5296, that it regulates laws 10,048, of 8 of November of 2000, that gives priority of attention to the people whom it specifies, and 10,098, of 19 of December of 2000, that establishes general norms and basic criteria for the promotion of the accessibility. The decree defines the concepts of accessibility barrier, technical assistance and of universal design and, in article 47, it marks a term of 12 months from its publication from which “it will be obligatory the accessibility to the web sites of the public administration in the world-wide network of computers (Internet), for the use of the people with visual deficiency, guaranteeing the total access to them to the information available” In addition, in Chapter VIII, it indicates that the National Program of Acessibilidade has like mission, among others, the one to make the support and improvement of the legislation on accessibility, and the organization of studies, campaigns, aids and the study and proposal of creation and normalization of a national seal of accessibility. Decree 5296. Available on-line at: http://www.deficiente.com.br/modules.php?name=News&file=article&sid=7 59. Last check: 15th January 2007 D.2.2.9.5 Peru Law 28530 “Law of Promotion of Access to Internet for people with disability and adjustment of the physical space of the Internet cabins”, took effect the 25 of September of 2005. According to the text of the law: “Article 3º. - Adjustment of web sites of the public organizations and the universities. They must incorporate in their web sites of Internet access options so that the people with visual disability can accede to the information who contain.” Law 28530 “Law of Promotion of Access to Internet for people with disability and adjustment of the physical space of the Internet cabins” (Spanish) Page 125 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Available on-line at: http://www.congreso.gob.pe/ntley/imagenes/Leyes/28530.pdf. Last check: 15th January 2007 D.2.2.9.6 Other References European Union. Available on-line at: (Spanish)http://register.consilium.eu.int/pdf/es/03/st05/st05165es03.pdf. (English)http://www.europarl.europa.eu/sides/getDoc.do?pubRef=//EP//TEXT+REPORT+A5-2002-0147+0+DOC+XML+V0//EN (Spanish)http://www.sidar.org/recur/direc/legis/euro.php Last check: 15th January 2007 United Nations. Available on-line at: http://www.un.org/esa/socdev/enable/disunandpwd.htm. Last check: 15th January 2007 SAP Design Guild - Accessibility Legislation. Available on-line at: http://www.sapdesignguild.org/editions/edition9/policies2.asp. Last check: 15th January 2007 Portugal. Available on-line at: (Portuguese) http://www.acessibilidade.net/. Last check: 15th January 2007 Page 126 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Annex E Open Systems Page 127 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture E.1 Existing Open Systems In this section we have identified some existing open systems for building oriented web applications that can serve as a starting point for the EU4ALL architecture. E.1.1 ORCHESTRA The integrated project ORCHESTRA (Open Architecture and Spatial Data Infrastructure for Risk Management, IST Integrated Project no. 511678) is one of the projects funded by the European Commission to cover the “Improving risk management” strategic objective of the Information Society Technology (IST). The overall goal of ORCHESTRA is the design and implementation of an open, service-oriented software architecture as a contribution to overcome the interoperability problems in the domain of multi-risk management. Furthermore, the application of numerous and different policies, procedures, data standards and systems, results in co-ordination problems with respect to data analysis, information delivery and resource management, all critical elements of risk management. In addition, emerging specifications out of the INSPIRE[1] and GMES[2] initiatives will be incorporated. Software adhering to the ORCHESTRA architecture will be able to interoperate, to a certain extent even at a semantic level, and organisations will be able to cooperate much more efficiently than it is currently possible. Public information about the ORCHESTRA project is available under http://www.eu-orchestra.org. E.1.2 Zope Zope is an open-source, object-oriented web application server written in the programming language Python. Zope stands for "Z Object Publishing Environment." It can be almost fully managed with a web-based user interface. Zope publishes on the web Python objects that are typically persisted in an object database, ZODB. Basic object types, such as documents, images, page templates, are available for the user to create and manage through the web. Specialized object types, such as wikis, blogs, and photo galleries, are available as third-party add-ons (called Zope products). Zope is an application server, a web server, and a content management system all in one. It is a complete, self-contained solution, that includes a Page 128 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture object database, web services architecture, and programming capabilities. It is designed for customization and extensibility. However Zope only provides SCORM as Educational Standards in one of his products (Zschool). E.1.3 OpenACS OpenACS (Open Architecture Community System) is an advanced toolkit for building scalable, community-oriented web applications. It provides a collection of pre-built applications and services that can be used to build services and applications through a modular architecture (dotLRN, dotFolio, etc.). OpenACS runs on the multi-threaded AOLserver web server and uses pooled database connection. The OpenACS architecture is very modular, providing a component package system for easy integration, installation and upgrading of components. The core packages of OpenACS provides a content management system, users management, security and permission features, internationalization, templating system to separate content from code, an object system that resides on top of the database, permitting site developers to create complex applications using an object API. OpenACS provides also most of the technical standards used in a web application, support to web services and the IMS suite Educational Standards. Given its flexibility, the implementation and integration of new developments in OpenACS is straightforward. New set of components can be easily added to provide services for specific applications. With regards to that matter, it is worth noting that many applications have already been developped by the OpenACS community to fullfil educational needs. E.1.3.1 References OpenACS wiki. Available on-line at: http://openacs.org/xowiki/. Last check: 11 of April, 2007. E.1.4 IEEE Learning Technology Systems Architecture It is part of the IEEE LTSC (Learning Technology Standards Committee). The objective is to define a framework of reference at architectural level for Page 129 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture educational systems. It is neutral at pedagogical, content, cultural and implementation levels. The objectives are: • Component reuse. • Independence between content and access to the content, enabling the adaptation of the learning experience for each user. • Scalability, through independant components. • Interoperability with other systems, through interface definition. • Maintenance, through its architecture divided in layers and components E.1.5 Sakai Sakai is an open source on-line collaboration and learning environment which supports teaching and learning, ad hoc group collaboration, support for portfolios, and research collaboration. The Sakai architecture consists of an abstract architecture and a design based on Java. E.1.5.1 Sakai Architecture E.1.5.1.1 Abstract Architecture The abstract architecture consists on the abstract concepts that constitute an application, environment, or proposed framework. Technology is specifically absent from this description, as that is what a design consists of. The Sakai Java Framework (see below) is an example of an implementation strategy that can be drawn from this. The Sakai architecture consist of the following elements: • Client: Sakai is intended to be run as a client / server application pair. While the majority of the clients will be standard, off the shelf web browsers, customized browsers and other network aware applications may be used in some situations. The majority of Sakai applications will have their output aggregated and presented to the client using a markup language, such as HTML. Specialized clients may communicate directly with Sakai services provided they are enabled for such transactions (content authoring, for example). • Aggregator: The output of one or more Sakai application (and potentially non-Sakai applications as well) can be combined using an aggregator server application. This aggregator allocates and manages screen real estate and certain user interface transactions (to be defined). Support Page 130 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture for accessibility is provided using a combination of standard UI elements in the presentation layer and the aggregator. • Presentation: The presentation layer combines data from a Sakai tool and a user interface description to create a mark up fragment which is aggregated before delivery to the user. The user interface description is ideally contained in a resource external to the software and makes use of standard user interface elements designed to deliver a consistent Sakai user experience. • Tools: A Sakai tool is an application which marries presentation logic with application logic contained in services. Tools provide code to respond to user interface requests and events, which may (or not) modify data managed by services. The tool may draw on services to provide data to the presentation layer. • Services: A service is a collection of classes which manage data via a defined set of behaviors. This data may or may not be persistent across user sessions. Where possible data should be modeled and represented using accepted industry standards. Behavior is represented using a published Application Programming Interface (API). Services may call other services, creating dependencies on them. Services are intended to be modular, reusable and portable across Sakai environments, and potentially to non-Sakai environments also. • System: The system is the server environment which the Sakai environment resides, plus any remote capabilities available to it. This environment may include web servers,database servers, operating systems, file and resource repositories, enterprise and back office systems, etc. E.1.5.1.2 Java Framework The Sakai Java framework provides capabilities to deploy tools and services in a collaborative learning environment. There are a number of different levels of integration between a tool and the Sakai Java Framework. The Sakai Tool Portability Profile (TPP) provides a Sakai-specific unit of expansion that constrains developers but produces tools with a very uniform look and feel and flexibility in rendering technologies. Sakai also provides a mechanism to integrate tools that already exist without major re-write. By allowing multiple approaches developers can choose how to integrate their particular application into Sakai. E.1.5.2 References Sakai Architecture. Available on-line at: http://bugs.sakaiproject.org/confluence/display/ENC/Abstract+Architecture. Last check: 11 of April, 2007 Page 131 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Technical Report Sakai Project. Sakai Java Framework. Available on-line at: http://bugs.sakaiproject.org/confluence/download/attachments/2749/sakaijava-framework-1.doc?version=1. Last check: 11 of April, 2007 E.1.6 Open Knowledge Initiative The Open Knowledge Initiative (O.K.I) develops and promotes that describe how the components of a software environment with each other and with other enterprise systems. O.K.I. enable sustainable interoperability and integration by defining Service Oriented Architecture (SOA). specifications communicate specifications standards for O.K.I. has developed and published the Open Service Interface Definitions (OSIDs), whose design has been informed by a broad architectural view. The OSIDs define important components of a SOA as they provide general software contracts between service consumers and service providers. This enables applications to be constructed independently of any particular service environment, and eases integration. The OSIDs enable choice of end-user tools by providing plugin interoperability. OSIDs are not quite like typical specifications but a kind of conceptual API, which can be expressed in different programming languages. The bindings to these languages are interfaces (or the nearest thing to that concept that the language has). The interfaces require implementations by service providers, which are separate releases by vendors or other contributors. OSIDs are software contracts only and therefore are compatible with most other technologies and specifications, such a SOAP, WSDL. They can be used with existing technology, open source or vended solutions. OSIDs are a local language service definition and bindings of them are provided in Java, PHP, and soon Objective C and C#. Although the OSIDs represent an approach to a Service-Oriented Architecture, it is different from the more protocol-oriented approaches and has some new concepts to offer. The OSIDs themselves are very generic and they use Types as a way of allowing implementation-specific behavior. Developing a community consensus on Types is a crucial part of obtaining interoperability with OKI. The most popular OSID, Repository, has been so successful at interoperability because most of the implementations share at least one common Search Type. The Types themselves are not part of the OKI specification per se; they are expected to be developed by the community as implementations are created. Implementors of OSIDs are strongly encouraged to submit their Types to the community at large. Page 132 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture As new languages are being added, an XML expression of the "conceptual API" has been released (XOSIDs), along with XSLT for transformation into language-specific bindings. E.1.6.1 References OKI. Available on-line at: http://plectrudis.mit.edu/okicommunity/. Last check: 11 of April, 2007 Page 133 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Annex F R&D Projects Page 134 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture F.1 List of related R&D projects The following table shows existing R&D projects that make use of related technologies with EU4ALL requirements. In most of these projects, partners or members of EU4ALL have actively participated. Considering the work done in them assures that the experience gathered in previous developments is taken into account when designing and building the open architecture of services for ALL. In particular, it is foreseen to consider service models at European level, open service architectures providing semantic web services, ontologies and knowledge management techniques, community-oriented web applications and adaptive learning management systems. Moreover, other projects that can provide insight for EU4ALL project are the following: Kaleidoscope, PROLEARN, iCamp, PARCEL, LD Share, ELENA, Embedding Standards, TEP Elderly, iCOLL, PEARL, EARL, MICOLE, METACAMPUS, SEN-IST-NET, OR-WORLD, TENCompetence, TIME2LEARN, CLIFF, TELCERT and e-learn VIP. Page 135 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards LUISA Usage of Semantic Web Services techniques to enhance learning. XML, XML Schema, RDF, OWL-S IEEE, LOM, IMS, AICC, ADL http://www.luisa-project.eu aLFanet Adaptive Learning Management System XML, WebDAV, SOAP, FIPAACL. IMS-LD, IMSLIP, IMS-CP, IMS-QTI, IMSMD http://alfanet.ia.uned.es UNIVERSAL Educational brokerage platform of learning resources XML, RDF, Dublin Core IMS-MD http://www.ist-universal.org/ OPAL Delivers XML SCORM, IMSCP, IMS-MD, IMS-LIP, PAPI. https://www.cs.tcd.ie/Owen.Conlan/publi cations/eLearn2002_v1.24_Conlan.pdf content personalized to the learner’s cognitive and presentation learning preferences Accessibility URL Page 136 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards Accessibility URL OLO Exposes an interface to export the results of LO-to-Learner interaction and for LO adaptation XML, DTD, SOAP IMS-MD, IMSQTI, IMS-LIP UAAG, IMS GDALA3 http://wwwconf.ecs.soton.ac.uk/archive/0 0000211/01/index.html KOD Develops adaptive content in an interoperable and interchangeable format XML, XML Schema IMS-CP, IMSMD, http://ifets.ieee.org/periodical/vol_3_200 1/karagiannidis.html EPICC ePortfolio fully IMS compliant IMS eP http://www.eifel.org/activities/projects/epicc/ IRIS Defines a combined user and RDF, CC/PP and device model to be used for Web Services content negotiation. Encapsulate into a design aid environment work on designfor-all tools and methods; user http://www.irisdesign4all.org/ 3 http://www.imsglobal.org/accessibility/accessiblevers/index.html Page 137 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards Accessibility URL WCAG http://bentoweb.org Accessibility based on user Demonstration of content: http://demo.tribalctad.co.uk/portland_flier modelling theories and methods including users with special needs; guidelines, recommendations and results from work about hypermedia, enrolment and accessibility BenToWeb Benchmarking Tools and Methods for the Web. The work of the BenToWeb project is a mixture of advanced developments in the area Web- benchmarking, quality assurance and compliance (with accessibility requirements). Portland Partnership Content developed for VLE (custom-built by partners) for XML SCORM Page 138 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards adults with severe learning difficulties; responds to user profiles (different input devices and preferences) TATE Health and safety training XML materials for those supporting people with learning difficulties XHTML in employment Educational Standards Accessibility URL IMS-LIP requirements for non-text based visual and auditory content appropriate to cognitive level, accessible by mouse, keyboard and switches. s/index.html Accessibility based on user requirements for non-text based visual and auditory content appropriate to Ongoing Most standards proved not relevant to these learners SCORM IMS-LIP Project website: http://www.portlandpartnership.net/gillmacmillan/ Page 139 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards Accessibility URL cognitive level Dedalos Delivers English (as a second language) online training to deaf people using sign language. XML, XHTML 1.0, CSS SCORM, IMSCP WAI-A WCAG 1.0 http://demo.tribalctad.co.uk/dedalos Mlearning Developed learning methodologies and materials, spanning a wide range of gadgets and functions SMS, MMS, WAP, XHTML 1.0, CSS IMS-LIP At the time there were no specific accessibility standards to cover the wide-spread technologies of mobile learning, but all mobile browserbased content complied with http://www.m-learning.net/ IMS-CP IMS-LOM DAML+OIL SHOE http://www.m-learning.org Page 140 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards Accessibility URL strict XHTML and simple CSS Basic Skills on line for Europe UNITE Multilingual web-based educational and training products and services for learners with basic and lower skills XML, XHTML 1.0, CSS SCORM, IMSCP The main objective is the development of a multilingual framework that consists of a leraning platform providing services to schools and a sustainable repository of reusable eLearning content SMS, MMS, IMS-CP SOAP, WAP, XHTML 1.0, CSS IMS-LOM WAI-A WCAG 1.0 http://www.bsole.com/ Still in progress. The plan is to mask all functionality of the mobile tools behind web services, so that the tools inherit http://www.unite-ist.org IMS-LOM Web services Page 141 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards Accessibility URL the accessibility features of the calling VLE. TELENET modular and inter-operable tele-training platform that addresses the needs of training centres, of users and of instigators XML ORCHESTRA service-oriented software architecture in the domain of multi-risk management XML, SOA, Web Services D4ALLnet D4ALLnet aimed to develop a common platform for discussion and debate, in order to promote and advance DfA practices in the IMS CP, MD, QTI http://www.euorchestra.org/ Networking, collaborative environments http://www.d4allnet.gr/ Page 142 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards Accessibility URL Information Society, raise awareness on Design for All (DfA) through specific outreach activities, and in particular to support the efforts of EDeAN towards the implementation of the e Europe 2002 / 2005 Action Plan. ARIADNE Foundation for the European knowledge pool Server network to share and reuse pedagogical materials Influenced by AICC, IMS, SCORM, IEEE LTSC http://www.ariadne-eu.org/ CEN/ISSS WS-LT (European Model for It aims to provide a European data model and guidelines to define, reference and capture IMS RDCEO (Reusable Definition of Competency or http://www.cenorm.be/cenor m/businessdomains/business domains/isss/activity/wslt.as Page 143 of 144 D2.1.1 Technological infrastructure for an Open and Accessible Service Architecture Name Description Technological Standards Educational Standards Accessibility URL learner learning characteristics competencies ) Educational Objective), IEEE LOM p IEEE LTSC P1484.4 DREL http://ltsc.ieee.org/wg4/ DREL (Digital Rights Expression Language) Formal language to provide the syntax and grammar needed to express conditions and grants related with the use of digital resources, in this case, for e-Learning applications. http://www.imsglobal.org/co mpetencies/index.html Table 1: List of related R&D projects Page 144 of 144