Application Profiles - Overview

Terms of use
X Terms of use
These contents have been obtained from the IMS official Web site and edited for presentation. Please refer to the IMS Web site for additional information on terms of use.
Print
An Application Profile is a refinement of an existing specification (or set of specifications) to make it more suitable for its application by a particular community of practice. Some key reasons for developing an Application Profile include:

  1. To meet technical and other requirements and preferences specific to a project, community, domain, or region;
  2. To address ambiguity and generality in a specification or standard;
  3. To foster semantic interoperability, e.g., through the use of commonly understood vocabularies;
  4. To facilitate testing for conformance and successful interoperability.
There are many sources which seek to define Application Profiles more precisely, in particular by defining rules which need to be followed when producing an Application Profile. The main reference works of interest to the learning technology community are reviewed in this section. Whilst there are minor differences in emphasis and interpretation between these sources, it is generally agreed that the process of generating a derived specification and schema is likely to involve one or more of the following activities:
  • Selection of a core sub-set of elements and fields from the source schema/specification (expressed perhaps as a mandatory sub-set of elements which must be supported as a minimum);
  • The addition of elements and/or fields (usually referred to as “extensions”) to the source schema/specification in a manner defined within the derived schema;
  • Tightening of constraints placed upon the an element to reflect the needs of the target community (e.g. replacing a free text vaule space with a controlled vocabulary or extending an existing, vocabulary such as a bounded set of competencies or a curriculum model);
  • Producing a comprehensive description of the semantics and common usage of the data elements as they are to be applied across the community.

The process of of developing an Application Profile can be characterised as involving the following activities:

  1. Localization: the specialization of one or more conceptual data models (source specifications) to the precise needs of a community, generating a derived specification;
  2. Representation: mapping the derived conceptual data model(s) to a technology binding (schema) for interchange;
  3. Transaction: define how the abstract interface and service model, i.e., the APIs, and implied/stated transactions are to be realized utilizing a concrete platform technology.
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the CEN official Web site and edited for presentation. Please refer to the CEN Web site for additional information on terms of use.
Print
Image for 'Overview'
European Committee for Standardization
The CEN Workshop Agreement CWA 15555 (Guidelines and Support for Building Application Profiles in e-Learning) seeks to address possible confusion and lack of experience amongst communities wishing to develop Application Profiles relating to e-learning.

Application profiles enable “mixing and matching” metadata elements, in order to meet specific requirements for a particular context. As an example, some communities may want to make certain elements mandatory or restrict the value space of a particular element. However, there is much confusion and only limited experience and expertise in the development and deployment of application profiles. That is why the CEN Learning Technologies Workshop decided to develop guidelines on the use of application profiles for e-earning.

Although many of the guidelines presented in this CWA can be applied to any kind of application profile, the focus here is on application profiles for metadata, more specifically for IEEE Learning Object Metadata (LOM). In addition, application profiles of other metadata standards, such as for instance the IMS Learner Information Package (LIP), have also been considered.

In parallel to the CWA, an online Registry for Application Profiles equally with a particular focus on the IEEE LOM standard has been developed.
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the DCMI official Web site and edited for presentation. Please refer to the DCMI Web site for additional information on terms of use.
Print
Image for 'Overview'
Dublin Core Metadata Initiative
When it comes to metadata, one size does not fit all. In fact, one size often does not even fit many. The metadata needs of particular communities and applications are very diverse. The result is a great proliferation of metadata formats, even across applications that have metadata needs in common. The Dublin Core Metadata Initiative has addressed this by providing a framework for designing a Dublin Core Application Profile (DCAP). A DCAP defines metadata records which meet specific application needs while providing semantic interoperability with other applications on the basis of globally defined vocabularies and models.

Note that a DCAP is a generic construct for designing metadata records that does not require the use of metadata terms defined by DCMI. A DCAP can use any terms that are defined on the basis of RDF, combining terms from multiple namespaces as needed. A DCAP follows the DCMI Abstract Model, a generic model for metadata records.

A DCAP includes guidance for metadata creators and clear specifications for metadata developers. By articulating what is intended and can be expected from data, application profiles promote the sharing and linking of data within and between communities. The resulting metadata will integrate with a semantic web of linked data. To achieve this it is recommended that application profiles be developed by a team with specialized knowledge of the resources that need to be described, the metadata to be used in the description of those resources, as well as an understanding of the Semantic Web and the linked data environment.

The interoperability of DCAP-based metadata in linked data environments derives from its basis in standards:
  • Resource Description Framework (RDF), the foundation standard on which domain standards rest,
  • the Dublin Core Abstract Model, a generic syntax for metadata records,
  • the Dublin Core Description Set Profile, a constraint language for Application Profiles
  • DCMI guidelines for implementation encodings.
NOTE: The Dublin Core Education Community is developing an DC-Education Application Profile (DC-Ed AP) intended to describe a precise category of "things in the world" that have been deliberately purposed (or re-purposed) for use in the processes of formal and informal teaching and learning. The DC-Ed AP is limited to defining use of properties describing the educational characteristics of a resource. Properties describing general descriptive attributes of a resource or properties describing use of a resource in contexts other than teaching and learning, are outside the scope of the application profile.
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send
Terms of use
X
These contents have been obtained from the IMS official Web site and edited for presentation. Please refer to the IMS Web site for additional information on terms of use.
Print
Image for 'Scope'
Each of the present set of IMS learning technology specifications has been driven by requirements (normally expressed as use cases) from a cross-section of potential users of the target specification. A user of a specification in this sense encompasses:
  • Vendors of e-Learning platforms, tools, and services wishing to address a need amongst their existing and prospective customers;
  • Third-party suppliers of ancillary or related services, e.g. hardware, network services etc.;
  • Institutions representing adopting communities;
  • Researchers wishing to harness specifications in applied research of next generation tools and services.

The intention has been and remains, to ensure that specifications going through the IMS process are well grounded in established practice and are sufficiently general to meet the needs of a number of distinct users rather than a special case.

Experience of increasing adoption of the specifications across both vertical domains, i.e., K-12, vocational training, higher education, corporate training, basic skills for life, and geographical regions, has made evident a recurring process of adaptation of the specifications to meet the specific needs of each community.

Agencies undertaking this process clearly have a well identified community in mind and have researched the precise needs of that community, in order to both select the sub-set of the specifications required and propose the necessary changes and extensions to meet their needs.

This emerging model for the adoption process is encouraging as it would seem to confirm that the IMS specifications have indeed been kept sufficiently general for them to have broad-based appeal and offer utility across communities. An Application Profile on the other hand, clearly enhances the utility of a specification to a community and, if adhered to, promises greater interoperability between members of that community.

Experience to-date has identified real benefits to be gained from closer collaboration across communities in developing these profiles, particularly in agreeing basic rules to be followed, and adopting a consistent format for documenting each Application Profile:

  1. Agreeing a consistent set of rules for constructing a profile will bound the changes that can be made thus ensuring greater interoperability across conformant Application Profiles;
  2. Providing consistent documentation of Application Profiles will enable vendors to more easily build products and services that span multiple communities with simple configuration settings for localization;
  3. The growing number of publicly documented Application Profiles will allow subsequent adopting communities to select and reuse elements of existing profiles, rather than develop from first principles;
  4. Ultimately, providing strongly typed, machine readable definitions of these Application Profiles will enable runtime context negotiation between domains to facilitate data exchange and interoperability across communities.

The IMS Application Profile Guidelines define a process for taking one or more source specifications and refining these to create a tighter and more cohesive specification (i.e. the profile) that meets the requirements of a specific target community. Crucially, a well defined profile should be precise about what must be supported, thus offering implementers a clear and unambiguous target for them to achieve conformance.
IMS GLC Profiles Web Site
Comments / Suggestions / Error reporting on this page
Please, choose an item on drop-down menu and write your text
Send