Skip navigation.
Home

ASPECT for Tools 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-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.

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.

Automatic Translation Service for Learning Object Metadata

Deliverables

  • D1.3.2 Final Public Report
  • D2.3 ASPECT Approach To Multilingual Vocabularies, Including Automated Translation Services
  • D2.7 Infrastructure and services v3.0
  • D3.2.2 Conformance Testing Tools version 2
  • D3.5 Best practice report for content use 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

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