ASPECT for Commercial Content Providers

Recommendations

R-G.1: Use standards and specifications.

There are four core reasons to use standards and specifications:

1. They avoid dependency on single vendors (vendor lock-in);
2. Their use facilitates interoperability;
3. Their use lowers costs by making it possible to build higher-level services on top of proven and standard compliant systems;
4. They represent best-practice solutions to known problems even when interoperability is not at issue.

R-G.2: Check conformance.

Standards and specifications are of little value when implemented poorly. Systematic conformance testing permits for verifying that a specification is implemented correctly and ensures (at least) syntactical interoperability.

R-G3: Select appropriate standards.

Given the profusion of standards available, it is critical to identify the existing standards of communities with which you want to interoperate. When a standard exists that addresses a certain requirement, using it, even if it is complex or incomplete – is often better than creating a new specification. Keep in mind that trying to create a new standard, when existing standards are already available, guarantees failure to interoperate with existing practices!
Do not abuse data elements: Using a data element for content for which it has not been foreseen leads to semantic interoperability problems that are particularly hard to detect. Instead, consider inserting additional elements at extension points foreseen in a specification (see also R-G5).

R-G4: Don’t profile without consent.

Interoperability is jeopardized when standards and specifications are customized (profiled) without consent of the target community; in particular when data providers and data consumers use incompatible profiles. Therefore, as much as possible, try to use standards and specifications ‘as-is’. A profile must always have a clearly defined scope and purpose for the target community whose needs it should meet. If no formal consensus can be reached in this community, it is recommended to meet the needs of its common practice.
Providing tools that help community members in achieving conformance with profiles can greatly ease the establishment of informal consensus.

R-G5: When profiling, preserve interoperability.

When profiling is unavoidable, keep any customization as limited as possible and profile in a way that preserves interoperability with the original specifications. For example, do not make mandatory elements optional or do not remove terms from an existing controlled vocabulary. If new elements must be introduced, do it only at the extension points foreseen in the specification. Several standardization organizations have created guidelines for application profiles. Examples of lists of dos and don’ts can be found at http://www.imsglobal.org/ap/index.html and http://www.cen-ltso.net/main.aspx?put=922.

R-G6: Combine standards and specifications consistently.

Most solutions call for combining several specifications in a domain profile. Ensure that the standards to be combined work together in a precisely defined way. Moreover, ensure that this combination is compatible with the practices of the target communities. The ASPECT Integrated System, described in ASPECT deliverable D5.4, is an example of how to combine specifications, such as OAI-PMH, IMS ILOX, IEEE LOM, IMS VDEX, in a consistent way.

R-G7: Use a progressive strategy.

Adopting a complete solution can be expensive but interoperability can be built gradually. Build interoperability in stages by adopting specifications most pertinent to your immediate requirements and progressively add other complementary specifications. For instance, adopt first the most common protocol specification in a community for exposing metadata and then add other protocols to address other needs. Always be frank: Describe explicitly which specifications or profiles are fully supported in your application.

R-CP.1: Only use content specifications when required

If content is always to be used only on a single platform, providing it in a format which this particular platform can process most efficiently is usually more efficient than using a standard format. Nevertheless, the correct functioning of the content in all variants of the target platform should be carefully tested.

R-CP.2: For learning assets, stick to web-standards

When the intention is to make simple learning assets (i.e., images, videos, texts, sounds) widely available, employ web-standard formats, i.e., standards that can be directly rendered in a web browser or only require popular plug-ins such as pdf. For example, in the Learning Resource Exchange (LRE), high-quality images in encapsulated postscript (EPS) format and thus could not be rendered in a browser, were not used before they were made available in JPEG format despite their lower quality. Keep in mind that Adobe Flash is not supported by some mobile systems.

R-CP.3: Learning assets (i.e., single file content) should not be packaged

Web standards are sufficient to make learning assets interoperable and they should not be packaged. Collections of content objects should be packaged as zip files, if the structure of the collection is only used to resolve internal references.

R-CP.4: The distribution of complex content requires packaging

The distribution of complex content requires packaging because such content consists of multiple components that should be rendered in specific ways. Packaging specifications determine how complex content can be rendered. It allows the importing system to infer the intended role of each content object. The IMS Content Packaging specification should be the first choice for describing multi-faceted hierarchically structured content collections. The IMS Question and Test Interoperability (QTI) standard was designed to support the distribution of assessments.

R-CP.5: Use content package specifications used by your intended audience

Packaged content can only be rendered on platforms that support it. Use specifications supported by the platforms commonly used by your intended audience. Contact the developers of the target platforms and request precise information on the formats they can process, i.e. about the read profiles of the target platforms. Ask them for tools to test whether your content conforms to their requirements.

R-CP.6: “Creative Commons” maximizes reuse

If you plan to use open content to maximize reuse, opt for a Creative Commons license.
For example, the LRE specifically encourages Creative Commons Attribution.

R-CP.7: Make sure the distribution of interoperable content does not conflict with your business model.

There are two main categories of scenarios for accessing content. Either the content is delivered to the user or a list of links is given to the user and the content remains on the content providers’ server. Since Digital Rights Management (DRM) solutions are not supported in the technology-enhanced learning domain, controlling content access requires another combination of licensing regimes and technical solutions.
When content is delivered to an institution and delivered through a learning management system (LMS), an appropriate license agreement can be enforced by the LMS’s access control mechanism. When content remains on the content provider’s server, that server can control access by requesting credentials or by identifying the calling system through its IP address.
The IMS Common Cartridge and Basic LTI specification define ways to control content access. It should be checked whether these features are supported by the target systems.

R-CP.8: Make metadata creation easy and, where possible, try to generate metadata automatically.

Metadata is necessary for effectively managing, finding, and assessing the usefulness of learning resources. However, creating quality metadata is a challenging activity. Most users don't like to describe learning resources and usually produce poor or incomplete descriptions while professional indexers are expensive and not always consistent over time. Many metadata elements either already exist in one form or another and can be reused or can be produced in an automatic or semi-automatic way from the resource itself or its context. Moreover, tools exist for automatic metadata creation (such as the Simple automatic metadata generation Interface – SamgI). Therefore, each time it is possible and relevant, put in place tools and services to automate the generation of metadata. The LRE Service Centre provided by ASPECT offers examples of such tools and services such as:

• The LRE automatic metadata translator that allows for systematically translating English metadata into 6 additional languages.
• The ASPECT metadata transformer that, in a fully automated way, extract metadata from a common cartridge package, generates the corresponding metadata record in a specified standard, and exposes it using OAI-PMH.

R-CP.9: Combine as many sources of information as possible about the resource.

Descriptive metadata provided by content providers is only one of the possible sources of information about a learning resource. It can be complemented by other valuable information such as:

• Usage data, such as the number of times a resource is retrieved;
• Explicit feedback from users, such as ratings and annotations (Web 2.0 tools and practices);
• Third-party metadata provided by aggregators or reviewers.

This type of information provides feedback to enhance searching by users and ranking and feedback helps providers better understand issues related to the quality and usage of their content.

R-CP.10: Expose metadata and content in as many ways as possible.

Each specification supports a different way of exposing metadata (e.g., metadata harvesting with OAI-PMH, search with SQI, metadata publication with SPI). These specifications make possible the development of different types of specialized discovery services. Although such services offer high degrees of precision in searches, it is important to recognize that a significant number of users rely on a different set of discovery tools. These include web search engines, social web services, full text indexing, etc. Therefore it is important to expose metadata and content in ways that make them accessible by these tools.

R-CP.11: Register your repository to ensure its discoverability.

Learning object repository registries, such as the ones developed in ASPECT, allow content aggregators to easily discover and access repositories. Properly describing a repository in such a registry ensures that its content will be made available in the federations that use this registry.

R-CP.12: Describe each re-usable part of content

If content can be disaggregated, as in the case of Common Cartridges, describe each re-usable part with appropriate metadata so that it can be easily found. Metadata for parts can be inherited from metadata of the package but their validity needs to be checked.

Tools and Services

Learning Technology Standards Observatory LTSO

• URL: http://www.cen-ltso.net
• End users: Anyone interested in Learning Technology Standards and Specifications
• Description: The Learning Technology Standards Observatory (LTSO) is a focal access point to updated information on projects, results, news, organisations, activities and events that are relevant to the development and adoption of e-learning technology standards and specifications. It offers a newsletter service, access to relevant experts and up-to-date information in this field.

Application Profile Registry

• URL: http://apr.vocman.com
• End Users: Systems needing information about application profiles. Owners of application profiles and specialists developing new application profiles
• Description: The ASPECT Application Profile Registry (APR) provides a browsable interface, which allows specialists to find information about the data elements and vocabularies used by different application profiles and to view mappings between different profiles of the same base standard. The interface allows authorised users to add details of new application profiles. The machine interface (REST API) provides this information in XML and JSON formats to consuming systems.

Vocabulary Bank for Education VBE

• URL: http://aspect.vocman.com/vbe/
• End users: Taggers, taxonomists, developers and curriculum designers.
• Description: The ASPECT Vocabulary Bank for Education (VBE) provides a browsable and searchable web application to locate, view and download sets of terms, plus a machine interface (REST API). The vocabularies can be used for metadata, in particular for the Learning Resource Exchange.

ARIADNE Validation Service

• URL: http://ariadne.cs.kuleuven.be/validationService/
• End users: System Administrators & developers of Content providers
• Description: The validation service is available for providing validation of metadata instances against predefined application profiles, for example based on IEEE LOM such as the LREv4.5 AP. To ensure that only compliant metadata are stored in a LOR, we use the validation service to check both the syntactic and semantic validity of the instances against the used profiles. The validation service has a modular approach, and combines different sorts of validation techniques, etc.

Transformer Service, transforming metadata and vocabularies into another format

• URL: http://lrecoreprod.eun.org:6080/mtdTransformer/
• Source code: https://lretools.svn.sourceforge.net/svnroot/lretools/trunk/transformati...
• End users: Metadata creators, Metadata developers
• Description: The purpose of the Metadata transformation service is to allow users transform metadata from one format (one application profile) such as LOM Strict to another format (another application profile) such as LREv4.0 application profile. The service does not only support structural transformation using Extensible Stylesheet Language (XSL) transformation or Java-based transformation but also support for the vocabulary crosswalks from the vocabulary bank. From a software standpoint, it is based on a plugin architecture where new transformations can be added as plugins, provided as jar files, with no needs for modifying the transformer core. The transformation service is available online at http://lrecoreprod.eun.org:6080/mtdTransformer/. However, this version only permits users to transform one metadata instance at a time, which is convenient for demonstration or to see how the transformation service works. In case the user wants to transform a large number of metadata instances, it is recommended that the user checks out the transformation library at source forge and develops an upper “layout” which connects to his/her repository.

Automatic Translation Service for Learning Object Metadata

• URL: http://lreforschools.eun.org, http://lrecoreprod.eun.org:6080/oaitarget/OAIHandler?verb=Identify
• End users: Metadata editors, LRE end users
• Description: Automatic Translation Service, which is integrated in the Learning Resource Exchange (LRE), enables better discovery rate of resources. All the metadata collected by the LRE are machine translated from English into German, Greek, Spanish, French, Italian and Portuguese using SYSTRAN. Due to license costs, these services are currently limited to the LRE Associate Partners and ASPECT Associate Partners. Partners' metadata collections that contribute to the LRE are enriched with translations and identifiers and can be harvested back using the LRE OAI-PMH target
  (http://lrecoreprod.eun.org:6080/oaitarget/OAIHandler?verb=Identify).

Deliverables

• D1.3.2 Final Public Report
• D2.1 ASPECT Approach to Federated Search and Harvesting of Learning Object Repositories
• D2.3 ASPECT Approach To Multilingual Vocabularies, Including Automated Translation Services
• D3.1 Best Practice Report for Content Use
• D3.2.2 Conformance Testing Tools version 2
• D3.5 Best practice report for content use v2.0
• D3.6 IMS CC & SCORM Demonstrator v2.0
• D4.6 LRE Service Center provided by ASPECT
• D5.5 Report on the advantages/issues associated with the large-scale implementation of selected standards
• D6.5 Final Report on the Experimentation

All these deliverables can be accessed from http://www.aspect-project.org/node/28 .