This is a presentation of my Metadata Design Project. It discusses the project purpose, the project realization and emphasizes on the importance of using the Metadata Application Profile for more consistent and quality metadata. The Metadata Design Project is available in full text at this link: http://www.slideshare.net/Marina_Georgieva/metadata-design-project-restricted

1. METADATA DESIGN PROJECT
Digital Collection Picturesque Churches of Bulgaria
November 2014 Copyright 2014 Marina Georgieva

2. About the project
• Create a metadata project scenario from scratch
• Create an imaginary but yet realistic cultural heritage
organization
• Develop a local metadata schema appropriate for the project
scope and collection
• Develop several unique metadata elements
• Include the following parts in the project:
– Application Scenario Description
– Functional Requirements
– Metadata Application Profile (MAP)
– Sample metadata records adhering to MAP
– Replica of drop-down browsing functionality

3. The project also demonstrates:
• ability to develop Local
Authority File for structuring
metadata that is inconsistent
and cannot adhere to any of
the existing controlled
vocabularies
• ability to map local metadata
elements to standard
metadata schemas like DC and
MODS
• ability to assign the most
appropriate functionalities for
the important metadata fields
in order to promote easy
resource discovery
Project purpose
The project aims to demonstrate understanding
of:
• practices for developing a whole metadata
project scenario
• principles for achieving consistent and quality
metadata
• practices for developing local metadata
schema appropriate for particular
project/organization
• most popular metadata schema Dublin Core
(DC) and Metadata Object Description
Schema (MODS)
• the significance of using controlled
vocabularies consistently throughout certain
metadata fields
• the crosswalks among the various metadata
schemas for OIA-PMH data interchange

4. This part provides background information about the
project, the organization and the potential users
• Organizational context
 Provides information about the organization
 Gives information about the organization affiliation
 Defines the purpose of this collection
 Promotes active contribution of users who are interested in
donating resources
 Provides information about the selection criteria for inclusion of
new resources
• Digital content
 Provides information about the resources (digital and analog)
 Provides details about the types of formats hosted in the collection
 Discusses how the analog resources are digitized and processed so
that they preserve their best quality
 Discusses that the collection is exposed to OAI harvesting and
aggregating and it participates in data interchange
• Anticipated users
 Defining the target audience
 Defining the secondary audience
 Suggestions for necessary skills to view the collection
Project realization
Part 1: Application Scenario Description

5. ExcerptfromPart1:ApplicationScenarioDescription

6. This part outlines the functional requirements for each of the
metadata elements.
This is equally useful in cases when a DAM software (like CONTENTdm)
is used and in cases when software engineers develop a special
database for that particular project.
In both cases the functionalities of the elements as they are outlined
are valuable for buildings easy-to-navigate and user-friendly digital
collection.
• Browsing functionalities
 Browsing by icons
 Browsing by drop-down menu
 Each particular church type should have a thumbnail image with the
architectural design of that particular type of church
 The thumbnail icons will not be available in the drop-down menu
 The scope note as provided in AAT, TGM and LCSH need to be presented
• Searching
 Subject search
 Keyword search
 Fielded search
• Faceted navigation
 Convenient way for further refinement of search results
 Appears as filtering options on the left navigation bar
 Provide the total number of the resources hosted in each category
Project realization
Part 2: Functional Requirements

7. ExcerptfromPart2:FunctionalRequirements

8. This part of the project is the most important one.
Metadata Application Profile (MAP) is the most significant document for
each digital collection. It is the backbone of the collection consistency and
valuable quick reference resource for metadata creators.
• Local element
 Provides the name of the local elements as it appears in the database
 Local metadata schema is needed when a collection is very unique and
the standard schemas cannot describe the resources properly.
 Local elements are created after careful analysis of the resource types
 Local elements aim to describe the resources in a very detailed fashion
• Definition
 The scope note of the local element
 Provides more insight about each of the local elements for more clarity
• Obligation
 Provides information about the occurrence of the values in each
particular metadata field
 Mandatory
 Required if available
 Optional
 Recommended
• Occurrence
 If the element can be repeated or not
Project realization
Part 3: Application Profile Table

9. .:: continued ::.
• Vocabulary encoding scheme
 Crucial for the metadata consistency in critical fields indexed for
searching/browsing
 Usage of controlled vocabulary promotes consistency, quality metadata
and easy resource discovery
 Provides information which local field requires controlled terms and
which vocabulary is used
 Provides hyperlinks to each of the vocabularies for convenient search of
terms during the metadata creation process
 Used vocabulary encoding schemes in this project
 TGN – Thesaurus for Geographic Names
 ISO 6709 – Standard for Geographic Coordinates
 AAT – Art & Architecture Thesaurus
 TGM – Thesaurus of Graphic Materials
 LCSH – Library of Congress Subject Headings
 W3CDTF – W3C Date and Time Format
 LCNAF – Library of Congress Name Authority File
 DCMIType – Dublin Core Type Vocabulary
 IMT – Internet Media Type
 ISO 639-2 – Standard for Language Codes
 A local authority file was also developed to accommodate the church
locations represented in their native language.
 The local authority file structures the Bulgarian geographic locations of the churches
in a consisted and easy-to-find manner
Project realization
Part 3: Application Profile Table

10. .:: continued ::.
• Mapping to Dublin Core (DC)
 Important for data interchange
 Crosswalks from the local metadata elements were created to map
them to the Qualified DC elements
 Promotes OAI harvesting and aggregating
• Mapping to Metadata Object Description Schema (MODS)
 Important for data interchange
 Crosswalks from the local metadata elements were created to map
them to the MODS elements and their attributes
• Input guidelines
 Provide very specific details and restrictions what is allowed in each
particular metadata field.
 Important especially for those fields which do not have any
controlled vocabulary values
• Examples
 Disambiguate any confusions about the metadata input
 Provide nice fundaments for novice metadata creators
 Serve as a quick cheat sheet for experienced metadata creators
 Promote consistency of metadata input
Project realization
Part 3: Application Profile Table

11. ExcerptfromPart3:MetadataApplicationProfile

12. Project realization
Part 4: Sample Metadata Records
• 10 Excel metadata records
• Metadata records adhere strictly to MAP
• Each row represents a record
• Each column represents a local metadata field
• High consistency is achieved thanks to the strict
observation of the MAP guidelines and its
restrictions
• Some of the fields intentionally have repeated
values across the records
• This allows replicating the drop-down browsing
functionality which was tested in part 5

13. ExcerptfromPart4:SampleMetadataRecords

14. Project realization
Part 5: Replica of Drop-Down Browsing
Functionality
• 4 metadata fields were tested for the drop-down browsing
functionality
– Church Type (AAT)
– Church Type (TGM)
– Church Type (LCSH)
– Church Location (TGN)
• Applying the Excel filtering option in each of the fields
• Each of the repeated values in the same metadata fields are grouped
together
• This enables users to retrieve only records that have a specific value
in a particular metadata field
• This replica is a good example of the significance of consistent and
quality metadata entered in the fields indexed for searching/browsing
• Facilitates easy resource discovery

15. This is the results after applying the Filtering option in the Church Type (TGM) field.
The selected value Cave churches—Bulgaria retrieved 3 records out of 10 – all of the
retrieved records have this controlled TGM term listed in their metadata field.

16. The end
• A brief video presentation of this project is available here:
– Part 1 (including Application Scenario Description; Functional
Requirements; Metadata Application Profile (MAP))
https://www.youtube.com/watch?v=MIxeOMronGs&feature=youtu.be
– Part 2 (including Sample metadata records adhering to MAP;
Replica of drop-down browsing functionality)
https://www.youtube.com/watch?v=JsWdMAd3G6s&feature=youtu.be
• The project itself is available in PDF format at the following web
address:
http://www.slideshare.net/Marina_Georgieva/metadata-design-project-
restricted
• All rights reserved.
Reproduction of any part of the Metadata Design Project and this
slide presentation will be considered as copyright infringement.
Copyright 2014 Marina Georgieva