ABOUT KMODDL

about KMODDL metadata: METADATA ACTIVITIESAPPLICATION PROFILETYPE VOCABULARYOAI MAPPING

KMODDL Metadata Development Activities


This document describes the work done in 2003-2004 by KMODDL metadata developers at Cornell University Library to create a metadata profile for KMODDL digital resources.


KMODDL Background

The Kinematic Models for Design Digital Library (KMODDL) is an open access, multimedia resource for learning and teaching about kinematics the geometry of pure motion and the history and theory of machines. KMODDL is a pedagogical space designed for use by teachers and researchers, as well as students at a range of educational levels, and other learners, young and adult. The core of KMODDL is the Reuleaux Collection of Kinematic Mechanisms at Cornell University, which comprises more than 200 models developed by Franz Reuleaux (1829-1905), the founder of kinematics, for teaching and researching the principles of mechanical motion. KMODDL provides online access to the Reuleaux Collection via still and interactive moving images and descriptions of the models, as well as computer simulations, tutorials, and related full-text documents.

KMODDL will expand to include other collections of mechanisms and machines, beginning in 2005 with the Clark Collection of Mechanical Movements at the Museum of Science in Boston. In addition to incorporating new mechanical artifacts, the project team will continue to explore ways of enhancing KMODDL's pedagogical and research offerings.


Use of the Dublin Core Metadata Element Set for KMODDL

In addition to creating and making available digital images of the Reuleaux models and related resources, KMODDL is devising the metadata structure necessary to describe and provide intellectual access to them. As a first in building the KMODDL metadata structure, KMODDL metadata developers determined which categories of resources would be required on the site. For each Model, which of course will not be accessible online, these file formats and digital versions are possible: Stereolithography File (enabling the user with a 3-D printer to create his/her own Model facsimiles), Still Image, Movie, Simulation and Virtual Reality Model. Another resource category is Tutorial, which combines digital versions of models with mechanical, mathematical or historical descriptions of them. Biography provides information about one or another figure in the history of kinematics. Finally, there are a number of bibliographic/expository categories: Digital Book, Print Book, Digital Book Section, Print Book Section, Digital Paper, Print Paper, Digital Article, Print Article, Digital Conference Proceeding, Print Conference Proceeding, Digital Thesis/Dissertation and Print Thesis/Dissertation.

KMODDL metadata developers next decided on metadata element sets for the various resource categories. Because KMODDL is part of the National Science Digital Library, which requires Dublin Core Metadata Element Set (DCMES) output, KMODDL developers elected to use the DCMES to describe KMODDL resources. For guidance in how best to use the DCMES, the developers turned to the DC-Library Application Profile (DC-Lib), which addresses DCMES usage in libraries and library-related applications. KMODDL metadata staff modified the DC-Lib profile for KMODDL because not every DC-Lib element, element refinement, or encoding scheme was necessary for each KMODDL component, and because some DC-Lib metadata terms were not required at all. In the end, the metadata terms (elements, element refinements and schemes) adopted by KMODDL come from four of the namespaces in use by DC-Lib:

There are also a few metadata terms adopted by KMODDL that come from other namespaces. These namespaces are:

The DC-Lib elements that do not appear in the KMODDL profile are: Coverage and Edition. The DC-Lib element Location is adopted by KMODDL, but it is renamed Physical Location (after the name of the MODS subelement of Location).

As a further refinement, KMODDL metadata developers realized that the element set for one resource category would not be exactly the same as that for another. To give one, and fairly obvious example, the element Language would be included in the profile for Book, but would play no role in the profile for Still Image. There are also differences, albeit subtle or few in number, among all the components. In creating the KMODDL element profiles, KMODDL developers found it useful to cluster resources with the most shared characteristics. Thus, the developers created one profile for Model; another for Stereolithography File; another for Still Image, Movie, Simulation and Virtual Reality Model; another for Tutorial; another for Biography; another forDigital Book, Digital Book Section, Digital Paper, Digital Article, Digital Conference Proceeding, Digital Thesis/Dissertation; and yet another for Print Book, Print Book Section, Print Paper, Print Article, Print Conference Proceeding and Print Thesis/Dissertation. Finally, as differences usually existed even among components in the same cluster, developers added notes as necessary to make finer distinctions, as between Still Image and Movie. The end result was that each resource category received, in effect, its own metadata profile, combining the elements, element refinements and encoding schemes from the various DC-Lib namespaces that best suited it.


The KMODDL Namespace

KMODDL metadata staff discovered early in the development process that the kinematics subject domain and the KMODDL resources possess some characteristics that required a small set of unique KMODDL metadata terms. Among the unique KMODDL characteristics, there are two kinds of identifiers that do not fall into any of the encoding schemes recognized by Dublin Core for the Identifier element. One is the identifier that KMODDL itself assigns to each resource. Another is the number under which each model is listed in the Voigt catalog (a catalog whose entries include the over 300 Reuleaux models manufactured by Gustav Voigt Mechanische Werkstatt). In both cases, every resource will share the same identifier as that of the corresponding model. In addition to the unique KMODDL identifiers, KMODDL uses a set of subject terms found in the Voigt catalog. As is the case with identifiers, subject terms referring to a particular model will be used for all corresponding resources. Finally, KMODDL developers elected to include terms for the resource categories themselves in the metadata. To accomplish this, KMODDL will add a KMODDL-specific instance of the DCMES Type element to each record.

The number of metadata terms unique to KMODDL indicated to KMODDL developers that the creation of a KMODDL namespace was in order. The KMODDL namespace accounts for various unique features of KMODDL resources, the most important of which are: 1) a KMODDL scheme for Type element instances that uses KMODDL resource category names; 2) a KMODDL scheme for Identifier element instances that uses KMODDL-assigned identifiers; 3) two Voigt schemes for Identifier element instances (one for each set of Voigt Catalog numbers); and 4) two Voigt schemes for Subject element instances that use subject terms from the Voigt Catalog.

In KMODDL, the Dublin Core element Type will have two occurrences per record. For example, a record for a Still Image will have one KMODDL-encoded Type instance, "Still Image", and one DCMI-encoded Type instance, "Text". Adding KMODDL Type values to the KMODDL database has given developers greater control over the way resources display in the KMODDL interface. Using specific terms such as "Simulation", "Book" and "Tutorial" clearly identifies these categories of resources to KMODDL users.


KMODDL Application Profile and KMODDL Schemas

KMODDL metadata developers next created an application profile offering detailed descriptions and implementation guidelines for all elements, element refinements, and encoding schemes used in KMODDL. It is adapted from the DC-Lib Profile and is in compliance with the Dublin Core Application Profile Guidelines as drafted by the European Committee for Standardization (CEN Guidelines). Finally, developers created the KMODDL namespace with associated schemas, one to define the content and structure of the KMODDL metadata as a whole, another for the KMODDL Type Vocabulary.