Metadata Schema Registries, Metadata Application Profiles

1
Metadata Schema Registries,Metadata Application
Profiles, the Information Environment JISC
Development Team, London Monday 18 April
2005 Pete Johnston Research Officer, UKOLN
UKOLN is supported by
www.bath.ac.uk
2
Metadata Schema Registry

• Application that provides services based on
  information about "metadata terms" (and related
  resources)
• "Metadata term" "unit of meaning" deployed in
  metadata descriptions
• Functions might include
• Disclosure/discovery of information about "terms"
• Verification of provenance/status of "terms"
• Discovery of relationships between "terms"
• support for mapping, inferencing
• Pointers to related resources
• usage in metadata application profiles,
  guidelines for use,bbindings
• Support for services to human readers, software
  agents

3
MSR
4
IEMSR project

• Funded under JISC Shared Services programme, Jan
  2004 July 2005
• UKOLN, University of Bath
• ILRT, University of Bristol
• CETIS, Becta as "contributing partners"
• advice, evaluation, assistance with liaison with
  users
• External evaluators (ESYS)
• Building on previous work in MEG Registry Project
  (JISC/Becta)

http//www.ukoln.ac.uk/projects/iemsr/
5
IEMSR project

• Primary outputs
• Description of requirements
• Models for metadata application profiles
• Pilot metadata schema registry service
• Pilot Web site
• Data creation tool(s) for DC LOM implementers
  (plus documentation)
• Open-source software
• Recommendations re policy framework

6
IEMSR project

• Outcomes
• Consensus on models for DCAP, LOMAP
• Improved disclosure/discovery of metadata
  semantics
• Foundation for richer services (mapping,
  inferencing etc)
• Benefits
• Consistency in creating APs
• Collaboration between LOM and DC communities
• Wider access to/re-use of existing solutions
• Reduced duplication of developer effort
• Improved interoperability between applications

7
Metadata Application Profiles
8
Metadata Application Profiles

• Metadata standards provide sets of "terms",
  defined to support some function
• resource discovery, resource (re)use,
  preservation etc
• Implementers adopt metadata standards in
  pragmatic way
• optimise for requirements of application
• Metadata "application profile" as declaration of
  usage
• (re-)use of previously defined terms
• customised for context of application
• may reference "terms" from multiple sources

9
Examples

• OAI-DC (Simple DC) Application Profile
• "Simple DC"
• 15 properties of DCMES
• All optional, all repeatable
• Value strings
• RDN-DC Application Profile
• Additional properties from DC Terms, RDN Terms
• Encoding Schemes
• RSLP CD
• Multiple resource types

10
Examples

• UK LOM Core
• Usage of IEEE LOM to support disclosure/discovery/
  access/use of UK learning resources
• RDN LTSN LOM Application Profile
• Disclosure/discovery/access/use
• Record sharing between RDN and LTSN partners over
  OAI-PMH

11
The IEMSR and the IE
12
The IEMSR and the IE

• Effective exchange of metadata essential to
  interoperability
• IE Technical Standards specify "baseline" of
• Simple DC and/or UK LOM Core
• Serialised using specified XML bindings
• Also exchange of richer/different metadata
• use of additional metadata "application profiles"
  
• introduction of new "metadata terms"
• Increasing requirement to disclose information
  about new "metadata terms"
• Issues of authority, currency, provenance, trust

13
The IEMSR and the IE

• IEMSR as shared/infrastructural service
• Machine interface(s) ("structured")
• However metadata exchange in IE currently based
  on prior co-ordination between human data/service
  providers on metadata formats
• typically based on XML rather than on
  higher-level data models
• limited/controlled extensibility?
• no unknown terms?

14
IEMSR Use Scenarios

• Metadata creation tool accesses machine-readable
  description of selected application profile
• Obligation/occurrence constraints
• Human-readable documentation for help info/tool
  tips
• Controlled vocabularies/encoding schemes
• Schemas for bindings
• Presentation service requires information on
  selected application profile
• What labels to use in display of harvested records

15
(based on Andy Powell's JISC IE Architecture
diagram)
16
The IEMSR and the IE

• Presentational service based on data from IEMSR
• Human-readable interface ("unstructured")
• "Metadata portal" for the IE
• Disclose/discover metadata semantics, usage
• Promote appropriate reuse of existing solutions
• Minimise duplication of effort

17
IEMSR Use Scenarios

• Content provision service provider discloses
  application profile
• Constructs publishes description, submits to
  registry
• Metadata schema developer explores/(re-) uses
  existing implementation choices
• Selects terms for reuse in new application
  profile
• Concerns of status, provenance, trust
• Researcher surveys existing usage of metadata
  standards
• How terms used in practice (within domain,
  community, area)

18
(based on Andy Powell's JISC IE Architecture
diagram)
19
IEMSR Project Progress to Date
20
IEMSR project Progress

• Investigation of user requirements
• CETIS, Becta,
• Curriculum Online/Tagging Tool, JORUM
• Functional requirements document
• Data models for DC AP, LOM AP
• RDF binding for models
• Registry server
• Web site
• Initial prototype tabbed browse
• Data Creation Tool
• Workshop (March 2004)
• Evaluation by ESYS

21
Metadata Application Profiles revisited
22
The trouble with "terms"

• "Metadata terms" defined with reference to
  conceptual frameworks ("meta-models")
• Multiple frameworks/meta-models exist
• Different metadata standards reference different
  meta-models/frameworks
• possibly incompatible
• "Metadata terms" not necessarily directly
  comparable
• must always take framework into account
• Consider DC and LOM.

23
DCMI Abstract Model

• DC metadata description as set of statements
  about a subject resource
• Each statement consists of
• a reference to a property
• a reference to a value
• (optionally) a reference to an encoding scheme
• All DC "elements" are properties
• Compatible with RDF model
• Metadata applications typically based on
  description sets
• sets of descriptions of related resources

24
DC Application Profile

• Specifies which properties occur in a class of
  description sets
• Does not define new properties
• References ("uses") properties already defined
• DCAP as set of "property usages"
• May
• provide additional documentation on
  interpretation of the property
• provide an application-specific label
• specify constraints on the occurrence of
  statements referring to the property
• specify constraints on the permitted values of
  the property (i.e. "encoding schemes")

25
LOM Model

• No explicit LOM abstract model
• IEEE LOM standard defines LOM instance as
  hierarchical tree/container structure
• LOM data element is component in hierarchy
• aggregate LOM data elements
• simple LOM data elements
• related by containment relationships
• Each Simple LOM data element is associated with
• LOM datatype
• Value space
• Reference to a standard
• LOM Vocabulary

26
LOM Application Profile

• Specifies which LOM data elements are used in a
  class of LOM instances
• May
• provide additional information on how LOM Data
  Elements are interpreted in the context of the
  application
• describe constraints on their occurrence
• specify the use of vocabularies to provide values
  for LOM data elements where the datatype in the
  LOM standard permits
• specify taxonomies and classification schemes for
  use for specified 'purposes' with the LOM
  Classification data element

27
DC AP v LOM AP

• DC AP describes DC metadata description set
• LOM AP describes constraints on LOM tree
  structure
• Subject to constraints in LOM standard
• LOM Data Element ! DC Element
• LOM AP ! DC AP

28
The IEMSR Architecture Tools
29
IEMSR Development

• Software development by ILRT
• Dave Beckett, Nikki Rogers, Simon Price
• RDF used throughout
• Registry server
• Redland, MySQL, Perl
• REST interfaces, supporting SPARQL
• redevelop as Java application using Jena?
• Web Site
• Java J2EE application
• Apache Struts Tiles, Java Beans
• Data Creation Tool
• Java application, Eclipse SWTJface libraries

30
IEMSRRegistry Server
API
IEMSR Web Site
OtherPresentational Service
IEMSR Data Creation Tool
Other Data Creation Tool
31
IEMSR Data Creation Tool
IEMSRRegistry Server
API
data
response
RDFDataSource
IEMSR Web Site
IEMSR Data Creation Tool
32
(No Transcript)
33
(No Transcript)
34
Query registry server
35
Select property to use
36
Describe how property used in this DCAP
37
Query again select again
38
Select encoding scheme
39
IEMSR Web Site
IEMSRRegistry Server
API
query
results
IEMSR Web Site
IEMSR Data Creation Tool
40
View Agency
41
Browse Agency list
42
View DCAP
43
Browse Agency list
44
View Agency
45
View Metadata Vocabulary
46
View DCAP
47
Issues, challenges, thoughts
48
Issues, challenges, thoughts

• Complexity of working with multiple meta-models
• Not only an issue for IEMSR or AP developers, but
  for other applications working across LOM and DC
  metadata
• Ongoing discussions between DCMI and IEEE LOM
  communities
• "Validation" of LOM APs
• TELCERT project
• Centralised v distributed registry services
• IEMSR as "semi-distributed"
• Reads/indexes data distributed on Web
• But single point of provision of service
• Distributed model?
• W3C work on RDF query languages, protocol

49
Issues, challenges, thoughts

• Users of machine-oriented IEMSR interfaces
• IEMSR and other shared services
• IEMSR as component in JISC IE
• used in combination with other components,
  including other shared services
• e.g. "which services deploy DCAP D or binding B?"
• IEMSR IESR
• Scope/policy issues
• which standards/profiles/terms are "in scope"?
• authority, status, provenance, trust
• "who says what about what"

50
Metadata Schema Registries,Metadata Application
Profiles, the Information Environment JISC
Development Team, London Monday 18 April
2005 Pete Johnston Research Officer, UKOLN
UKOLN is supported by
www.bath.ac.uk