DC2003 Application profiles

1
Application profiles Tutorial session
Rachel Heery, UKOLN, University of
Bath www.ukoln.ac.uk DC-2003, Seattle,
Washington, USA28 September 2 October, 2003
2
Contents

• What problem are we solving?
• Way forward?
• DC Application Profile Guidelines
• Case study 1 DC Library Application Profile
• Case study 2 DC Government Application Profile
• Summing Up

3

• What problem are we solving?

4
Proliferation of metadata

• Increase in requirement for metadata
• Corporate portals
• Subject gateways
• eCommerce
• eScience
• Rights
• Web Services
• Appropriate terms must be identified wherever
  metadata is needed

5
Proliferation of standards

• Descriptive metadata
• DCMI
• IEEE LOM
• GILS
• METS
• MODS
• MARC 21
• UNIMARC
• MPEG-7

6
Implementor perspective

• Implementors are seeking a standard for
  their particular service or system
• Implementors approve of re-use
• Implementors acknowledge importance of
  interoperability
• . but there is pressure to satisfy local
  requirements and to be innovative
• Tension between using a standard and
  localisation

7
Proliferation of localised extensions

• Metadata standards are published
• but
• Implementor adaptations and extensions are not
  made widely available
• Sharing semantics will reduce duplication and
  repetition

8

• Way forward.

9
Exchange data about new terms

• What terms does your metadata use?
• Express in structured way
• Which standard terms are used in an application
• How terms are adapted or used locally
• Other related usage constraints
• Caveat first step is human readable !

10
Aims of application profiles

• To provide authoritative specification of term
  usage
• To facilitate interoperability by informing
  unknown targets
• To support evolution of vocabulary
• To encourage alignment

11
Profiling is not new

• MARC local fields
• 9XX and XX9 tags
• Z39.50 application profiles
• sub-sets of standard appropriate for application
  area
• IEEE LOM
• UK Common Metadata Format
• Project specific activity
• Defining schema

12
What does an application profile express?

• Implementors need to declare various
  characteristics of their schema
• Terms in use
• Whether a term is mandatory
• Any refinement of standard definitions of terms
• Schemes for values
• Other rules for content

13
Examples of application profiles

• RSLP Collection Level description
• TEL (The European Library)
• Australian Government Locator Service
• Food and Agricultural Organisation
• European Environment Agency
• Various UK educational initiatives
• UK CMF, Qualifications and Curriculum Authority,
  Virtual Teacher Centre,
• DCMI Application Profiles
• Libraries, Education

14
RSLP Collection Level Description

• Enabling RSLP projects to describe collections in
  a consistent and machine readable way
• For simple description of collections, locations
  and related people
• Uses qualified DC with additional local RSLP
  terms
• http//www.ukoln.ac.uk/metadata/rslp/

15
The European Library (TEL) application profile

• Starting point was DC-Lib AP
• TEL-specific additions to support desired
  functionality e.g.
• OpenURL (get local services for this record)
• RecordId (get original record)
• Thumbnail (thumbnail image)
• Why? acknowledged need for controlled evolution
  of metadata terms
• the ability to add future functionality may
  depend on additional terms
• new sectors/collections may require specific
  terms
• http//www.europeanlibrary.org/

16
Virtual Teacher Centre

• Virtual Teacher Centre (VTC) Metadata Standard
• To describe educational resources, including the
  content of the Virtual Teacher Centre website
• Based on DCMI terms, National Curriculum
  Metadata Standard and local VTC terms
• http//vtc.ngfl.gov.uk/

17
Format of DCAPs

• Normalized and readable view of Dublin Core based
  schemas for use by humans
• No particular format mandated plain text, Web
  pages, Powerpoint
• Enough structure for future conversion into
  machine-processable expressions (eg, RDF)
• Future conversion not assumed to be automatic
• Caveat normalized documentation does not in
  itself address deeper problems of
  interoperability between metadata models.

18
CEN Workshop Agreement 1485526 September 2003

• Dublin Core Application Profile Guidelines
  Final Draft
• Thomas Baker, Makx Dekkers, Thomas Fischer,
  Rachel Heery
• www.cenorm.be/sh/mmi-dc
• ftp//ftp.cenorm.be/PUBLIC/ws-mmi-dc/

19
With acknowledgement to Tom Baker.
20
DC Application Profiles

• Declaration specifying which metadata terms an
  information provider uses in metadata
• Identifies source of terms used
• May provide additional documentation
• Designed to promote interoperability within
  constraints of Dublin Core model
• Many purposes in practice harmonization,
  "emerging semantics", interpreting legacy
  metadata
• May evolve over time through incremental
  improvement

21
DCAPs by definition

• Based (in part) on Dublin Core
• Follow DCMI Grammatical Principles
• Simple model of a resource with a flat set of
  properties
• Consist of Descriptive Header and Term Usages
• Descriptive Header
• DC-based description
• Optional Preamble
• Term Usage
• Terms used identified with "appropriate
  precision"
• May be annotated with additional attributes and
  constraints

22
Attributes of Term Usages

• Identifying attributes
• Term URI, Name, Label, Defined By
• Definitional attributes
• Definition, Comments, Type of Term
• Relational attributes
• Refines, Refined By, Encoding Scheme For, Uses
  Encoding Scheme, Similar To
• Constraints
• Obligation, Condition, Datatype, Occurrence

23
Principle of Appropriate Identification

• Terms should be identified "as precisely as
  possible" ("appropriate precision")
• In accordance with CORES Resolution, URIs should
  be used when available
• Terms to which URIs have not (or not yet) been
  assigned should be identified using other
  attributes as appropriate

24
Identifying terms

• Term used in a Term Usage should be identified
  with appropriate precision
• Preferred cite term's URI if available
• Term URI http//purl.org/dc/terms/audience
• Or if a term has been declared somewhere, cite
  the defining document and its name
• Name attendancePattern
• Label Attendance Pattern
• Defined By http//someones-project.org/schema.html
  
• If term has not been declared elsewhere, Defined
  By should cite the DCAP itself
• Name starRatings
• Label Star Ratings
• Defined By http//myproject.org/profile.html

25
Principle of Readability

• "DCAP should include enough information in Term
  Usages to be of optimal usefulness for the
  intended audience"
• Even if this redundantly includes information
  which, in a machine-processable schema, might be
  fetched dynamically from another source
• Order of attributes may be changed for
  readability (though it may make visual comparison
  harder)
• Unused attributes can simply be omitted from
  display

26
Readability of Term Usages

• Principle of Readability allows flexibility in
  presentational style
• Redundant attributes do not need to be displayed
  (as blank)
• Order of attributes may be altered for visual
  effect (not significant for future
  machine-processable representations)
• DCAP may want to group terms by Type of Term
• Attributes should be repeated as necessary

27
Controlled vocabulary terms

• Generally not the role of DCAPs to declare
  controlled vocabularies of values
• Ideally, should be declared in separately citable
  documents external to a DCAP
• However, short lists of possible values may be
  documented in a Comment field

28
Using Encoding Schemes

• Options
• Can be declared one-by-one in the Term Usage of
  an Element in the field "Has Encoding Scheme"
• Field "Has Encoding Scheme" can point to a list
  of encoding schemes somewhere (e.g. "use RDN
  Subject Encoding Schemes")
• If Encoding Schemes need to be annotated, a
  separate Term Usage may be created for each

29
Using Element Refinements

• Options
• Blanket statements in a "Refined By" field ("all
  terms in Vocabulary D can be used as element
  refinements for Contributor")
• Cite Element Refinements one-by-one using the
  attribute Refined By under the Term Usage of an
  Element
• Create a separate Term Usage for each Element
  Refinement

30
Term URIs

• URIs are (ideally) unique and unambiguous
• Example http//purl.org/dc/elements/1.1/title
• Qualified Names use a prefix standing for a
  namespace
• For readability (and by popular demand),
  Qualified Names can be cited in Name field
• Example dctitle
• Explain in the Preamble that this is the case
• Also cite the URIs

31
Examples

• RDN OAI application profile
• http//www.rdn.ac.uk/oai/rdn_dc/
• Renardus Application Profile
• http//renardus.sub.uni-goettingen.de/renap/renap.
  html
• UK e-Government Metadata Standard Application
  Profile
• http//purl.oclc.org/NET/e-GMS-AP_v1

32
RDN OAI Application Profile - header
Title RDN OAI Application Profile
Contributor Andy Powell
Date 2003-03-23
Identifier
Description This document expresses the application profile established by the Resource Discovery Network (RDN) to be used by RDN partners for harvesting of records using the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). The Application Profile is expressed according to guidelines published by the CEN/ISSS Reference. Full user documentation for the Application Profile, together with associated XML schemas, is available at http//www.rdn.ac.uk/oai/rdn_dc/
33
RDN OAI Application Profile term usage
Name Subject
Term URI http//purl.org/dc/elements/1.1/subject
Has Encoding Scheme DC Subject Encoding Schemes
Has Encoding Scheme RDN Subject Encoding Schemes
Comment RDN Subject Encoding Schemes are available from http//www.rdn.ac.uk/publications/cat-guide/subject-schemes/
Obligation Recommended
34
Further reading

• Rachel Heery Manjula Patel, Application
  Profiles mixing and matching metadata schemas.
  Ariadne, September 2000. http//www.ariadne.ac.u
  k/issue25/app-profiles/http//jodi.ecs.soton.ac.uk
  /Articles/v02/i02/Baker/
• Thomas Baker, Makx Dekkers, Rachel Heery, Manjula
  Patel, Gauri Salokhe, What Terms Does Your
  Metadata Use? Application Profiles as
  Machine-Understandable Narratives. Journal of
  Digital Information, Vol.2, no. 2, November 2001.
  http//jodi.ecs.soton.ac.uk/Articles/v02/i02/Baker
  /
• Heike Neuroth and Traugott Koch, Metadata mapping
  and application profiles approaches to providing
  the cross-searching of heterogeneous resources in
  the EU project Renardus. DC-2001 proceedings of
  the International Conference on Dublin Core and
  Metadata Applications, Tokyo. http//www.nii.ac.j
  p/dc2001/proceedings/
• Thomas Baker and Makx Dekkers, Identifying
  metadata elements with URIs the CORES
  Resolution. D-Lib magazine, July/August 2003.
• http//www.dlib.org/dlib/july03/baker/07baker.html
  

35
Questions?
36
Case studies.
37
Terminology

• Data Element A formally defined term used to
  describe an attribute of a resource. A unit of
  data for which the definition, identification,
  representation, and permissible values can be
  specified.
• Element Set A coherent bounded set of Elements
  formulated as a basis for metadata creation. An
  Element Set is managed as an entity.

38
More terminology

• Element Usage A deployment of a (previously
  defined) metadata Element in the context of a
  particular domain or application.
• Application Profile A set of Element Usages
  optimised for the resource description
  requirements of a particular application or
  context. An Application Profile is managed as an
  entity.
• Schema A structured representation of one or
  more Element Sets, Application Profiles or
  Encoding Schemes.