The JISC IE Metadata Schema Registry and IEEE LOM Application Profiles Pete Johnston UKOLN, University of Bath CETIS Metadata & Digital Repositories SIG,

The JISC IE Metadata Schema Registry and IEEE LOM Application Profiles

Pete Johnston UKOLN, University of Bath

CETIS Metadata & Digital Repositories SIG, Liverpool

30 June 2004

http://www.ukoln.ac.uk/


Outline

• What is a metadata schema registry?

• The JISC IE and the IEMSR

• Metadata application profiles– DC and IEEE LOM


JISC IE Metadata Schema Registry project (IEMSR)

• Funded under JISC Shared Services programme, Jan 2004 – July 2005– UKOLN, University of Bath– ILRT, University of Bristol– CETIS, Becta as contributing partners

• Main outputs– Pilot metadata schema registry service for JISC IE– Schema creation tool(s) for DC & LOM implementers (plus

documentation)– Open-source software– Models for application profiles– Recommendations re policy framework


Metadata Schema Registries

• What is a metadata schema registry? – Application that provides services based on

information about metadata vocabularies and their component terms

• Metadata vocabulary – Functional set of terms managed as a unit

(element set)

• Services to human readers, software agents


Metadata Schema Registries

• What functions might a metadata schema registry support?– Disclosure of metadata vocabularies, terms– Discovery/selection (and re-use) of vocabularies,

terms– Verification of provenance/status of vocabularies,

terms– Navigation of relationships between terms– Mapping, inferencing– Pointers to related resources

• guidelines, bindings, transformations…


JISC IE Metadata Schema Registry

• Effective exchange of metadata essential to interoperability in IE– IE Technical Standards specify "baseline" of Simple DC

and/or UK LOM Core– Also exchange of richer metadata between services– Use of "application profiles"

• Increasing requirement to disclose metadata semantics– Issues of authority, currency, provenance, trust

• N.B. IEMSR concerned with metadata exposed by applications, not internal database schemas


JISC IE Metadata Schema Registry

• IEMSR as shared/infrastructural service – Machine interface(s) ("structured")– Provide functions of common interest to other

service components (content providers, fusion services, presentation services) in IE

– "Common service" in e-Learning Framework

• IEMSR as presentational service – Human-readable interface ("unstructured")– Disclose/discover metadata semantics, usage– Promote appropriate reuse of existing solutions– Minimise duplication of effort

JISC-fundedcontent providers

institutionalcontent providers

externalcontent providers

brokers aggregators catalogues indexes

institutionalportals

subjectportals

learning managementsystems

media-specificportals

end-userdesktop/browser pr

esen

tatio

n

fusion

prov

isio

n

OpenURLresolvers

shared infrastructure

authentication/authorisation (Athens)

JISC IE service registry

institutional preferencesservices

terminology services

user preferences services

resolvers

IEMSR






subjectportals




esen

tatio

n

fusion

prov

isio

n

OpenURLresolvers







resolvers

IEMSR






subjectportals




esen

tatio

n

fusi

on

prov

isio

n

OpenURLresolvers







resolvers

IEMSR






subjectportals



end-userdesktop/browser

pres

enta

tion

fusion

prov

isio

n

OpenURLresolvers







resolvers

IEMSR






subjectportals




esen

tatio

n

fusion

prov

isio

n

OpenURLresolvers







resolvers

IEMSR






subjectportals




esen

tatio

n

fusion

prov

isio

n

OpenURLresolvers







resolvers

IEMSR

metadatavocabulary

portal


IEMSR: Use Scenarios

• Content provision service discloses application profile– Constructs & publishes schema, submits to registry

• Metadata schema developer explores/(re-) uses existing implementation choices– Human-readable documentation– Controlled vocabularies used– Schemas for bindings

• Metadata schema researcher surveys existing usage of metadata standards– How properties/data elements used in practice (within

domain, community, area)


IEMSR: Use Scenarios

• Metadata creation tool accesses machine-readable description of selected application profile– Obligation/occurrence constraints– Human-readable documentation– Controlled vocabularies as e.g. VDEX – Schemas for bindings

• Aggregation or presentation service requires information on application profile– Which "metadata formats" to request via OAI-PMH for

bindings of this AP– What labels to use in display of harvested records


Metadata Application Profiles

• Recognition that implementers adopt metadata standards in pragmatic way– Optimise for requirements of application

• Metadata "application profile" as declaration of usage (Heery/Patel, Ariadne)– Select terms from multiple metadata

vocabularies– Provide context-specific interpretations– Provide constraints on occurrence of terms– Provide constraints on values of terms


Metadata Schema Registries & Metadata Application Profiles

• CORES/MEG schema registries (2002-2003)– Model for metadata "application profile" as

basis of registry data model

• Based on Dublin Core "meta-model"– DC description as set of property-value

statements about resource– DC element as property of resource– CORES/MEG AP as set of "element/property

usages"


Metadata Schema Registries & Metadata Application Profiles

• IEEE LOM based on different "meta-model"– LOM standard describes LOM instance as

tree/container structure– LOM data element as component in hierarchy– LOM data element != DC element

• LOM AP describes constraints on LOM tree structure– Subject to constraints in LOM standard– LOM AP != DC AP

• Not adequately represented in CORES/MEG data model


LOM Application Profiles

• Recognise need to develop model for LOM AP for IEMSR

• LOM AP as set of LOM data element usages

• A data element usage– may provide additional documentation on

how the data element is interpreted– may specify obligation for the data element – may specify permitted number of occurrences

for the data element


LOM Application Profiles

• For a aggregate LOM data element– “shall not define datatype and value space”

• For a simple LOM data element– “must retain datatype and value space”

• For a simple LOM data element of datatype Vocabulary – May extend the value space, by allowing values from one or

more non-LOM vocabularies• For the LOM Classification data element

– must specify a purpose for the classification (from the LOM standard vocabulary)

– may specify the use of one or more taxonomies for that specified purpose of classification

Taxonomy

LOM data element

LOM data element usage

usesLOMDataElement

LOM aggregatedata element

usage

LOM simpledata element

usage

extendsValueSpace

Non-LOMvocabulary

Classificationdata element

usage

hasPurposeuses

Taxonomy

LOMClassification

purpose

m 1

m

n

mm

1 n

LOMAP

contains

m

1

Vocabularydatatype element

usage


IEMSR, LOM APs, LOM applications/tools

• API requirements?• How to expose LOMAPs to tools?

– e.g. Reload profile/helper documents

• Extended data elements in LOM APs– What is an extended data element?– How is an extended data element declared?

• Support for VDEX– Import VDEX XML?– Expose VDEX XML?

• Relationship between LOMAP and DCAP models?– Building on LOM RDF binding

JISC IE Metadata Schema Registry Project

http://www.ukoln.ac.uk/projects/iemsr/


Acknowledgements

• UKOLN is funded by the UK Museums, Libraries and Archives Council (MLA), the Joint Information Systems Committee (JISC) of the UK higher and further education funding councils, as well as by project funding from the JISC and the European Union. UKOLN also receives support from the University of Bath where it is based.

• http://www.ukoln.ac.uk/

The JISC IE Metadata Schema Registry and IEEE LOM Application Profiles

Pete Johnston UKOLN, University of Bath

CETIS Metadata & Digital Repositories SIG, Liverpool

30 June 2004


Documents

The JISC IE Metadata Schema Registry and IEEE LOM Application Profiles Pete Johnston UKOLN, University of Bath CETIS Metadata & Digital Repositories SIG,