Implementers may choose from a range of persistent, globally unique identifier schemata which include, but are not restricted to, URI, URN, PURL, Handle, DOI, POI, ISSN, ISBN, XRI.

In order to facilitate interoperability within distributed environments it is recommended that the chosen scheme is encoded in the form of a URI. For specific examples see UKOLN / CETIS Guidelines for encoding identifiers in Dublin Core and IEEE LOM metadata

For further general guidance refer to CanCore's Recommendations for Globally Unique, Location-Independent, Persistent Identifiers and the IMS's Persistent, Location-Independent, Resource Identifier Implementation Handbook

Transcribe the title preserving the original wording, order and spelling. Only capitalize proper nouns. Subtitles should be separated from the title using a colon (':'). This element may not be repeated, so only one title may be encoded.

For untitled objects, multiple titles, multilingual titles and surrogate objects refer to CanCore Guidelines Version 1.9

• Untitled

  If the learning object does not have a title, create one that is succinct and descriptive. If a work is deliberately untitled (for example, an artwork purposely left untitled by its creator), use "Untitled" as its title but, if possible, provide a description of the learning resource in 1.4: Description.

• Multiple titles

  If an object is known by two competing yet equally valid titles (e.g. a painting is officially "Untitled" but historically known as "Field of Flowers"), provide the title most useful for resource discovery first, followed by the second in parentheses.

• Multilingual titles

  Enter the title in as many languages as is appropriate for your context, ensuring that the language of each instance is identified. Each of these titles will be interpreted as a single title with multiple translations in the metadata record. However, translated titles are not always literal equivalents of the original. For example, 1993 American film Grumpy Old Men was released in French as les Grincheux; a more literal translation would be "les vieillards grognons". Alternate titles of this kind can be included using the recommendations provided for "Multiple Titles", above.

• Surrogate objects

  Some learning objects, especially works of art and archival materials, are representations or surrogates of physical or analog objects (e.g. a jpeg image of Van Gogh's Starry Night is only a surrogate for the painting). Indicate the original title in the title element, but make certain their surrogate nature is described in other key elements within your metadata record (e.g. 1.4:Description, 2.3:Lifecycle.Contribute, and 4:Technical

These keywords should ideally be created by the author of the resource rather than through a classification process. Choose specific significant terms for keywords, avoiding those that are too general to describe the object effectively.

If the subject of the learning object is a person, enter their name using the 'familyname, forename' format.

E.g. Shakespeare, William

If the subject of the learning object is an organisation, enter its name.

E.g. Royal National Institute for the Blind.

If the name is hierarchical, list the parts of the hierarchy from largest to smallest, separated by full stops.

E.g. University of Edinburgh. School of Literatures Languages and Cultures. Celtic and Scottish Studies.

For multiple free-text keywords repeat the element for each term.

Refer to Dublin Core Coverage element:

Typically, Coverage will include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [TGN]) and to use, where appropriate, named places or time periods in preference to numeric identifiers such as sets of coordinates or date ranges.

Dublin Core Element Set

For temporal coverage, the date must be recorded in ISO 8601:2000 format e.g. YYYY-MM-DD. See W3C Date Time Note for further details.

Refer to CanCore Guidelines Version 1.9:

CanCore does not recommend the use of this element.

• Resources incorporating multiple levels of aggregation will likely include more than one kind of structure (e.g. a Website that includes both hierarchical and linear structures or linkages). The expressive power of this element is consequently limited in that it does not accommodate more than one value, and does not recommend a value that would indicate that a multiplicity of structures are incorporated into a single aggregate resource.

• It is also not clear how the underlying structure of a resource might relate to learning styles or user preferences.

• The fact that this element recommends the use of non-numeric vocabulary values also presents difficulties for implementation in multilingual contexts.

CanCore Guidelines Version 1.9

The mandatory minimum set of element types declared by the vCard specification vCard and vCalendar are:

FN (formatted name)

the formatted text corresponding to the name of the object the vCard represents, based on the semantics of the X.520 Common Name attribute.

E.g. FN:Ms Jane A. Smith, MA

N (structured name)

the structured components of the name of the object the vCard represents. The structured type value corresponds, in sequence, to the Family Name, Given Name, Additional Names, Honorific Prefixes, and Honorific Suffixes. The text components are separated by the semi-colon character (ASCII decimal 59). Individual text components can include multiple text values separated by the comma character (ASCII decimal 44). This type is based on the semantics of the X.520 individual name attributes.

E.g. N:Smith;Jane;Anne;Ms;MA

VERSION

the version of the vCard specification used. The LOM states that the value of this property must be 3.0.

E.g. VERSION:3.0

In addition, UK LOM Core 0.2 mandates the use of the ORG type:

ORG

specifies the organizational name and units associated with the vCard. The type is based on the X.520 Organization Name and Organization Unit attributes. The type value is a structured type consisting of the organization name, followed by one or more levels of organizational unit names. Text components are separated by the semi-colon character (ASCII decimal 59).

E.g. ORG:University of Edinburgh; School of Literatures Languages and Cultures; Celtic and Scottish Studies

Values must be structured according to vCard as defined by IMC vCard 3.0 and must be enclosed between BEGIN:VCARD and END:VCARD. It is required that vCard components are separated with '\n' and escape ';' and ',' using '\;' and '\,' where these characters appear in a component value.

Additional vCard elements may be used but it is recommended that the total number of elements used should be kept to a minimum for the sake of simplicity.

Multiple authors may be recorded. If the author of the object is not associated with an organisation the ORG entry should be left empty. If the author of an object is identified as an institution or organisation then the FN and N entries should be left empty.

Typically this will be the date of creation or publication of the learning object.

The Data type for this element, DateTime, is described in Section 8, Table 3 of the LOM Standard.

Date must be recorded in ISO 8601:2000 format e.g. YYYY-MM-DD. See W3C Date Time Note for further details. If the exact date is not know the first day of the month may be substituted e.g. YYYY-MM-01. If the month is not know only the year may be recorded e.g. YYYY.

If the date cannot be recorded in ISO 8601:2000 format, or additional information is required, a textual description of the date may be added.

This element could be used to identify a specific version of a resource in the absence of a formal method of version control.

Implementers may choose from a range of persistent, globally unique identifier schemata which include, but are not restricted to, URI, URN, PURL, Handle, DOI, POI, ISSN, ISBN, XRI.

In order to facilitate interoperability within distributed environments it is recommended that the chosen scheme is encoded in the form of a URI. For specific examples see UKOLN / CETIS Guidelines for encoding identifiers in Dublin Core and IEEE LOM metadata

For further guidance refer to CanCore's Recommendations for Globally Unique, Location-Independent, Persistent Identifiers and the IMS's Persistent, Location-Independent, Resource Identifier Implementation Handbook

The Data type for this element, DateTime, is described in Section 8, Table 3 of the LOM Standard.

Date must be recorded in ISO 8601:2000 format e.g. YYYY-MM-DD, and should preferably be generated automatically by the metadata authoring tool. See W3C Date Time Note for further guidelines.

The appropriate two character language code should be chosen from ISO 639-2:1988. An additional two character country code from ISO 3166-1:1997 should also be used where appropriate.

The default entry for this element is 'en-GB'. This value should be generated automatically by the metadata authoring tool.

Use MIME types only. LOM stipulates that the technical data types of all compenents are recorded. For example for a Flash animation in an HTML Web page, repeat this element to encode both 'text/html' and 'application/x-shockwave-flash'.

Non digital objects should be recorded as 'non-digital'.

If it is not possible to acurately determine the MIME type(s) of an object use 'application/x-unknown'.

Ideally the size of the learning object should be generated automatically by the tool that packages or stores it.

The size must refer to the uncompressed size of the resource.

Although LOMv1.0 stipulates that the number is stored in bytes it should be displayed to the user in the most appropriate format e.g. Kb, Mb etc.

This refers to the location of the object rather than the location of the metadata record. The value must resolve to a location where the learning object can be found e.g. a URL. If the resource is held in a repository system this element would refer to the location of the object in the repository and should be generated automatically.

For bibliographic physical objects (books and journals), encode an OpenURL as follows:

 openurl:?genre=article& atitle=Information%20gateways:%20collaboration%20on%20content& title=Online%20Information%20Review&issn=1468-527& volume=24&spage=40&epage=45&artnum=1& aulast=Heery&aufirst=Rachel 

Note that this has been wrapped for readability. For non-bibliographic physical resources (e.g. VHS videos), provide the URL of a Web page or service that describes how to obtain the resource.

Refer to CanCore Guidelines 1.9:

CanCore does not recommend the use of this aggregate element for the purposes of interoperation in distributed environments. CanCore recommends that any technical requirements be expressed in human readable form in 4.6:Other Platform Requirements.

• The formalized statements that can be created with this element aggregate can specify the type, name, and permissible version numbers or number ranges for the required technology. This aggregate element also allows record creators to indicate whether all such requirements need to be satisfied (using the Boolean connector "And", and repeating element 4.4:Requirement), or whether only one of a group of requirements needs to be met (using the Boolean connector "Or", and repeating element

4.4.1 OrComposite).

• Such formulations may be useful for standard, default requirements expressions.

• The implementation of this aggregate element may present challenges, and can be avoided by exploiting other LOM elements:

• It may be difficult to establish and maintain vocabulary values for 4.4.1.2:Name. Browsers and operating systems are developing rapidly and proliferating, especially as they move into mobile devices and information appliances. The suggested value of "netscape communicator", for example, is already superannuated by other, differently named versions of Netscape. Maintaining an up-to-date list of such software is difficult (and testing requirements against such a list, likely prohibitive).

• Requirement statements are likely to describe conditions that cannot be accommodated in the formalized elements and permissible values. For example, this aggregate element lacks a qualifier to indicate that certain software is optimal or preferred.

• The recommended vocabulary for 4.4.1.1:Type (consisting only of "operating system", "browser") may be insufficient for expressing some technical requirements (e.g. those related to computer hardware, network capabilities, etc.)

• General software requirements information is in many cases already indicated economically in the MIME type values supplied in 4.1:Format.

As the LOM notes for element 4.6:Other Platform Requirements, "This element is intended for descriptions of requirements that cannot be expressed by data element 4.4:Technical.Requirement." Given the expressive limitations that apply to element 4.4, CanCore recommends the use of 4.6:Other Platform Requirements for the description of all technical requirements not already indicated by 4.1:Formal

Refer to CanCore Guidelines 1.9:

• This element should be used to describe only those requirements and procedures specific to software or resource installation. Other technical requirements should be expressed using other LOM elements.

This element is not included in CanCore for the following reasons:

• It is useful only in exceptional cases, most likely where an educational resource is stand-alone software requiring special installation procedures.

• It is of limited use for resource discovery and selection (installation instructions are not likely to form a primary criterion for the selection of resources by students or educators).

• For those resources requiring it, installation information is likely to be provided with the object itself (e.g. in a "readme" file), and would preferably be presented via a set-up "wizard" or other mechanism developed for increased usability.

Recommendations for Globally Unique, Location-Independent, Persistent Identifiers

Use of the LOMv1.0 vocabulary is problematic as it includes terms that describe both the form (e.g. diagram) and the function (e.g exam) of the object. In recognition of this, many application profiles recommend the use of customised

vocabularies to describe this element.

A range of UK and European Type and Learning Resource Type vocabularies are presented in Appendix 2 below. CanCore Guidelines 1.9 also present a survey of Learning Resource Type vocabularies in Appendix A. CanCore Guidelines Version 1.9

It is recommended that customised vocabularies should be used in conjunction with the LOMv1.0 vocabulary to facilitate interoperability with other applications. This follows the LOM recommendations for element 5.6 Educational. Context: "Suggested good practice is to use one of the values of the value space and to use an additional instance of this data element for further refinement."

It is recommended that this element should only refer to the chronological age of a user and not their developmental age as sugegsted by the LOM explanation. Therefore the element is used to indicate the appropriateness of the object for a particular age group. Developmental 'age' or level should be described uding 9.1 Classification. Purpose. Educational Level.

E.g to describe a learning object designed for use with adult learners with basic reading skills 5.7 Educational. Typical Age Range should should be "18 -" or "adult learners" and 9.1 Classification. Purpose. Educational Level should be UK Educational Level 2.

Appropriate use of these elements can be labour intensive. Refer to CanCore Guidelines 1.9 for further advice:

The utility of the Relation category is highly dependent on the provision and interoperation of infrastructure elements other than metadata (e.g. identification and resolution services, content packaging technology, aggregation and disaggregation mechanisms). Properly supported and integrated, the Relation category can support important functionality and add considerable value to an implementation. Such support and integration, however, is not likely to be available across domains, or in highly distributed environments. All of these factors should be taken into account in decisions to use these elements.

CanCore Guidelines Version 1.9

Refer to CanCore Guidelines 1.9:

The LOM vocabulary and the Dublin Core vocabulary on which it is based differ in two respects. The LOM vocabulary omits the "replaces" and "is replaced by" values in the Dublin Core vocabulary. The LOM includes "is based on" and "is basis for" values that are not in Dublin Core. However, the crosswalk to Dublin Core included in the LOM data model indicates the equivalent of the "Source" element in Dublin Core.

CanCore Guidelines

Refer to CanCore Guidelines 1.9:

This element aggregate refers explicitly to the learning resource being described by the metadata record. It does not refer to the metadata record itself.exception is if the related resource exists only as a metadata record.

CanCore Guidelines

Implementers may choose from a range of persistent, globally unique identifier schemata which include, but are not restricted to, URI, URN, PURL, Handle, DOI, POI, ISSN, ISBN, XRI.

In order to facilitate interoperability within distributed environments it is recommended that the chosen scheme is encoded in the form of a URI. For specific examples see UKOLN / CETIS Guidelines for encoding identifiers in Dublin Core and IEEE LOM metadata

For further guidance refer to CanCore's Recommendations for Globally Unique, Location-Independent, Persistent Identifiers and the IMS's Persistent, Location-Independent, Resource Identifier Implementation Handbook

Refer to CanCore Guidelines 1.9:

CanCore does not recommend the use of this element for the purposes of interoperation in distributed environments.

• A description of the resource is not required for its retrieval.

• CanCore recommends that descriptions be less than 1000 characters in length. Keep in mind that this element is intended only to identify what the related resource is to the end-user. It is not meant to act as a surrogate metadata record for that resource. Otherwise, see the CanCore recommendations for 1.4:General.Description for further guidance. (E.g. Just the title of the related resource can be included as its description.)

CanCore Guidelines

This element can be used to enable educators to describe the experience of using the object in a teaching and learning situation.

CanCore Guidelines 1.9 also recommend using this element to describe educational characteristic that cannot be accommodated by the elements in 5. Educational category.

CanCore Guidelines Version 1.9

Classification may be used for multiple puposes. The UK LOM Core recommends the following usage at present.

Discipline - formal subject classification or idenification in use by the institution or sector. E.g. National Curriculum 5-14 http://www.nc.uk.net/home.html, learndirect Subject Classification (Levels 1-2) http://www.learndirect-advice.co.uk/provider/standardsandclassifications/classpage/, Joint Academic Coding System http://www.hesa.ac.uk/jacs/completeclassification.htm, Dewey Decimal Classification (Summary Levels 1-2) http://www.oclc.org/dewey/about/ddc_21_summaries.htm.

Idea - relates to the concept contained in the resource. It is possible to use vocabularies already used for Discipline but to a deeper level e.g. LDSC, DDC. Other excamples include subject specific vocabularies e.g. MESH http://www.nlm.nih.gov/mesh/meshhome.html

Accessibility Restrictions - no suitable vocabulary exists at present.

Educational Level - the cognitive/grade level for which the resource is intended. It is recommended that the UK Educational Levels vocabulary should be used. http://www.ukoln.ac.uk/metadata/education/ukel/ The UKEL terms correspond directly to the Scottish Credit and Qualifications Framework http://www.ngflscotland.gov.uk/nq/cqframework.asp

Appendix 2 provides a draft mapping between UKEL, the SCQF and other UK qualification frameworks.

Refer to CanCore Guidelines 1.9: CanCore does not recommend the use of this element for the purposes of interoperation in distributed environments.

• For general descriptions of the contents or purpose of the resource, CanCore strongly recommends the use of 1.4:Description.

Only one description can be provided for each iteration of the Classification group of elements as a whole. This means that only one description would typically be provided for each descriptive function or purpose.

CanCore Guidelines Version 1.9

Refer to CanCore Guidelines 1.9:

Provide the most specific terms appropriate to the purpose stated in 9.1:Purpose.

• Use a separate 9.4:Keyword element for each term or phrase used.

• If the value of 9.1 is "discipline," and the keywords are not from a specific taxonomy, use 1.5:General.Keyword.

Keywords are assigned by the indexer based on his/her interpretation of the learning resource's properties. As such, keywords are derived either from the object itself or from an indexer's interpretation of the object. They are not derived from an external vocabulary. Terms derived from an external vocabulary are best dealt with in 9.2:Taxon Path. CanCore Guidelines Version 1.9