Docstoc

SECTION 1 Metadata _Nik Jewel_

Document Sample
SECTION 1 Metadata _Nik Jewel_ Powered By Docstoc
					                                                                        A Guide to Metadata.
About this document
This document was prepared by Jenny Slater, former CETIS Metadata SIG co-ordinator. It was last updated on 18/12/02,
and all information was correct and up to date at this time. The explanations here are not intended as authoritative and
are provided as a guide only. Further references and definitions of the terms used in this document can be found on the
http://www.cetis.ac.uk web pages.


Contents
About this document .............................................................................................................................................................................. 1
Contents .................................................................................................................................................................................................. 1
SECTION 1 : About metadata. ............................................................................................................................................................. 1
    Introduction. .................................................................................................................................................................................... 1
    What are metadata elements? ..................................................................................................................................................... 2
    The metadata schema. .................................................................................................................................................................. 2
    Metadata and vocabularies........................................................................................................................................................... 2
    What is a metadata specification? ............................................................................................................................................... 2
    What metadata cannot do. ............................................................................................................................................................ 3
    What is metadata used for? .......................................................................................................................................................... 3
    Who creates metadata and how is it stored? ............................................................................................................................. 4
    Metadata for Interoperability (in brief!) ........................................................................................................................................ 5
SECTION 2 : Creating your own metadata implementation ............................................................................................................ 6
    Introduction ...................................................................................................................................................................................... 6
    Step 1: Consider the needs of your project. ............................................................................................................................... 6
    Step 2: Look at relevant standards and specifications. ............................................................................................................ 7
    Step 3: Look at existing practice. ................................................................................................................................................. 7
    Step 4: Create a schema. ............................................................................................................................................................. 7
SECTION 3 : Documenting your implementation .............................................................................................................................. 8
    Application profiles: what are they? ............................................................................................................................................. 8
    Application Profiles: how do I create one? ................................................................................................................................. 8
    The Resource Description Framework (RDF) ............................................................................................................................ 8
    Namespaces ................................................................................................................................................................................... 9
Appendix 1 – Metadata elements divided ......................................................................................................................................... 10
    Objective – Subjective Metadata ............................................................................................................................................... 10
    Intrinsic – Extrinsic Metadata ...................................................................................................................................................... 10
Appendix 2 – “Organisations involved on metadata standards”.................................................................................................... 10
    ADL/SCORM ................................................................................................................................................................................. 10
    ARIADNE ....................................................................................................................................................................................... 11
    British Standards Institute (BSI) ................................................................................................................................................. 11
    CEN/ISSS ...................................................................................................................................................................................... 11
    Dublin Core Metadata Initiative (DCMI) .................................................................................................................................... 11
    IEEE Learning Technology Standards Committee (LTSC) .................................................................................................... 12
    IMS Global Learning Consortium Inc. (IMS) ............................................................................................................................ 12
    International Standards Organisation (ISO) ............................................................................................................................. 12


SECTION 1 : About metadata.

Introduction.

The literal meaning of “metadata” is “data about data”. It is also described as structured, descriptive information.




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
Metadata can be used to describe an information resource, an image, a collection or a simulation, amongst a multitude of
other kinds of resources. Metadata is often compared to a library catalogue record, which is a structured description of an
information resource.

Libraries have had cataloguing rules for many years, to specify how descriptive information ought to be recorded. The
Anglo-American Cataloguing Rules were developed to promote consistency of description and enable record sharing. The
MARC format was created as a way of storing catalogue records in a machine-readable format. Similarly, metadata has
features that improve its function of describing a resource (semantics) and there are different ways to make the metadata
machine-readable (syntax).

A library catalogue record is very detailed, the rules for description are complicated and the method of description was
originally tailored to the printed document. Metadata emerged from the information and communication technology (ICT)
sector as a way of structuring information about the various new types of resources that were being created, which had
different characteristics to be described than the traditional library resource.

Metadata is used by a number of different interest groups in different ways, and different specifications and standards are
being developed. The CETIS Metadata Special Interest Group (SIG) is focused on metadata that is used for describing
learning resources, and this guide will reflect this focus.

What are metadata elements?

Metadata elements are the individual parts of a metadata schema, used to describe individual characteristics of a
resource and to give the description its structure. For example, there is usually an element for the title of a resource, and
for a general description. How the information relating to each metadata element is recorded is often unique to each
implementation, but metadata elements often become fields or tables in a database.

Metadata elements can be said to be intrinsic or extrinsic to a resource. The intrinsic metadata describes what an object
or resource contains, or is about. Extrinsic metadata gives the object context, describing how it was created, where and
by whom, etc. The distinction between intrinsic and extrinsic metadata is not often made by those using metadata
schemas, and is most often discussed amongst those developing specifications and standards. Please see Appendix 1
for a discussion of this division.

The metadata schema.

A metadata schema defines the relationships between individual metadata elements. The SCHEMAS glossary defines a
schema as: “A set of metadata elements representing the attributes of a resource. Each element will have a name and
associated semantics.” This means that the relationships between elements are defined, and relationships with any “sub-
elements” or “qualifiers” are described in the schema. Ways in which the elements can be used are specified. The Dublin
Core Element Set is therefore a schema, as is the IMS Learning Resource Meta-data Specification

The term “scheme” is often confused with “schema”. A metadata schema describes metadata elements, some of which
may be suitable for use with controlled vocabularies. Where a suitable vocabulary from a published or well known source
is used, this is known as a scheme. Ontologies, taxonomies and thesauri are all types of controlled vocabulary. Thus
there can be many schemes in one metadata schema.

Metadata and vocabularies.

The vocabularies or classification schemes chosen for use with each element are very important in deciding the structure
of a metadata schema. If a characteristic can be described by one particular element, when a comprehensive list of terms
has been allocated to that element, then it may prevent the creation of a separate metadata element. This is important, as
fewer elements mean faster and simpler searching. It also makes for a “purer” description, from the point of view of
experts! One example is, rather than recording if the resource was created in the UK (yes/no), and if not where not (A list
of country codes), it makes much more sense to record just one piece of information that describes where the resource
was created.

What is a metadata specification?




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
A specification is an embryo standard. It has been drawn up by experts and is based on research and experiences of
implementing the schema that the specification describes. A specification is intended to provide the basis for development
of a commonly agreed standard that will be developed at some time in the future.

The IMS Global Consortium, authors of the IMS Learning Resource Meta-Data specification are not a standards body, so
their specification will be submitted to a standards body when work on it has been completed. Standards bodies world-
wide set up working groups to track developments such as this. In the meantime, a specification serves metadata users
as an example of good practice, and gives those who conform to it an opportunity to share records or develop cross-
searching between distant repositories of descriptions.

What metadata cannot do.

Metadata is not something that you can simply add in to a resource and expect it to work with any other resources that
comply with the same standard you are using. To make your resource work with other resources, there are specifications
and standards for the design and packaging of resources, which are often referred to as “content.” For further information
on making the resources themselves interoperable, please visit the CETIS Educational Content Special Interest Group
pages at: http://www.cetis.ac.uk/learning-content/

At present, there are a number of metadata standards and specifications, and even though in many cases those involved
in their development are working together, there are some differences between them.
Also, the specifications and standards available at present are open to a good deal of interpretation by an individual
implementation. This is because:

1) The use of elements remain optional in some standards and specifications. Therefore different implementations may
   not use many metadata elements in common with each other.
2) New elements or extensions to existing elements may be used by an implementation, in addition to the set of
   elements defined by a standard or specification. Where two implementations have needed to describe a characteristic
   not covered by a standard or specification, it is not likely that their extensions will be compatible.
3) Metadata implementers have a choice of specifications and standards to describe the same characteristics of a
   resource. Unless two different implementations choose the same specification or standard for the description of the
   same characteristics, their metadata will not necessarily be shareable, due to the differences between the
   specifications or standards they have chosen.
4) Controlled vocabularies for use with metadata elements are not always included in standards and specifications.
   Where controlled vocabularies are provided for metadata elements, once again the issue of compliance/conformance
   is clouded. Often they are recommended as “best practice” and are not compulsory, so that individual
   implementations may choose their own controlled vocabularies. This is often for the best, as it is very difficult to agree
   on controlled vocabularies to suit every need on an international scale.
5) Where controlled vocabularies are provided by specifications and standards, and are adopted on a wide scale by
   individual implementations, their use is always subject to different interpretations of how the terms should be applied,
   and what they can be taken to mean. The same words may have different meanings in different cultures.

Metadata standards and specifications need to be fairly loose, so that they are relevant across as wide a range of cultures
and implementations as possible. There is a possibility that national recommendations for the use of certain standards
and specifications can improve their usefulness. There is a need for national taxonomies for the key areas implementers
want to describe: discipline, level, type, format etc. Communities of metadata implementers are slowly moving towards
more common taxonomies, but we are not there yet and it is increasingly being recognised that there is also a need for
local guidance on how the standards and specifications should be used.

What is metadata used for?

Resource retrieval
The richness and structure that metadata gives to a description enables people looking for a resource to specify
characteristics that they would like to find. For example, a French language teacher might be looking for learning material
written in French and intended for non-native speakers of that language. It is unlikely that resources with such
characteristics would be easily identifiable through free-text searching. The language a resource was written in, and the
first language of its intended audience can be described in a metadata record, and therefore searched for in metadata
records. Only resources matching the teacher’s criteria would be presented in the results of a search of metadata records,
thus improving the precision of resource retrieval, and all resources with metadata that matches the teacher’s criteria
would be returned, improving the recall of resource retrieval.



D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
Metadata can be used to describe any number of characteristics for a resource, and made searchable. There are
standards and specifications emerging to encourage the description of core sets of characteristics that might be useful to
certain communities.

For further examples of how metadata can be used to enhance searching, please refer to the article by Marti A. Hearst,
entitled “Next Generation Web Search: Setting Our Sites”, in the IEEE Data Engineering Bulletin Special issue on Next
Generation Web Search, September 2000.

Informing people
By describing resources in a standard way, metadata records also enable humans to compare the characteristics of
resources when looking at a set of records. A well-structured description provides information upon which people can
make judgements about a resource and compare it with other resources.

Future uses
It is anticipated that metadata used to describe resources of low granularity (ie a single image or piece of text) will be
used in order to create new, larger, composite resources that meet a user’s particular requirements for learning. In such
instances the metadata would be used alongside the learner’s profile information, for which there is also an IMS
specification and a CETIS Special Interest Group.

Metadata can be used for any number of purposes. How metadata can be used depends on which characteristics are
described. For example, using metadata to locate resources suitable for teaching first year high school students history
requires a description of the subject of a resource, and the educational level of audience for whom it is suitable. A
database or collection that uses metadata would therefore need to include elements to describe all characteristics of
resources that would be of use for those searching that collection or database.

Who creates metadata and how is it stored?

Metadata can be stored as part of a resource, such as the HTML <meta name> tags which appear in the source code of
the following web page: http://failte.ac.uk/ as displayed below:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<link href="failte_style.css" type="text/css" rel="stylesheet" />

 <title>FAILTE: home page</title>
 <meta name="Description" content="Home page for the FAILTE project. FAILTE (Facilitating Access to Information on Learning
Technology for Engineering), aims to provide Engineering lecturers in UK Higher Education with information on the availability of
computer and web-based teaching and learning resources." />
 <meta name="Keywords" content="engineering, teaching, learning , university, computer based learning, web based learning, higher
education" />

  <link rel="schema.DC" href="http://dublincore.org/" />
  <meta name="DC.Title" content="FAILTE: home page" />
  <meta name="DC.Creator" content="Phil Barker" />
  <meta name="DC.Subject" content="engineering; teaching; learning; university; computer based learning; web based learning;
learning resources; higher education" />
  <meta name="DC.Description" content="Home page for the FAILTE project. FAILTE (Facilitating Access to Information on
Learning Technology for Engineering), aims to provide Engineering lecturers in UK Higher Education with information on the
availability of computer and web-based teaching and learning resources." />
  <meta name="DC.Publisher" content="Heriot-Watt University" />
  <meta name="DC.Date" scheme="W3CDTF" content="2000-12-05" />
  <meta name="DC.Type" scheme="DCMIType" content="Text" />
  <meta name="DC.Format" content="text/html" />
  <meta name="DC.Identifier" content="http://failte.ac.uk/index.html" />
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
This metadata was added to the resource by its own creator. It is possible for search engines to use meta-tags like these
to enhance their capabilities. (For more information about meta-tags and search engines that use them, please see:
Sullivan, Danny (2000) How To Use HTML Meta Tags. http://searchenginewatch.com/webmasters/meta.html)

Tools are being developed for the automatic creation of a metadata record to be attached to a resource, as that resource
is being created. An example of this is the now finished SeSDL project, where an IMS conformant content package and
IMS conformant metadata record were created at the same time. In this way, a metadata record is generated by a tool
and created by the author of the package.

The metadata record may then be stored with the content, often as a separate record in the manifest file which describes
how the resource is put together and broken down. For more information about how metadata may be created and stored
together, please investigate the CETIS Educational Content Special Interest Group and it’s web pages at:
http://www.cetis.ac.uk/learning-content/


Metadata can also be stored remotely, as a separate document, in the same way as library catalogue records work. In
this instance, the metadata records are often created by a specialist. A collection of metadata records based on a
specialist metadata schema, chosen to meet the needs of the collection’s end-users, has the potential to contain
descriptions that are much richer and potentially more useful than those provided by the resource creator. The ideal
situation would be for such records to be based upon a brief metadata record created by the resource creator. The
FAILTE project is an example of such a collection.

Metadata for Interoperability (in brief!)

Interoperability can be defined as: The ability of systems and data to work seamlessly together (CETIS reference tool).
Interoperable metadata records are those which describe the same characteristics in the same way, and can therefore be
understood by both people and computers in the same way. At the very lowest level of metadata interoperability,
metadata records should all contain a certain number of the same elements of description. (Simple Dublin Core involves
15 elements.) Further interoperability is achieved if metadata records use the same syntax or binding, for computers to be
able to interpret. Full interoperability would mean that two computer systems that store metadata records would be able to
interact with each other, to share records, or be searched simultaneously. This level of interoperability is hardest to
achieve, and goes beyond the scope of metadata standards and specifications. IMS have a working group to look at
specifications to make systems work together in this way, called the Digital Repositories Working Group.

Metadata standards and specifications are intended to provide a template for those wishing to store descriptive records to
follow. Those who use metadata follow the template to create a metadata “implementation” (also called a metadata
“application”). Where two metadata implementations are based on the same standard or specification schema, there is a
potential for interoperability between those two implementations. Where two implementations have used different
standards or specifications, there is often still a potential for interoperability, with a little more work, as many of the main
standards and specifications contain metadata elements that describe the same characteristics. The standards and
specifications can be mapped to one another. By matching elements that are the same in each schema, interoperability
between two implementations based on different standards can be achieved.

Further information about individual metadata standards and specifications can be found in the section on “Organisations
involved in learning resources metadata.”

Application profiles enable a metadata implementation to describe which standard or specification each of the metadata
elements it uses has come from. Thus an individual metadata implementation can choose the metadata elements that
best suit its own needs from amongst the standards and specifications. The application profile allows those from another
implementation to identify which metadata elements are common to both implementations and can therefore form the
basis of record sharing or a cross-searching service. (Further information about application profiles can be found in the
“Documenting your implementation” section.)

Benefits of creating interoperable metadata records.
Interoperable metadata records can be shared between different collections, imported from one database to another. This
has the advantage of saving duplication of effort in describing a resource, and also means that useful metadata records
can be stored and made available through another database or repository even once the original source of the records
has ceased to exist. Record sharing will mean that specialist collections will be built more rapidly, with a more complete
coverage.




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
The potential of cross-searching more than one collection of records depends on the compatibility of the metadata
records, as well as the compatibility of the technology used to run the databases or repositories themselves. Thus, even if
two databases are built using the same or compatible technology, so that they can both be queried simultaneously, the
results of such a search would only be meaningful if both databases had used similar metadata. Cross-searching facilities
will mean that people can perform more extensive searches and save time by not having to search databases separately,
which might require the forming of separate search strategies for each database.

The benefits of standardised metadata to the database user will be that he or she will already be familiar with the format
of records in an unfamiliar database, enabling the user to understand descriptions of resources and compare resources
more easily.

Links and Further references to introductory material




SECTION 2 : Creating your own metadata implementation

Introduction

The terms “implementation” and “application” are both used to refer to an individual project’s use and interpretation of
metadata elements from one or more standard or specification. An implementation may involve interpretation of more
than just the set of metadata elements, and include features such as how metadata records are to be codified, and how
those records are to be stored and shared with others. The term “application” is generally used in the context of the
interpretation of metadata elements themselves.

A metadata implementation begins with the definition of a metadata element set, to meet the needs of a particular project.
A defined metadata element set is referred to as a schema. Some steps towards defining a metadata schema for an
individual project are described in the sections that follow. These steps need not be taken in a particular order, although
the needs of the project are probably the best place to start, and will need to be re-visited frequently.

Step 1: Consider the needs of your project.

This is the first, most important stage. If you begin with your projects’ own needs, then you will know what you are looking
for in a specification or standard, and it will guide you in looking for specifications and standards that will suit your needs.
Some points to investigate:

1) Consider the nature of the material that you will be describing. This may require a definition of what you mean by the
   term “Learning resource”, or a selection procedure for deciding on what you include in your collection. For instance, if
   the material you intend to describe is all of a particular resource type, or for a particular level of education, you might
   not need to describe this in every record, or could easily insert it into a metadata record as a default.

2) Consider the needs of those who will be using your metadata to search for resources. This might involve approaching
   your community of end users, to ask them what characteristics they would be searching for, through focus groups or
   surveys and the like. Any characteristic of a resource that you might expect an end user to search for will need to be
   described, and will need a metadata element.

3) Consider what information you will need on a resource or record, for the purposes of maintaining your database. For
   instance, if you need to know when a record was created, by whom and when it was last up-dated, then you will need
   a metadata element to describe each of these characteristics. This type of metadata, describing the record itself is
   referred to as meta-metadata.

4) Consider any other metadata implementations that you might wish to be interoperable with. This consideration fits in
   with Step 3: “Look at existing practice”, which might be the stage when other projects with which to share records or
   allow cross-searching are discovered. If two projects have different interpretations of how metadata elements should
   be used, then the interoperability of their records will be limited, and cross-searching or record sharing may not be
   practical.




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
Step 2: Look at relevant standards and specifications.

Once you have considered what you will need to describe about a resource, and what elements of description you will
require a record to consist of, you will have an idea about what sort of metadata specifications and standards will be best
suited to your needs. It is possible to use elements from more than one metadata standard or specification in your
schema, and it is possible that by complying with or conforming to one standard or specification, you will also be
complying/conforming to another. (NB It is said that a standard is “complied with”, and a specification “conformed to”!)

For example, if you are describing learning and teaching material, the IMS learning resource meta-data specification
might suit your needs. This specification is based on the IEEE Learning Object Metadata standard, which in turn has
links with the Dublin Core standard, so you may be compliant/conformant with all three specifications, at some level. You
might also find that the Dublin Core way of describing the intended audience of a resource meets the needs of your
project better than any IMS or IEEE LOM metadata element, and could use this alongside IMS metadata elements in your
schema. Please see the section “Metadata bodies” for introductory information about some metadata specifications and
standards.

When searching for relevant metadata standards and specifications to consider, it may help to look at the standards and
specifications that others have used. Appendix 2 – “Organisations involved on metadata standards” details organisations
involved in metadata standards and the situation in Spetember 2001. Further, up-to-date information about learning
resources metadata standards and specifications, and the bodies that produce them is available from the CETIS web site.

Step 3: Look at existing practice.

You may find that others have been describing material similar to that which you wish to describe, and that they have
already found solutions to certain problems that you may be encountering. Here are some ways in which you can find
other metadata implementers and documentation on metadata implementations:

    UK-MEG - this is a community of educational metadata users, and has a wide ranging membership.
    CETIS Metadata SIG - this is a community of educational metadata implementers who have got together to work out
     solutions to some common problems.
    Registry of MEG related schemas
    SCHEMAS forum – for metadata schema implementers.


Step 4: Create a schema.

When creating your own schema, consider carefully how the metadata elements you will be using will work together, in
creating a description to suit the needs of your project. Once you have chosen your set of metadata elements, each
element will need to have certain characteristics defined. The following sections suggest some aspects of your metadata
elements that it might help you to describe.

Obligation
In order for your metadata implementation to work, you will need to agree on which metadata elements will make up the
minimum required set for a full description for the purposes of your project. Each element can be given an obligation
status, to describe whether it is compulsory for this information to be recorded, or whether it is optional for the information
to be recorded. Any information that you expect your end user to search for ought to be compulsory for the cataloguer,
but you might consider that it might be difficult for some information about a resource to be ascertained, so that a neutral
option, such as “information not available” ought to be provided.

Type
Such as free text, restricted format, or controlled vocabulary.

Size
Length of text, or number of terms from a vocabulary that can be selected

Guidelines
Any information on how to find out information about the particular resource characteristic that the metadata element
describes, and any guidance on how this information ought to be represented for the sake of consistency. Also, if



D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
necessary, information about how vocabularies ought to be used, and anything to look out for to describe for a free text
element.

Such information about your metadata elements will help you to build your metadata implementation, and will also help
others to understand how your metadata works. This information can be incorporated into an application profile for your
project’s metadata schema.


SECTION 3 : Documenting your implementation

Application profiles: what are they?

The concept of an application profile has arisen out of the need for metadata implementations to document what they
have been doing, in order to share good practice, and to further interoperability. The application profile is a record of what
metadata elements have been/are being used for a particular project or community. A metadata application or
implementation might be conformant or compliant with only one authoritative metadata schema, but since metadata
elements are often optional, some documentation of how that schema has been applied would be helpful to other
metadata implementations that might interoperate with it.

Many of those who are using or intend to use metadata have found that there is no one authority that defines metadata
elements for all of the important features of the resources that they wish to describe. When different projects or
communities are using different metadata schemas that are based around their unique needs, then they may come
across difficulties when they wish to share records or open up their metadata for cross searching. There is a need for the
identification of metadata elements from authoritative sources used by different applications, in order that common
elements from their metadata can be shared or cross-searched, thus maintaining interoperability functions whilst also
meeting the particular needs of their community or project.

Application profiles can be human readable documents or machine-readable documents. Machine-readable application
profiles are intended to enable interoperability between two applications with less input from human beings, since
metadata-handling programmes could be designed to read application profiles and to interpret them to enable
interoperation, although this is not happening in practice at present, to the best of the author’s knowledge.

Precisely how metadata implementations/applications interact with each other is beyond the scope of metadata, but
interoperability is only possible if common metadata elements are used, and the implementers or their machines are
capable of recognising the common metadata. (Please see the IMS Digital Repositories Working Group for information
about repositories working together.)

Application Profiles: how do I create one?

There is no standard for the creation of an application profile. Different models and styles of application profile have been
proposed, especially by those establishing metadata registries. Generally, an application profile should contain
information about:
      The source of each metadata element.
      Mappings of proprietary elements to authoritative ones from standards or specifications where appropriate.
      Details of any modifications to the standard elements, such as to the optionality or repeatability of elements.
      Vocabularies and standards for the representation of data, where appropriate.

The South Bank University application profile : http://litc.sbu.ac.uk/easel/DCMES.htm is a good example to follow.

The Resource Description Framework (RDF)

The most widely preferred syntax for machine-readable documentation of application profiles is RDF. The Resource
Description Framework was developed by W3C and provides a grammar for statements about metadata schemas. RDF
uses the structure of a Subject, Predicate and Object, where the Subject and Object are URIs and the Predicate “is a verb
phrase characterizing the relationship between the Subject and Object. For example, the Subject might be an application
profile’s URI, while the predicate would be the verb “uses” and the object another URI namespace for a standard
metadata term. Further examples of RDF statements that are easy to understand, along with an example of some code




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
can be found in: Baker, Thomas et al. What terms does your metadata use? Application profiles as machine-
understandable narratives. URL: http://jodi.ecs.soton.ac.uk/Articles/v02/i02/Baker/

Namespaces

In the context of metadata documentation, namespaces are element sets and vocabularies that are maintained as stable
points of reference.

A namespace is identified by a URI (Uniform Resource Identifier). Where the URI of a namespace is a URL(or a PURL),
then it can be used to link to the declaration of the scope and bounds of the element set or vocabulary being referred to,
sometimes called a namespace schema or a namespace declaration. The URI might simply be an identification of a
namespace, however, without a link to the declaration itself.

Namespace authorities are those who manage and maintain namespace declarations. These authorities might be
internationally recognised standards bodies, or individual projects who have created metadata elements to suit their
particular needs where no standard exists.

Namespace URIs are generally used within a machine-readable metadata instance (a record) or an application profile, to
identify the source of a metadata element that is being used. In this way, when metadata records are shared between
applications, it is possible to enable them to recognise URIs that are common to both applications, and therefore which
elements from their records can be transported from one application to another. (At the time of writing, the author is not
aware of any practical instances of this occurring yet.)

The namespace schema or declaration referred to by a URI might also be encoded in machine readable format, or it
might be intended to be read by people. Namespace declarations in machine readable formats would enable processes
such as automated authority control to ensure that an application has indeed used the precise scope and bounds defined
by the namespace authority. However, as there is no specified syntax or machine readable language namespace
declarations, additional functionality is not a realistic possibility at present.

Example
The Dublin Core Metadata Element Set, Version 1.1 namespace URI (also a PURL) is:
http://purl.org/dc/elements/1.1/
This declaration is encoded in RDF and is managed by the Dublin Core Metadata Initiative (DCMI).
The Namespace Policy of the DCMI can be found at: http://dublincore.org/documents/2001/10/26/dcmi-namespace/




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
Appendix 1 – Metadata elements divided
These divisions are not often discussed, but are sometimes referred to.

Objective – Subjective Metadata

Objective metadata is not judgemental about a resource in any way, and no assumptions are made about the resource in
describing it. A metadata record that aims to describe a resource should be as objective as possible, but sometimes it is
very difficult to be objective when describing a particular feature. It has been argued that detailed, specialist metadata
schemas, such as those for learning resources, include subjective metadata elements, as it is necessary to make a
judgement about a resource in order to describe certain features, such as the educational level of it’s intended users. The
question is, if the metadata presents an opinion of a resource, rather than describing it, is it really useful to someone
searching for a resource? The answer probably depends on who has created the record!

Intrinsic – Extrinsic Metadata

Intrinsic metadata is incontrovertible and will remain relevant to the resource it describes, no matter what the context.
Extrinsic metadata is that which may be described about a resource, when it is presented within a particular context. It
may be that a set of intrinsic metadata elements will be defined that cannot be altered in the transfer of metadata from
one collection to another. What is intrinsic to a resource is difficult to agree on, so this may be agreed between parties
sharing metadata, rather than defined by any standards or specifications body.

What can be defined as intrinsic metadata will depend on the level of granularity of what is defined as a learning resource.
For instance, a tutorial will have a creator, a title, a location, a subject and probably some learning objectives, too, just for
starters. However, individual images, explanations, questions and animations will not necessarily have an intrinsic
subject, nor learning objectives, or many other characteristics which learning resources metadata can be used to
describe, although they can all be used in learning and teaching activities.

An example would be a photograph of the Clifton Suspension Bridge. This could be used in a history tutorial about the
achievements of the Victorian era; or in a civil engineering lecture to illustrate the structure of a suspension bridge; or in
an architecture text-book to illustrate one of the forms a bridge can take; or even in an art lesson to demonstrate the
qualities of the photograph itself! Thus the subject, the context and the educational level of the resource are not intrinsic.
An individual question or explanation might be more rooted in its context, level or subject, but even so, it would depend on
how the question was posed.

Intrinsic metadata can remain with the resource, and form the basis of more subject or context specific descriptions,
based on different specifications and standards. This is similar to the way as books are published with cataloguing details
on the back of their title pages, which libraries copy and adapt to their own cataloguing conventions. Metadata which
travels with a resource in this way would help to populate databases quickly, since it could be copied and adapted to
create a new instance of metadata.


Appendix 2 – “Organisations involved on metadata standards”
Please note that these bodies are not all working in isolation! They are increasingly co-operating, sharing expertise and
agreeing to common principles in order to establish some standardisation between them. Some organisations work faster
than others, and they all have slightly different aims, though, so there is some way to go before a universally agreed
metadata standard is achieved.

ADL/SCORM
ADLNet (Advanced Distributed Learning Network) is an initiative sponsored by the US federal government to: "accelerate
large-scale development of dynamic and cost-effective learning software and to stimulate an efficient market for these
products in order to meet the education and training needs of the military and the nation's workforce of the future."
As part of this objective, ADL produce SCORM (Sharable Content Object Reference Model), a specification for reusable
learning content. Outside the defence sector, SCORM is being adopted by a number of training and education vendors as




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
a useful standard for learning content. Version 1.2 of SCORM will also incorporate the IMS Metadata and Content
Packaging specifications.

ARIADNE
ARIADNE (Association of Remote Instructional Authoring and Distribution Networks for Europe) is an association of
mainly Higher Education Institutions in Europe sharing learning resources. Having begun life as a project funded under
the EC's Framework 3 programme, its membership has grown out of the original project partners, and it aims to provide a
mechanism for the sharing of learning resources. Its most significant contribution has been the development of a learning
content metadata scheme, which was harmonised with the IMS metadata specification, and submitted jointly to IEEE,
where it currently awaits ratification.

The ARIADNE Knowledge Pool System is a European-wide distributed repository for learning and teaching resources,
and documents relating to learning and teaching. It is sometimes also referred to as the "European Knowledge Pool".
Further information about this system, as well as about the authoring and indexing tools that have been developed by
ARIADNE can be found on the web site at: http://www.ariadne-eu.org/2_AS/2.2_tools/main.html

British Standards Institute (BSI)
The BSI participates in International Standards activities on behalf of the UK. The BSI IST/43 - Information technology for
Learning, Education and Training standards in the UK has been set up as a response to the establishment of the ISO/IEC
JTC1 sub committee for standards in the areas of Learning, Education, and Training. (see below). BSI IST/43 aims to
promote standardisation, and is contributing to the ISO/IEC work as well as beginning to develop British standards. The
group also intends to develop added value products to assist users of standards with their practical application.

BSI IST/43 are becoming involved in the following fields of interest:
 Agreeing standards for metadata in learning technology
 Defining interoperability for computer managed instruction and between content software and learning management
    software
 Work in the area of assessment or questions in IT
 Agreeing a standard for student identifiers

For more information please see the BSI IST/43web site at: (http://edd.bsi.org.uk/link.php3/ist/43).

CEN/ISSS
In 1999, the European Commission gave a mandate to CEN/ISSS (the Centre de European Normalisation / the
Information Society Standardisation System - http://www.cenorm.be/isss/) to identify a work-plan for Europe in the area of
learning technology interoperability. This it has done, publishing a report last year.

CEN/ISSS continues with this work, seeking to ensure that any standards reflect European needs - i.e. can be
internationalised and/or localised. This body claims to combine the rapid process of informal specification with the security
offered by the formal open consensus of traditional standardisation. CEN/ISSS also produces standardisation-oriented
services and products for the European information technology market.

The CEN/ISSS Learning Technologies Workshop has contributed to work on the localisation of the IEEE LTSC Learning
Object Metadata (LOM). The Workshop also has Project teams focussed around the following areas:

    Educational modelling languages
    Repository of taxonomies/vocabularies for a European Learning Society
    Educational Copyright Licence Conditions
    A Quarterly Electronic Newsletter

A business plan (http://www.cenorm.be/isss/Workshop/lt/BP/busplanwslt0402.pdf) contains a detailed description of the
work of the CEN/ISSS Learning Technologies Workshop.

Dublin Core Metadata Initiative (DCMI)
The DCMI (http://dublincore.org/) is an open forum engaged in the development of interoperable online metadata
standards that support a broad range of purposes and business models. The Dublin Core Metadata Element Set
(DCMES) (http://dublincore.org/documents/dces/) contains 15 elements, which can be refined to add richness of




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
description. The DCMES is used world-wide for the description of information resources. DCMI activities include
consensus-driven working groups, global workshops, conferences, standards liaison and dissemination efforts.

DCMI Education Working Group (http://dublincore.org/groups/education/)
The objectives of the Working Group are to discuss and develop proposals for the use of Dublin Core metadata in the
description of educational resources. The scope includes educational resources applicable for many national education
communities and cross-sectoral communities. The Working Group has been developing an additional element for the
DCMES, and qualifiers for this and existing elements, to describe educational materials for the purpose of enhancing
resource discovery. The group mailing list archives can be found at: http://www.jiscmail.ac.uk/lists/dc-education.html.


IEEE Learning Technology Standards Committee (LTSC)

The IEEE LTSC (http://ltsc.ieee.org/index.html) consists of working groups that develop technical standards in
approximately 20 different areas of information technology for learning, education and training. Their aim is to facilitate the
development, use, maintenance and interoperation of educational resources. LTSC has been chartered by the IEEE
Computer Society Standards ActivityBoard. (http://www.computer.org/standards/)The IEEE (http://www.ieee.org/)is a
leading authority in technical areas, including computer engineering. Many of the standards developed by LTSC will be
advanced as international standards by ISO/IEC JTC1/SC36 - Information Technology for Learning, Education, and
Training (http://jtc1sc36.org/).

IEEE P1484.12 Learning Object Metadata Working Group (http://ltsc.ieee.org/wg12/index.html)
This working group is focussed on the draft “Standard for Information Technology --Education and Training Systems --
Learning Objects and Metadata”. The LOM draft standard is intended to enable learning objects to be managed, located,
and evaluated. In the context of this standard, a learning object is defined as: “any entity, digital or non-digital, which can
be used, re-used or referenced during technology supported learning.” The working group has a mailing list and is
working to specify the syntax and semantics of Learning Object Metadata.

IMS Global Learning Consortium Inc. (IMS)
IMS is developing and promoting open specifications for facilitating online distributed learning activities such as locating
and using educational content, tracking learner progress, reporting learner performance, and exchanging student records
between administrative systems. The consortium has developed a membership that includes almost all the leading
technology system suppliers, publishers and many user organisations including leading US universities active in
eLearning. It has become an independent, subscription-based non-profit organisation, and has recently launched a
subsidiary, IMS Europe.

IMS is the fastest moving specifications body in its field, releasing and reviewing its specifications regularly. While it aims
to be technology and pedagogy neutral, IMS inevitably has to represent the interests of its subscribers. For these
reasons, CETIS has become actively involved in IMS, through JISC’s membership, in order to represent UK interests in
the global development of learning technology standards. CETIS activity is focussed on the IMS specifications because of
their speedy development, although CETIS also monitors the other bodies’ activities.

IMS Europe
This branch of IMS aims to facilitate participation by European based organisations in the development of IMS
specifications and to support adopting communities in their use and implementation of the specifications.

IMS Meta-data Interoperability Team
Working Groups or “Teams” are involved in the development of individual specifications. The meta-data working group is
focussed on the IMS Learning Resource Meta-data specification. Version 1.2 is now available, having been approved by
the IMS Technical Board after revisions based on the feedback and input of this team. The working group is not currently
active.

International Standards Organisation (ISO)
The ISO (http://www.iso.ch/) is a network of national standards institutes form 140 countries and works in partnership with
international organisations, governments, industry, business and consumer representatives.

The ISO/IEC JTC1 SC36 (http://jtc1sc36.org/) develops international standards in the field of Learning, Education, and
Training, with an aim to enable interoperability and reusability of resources and tools. The IEC (http://www.iec.ch/), also
known as the International Electrotechnical Commission, is the international standards and conformity assessment body


D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc
for electrotechnology and is working with the ISO on this sub committee. JTC1 stands for “Joint Technical Committee 1”
(http://www.jtc1.org/) which has a scope of standardisation in the field of information technology as a whole, and SC36
means “sub committee 36”.

ISO/IEC JTC1 SC36 consists of Working groups, Rapporteur groups and Ad Hoc committees which focus on different
topics within the field. The focus of the sub committee is on existing standards and technical reports. ISO/IEC JTC1 SC36
liaises with other JTC1 sub committees, and with DCMI, IEEE LTSC and CEN/ISSS/LTWS (see above). ISO standards
will emerge from the work of these specification bodies, which will be tested and submitted to the standards bodies, with a
continuous feedback mechanism between research and development, specifications bodies, testbeds, and standards
bodies to produce standards.




D:\Docstoc\Working\pdf\d695cca8-b43f-44fe-ba30-ff8a32b7a6b5.doc

				
DOCUMENT INFO