Existing Specifications

The following table provides an overview of existing specifications for the transparency instruments (including the European Credit Transfer System as an integral part of the Europass-DS).

Format of Table Entries [Application Profile Name - optional] of [existing LT Specification Name]

Developing ELM interoperability standards

The establishment of a common framework which is accepted all over Europe demonstrates that European Education has reached a stage of maturity where the recording and exchange of learner mobility information needs to be efficiently supported by technical interoperability standards. Several relevant standardization efforts exist, and significant national expertise has already been accumulated. However, harmonisation is deemed necessary towards a European solution, in order to provide viable support for emerging European learner information systems and dissuade service providers from developing proprietary services and platforms. This solution will support the development of a new generation of technology-enhanced services for learners (learning and employment opportunities exploration), higher educational institutions administrations (certification or augmentation of learner information), employers (work-place descriptions, recruiting and development of learners' competencies) and other stakeholders of learning, education and training throughout Europe, as the European Union and Commission, the Member States and their governments and ministries, etc.

The overall process extends from the elicitation of European requirements to policy consensus and adoption, and, further on, to the actual implementation of open, distributed information systems to support the exchange of learner information throughout Europe, in a transparent manner. The process involves two discrete, yet equally important stages.

• In the policy development stage, agreement is reached on the human, organisational and educational questions as to what information needs to be gathered and exchanged, for what purposes, in what contexts, and how this information should be organised. As far as the realisation of the European Higher Education Area (EHEA) is concerned, the Bologna process constitutes the coordinated effort for the establishment of a European-wide policy, involving frameworks and instruments that aspire to enhance transparency and comparability of qualifications, learner and employment mobility, intra-European and international cooperation. Figure 8 illustrates the steps of this policy development process in terms of national and European activities, the contributing parts, as well as the established and emerging implementation tools (National Qualifications Frameworks (NQF) and European Qualifications Frameworks (EQF), ECTS, Europass transparency documents, etc.).
  
  
• The technical implementation stage is to evaluate currently available interoperability specifications and standards, in order to provide technical formatting of information, thus enabling its accommodation and exchange between systems. In particular, the implementation of interoperating student management systems, capable of managing and exchanging the information structures defined at the policy development stage, requires a technical process, initiated with the analysis and evaluation of technical specifications and standards and concluding with the application profiling of the generic specifications.

Figure 8: Policy development and technical implementation for European learner mobility

Why Application Profiling?

Well established metadata standards for cross-domain and domain-specific information resource description have already been around for quite some time. Dublin Core Metadata and IEEE Learning Object Metadata, among others, are examples of such standards, providing semantic support for a broad range of purposes and business models.

Implementers often make explicit choices on the adoption of a metadata vocabulary for their particular service or system. Although they approve of re-use and acknowledge the importance of interoperability, the pressure to satisfy local requirements often forces adoption of subsets of possible options and interpretations. Indeed, different starting points, different functional requirements and levels of granularity for different things, different views of "reality", justify such practice, which, nevertheless, results to a tension between standard terms and localisations, and ends up hindering interoperability instead of supporting it.

So, what is the right course to be followed? As Godfrey Rust pinpoints [RUST 2005]: "The days of "one size fits all" standards are over...Domains are now overlapping and becoming "liquid"...The challenge now is interoperability and re-purposing", through the building of metadata standards application profiles.

The term Application Profile (AP) denotes the "assemblage of metadata elements selected from one or more metadata schemas and combined in a compound schema. The purpose of an application profile is to adapt or combine existing schemas into a package that is tailored to the functional requirements of a particular application, while retaining interoperability with the original base schemas" (CEN/ISSS WSLT, 2006).

Application profiling provides with the ability to use community or domain-specific metadata standards or component parts of those standards in combination. By following application profiling principles, the implementers of metadata standards are able to assemble the components that they require for some particular set of functions. They are also safe in the knowledge that the assembled whole can be interpreted correctly by independently designed applications (Nilsson, Miles, et. al., 2008).

Building APs involves the following processes (Hillman, 2006):

• Determining the AP scope and purpose: outline of a specific community for the AP (who the target users are; who the stakeholders are; what the political realities are), identification of the community's information exchange needs, participation of metadata aware practitioners, etc.
• Choosing a basic schema (format): research on what others in the domain are using, consideration of stability/volatility of the standard and of how the community for the standard integrates new needs and ideas, documentation of choices and reasoning for attributes for describing terms
• Setting up documentation, decision making and community review processes
• Maintaining realistic expectations: creating an AP takes time, requires organisational effort and persistence may not be a model that can be sustained or re-produced in other communities

In 2008 the Dublin Core Metadata Initiative issued the Singapore Framework for Dublin Core Application Profiles (DCAPs) [DCMI-SF] providing a formalisation for building and documenting APs. The DC notion of the AP imposes no limitations on whether those properties or encoding schemes are defined and managed by the Dublin Core Metadata Initiative or by some agency [NILSSON 2007]. As described in the framework, a DCAP is a packet of documentation containing:

• Functional requirements, describing the functions that the application profile is designed to support, as well as functions that are out of scope
• A domain model, defining the basic entities and their relationships using a formal or informal modeling framework.
• A Description Set Profile, designed to offer a simple constraint language for metadata
• Usage guidelines, describing how to apply the application profile, how the used properties are intended to be used in the application context etc.
• Encoding syntax guidelines, defining application profile-specific syntaxes, if any.

The Diploma Supplement case

The Diploma Supplement has an important role to play to the transparent interpretation and recognition of academic and professional qualifications (diplomas, degrees, certificates) across the diverse European educational systems map, constituting an instrument upon which a high level of agreement on the content and structure has been achieved among the member states. Currently the DS is only issued in paper-based format. A major problem is now the lack of interoperable tools, impeding the reuse of data in existing student management systems for the production of an electronic DS.

The above has been the exact methodological framework for the development of an interoperability specification for the Europass DS.

As a first step, research and extensive study of the EU-defined transparency information structures, their so far application in the European countries and the problems that arise (e.g. security issues), has been conducted. In alignment with the "application profiling culture", there has been a firm decision to investigate the utilisation of currently available interoperability specifications and standards, rather than develop a new isolated specification and to draw on the extensive application profiling experience of transparency documents in European countries such as the UK, Norway, Germany, France and Greece.

This research work has led to the choice of a set of schemas as a "mix and match" basis for the production of the ELM DS specification: the Metadata for Learning Opportunities - Advertising (MLO-AD) [CWA 15903] and its ECTS refinements cover a substantial part of the technical representation aspects of DS information, given that a large subset of HE mobility information is related to the description and referencing on learning opportunities. In addition, ELM DS re-uses the emerging specification on a Credit Information Model, due to its particular capability of representing credit information in learning opportunities and transcripts of results for units of learning. Last but not least, consolidated DC and vCard elements are utilised.