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: [email protected]
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