Diploma Supplement - Core Elements

Skip to end of metadata
Go to start of metadata

WG2: Diploma Supplement - Core Elements

Foreword

This document has been prepared by Technical Committee CEN/TC 353 "Information and Communication Technologies for Learning, Education and Training", the secretariat of which is held by UNI.

This document is currently submitted to the CEN Enquiry.

The "European Learner Mobility (ELM)" Working Item was initiated by Greece in order to address the identified need for providing a harmonized solution for the recording and exchange of learner mobility information as defined by the European Transparency instruments. The results of this work will contribute to the effort towards interoperable European-wide IT systems that manage and exchange Europass related information.

The EuroLM work is expected to result in a multipart standard, however in this phase the main focus will be on the Europass Diploma Supplement (DS).

The development of the proposed standard has been carried out within the context of the CEN/ISSS WSLT project "Guidelines for a European Learner Mobility Model". Experts from the National Bodies of Greece, UK, Norway, Germany and Spain have mainly led the development activities. The substantial contribution of individual experts representing the National Europass Center of Italy and the Rome Student Systems and Standards Group of software implementers and stakeholders in the European Higher Education domain is highly acknowledged.

Introduction

The enhancement of learner mobility and employability is undoubtedly a high priority action item within the European Education Area. The establishment of the European Credit Transfer System (ECTS) and Europass as a framework for the transparent description of qualifications and competences provides the common basis for the well-structured recording of all opportunities for life-long learning including European higher education structures and learners' private / institution-owned information.

The establishment of a common framework which is accepted all over Europe demonstrates that European Education has reached a maturity stage 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, harmonization 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 DS is considered one of the most important Europass documents, having an essential role in the transparent interpretation and recognition of academic and professional qualifications (diplomas, degrees, certificates) across the diverse European educational systems map. In particular, the EDS aims at:

  • Promoting transparency within and between higher education systems;
  • Providing accurate and up-to-date information on an individual's qualifications;
  • Aiding mobility and access to further study and employment abroad;
  • Providing fair and informed information relating to qualifications; and
  • Facilitating academic and professional recognition and thus increasing the transparency of qualifications.

The DS constitutes an instrument upon which a high level of agreement on the content and structure has been achieved among the EU member states. Indeed, most of the European countries have taken up the DS initiative and have specified their national variants of DS, in most cases being minor variations of the Europass DS. However, currently the DS is mostly issued in paper-based format. In cases where it is issued electronically, the DS is represented in a proprietary manner. A major problem is now the lack of interoperable tools, impeding the recording and/or reuse of data in existing learning management systems for the production of an electronic DS and the exchange of information among interested parties.

Scope

The EuroLM-DS is a proposed standard supporting the recording and exchange of DS information among learner information systems, as well as the aggregation of information by third party suppliers.

The EuroLM-DS has been developed as:

  • a lightweight standard taking into consideration existing and emerging business processes
  • an easy-to-implement standard in order to ensure a rapid uptake by stakeholders of learning, education and training throughout Europe (Higher Education Institutions, learners, employers, service providers, etc.)

The EuroLM-DS is based on a data model expressing information of a learner's qualification, in full compliance with the Europass requirements, needed for the general purposes of:

  • the exploitation of academic achievements abroad: in continuing education or in seeking job opportunities
  • the admission of students or graduates in home and European universities: acknowledgment of credits or transfer of credits accumulated in home institutions moving from one university to another.
  • the expression of the level, content and nature of qualifications to potential employers both nationally and at a European level.
  • the enhancement of internal and European student mobility, from a university to another, or from one branch of studies to another.
  • the proper integration of foreign workers into a country's employment setting.
  • the normalization of higher education qualifications, either in academic or non academic paths.
  • the establishment of good practices in the recognition procedures of qualifications among Higher Education Institutions.

Normative References

[OJ L 390, 31.12.2004], DECISION No 2241/2004/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 15 December 2004 on a single Community framework for the transparency of qualifications and competences (Europass)
[CWA 15903], Metadata for Learning Opportunities (MLO) - Advertising
[CWA XXXXX], [Credit Information Model]
[CWA YYYYY], ECTS Refinements of Metadata For Learning Opportunities
[ISO 15836], Information and documentation - The Dublin Core metadata element set

Other References

See also References.

[DCMI-SF] DCMI Singapore Framework http://dublincore.org/documents/singapore-framework/
[DCMI-TERMS] Dublin Core Metadata Initiative: Terms 1.1
[DCMI-DSP] DCMI Description Set Profile http://dublincore.org/documents/2008/03/31/dc-dsp/
[W3C-DTF] W3C DateTime Format
[W3C-RDFS] W3C Resource Description Framework Schema Language 1.0 http://www.w3.org/TR/rdf-schema/
[W3C-VCARD] W3C Note: Representing vCard Objects in RDF/XML http://www.w3.org/TR/vcard-rdf
[IETF-RFC2396] Uniform Resource Identifier
[IETF-RFC2426] vCard MIME Directory Profile
[UML] Unified Modelling Language, v2.1.2 http://www.omg.org/spec/UML/2.1.2/
[ORM] Object-Role Modeling version 2 (ORM 2), http://www.orm.net/

Terms and Definitions

See Definitions.

Diploma Supplement Model

It is recommended that the DS specification is developed in accordance with the the Singapore Framework for application profiles defined by the Dublin Core Metadata Initiative (DCMI-SF).

  • Conceptual Model

The following diagram is a draft idea for the development of a high-level working model for the Diploma Supplement domain. It focuses on the illustration of the main participating entities and on the detailed relations among these entities, in order to enhance the semantic clarity of the Abstract Model.

This version of the diagram follows the conventions of Object-Role Modelling (alias NIAM).

PDF version for printing/viewing

SVG version for editing

Domain Model

  • (Simon, Geir, Christian)

This section defines the domain model of EuroLM-DS. The EuroLM-DS model describes the Diploma Supplement Document consisting of:

  • a Learner instance, representing the learner/holder of the qualification,
  • a Provider instance, representing the awarding institution,
    and, optionally,
  • a Diploma instance, comprising information about the learning opportunity, at programme level, leading to the described qualification, as well as the actual result for the specific learner
  • a Transcript instance, containing LearningOpportunity instances representing the component units, each of which contains provider, credit, and result information.
  • an Additional Information property containing a description of additional achievement information.

Figure 2. illustrates the domain model in UML. Attention is drawn to UML for an explanation of the underlying semantics of this diagram. Each box in the diagram relates to a Class defined in this standard (see section Classes). Each named association (line with label) in the diagram represents a Property defined in this standard (see section Associations). Arrows on named associations indicate the direction in which traversal between instances can occur. No cardinality is specified for any association. Lines with an unfilled diamond shape represent an association with an aggregation relationship, indicating that one class is a part of another class. Lines with an filled diamond shape represent another form of the aggregation relationship, where the child class's instance life cycle is dependent on the parent class's instance life cycle.

Larger image

EuroLM-DS Classes


URI: elm:Learner
  Label: Learner
  Domain: Resource
  Range: Class
  Definition: A learner awarded with a qualification upon successful completion of a programme of study
  Comments: See Europass Diploma Supplement, section 1.

URI: elm:Result
   Label: Result
   Domain: Resource
   Range: Class
   Definition: A grade or classification of the actual outcome for a learning opportunity for a learner as stated by a provider.
   Comments:

Classes included from the MLO-AD specification [CWA 15903]


URI: mlo:LearningOpportunityProvider
  Label: Provider
  Comments:

URI: mlo:LearningOpportunity
  Label: Learning Opportunity
  Comments:

URI: mlo:LearningOpportunitySpecification
  Label: Learning Opportunity Specification
  Comments:

URI: mlo:LearningOpportunityInstance
  Label: Learning Opportunity Instance
  Comments:

EuroLM-DS Associations


  • (Cleo, Scott, Erlend)

URI: elm:hasResult
  Label: Has Result
  Domain: Resource
  Range: elm:Result
  Sub Property Of: dc:relation
  Definition: A relation of a resource to a Result
 Comments:

Associations included from the MLO-AD specification [CWA 15903]


URI: mlo:offeredAt
  Label: Offered At

URI: mlo:hasPart
  Label: Has Part 

EuroLM-DS Properties


URI: elm:status
  Label: Status
  Domain: elm:Result
  Range: http://www.w3.org/2000/01/rdf-schema#Literal
  Definition: The status of a result
  Comments: For example, whether the result has been already assessed or is a predicted result

URI: elm:additionalInformation
  Label: Additional Information
  Domain: http://www.w3.org/2000/01/rdf-schema#Resource
  Range: http://www.w3.org/2000/01/rdf-schema#Resource
  Definition: Additional information concerning the resource
  Comments: For example, additional information about the diploma supplement

URI: elm:IssueDate
  Label: Issue Date
  Domain: http://www.w3.org/2000/01/rdf-schema#Resource
  Range: http://www.w3.org/2000/01/rdf-schema#Resource
  Sub Property Of: http://purl.org/dc/elements/1.1/date
  Definition: The date on which the resource was formally issued
  Comments: For example, the date of issue of the diploma supplement

Properties included from [ISO 15836]


URI: http://purl.org/dc/elements/1.1/identifier
  Label: Identifier
  Comments: The content should conform to a URI, as defined by IETF-RFC2396.

URI: http://purl.org/dc/elements/1.1/title
  Label: Title

URI: http://purl.org/dc/elements/1.1/type
  Label: Type

URI: http://purl.org/dc/elements/1.1/description
  Label: Description

Properties included from [DCMI Terms]


URI: http://purl.org/dc/terms/educationLevel
  Label: Education Level

Properties included from [IETF-RFC2426]


URI: http://www.w3.org/2001/vcard-rdf/3.0#Given
  Label: Given

URI: http://www.w3.org/2001/vcard-rdf/3.0#Family
  Label: Family

URI: http://www.w3.org/2001/vcard-rdf/3.0#BDay
  Label: Birthday

Properties included from [CWA XXXXX]


URI: http://purl.org/net/cm/level
  Label: Level

URI: http://purl.org/net/cm/scheme
  Label: Scheme

URI: http://purl.org/net/cm/value
  Label: Value

Properties included from [CWA YYYYY]


URI: ects:institutionStatus
  Label: Institution Status

URI: ects:accessRequirements
  Label: Access Requirements

URI: ects:gradingScheme
 Label: Grading Scheme

URI: ects:furtherStudy
 Label: Further Study

URI: ects:professionalStatus
 Label: Professional Status

Diploma Supplement Description Set Profile


The EuroLM-DS model was based on the approach of developing an application profile of existing specifications. Application profiles can be defined as schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application [Heery & Patel, 2000]. The Diploma Supplement document comprises the following components:

  • the Diploma Supplement document itself
  • information about the learner (the holder of the qualification)
  • information about the provider of the document (awarding institution of the qualification)
  • Information about the programme of study, the qualification and the result obtained by the learner (diploma)
  • Information about the components studied as well as the result and credits in those components (transcript)
  • Other achievement information

The following constitute constraint clauses for the resources and properties of the EuroLM-DS model.

Diploma Supplement Document

The Diploma Supplement Document is a record that contains diploma supplement information.

  1. A Diploma Supplement Document MUST contain one and only one elm:Learner instance
  2. A Diploma Supplement Document MUST contain one and only one mlo:LearningOpportunityProvider instance
  3. A Diploma Supplement Document MAY contain one and only one mlo:LearningOpportunitySpecification instance, representing the programme of study
  4. A Diploma Supplement Document MAY contain one and only one elm:additionalInformation property
  5. A Diploma Supplement Document MUST contain one and only one elm:issueDate property

Constraint clauses for the elm:Learner, mlo:LearningOpportunityProvider, mlo:LearningOpportunitySpecification instances are given in the following sections.

Learner

  1. An elm:Learner instance MUST contain at least one http://purl.org/dc/elements/1.1/identifier property
  2. An elm:Learner instance MUST contain at least one http://www.w3.org/2001/vcard-rdf/3.0#Given property
  3. An elm:Learner instance MUST contain one and only one http://www.w3.org/2001/vcard-rdf/3.0#Family property
  4. An elm:Learner instance MUST contain one and only one http://www.w3.org/2001/vcard-rdf/3.0#BDay property

Notes

  1. Identifiers may be given for a learner using a range of identifier schemes, including provider-issued student identifiers, national personal identifiers, and schemes of identifiers used by education systems in specific jurisdictions. Where multiple identifiers are used in a Learner instance, each identifier should be specified by defining a sub property of http://purl.org/dc/elements/1.1/identifier for the scheme in use. what does the DS say the default identifier should be?

Learning Opportunity Provider

  1. The mlo:LearningOpportunityProvider instance MUST contain at least one http://purl.org/dc/elements/1.1/identifier property
  2. The mlo:LearningOpportunityProvider instance MUST contain at least one http://purl.org/dc/elements/1.1/title property
  3. The mlo:LearningOpportunityProvider instance MUST contain at least one http://purl.org/dc/elements/1.1/description property
  4. The mlo:LearningOpportunityProvider instance MAY contain any other properties allowed as defined in the MLO standard
  5. the mlo:LearningOpportunityProvider instance MAY contain one and only one ects:institutionStatus property

Learning Opportunity: Programme Level

The Learning Opportunity at programme level consists of an mlo:LearningOpportunitySpecification instance as a child of the Diploma Supplement Document, and an mlo:LearningOpportunityInstance instance associated with the mlo:LearningOpportunitySpecification instance using the mlo:specifies association.

Learning Opportunity Specification: Programme Level

  1. The mlo:LearningOpportunitySpecification instance MUST contain at least one http://purl.org/dc/elements/1.1/identifier property
  2. The mlo:LearningOpportunitySpecification instance MUST contain at least one http://purl.org/dc/elements/1.1/title property
  3. The mlo:LearningOpportunitySpecification instance MUST contain at least one http://purl.org/dc/elements/1.1/description property
  4. The mlo:LearningOpportunitySpecification instance MAY contain one and only one ects:accessRequirements property
  5. The mlo:LearningOpportunitySpecification instance MAY contain one and only one ects:furtherStudy property
  6. The mlo:LearningOpportunitySpecification instance MAY contain one and only one ects:professionalStatus property
  7. The mlo:LearningOpportunitySpecification instance MAY contain one and only one ects:gradingScheme property
  8. The mlo:LearningOpportunitySpecification instance MAY contain one and only one mlo:qualification property## Each mlo:qualification property MUST contain at least one http://purl.org/dc/elements/1.1/identifier property
    1. Each mlo:qualification property MUST contain at least one http://purl.org/dc/elements/1.1/title property
    2. Each mlo:qualification property MUST contain at least one http://purl.org/dc/terms/educationLevel property
  9. The mlo:LearningOpportunitySpecification instance MAY contain any other properties allowed as defined in the MLO standard
  10. The mlo:LearningOpportunitySpecification instance MUST contain one and only one mlo:LearningOpportunityInstance instance, associated using the mlo:specifies association.
  11. The mlo:LearningOpportunitySpecification instance MAY contain zero or more mlo:LearningOpportunitySpecification instances, associated using the mlo:hasPart association, representing transcript components. See Learning Opportunity: Transcript Level for constraint clauses

Learning Opportunity Instance: Programme Level

  1. The mlo:LearningOpportunityInstance instance MUST contain at least one mlo:languageOfInstruction property
  2. The mlo:LearningOpportunityInstance instance MUST contain at least one mlo:languageOfAssessment property
  3. The mlo:LearningOpportunityInstance instance MUST contain at least one mlo:duration property
  4. The mlo:LearningOpportunityInstance instance MUST contain at least one mlo:engagement property
  5. The mlo:LearningOpportunityInstance instance MAY contain any other properties allowed as defined in the MLO standard
  6. The mlo:LearningOpportunityInstance instance MUST contain one and only one elm:Result instance, associated using the elm:hasResult association
    1. Each elm:Result instance MAY contain one and only one elm:status property

Learning Opportunity: Transcript Level

A Learning Opportunity at transcript level consists of a mlo:LearningOpportunitySpecification instance associated with a mlo:LearningOpportunityInstance instance at Programme level using the mlo:hasPart association. Each mlo:LearningOpportunitySpecification instance may have child mlo:LearningOpportunitySpecification instances associated using the mlo:hasPart associations, representing modules or sub-components of the Transcript.

Learning Opportunity Specification: Transcript Level

  1. Each mlo:LearningOpportunitySpecification instance MUST contain at least one http://purl.org/dc/elements/1.1/identifier property
  2. Each mlo:LearningOpportunitySpecification instance MUST contain at least one http://purl.org/dc/elements/1.1/title property
  3. Each mlo:LearningOpportunitySpecification instance MUST contain at least one http://purl.org/dc/elements/1.1/type property
  4. Each mlo:LearningOpportunitySpecification instance MAY contain any number of mlo:credit properties
    1. Each mlo:credit property MAY zero or more http://purl.org/net/cm/level properties
    2. Each mlo:credit property MUST contain one and only one http://purl.org/net/cm/scheme property
    3. Each mlo:credit property MUST contain at least one http://purl.org/net/cm/value property
    4. Each mlo:credit property MUST NOT be used to provide a calculated credit value, such as may be obtained by summing the credit values of sub-components of the instance, but only a source credit value.
  5. Each mlo:LearningOpportunitySpecification instance MUST contain one and only one mlo:LearningOpportunityInstance instance, assocated using the mlo:specifies association
  6. Each mlo:LearningOpportunitySpecification instance MAY contain any other properties allowed as defined in the MLO standard
  7. Each mlo:LearningOpportunitySpecification instance MAY contain any number of mlo:LearningOpportunitySpecification instances, assocated using the mlo:hasPart association

Learning Opportunity Instance: Transcript Level

  1. Each mlo:LearningOpportunityInstance instance MAY contain one and only one elm:Result instance, assocated using the elm:hasResult association
    1. Each elm:Result instance MAY contain one and only one elm:status property
  2. Each mlo:LearningOpportunityInstance instance MAY contain one and only one mlo:LearningOpportunityProvider instance, assocated using the mlo:offeredAt association
  3. Each mlo:LearningOpportunityInstance instance MAY contain any other properties allowed as defined in the MLO standard

Notes

  1. A Transcript consists of a hierarchy of components, each of which may have results and credits associated with it. The actual structure of a transcript depends on the model adopted by a particular education system. For example, in the UK the standard convention is a series of "year of study" components, each of which has a collection of modules.
  2. The http://purl.org/dc/elements/1.1/type property should be used to indicate the type of component, such as a module-level component or a grouping component such as semester, programme year, level or subject of a programme.

DS Certification

See elsewhere for details on the recommended approach to applying digital signatures for authenticating European Learner Mobility documents such as the Diploma Supplement.

DS Section 7 and digital signatures

When a digital signature is created over a specified piece of content (i.e. a document), the signature itself is represented in a standardised format. Standards-based digital signature technologies such as certified PDF and ETSI TS 101 903 (XML Advanced Electronic Signatures) represent the following in their signature elements:

  1. The Date of the signature (akin to section 7.1 of DS)
  2. A unique digital signature over the signed document, made by the person/office/department certifying the document (section 7.2 DS)
  3. A means to identify the capacity of the document signatory (section 7.3, DS)

Section 7.4 of the DS represents the "Seal" of the awarding body and was likely included as a means to add security to the paper version of the DS. The strong authentication provided by using digital signatures would eliminate the need to have a separate "Seal" (from a paper security point of view), and this may no longer be required. The policies used to issue the Qualified digital certificate in section 7.2 can be used to assert that the signatory in section 7.2 is authorised to sign on behalf of the institution. If required, a second digital signature can be applied (on behalf of the institution) to represent section 7.4. This should be optional.

Representing section 7 in electronic DS

One of the useful properties of digital signatures is that a digital signature element can be located separately to the data that it refers to. As long as both the signature element and the referenced data can be located, then the ingredients are available to verify that the signature is authentic. For the DS, this means that the group does not need produce a technical specification that deals with the representation of digital signatures. I (Andy) would recommend the following:

  1. Section 7 should not be explicitly represented in the DS data model at all. Instead, section 7 is represented by the relevant digital signature element(s) computed by whatever digital signature mechanism covers the electronic DS, and the signature elements should be stored within the scope of the wrapper or container that holds the DS.
  2. One or more standards-compliant digital signatures (i.e. ETSI TS 101 903 XAdES) are computed over the electronic representation of the DS. That is, the signatures must reference the entire representation of the electronic DS, and not just individual elements.
  3. If using ETSI TS 101 903, the following additional caveats would apply:
    1. At a minimum, the root DS element shall be referenced when computing the digital signature (and therefore covering all child elements within the electronic DS)
    2. Exclusive C14N with no comments should be used when computing the digest for the root DS element (to allow portability of the DS element whilst maintaining signature integrity)
  4. The resulting signature element(s) are stored outside the scope of the DS elements (i.e. in whatever container holds the DS)

There are considerable advantages to this approach:

  1. We can recycle a variety of existing standards for digital signatures (i.e. compliance with ELM's signature requirements does not depend on one particular signature technology)
  2. The DS specification can be updated over time independently of the digital signature standards
  3. This approach to certification can be recycled for other documents as required

Vocabularies

We could probably do with putting something together for transcript component types, probably as a separate CWA.

Business Cases

(Simone, Alessandra)

See Business Cases.

Binding(s)

Recommended Interfaces

Appendices

SpecificationTables

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Apr 07, 2009

    Geir Vangen says:

    Just a few pre Easter thoughts about the ELM and Diploma Supplement  Geir  Diffe...

    Just a few pre Easter thoughts about the ELM and Diploma Supplement
     Geir
     Different needs for different receivers of Diploma Supplement
     Different receivers of student results have different needs for details. An employer may want to read only a short description of the education fulfilled. When we are talking about student mobility between institutions, there are demands for more detailed information about the education, and each module.
     ELM should give the possibility to represent the Diploma Supplement, and in addition distribute more detailed information about the education and each element within the education (course modules etc).
     Most of the information in the Diploma Supplement is short textual descriptions of the qualification and the study program the student has completed. As Andy has mentioned at http://wiki.teria.no/confluence/display/EuropeanLearnerMobility/Digitary+European+Diploma+Supplement, the XML schema must support multiple languages (in Norway we must support English, two Norwegian written languages and Sami).
     The Diploma Supplement consists of the following elements. To represent these elements inside a XLM schema, each element should be discussed.
     The elements of the Diploma Supplement
     1) Information identifying the holder of the qualification
    - Name, family and given name
    - Date of birth
    - National identification, student identification...
     2) Information identifying the qualification
    - Name
    - Main fields
    - Name and status of awarding institution
    - Name and status of administration institution
    - Language(s) of instruction and examination
     3) Information on the level of the qualification
    - Level - textual description
    - Official length of the programme (semesters, years?) Common time unit?
    - Access requirements - textual description
     4) Information on the contents and results gained
    - Mode of study - textual description
    - Programme requirements - textual description
    - Programme details - ECTS-transcript including descriptions of the modules?
    - Grading scheme and, if available, grad distribution guidance - textual description
    - Overall classification of the qualification - textual description
     5) Information in the function of the qualification
    - Access to further study - textual description
    - Professional status - textual description
     6) Additional information
    - Additional information - text description
    - Further information sources - text description
     7) Certification of the supplement
    - Date
    - Date of the original qualification (when the student achieved the qualification)
    - Signature - Digitary
    - Capacity
    - Official stamp or seal
     8) Information on the national higher education system
    - Text and figures explaining the higher education system at the time the student achieved the qualification. This information may change over time. How to represent this; Url to this information, PDF-document, ?
     * Addition information about the institution(s): MLO, URL's, both?
    * Addition information about the qualification. MLO, URL's, both?
    * Addition information about the study program. MLO, URL's, both?
     Transcript of records
     Point 4.3 refer to an ECTS Transcript
     * Header information?
     * Each course module/element;
    - Code
    - Name + more text containing more information, like title of paper etc
    - Module category
    - Time completing the module (common time unit?)
    - Mark/Grade
    - ECTS-credits
    - ECTS-grade
    - More textual information about the module - at the time the module was completed - MLO? Urls?
     * More information for the transcript?
     Addition information
     Will ELM be a large XML schema, covering all aspects of learner mobility? Or should it be a series of smaller probably easier implemented schemas, where Diploma Supplement is one of these (and maybe transcript of records is another)?
     The student administration and facilities (and possibly other groups) need information about programs and modules (++) and this information should be accessible along with the student information. How should this be solved? Is the safest way to bring the text along with the student information (MLO)? Or should this only be url's? How long will the url's last? We also have to consider that there are versions of information (changing over time), and that the information following the student should be the right version.
     How to spread the DS
     How should the xml-document be move from one institution to another? Via the student? Directly?
     

  2. Apr 08, 2009

    Cleo Sgouropoulou says:

    The above is a proposed outline for the DS specification. The paragraphs "Concep...

    The above is a proposed outline for the DS specification. The paragraphs "Conceptual Model" and "Abstract Model" illustrate base drafts for the initiation of the development process. I would like to thank Scott for our discussion towards the formation of this first draft. Apart from what is already included in the abstract model we find appropriate the inclusion of another entity for "Additional Information" and suggest that "Certification" is handled as meta-information of the DS document.

    You are kindly invited to post your comments on this approach and, of course, provide your contributions wherever you feel appropriate.

  3. Apr 13, 2009

    Andy Dowling says:

    Hi All, This is a good start, and nicely done! A few things that I'd like t...

    Hi All,

    This is a good start, and nicely done! A few things that I'd like to add:

    1. In section 4.3, does the "Learning Opportunity Specification" provide a means to specify the learning provider in each case. I'm thinking here of situations where a student obtains credit from a remote institution during an exchange programme, and we would like to represent the identity of that provider (and maybe even the HE system of that country??!). Also, I'm wondering if XCRI plays a part here in describing the course units being studied??
    2. Section 7 (Certification) - I'd be inclined to reference the existing standards around XML digital signatures rather than Digitary itself (which is a commercial implementation). The standards used by Digitary are (W3C XMLDSIG and ETSI TS 101 903 v1.3.2 - XAdES). Regarding Cleo's comment on "Certification" being handled as meta-information, are you suggesting that certification be handled outside of the DS XML specification (i.e. signature elements are not specified or referenced by the DS schema, but are managed by some form of "container XML")?
    3. As Geir quite rightly pointed out, we need to make some representation for section 8 of the DS (Higher Education System). My feeling on this is that representing this as XML could be a big task (unless MLO or something else already does this?!!), and I'd lean towards representing the HE system by a unique URL that links to an online representation of the HE system at the time at which the DS was issued. One idea could be to have the national Europass centres maintain the URLs (and archival of URLs over time as the HE systems change). This would provide a single, central, and trusted source of HE information for a given member state. The URL itself may actually be a HTML page or PDF that could be interpreted by a human, but the URL itself could be used for automated processing.
    4. Regarding the distribution model, I'm not sure if this is in scope or not, but Scott's work on the UK HEAR is of interest as it specifies a variety of distribution models and pays attention to issues such as access control. See http://wiki.cetis.ac.uk/Technical_architecture_considerations_for_implementing_the_HEARfor more information. In my experience with Digitary, different countries and institutions have different approaches when it comes to data protection, and so the student/graduate may or may not be involved in the distribution of the DS between an institution and a "relying party" (i.e. another institution, recruiter, etc.). Both models are possible. Whilst I'm on the topic of XML distribution - in my view, an XML representation of DS (i.e. content-only, no presentation), digitally-signed for authenticity and long life, is more useful in a system domain for automated processing. If it is to be rendered for human consumption, then it would need to be translated by a trusted online service and rendered as HTML/PDF or other presentable format that makes sense to the reader. My point here is that the XML document may not necessarily be visible to the user (i.e. in a cloud model, the XML document would remain "in the cloud", but the user can still gain and control access to it through the web. The direct consumers of the DS would break down into two high-level types - systems and humans. Systems could access the XML version via web services, whilst humans could access the translated version via online web applications.

    I hope this makes some sense . Talk tomorrow!

    Best Wishes,

    Andy


  4. Apr 13, 2009

    Geir Vangen says:

    Thanks for some fine models. This is also clarifying regarding to the use of MLO...

    Thanks for some fine models. This is also clarifying regarding to the use of MLO. I have a few comments to the Conseptual Model before the meeting tomorrow.

    1)

    I agree with Simon that the Diploma should reference the Programme Instance, not the Programme. And if Diploma represented the fulfilment of a Programme, the result should be referenced from the Diploma, not the Programme (or the Programme Instance);



    I have also added a line from the Diploma to the Qualification, as there are (I'm sorry to say) several programmes connected to more than one qualification (though this is not common).


    2)
    A question about the Transcript; What is a Programme Year? Is this a numbering of each year within the study, eg Year 1, Year 2 etc? We only have a few studies in Norway grouping the units in such a way. Other studies have a large variety of grouping the units on the transcript. Should instance of units be introduced here (as is for instance of programme)? We also have to consider the need of specifying results gained at other institutions.



     In the above sketch of a model for transcript, the term 'Unit Evaluation' refer to the evaluation of at certain unit (course unit, subject) for a student at a time. This 'Unit Evaluation' refer to a Provider via Unit Instance and Unit. The Unit Group/Category is an attempt to represent different kinds of grouping of units at a transcript (e.g. Year, Specialization etc).

    Should competence also be connected to units? Or will this be too detailed?
     

  5. Apr 27, 2009

    Christian Stracke says:

    Hello to all, as already mentioned within my e-mails, I'm repeating it here on...

    Hello to all,

    as already mentioned within my e-mails, I'm repeating it here only to keep the proposals:

    1. question: How can we refer to personal "competence"? The relation is called "leadsTo" but I assume that not all students will build the same competences within the same study programme.

    Recommendation: Let us remove "competence" or if we want to keep it, then relate it to the individual but not to the Diploma or LO Specification.

    And overall I have one general comment:
    I would prefer to *NOT* reference to the term "competence" as a synonym of "learning outcome": I would prefer to keep "learning outcome" and not to use "competence" anywhere. Everybody can think about it what "learning outcome" is and I assume that there will be many different opinions

    2. question: And I assume that "qualification" means formal qualification, is that correct? Then we should avoid any confusion with the usage of the term qualification within EQF.

  6. Apr 28, 2009

    Simone Ravaioli says:

    What happened ?!  Did Scott show up ?? ... all of a sudden the conten...

    What happened ?!  Did Scott show up ??

    ... all of a sudden the content of this page increased dramatically !

     thanks Scott!

     Simone

  7. May 07, 2009

    Luis Anido says:

    Great work so far!  First of all, I have to say that I fully agree wit...

    Great work so far!

     First of all, I have to say that I fully agree with Geir: multilinguality must be taken into account.

    Here in Spain we have four official languages: Spanish, Galician, Catalan and Basque and for sure those universities in Galicia, Catalonia and the Basque Country will use their languages in addition to Englishs/Spanish or even as the unique option.

    I have just two comments:

     1.- ISO has published ISO/IEC 24703 on Participant Identifier. This may be of interest for the unique identification of 'Person'

    2.- Application Profile is defined in this document. What about using the definition provided in CWA 15555 or even better in the ISO TR 10.000 (also included in the CWA)?

     More comments to come...

    Luis

  8. May 15, 2009

    Christian Stracke says:

    I can only agree: excellent work! In the "Domain Model" section above, it i...

    I can only agree: excellent work!

    In the "Domain Model" section above, it is stated:

    "a Transcript instance, containing LearningOpportunity instances representing the component units, each of which contains provider, credit, and result information"

    but the figure 2 below does not show any reference to a credit information contained within LO instance:

    Do we want to add it to the figure or delete any reference to credit information here?

    Best regards

    Christian 

  9. May 15, 2009

    Scott Wilson says:

    I'm not entirely convinced of this "tabular" representation - its much more ambi...

    I'm not entirely convinced of this "tabular" representation - its much more ambiguous than the demotic statements (e.g. associations, dependent conditions, mixed content models such as Result, etc.) and the only additional information is the comments on mapping to DS fields. Perhaps the statements should be restored, and the mapping statements given in a specific appendix?

  10. May 15, 2009

    Scott Wilson says:

    Re Credit: credit is a property already defined as part of MLO LOS, so doesn't n...

    Re Credit: credit is a property already defined as part of MLO LOS, so doesn't need to be represented in Figure 2.

  11. May 16, 2009

    Andy Dowling says:

    Hi all, Apologies for the lateness of my comments. Well done to all on the wo...

    Hi all,

    Apologies for the lateness of my comments.

    Well done to all on the work done so far! This is fantastic progress and very well done, in my opinion. I've made a few comments above:

    1. Section 1.4 (student id) - we have seen 1..* cardinality in the past, and this may become the norm with various student IDs such as the institution's own student id, HESA (HUSID?), ULN, and even a national id number.
    2. Section 3.1 (Level of the qualification). Cardinality again. This was probably covered already, but we should allow for both informal, institution-based descriptions ("i.e. Bachelor Degree") and more formal ones based on a national/European qualifications framework (i.e. Level 7)
    3. Added issueDate to Diploma Supplement table

    Regards,

    Andy

  12. May 16, 2009

    Geir Vangen says:

    3 very late comments: Both terms Unit and Module are used in the document....

    3 very late comments:

    Both terms Unit and Module are used in the document. Should the same term be used? (Module level, Unit level)

    Definition of Person: Only referring to a learner completed a programme. Should it also include learners completed one or more units? The domain model prepare for transferring transcript without information about the qualification.

    Agree with Scott and Andy that student id should have a 1..* cardinality. If this is supported with a identification type, there should not be any need for a primary identifier?

    If we want a very flexible, but simple person name model: name cardinality 1..*, consisting of type and value, where type can be lastName, familyName, preferredName etc.
    --

    Looking forward to use this specification!

    Geir

  13. May 18, 2009

    Scott Wilson says:

    I think perhaps "unit" should be the term used when relating MLO components to r...

    I think perhaps "unit" should be the term used when relating MLO components to real-world transcripts; otherwise "component" when discussing the actual spec internals.

    For identifiers, my preferred model is one of type refinement, e.g.

    <dc:identifier>defaultid</dc:identifier>
    <dc:identifier xsi:type="hesa:id">111111111</dc:identifier>
    <dc:identifier xsi:type="miap:uln">121313113131</dc:identifier>

    In which case, a rule for default identifiers is needed; I suspect there is already something in the DS documents about this though?

    For names, etc, my preference here is to avoid inventing anything if at all possible, hence reusing the vCard properties (defined in IETF RFC2426) with W3C URIs. But this is definitely a strawman and I'd like to hear about more ideas for this one, as the absence of a good generic "person" model is a common problem we have in many specs. Simon has done a good job here of comparing various specs: http://wiki.cetis.ac.uk/LEAP2A_personal_data

  14. May 28, 2009

    Simone Ravaioli says:

    About TRANSCRIPT: The European Commission ECTS website makes available a Standa...

    About TRANSCRIPT:

    The European Commission ECTS website makes available a Standard Form for the Transcript of Record

  15. Jul 01, 2009

    Scott Wilson says:

    I really do think the tables aren't adding anything, and are another thing that ...

    I really do think the tables aren't adding anything, and are another thing that has to be maintained and checked for consistency. Can we get rid of them, at least for now, and put any extra information they contain (mappings to DS sections) into another section?

  16. Aug 23, 2009

    Scott Wilson says:

    Just a note - we need to add in the ECTS refinements to the core model. E.g. in ...

    Just a note - we need to add in the ECTS refinements to the core model. E.g. in Provider.