---   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 .

Editing XML Metadata in HTML Forms

The first challenge that we face when dealing with XML metadata is that we want to make it simple to edit.  XML is certainly readable and there are editors available to simplify creating well-formed XML.  But, in libraries, often we deal with complex schemas, and XML nodes have attributes, and sometimes we nest XML nodes inside other nodes, and some nodes are repeatable and others not, and some fields' values should be restricted to a defined authority list, and we can leave a lot open to the interpretation of the person who is editing the XML directly.  In my experience, direct editing of the XML requires an intimate knowledge of the schema. 

...

Rather, we opt for web interfaces for editing the metadata.  And we want to allow our catalogers to use html forms to create and update the descriptive metadata.  With web forms, we can simplify the metadata entry, create contextual help for each metadata field, selects or lookups against authority lists, and we can provide mechanisms for error checking.  OK, so we decided that we wanted to use HTML forms.

Mapping XML to HTML Forms

Now, we needed to figure out how to map the XML metadata into the HTML forms.  HTML forms are very flat.  XML is not necessarily so, nodes can be repeatable, nodes can have attributes, nodes can be optional or required, nodes can be nested inside other nodes.  There are a lot of challenges that need to be considered. 

...

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

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.

...

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 . 

...