Meta Buddy

In concept, MetaBuddy is an interactive version of the DMC ApplicationProfile that a Community would use in considering the metadata needs of a collection. For a new collection, MetaBuddy would lead an EditorModerator through the ApplicationProfile, offering assistance in selecting field names and record structures, that would ensure the best possible capture of metadata by the Community and enable consistent, reliable searching across DRC collections. In the event that some form of metadata already exists, MetaBuddy would facilitate the mapping of existing data structures into the DRC.

MetaBuddy promotes the use of the ApplicationProfile through its ease of use and adaptability to local needs. As such, specific metadata formats will need special attention in order to provide the widest use and flexibility. For example, EncodedArchivalDescription? (EAD) -- used in creating archival finding aids -- is so broad and easily customized that it can be expect that local applications would include a number of elements named and used in OhioLINK institutions; these would need to be pre-coordinated by a task force to allow coherent mapping to DRC indexes. A similar coordination effort is expected among OhioLINK mebers using TextEncodingInitiative? (TEI) markup to provide access to archival texts and images.

In a future version, the system could also be used by an institution to develop an ApplicationProfile for a collection that resides on a non-OhioLINK server (e.g. local CONTENTdm server).

MetaBuddy can be used to collect DescriptiveMetadata, as defined in the ApplicationProfile, as well as TechnicalMetadata?, AdministrativeMetadata?, and PreservationMetadata?.

Suggested deliverables and list of functionalities:

Deliverable #1: A tool to assist in the development of project level APs

a. web input to register contact info (e.g., institution/project/project leader/project server location)

b. Create a sequence of webscreens that will prompt creation of an AP for a local project. This implies a database of elements that can be pulled together to output the full local AP document. We need some discussion on what the format of the output would be, it could be something like Charly's OhioLINK metadata core AP, but it might be better to be closer to the new CEN standard for APs, cf.: http://www.cenorm.be/cenorm/businessdomains/businessdomains/isss/cwa/cwa14855.asp

c. The interface design might include a concise display of the OhioLINK metadata core elements with clear prompts for editable subfield text boxes for each element (i.e. "definition", "obligation", "occurance", "recommended schemes", "input guidelines", "maps to DC element"). The local project could accept the OhioLINK core text or modify at will. (Jody Perkins suggests that a model similar to this might be the setting up the specs for variables in SPSS.)

d. In addition to direct input, picklist values which will be specified should be made available to fill in for subfields of certain OhioLINK core or local field elements: "obligation", "occurance", "recommended schemes" (e.g. LC Authorities, Getty, TGM), "maps to [DC/VRA/EAD/LOM] element".... LC name authorities can be accessed as a web service using OCLC's LC Name Authority Service.

e. In the case of a collection stored on the DRC, offer guidance on the use of GeneralTaxonomy? terms along with the explanation of why this is important for cross-collection search.

f. Offer guidance on the use of subject-specific thesauri (in the case of the DRC, a CommunityTaxonomy). Also assist with the creation of crosswalks between a subject-specific thesauri (CommunityTaxonomy) and community-generated thesauri (FolksonomyTag?).

g. Mandatory elements would be displayed first (i.e., Title, Creator, Digital Publisher) followed by all the optional core elements. h. Allow purely local elements and subfields to be added; make all elements repeatable.

i. User should be able to completely rearrange the order of the elements if desired. j. The system should store various versions in an AP's life cycle: draft, final, revised version, etc. and allow for secure logins for editing authorization k. Local APs created on the system will be permanently store at OhioLINK. (The APs can be deleted by OL system admin. only?)

l. The system will allow other OhioLINK users to browse the APs by category or institution.

m. Automate the configuration of BatchObjectLoad? parameters and workstation settings for data entry operators (e.g. ContentDM Acquisition Station).

Deliverable #2: A publicly accessible archive or repository of APs

a. Include a link on MetaBuddy homepage to download the pdf of OhioLINK metadata core (itself a type of application profile: http://www.ohiolink.edu/media/dmcinfo/DMC_AP.pdf)

b. Provide for OhioLINK storage and links (by DMC category and institution) to other established (as yet uncollected) local AP documents from OhioLINK institutions.

c. Provide for link to three current DMC Call for Proposal documents (see left-hand column on: http://www.ohiolink.edu/media/dmcinfo/). Application process in the future should require or strongly recommend that at least a first draft of an AP for the project be submitted electronically along with the project proposal.

d. Provide for display OL metadata core, element by element. (This could be as simple as linking to an appropriate bookmarked page in the current pdf document.)

e. A refinement of 2d would be to also provide for element by element display of OhioLINK and local APs created in this system. This could be accomplished by a series of hierarchical pull-down links that go to pull up appropriate metadata subfield elements (i.e. for quick access to: OL Core or DMC/Sciences, or DMC/Social Sciences, or LocalAPs):Subject:Schemes subfield text information. (see above 1h)

Deliverable #3: Feedback mechanism

a. Provide ability for OhioLINK staff or OhioLINK Metadata committee members to supply in-context, online editorial feedback on AP drafts.

Deliverable #4: provide for search and reporting interface

a. Provide search and retrieval capability for interface suggested in 2d-e

b. Provide ability to compare groups of APs to assist users, OhioLINK staff, and metadata taskforce members in developing the DMC.

c. Provide reports that are useful in analyzing OhioLINK metadata their links to OaiDataHarvesters?.

Name Authorities

In creating the application profile, the EditorModerator can choose to use one or more name authority files (including OCLC Research's LC Name Authority Service and an internally-created directory) for identifying AuthorCreators?. Ideally, the internally-created directory can be organized by several facets, and an AJAX-based technique such as "Complex Dynamic Lists: Your Order Please" can be used to provide a browser-convenient way to select names.