Dashboard > LIFE Roadmap Project > Home > 9 Learning Object Repositories
  LIFE Roadmap Project Log In | Sign Up   View a printable version of the current page.  
  9 Learning Object Repositories

Added by Frans Van Assche , last edited by Frans Van Assche on Oct 13, 2007  (view change)
Labels: 
(None)


This is a new chapter, started up after the LIFE project ended. It is work in progress. It is essentially factoring out the LO repository discussion because this deserves its own chapter. It builds on the results of the expert meeting on Content, metadata and learning object repositories.

Recommendations

Recommendation 1

To promote organisational/social interoperability and to invest more in supporting sustainable communities. This is part of the pragmatic interoperability as elaborated in chapter 1. Technical solutions should be more socially effective and therefore teachers should be more involved. For example, the judgement of users can be harnessed in order to find out what quality is and users may be able to provide metadata that connect better to their practice (cf folksonomies). Teachers should be given the tools for localising and adapting material more easily as well as tools for social and community based metadata tagging. The major challenge will be to find ways and provide tools and infrastructures for making the community generated outcomes interoperable. Furthermore, in order to empower users, trust is important, so that less control is needed. Systems fostering trust such as a federated identity management system are highly desirable.

Recommendation 2

To support communities in the agreement on use of LOM, vocabularies, application profiles, etc. This is directly related to the semantic interoperability as elaborated in Chapter 1. While recommendation 1 promotes diversity, recommendation 2 promotes harmonisation. Obviously there is a trade-off but to a certain extent they are complementary. Recommendation is intended to avoid unnecessary differences and to foster means to relate different approaches to each other. The use of the LOM by a community is described in a so-called application profile. In building an application profile many degrees of freedom exist. If one is aware of other application profiles it is often possible to choose particular options that are compatible with the existing ones. For example, there might be reasons to develop a different vocabulary than what is provided in the LOM. If however one develops this as an extension or refinement of an existing vocabulary, interoperability is preserved to a certain extend. Similarly it is good practice to base the development of an application profile on an existing one. This recommendation is intended to improve the support for reaching agreements and building application profiles. This includes the establishment of registries for vocabularies and application profiles, provide the tools and guidelines for easily extend, refine, and map vocabularies and application profiles, and provide tools for certifying whether certain LOM instances are adhering to a particular application profiles.

 Recommendation 3:

To provide a framework of well factored out services and there relationships in an interoperability stack together with a registry of available services.

To be done

Here comes some further elaboration with references to chapter 1




 Recommendation 4:

It is recommended that approaches for dealing with digital rights are further researched, tried out, and implemented. To this end the requirements of communities that share the same concern should be understood; requirements in terms of rights to be expressed and enforced, and workflow. For open content licensing schemes such as creative commons it will be necessary to identify how to deal with requirements of specific communities. For example it happens that creative commons is entirely suitable with the restriction that it only applies to users from a particular country or region. For commercial content it is recommended that models are developed for business to business situations as well as business to customer.

Recommendation 5 

The vast majority of teachers (including professors) will want to do small modifications to learning objects in order to repurpose it or adapt it to specific local conditions. The community of teachers has primarily a need for simple repurposing/localisation tools and methods rather than complex authoring tools. In addition methods and tools should be developed to make learning objects more adaptable. Furthermore, digital rights expression languages should be such that adaptation and localisation is made easy.

Recommendation 6

Related to querying other repositories the following recommendations are made

  • The definition of a query exchange format: When searching a federation for resources, it is necessary to transport queries between heterogeneous systems. The exchange format should be rich enough to express meaningful queries and abstract enough to be easily mapped into the concrete query languages supported by the target resource repositories.
  • The specification of a query interface: This is necessary to transport queries to the federated repositories and get results. Such an interface must take into account the requirements of federated searches (e.g., asynchronous remote façade).
  • The definition of a query result format: A common way to express query results is needed.
  • The global identification of resources: Resources should be uniquely identified so that it is possible to unambiguously refer to them in metadata exchanged between systems.
  • The global identification of systems and repositories: Similarly, it should be possible to unambiguously refer to the systems that host these resources.
  • The description of learning content repositories or collections using so-called collection level description for Learning Object collections. Metadata may include a subset of the LOM enriched with some new elements such as 'Quality assurance procedures'. 
  •  The specification of a synchronization interface: A synchronization interface is necessary to mirror metadata. Ideally, push and pull scenarios must be supported.
  • The definition of a user profile: Current specifications, such as IMS LIP, focus on the administrative data of learners. In order to provide more accurate search results it would be interesting to describe the "educational context" of a user (e.g., role: professor/teacher vs student/pupils, topics of interest, etc.)  
  •  Integration with federated identity management (single-sign on, user identity, access management): This is necessary (together with the integration with digital rights management systems) to make the rights associated with resources enforceable.
  • Integration with digital rights management systems.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.6.2 Build:#919 Nov 26, 2007) - Bug/feature request - Contact Administrators