Recommendations, Best Practices and known interoperability issues

The recommendations below reflect the experience of partners in the ASPECT Best Practice Network and are grouped by the different categories of stakeholders involved in the project:

• content providers and repository owners,
• tools providers,
• federation and discovery service builders, and
• standards organizations.

Given that end-users should benefit from standards and specifications rather than be concerned with issues related to their implementation and adoption, they are not addressed as a category of stakeholders.

The general recommendations are those that are applicable to all the categories of stakeholders. Policy making decisions should be informed by recommendations in all the categories.

General 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 here. 

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.

Content Providers and Repository Owners

Interoperable Content

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.

Open Content

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. 

Commercial Content

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.

Describing Content

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.

Exposing 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 providers

R-TP.1: Build tools that support all features and options in a specification.
Some specifications (for example IMS Common Cartridge, IMS LODE, IMS QTI) define core profiles reflecting common practice.

Tools producing data should allow use of all features of these core profiles and they should have a mode disabling all features beyond those defined in the respective core profile. Tools consuming data should be capable of reading all data conforming to the core profile. They should at least tolerate additional data provided at specified extension points.

R-TP.2: Support content specifications best adapted to the type of learning scenarios a platform supports.
ADL SCORM is best suited for self-paced learning, IMS Common Cartridge is best suited for blended learning, IMS Question and Test Interoperability for assessments.  Tools’ providers might support one or more of these content specifications depending on the type of learning activities provided by their learning platforms.

Federation and Discovery Service Builders

R-DS.1: Minimize the cost of joining a federation.
If the barriers to joining a federation are too high, the infrastructure will not be used.  Means to lower such barriers to entry include:

• Only requiring simple metadata application profile(s);
• Making appropriate tools available for joining (e.g., metadata generator, conformance tests, transformer services, metadata translators, identifier service, metadata enrichment service);
• Supporting multiple ways to join the federation both as content provider and consumer (i.e., supporting as many protocols as possible);
• Providing reference implementations for the main protocols (both server and client side);
• Providing mechanisms for sharing usage data and feedback on content within the federation.

R-DS.2: Offer persistent management of learning resources and metadata.
The following set of services and tools are recommended for this purpose (Note that the order does not impose a priority):

• A Collection Registry for learning object repositories is needed for providing up-to-date information on the repositories in their network. It provides interoperability between numerous LORs and other collection registries.
• An identifier service should be provided for maintaining persistent unique identifiers for learning objects.
• A validation service must be provided that checks both the syntactic and semantic validity of metadata instances against multiple standards, specifications and their application profiles.
• A broken link checker must be provided to ensure the availability of the learning objects referenced in metadata.
• It cannot be expected, nor is it necessary, that all content providers over the world should support one and the same metadata standard or application profiles. Therefore, a transformation service should be provided that converts metadata from one format, for instance Dublin Core or IEEE LOM, into another format, for instance IMS ILOX. 
• An enrichment service must be used to enrich incoming metadata from content providers in order to enable better discovery rates of resources. Examples of enrichments are automatic translations of titles, descriptions, etc.
• An application profile registry is recommended for storage of descriptive information about application profiles conforming to a specified schema. It should be connected with links to the formal documentation of the application profile required for validation and with links to the validation tools mentioned above. Moreover the application profile registry should provide information whether a profile in the registry is a restriction of another one.
• A vocabulary bank should be used in which controlled vocabularies can be published and disseminated in a range of standardized interchange formats.
• A client tool such as a harvester should be used to semi-automate the process from harvesting metadata from content providers to making it available in the broker network.

R-DS.3: Establish good communication channels between the different stakeholders of a federation.
A good communication between the different stakeholders of a federation is key to ensure federation service quality.   For example, communication with content providers requires that:

• Clear training documentation for content providers must be provided to successfully publish materials in a federation.
• Content providers must be able to subscribe to news-feeds that inform them whether a harvesting cycle (harvesting, identification, validation, etc.) succeeded or not.
• Request for Change tools such as TRAC are deployed to enable people to report problems with services, tools, etc.

R-DS.4: Use already existing best practices and tools when setting up a federation.
The ASPECT project and others have produced many recommendations, tools, and best practices for efficiently managing federations.  All these tools and services are available on the LRE service centre provided by ASPECT.

Standards Organizations

R-SO.1: Support the development of free and user-friendly tools to edit, deploy, re-arrange, and play educational content.
These tools should have open interfaces following open specifications. Coordinate the development of these tools. Leverage the potential of open source development in Europe.

R-SO.2: Provide community-based conformance competence forums, supporting stakeholders which apply open educational standards.
These centers should be freely accessible for all. They should allow for open discussions of practical interoperability issues.

No specification can foresee all potential issues. Authorize a specification management group to rapidly provide preliminary recommendations on how newly emerging issues should be handled until the specification is updated.

R-SO.3: Support the development of application profiles and domain profiles of existing standards reflecting what is used in common practice.
Provide tools helping software developers and content authors to become fully compliant with these profiles. Develop a culture where the end user can rely that all features described in these profiles are implemented in any product that claims conformance. Only release standards and profiles that have been fully implemented and tested.

R-SO.4: Maintain backward compatibility
Whenever possible, data conformant to one version of a specification should remain conformant when the specification is updated. This builds trust into the specification, avoids re-engineering costs prevents slow-down of specification take-up.

R-SO.5: Do not encode controlled vocabularies in bindings.
Controlled vocabularies evolve rapidly to meet changing requirements and must often be available in multiple languages.  Terms and their definitions must also be documented.  The management of controlled vocabularies is optimized when they are encoded using specifications such as VDEX, ZTHES, or SKOS and stored in a bank (such as the ASPECT Vocabulary Bank for Education) independent of a binding. The binding can then refer to these external vocabularies. This comes at the price of an extra look up for resolving an identifier into the corresponding vocabulary term in a given language. However, the benefits (e.g., better management of controlled vocabularies, support for multilingualism – see R-SO.6) are worth this extra cost.  Moreover, in order to lower this cost, ASPECT has developed an array of tools to integrate binding and vocabularies. These include the ASPECT transformer service, the ASPECT Application Profile Registry, the ASPECT Vocabulary Management Tool, the ASPECT Validation Services. When using changing vocabularies, make sure content is conformance tested using the latest version of the vocabularies in use.

R-SO.6: Uniquely identify each controlled vocabulary and controlled vocabulary term and only use identifiers in metadata records.
Because identifiers are language neutral tokens, they can be associated with multiple translations of the same term. Using tokens in metadata records makes it possible to display in a given language a metadata record created in another language provided that both languages are available in the vocabulary bank.

Note that this recommendation is applicable to all organizations developing controlled vocabularies, not just standards organizations.