Sharedresources Metadata
The Sharedresource system provides a full metadata based index for resources. This documentation explains how to setup the metadata system, and some reminders about those models.
What Are Metadata
Metadata ae piece of information that are NOT the content of the indexed object, but some information ABOUT this object that need to be stored aside. Metadata could be simple flat list of attributes, f.e. for an image, an explicit mention of its size in pixel, color model, authoring tool origine etc.
This metadata are quite usefull to help people searching for an adequate resource, if they are carefully initialized.
As long as metadata were used more and more, the number of attributes increased, and simple flat lists were a bit complicated to work with. So metadata came to be organized in a hierarchy, with chapters and subchapters. Thus metadata came to be stored as hierarchic schemas.
Dublin Core
Dublin Core is a generic technique to organize such information storage. What is essentially needed to be retained is that Dublin Core requires that each piece of information is to be stored as a "tree node" with an numeric index of the node made with each local node count (from 1) of all branches in the path to the root. Nodes are thus numbered 1, 1.1, 1.1.1, 1.1.2, 1.2, etc.
Each node can be a single value or a list of values. The schema will tell for each if a list or a scalar. When a node admits a list, all items of the list will still be identified by the same DC node index. (f.e. multiple keywords attached to a ressource will be multiple value items of the node 1.5)
Each node value or item value can be :
- some explicit format compliant value (f.e. a date)
- some vocabulary entry (one of a set of finite non mutable set of terms)
- a free input value
LOM
Standing for Learning Object Metadata, this is a Dublin Core compliant standard for describing learning resources of many types. The standard proned to be generic and international. The LOM opens 9 first level categories for storing metadata pieces of information.
Category 1 is "General information" while
Category 9 is related to "Classification".
LOM proposed a strict definition of vocabularies for some metadata entries such as "document type", with some possible caveheat that the initial set of terms being not able to follow the evolution of the surrounding technologic or practical environment.
LOM Extensions and Derivatives
As far as metadata being accepted by the pedagogic community, the initial schemes could not comply with the real field practices. The resource description needs were evolving and the standard did not clearly separate the semantic identification from the idiomatic environment.
Several countries provided they own extension, as admitted by the standard.
F.e. in France, a first LOM derivation was opened as LOMFRv1.0, taking the occasion to adapt and complete a few vocabularies. Then came requirements of the National French Education system, needing to precise some resource specifications related to the interaction of the resource with the organisation of education system in France. This came to the ScoLOMFRv1.0 standard. A third standard appear when french higher education examined the ScoLOMFR and decided some choice were NOT adapted to their environment. So the SupLOMFRv1.0 was established.
Other countries have similar standard progress.
the Sharedresource component set for Moodle provides a pluggable model for handling metadata for resources. The metadata scheme is held by a metadata plugin. One unique plugin must be activated in Moodle, deciding of the indexation model for the whole platform.
Developpers will be able to add new metadata models by cloning and renegociating the description of the information tree.
Implemented Schemas
The official distribution of the Sharedresource components provide as standard :
- LOM
- LOMFRv1.0
- ScoLOMFRv1.0
- SupLOMFRv1.0
User Profiles Relative to Metadata
As metadata schema often propose much more information definition that really directly usefull, or even known by authors, the sharedresource metadata implementation proposes three tunable profiles related to metadata operations. Each profile can be tuned to choose which part of the metadata schema will be accessible and usable. Forms for describing resources will be limited to that visible part, improving author user experience with metadata.
- The Author: The author usually have the smallest view of the metadata schema. The author is not well-willing to provide complete an exhaustive metadata information as he has a very indirect use of them (an implicit utility when he uses the search engine, but relationship to metadata feeding quality is not trivial).
- The Librarian: The Librarian usually have access to more information and has processes to fetch the missing information. He is usually skilled to understand the meaning of all attributes (or can be trained to).
- The Administrator: Not a real operational profile, but we needed someone who could access to all parts of the standard without restrictions.
An important work when publishing a ressource is providing the minimal set of metadata that will participate to keep search results consistant and usefull.
When adding a resource to a course using the sharedresource implementation, users will be proposed a 3 step process :
- Step 1 : provide the resource content (an uploaded file or an url)
- Step 2 : feed metadata (depending on profile)
- Step 3 : setup local publication parameters for the resource instance in the course.
When a Librarian adds a resource directly from the Sharedresource Library Front End, he will just have to process steps 1 and 2.
Using Metadata in Search Engine
An administrator can choose which piece of information will be presented as criteria for the search engine. Actually to improve user experience, the number of criteria should be as reduced as possible. As the Library may be used in multiple quite different contexts, there is no "absolute choice" of what is usefull and what is useless. So it has been left fully configurable.
