---   THIS PAGE IS IN DRAFT ----

Duke University - Trident Project

Explaining the Metadata Application Profile

At Duke, we have impemented a Fedora-based repository, and a web-based editor interface to manage the repository.  The design is very modular, and very flexible.  It was designed to be extended to fit different data models, as well as it is configurable to work with different descriptive metadata schemas.  In addition, it was designed not only to work with different metadata schema, but can be configured to have different metadata requirements per "collection" (ie. Topical Subject is required for items in collection A but is optional for items in collection B).  In order to make the editor configurable to work with different metadata schemas, we decided to make the editor completely dynamic and driven by data from the repository which instructs the editor how to create metadata forms for editing.  I will briefly explain below what led us to this decision as well as explain how it works.  There are also more details on our internal project wiki, http://library.duke.edu/trac/dc/wiki/Trident/MetadataApplicationProfile .

...

The mappings in the above examples are done with XSLT.  As you can imagine, the XSLT to produce a Metadata Form (MDF) from a different XML schema is rather straightforward, as well as is the XSLT to produce a native XML schema from a MDF.  In our repository, we have a single mapping for all DukeCore descriptive metadata records (DukeCore is the descriptive metadata schema we use, based on Dublin Core).  We can also create as many of these mappings as we have metadata schema in our system.  So we could create a DC_TO_MDF mapping as well as a MODS_TO_MDF mapping (and the converse transformations MDF_TO_DC and MDF_TO_MODS).  So, we're done, right?

Well, no.  Although we now have mapped the descriptive metadata into a flat format for the editor, the editor has no clue how it should display these field_groups and elements to the end user.  Which field groups are repeatable?  Which elements are free text, which should be selects, and which should be auto-completes?  If we want to use an authority list, how will the editor know which authority list to use?

Metadata Form Definitions

Also we don't want to create static HTML forms.  It would be short-sighted to think that our metadata schema will never change, or that we will always have just one descriptive metadata schema within our repository.  Or, if someone from another university has an interest in using our editor tool, we don't want it tied to our specific metadata schema.  So, we want the HTML forms to be dynamic, meaning we want them to be generated on the fly based on the metadata coming from the repository as well as some instruction from the repository on how the metadata fields should be displayed and edited.

So, at this point, we have the metadata in the MDF format, which is abstracted from the underlying metadata schema (could be MODS, could be DC, we don't care anymore).  From this point on, the editor is really just interested in the MDF.  But, the MDF doesn't provide any instruction on answering the above questions about how to display the fields for editing.

So, in addition to the XSLT mappings (one per schema) we have created Metadata Form Definitions.  Metadata Form Definitions mimic the structure of the MDF, meaning that they contain field_groups, fields and elements.  However, they do not contain the actual descriptive data and are embellished with attributes to instruct the editor how to display the data for editing.  So, we have added a handful of cues to the MDF.  The first of which is cardinality.  Cardinality defines whether or not the metadata field is repeatable.

We also added labels and cues for whether or not the field group is required:

We also needed to instruct the editor how to display each element for editing, whether to use free-text box, a lookup field, a select. So we added a type attribute to the element in the metadata form definition.  Since both of the fields in the example we have been using are free text inputs, I will add another metadata field in for example.  The new field is Topical Subjects.  In our editor interface, topical subjects should be drawn from a controlled authority list, and so should be input as a select.

You will notice that there is an additional attribute, values.  We have also developed an authority list application, and have designed the editor to work with the authority list application both for select drop downs and for auto-complete fields.  The values attribute instructs the editor which authority list to use for which element.

Are we done yet?

Well, not really.  There are a few more bells and whistles that we have added, error checking, styles, the ability to segment the editor form into multiple tabs/sections.  And I did not really get into how the metadata application profiles are defined in the repository or related to individual items or collections.  But, as far as this wiki page, I think we have covered the gist of the metadata application profile.  For more information, please visit our project page, http://library.duke.edu/trac/dc/wiki/Trident . 

We have designed this model to be extensible, so that it could meet others' needs (as well as make our own edits down the road less painful).  We welcome feedback on our design.  Please send comment to David Kennedy, david dot kennedy at duke dot edu.