Minutes of the Metadata Steering Group (MSG)

Discussion of the DLF Aquifer project.
Mapping DescMeta to MODS, while paying close attention to the DLF Aquifer "MODS Implementation Guidelines for Cultural Heritage Materials" in order to send public comments to the Aquifer Metadata Working Group
To look (philosophical) at how MODS could be used at UVa.
UVa is a DLF member institution and is a participant in the DLF Aquifer project whose primary goal is to "enable distributed content to be used effectively by libraries and scholars for teaching, learning, and research." The Metadata Working Group of the DLF Aquifer Initiative has developed a set of implementation guidelines for the Metadata Object Description Schema (MODS) for use in their DLF-shared digital library. The guidelines are meant specifically for metadata records that are to be shared and that describe digital cultural heritage and humanities-based scholarly resources. The Aquifer's Metadata Working Group is collecting comments and feedback on their document "DLF MODS Implementation Guidelines for Cultural Heritage Materials".
Mapping DescMeta to MODS. Erin made a first stab at mappings. Using her document as a start, the Mud wrestling began:
- "Summary of Requirements" chart
  Since sometimes we are describing the digital & sometimes the original analog, it would seem useful to add this distinction to the "Summary of Requirements" chart for easy reference. We can map to this from our local standards, but at UVa, we have made a much cleaner division between the use by the use of a <surrogate> tag. We can map, but it would be difficult for us to replace the DLF MODS profile for use internally without such a clean division. We have grown to really like our approach.
- <titleinfo>
  It would be difficult (but not impossible) for us to use the <nonSort> element. According to the guidelines, it recommends putting the non-sort characters in this element, and to not include them in the <title> element. It is the consensus of the MSG that <title> be the title "as formally presented". There are possible problems in the use of <title> as described in the guidelines from the differing member institutions. How is a metadata aggregator to know whether to check for the presence of a <nonSort> element? If the <nonSort> element is ignored, then the content of the <title> would not be the "real" title (it would be the title minus the nonsort character).
- <name>
  According to the guidelines, the attribute "authority" is recommended. Currently, the DescMeta mapping from EAD, TEI, and GDMS, does not capture this information. The DTD for DescMeta would need to be modified to include the attribute "scheme" to DescMeta <name>.
- <role><roleTerm>
  The documentation says to use the MARC Value List for Relators & Roles. We are using the AAT for art & architecture. These won't necessarily match. We are also sometimes using terms not likely to be found in the MARC list. These are not actually under authority control for us (although we do try to use a controlled vocabulary), so we can't promise they match. We suggest you add the AAT to the list of the allowed sources. But, overall, we're not convinced this recommendation is worth the bang for the buck.
- <typeOfResource>
  We are using the Dublin Core DCMI Type Vocabulary: http://dublincore.org/documents/dcmi-type-vocabulary/ . We're not using the MODS user guidelines value list. Should we map one to the other or can the two lists come together somehow? The biggest differences are "Physicalobject" vs. "Three dimensional resource" & the breakdown of sound. We can use the MODS list, if necessary, but we are wondering why these lists need to be different.
- <genre>
  It seems to be very hard to pin down exact meanings of genre for Cultural Heritage Items. It would be best that this element NOT be required in MODS implementation. We can not pull this information directly from DescMeta. We cannot require <genre> and are not inclined to go back and add this information. There was much discussion amongst MSG as to what did genre mean. We believe that there would be even more discussion, disagreement among the other DLF institutions to have reliable information in this element.

January 12, 2006

Present: Erin Stalberg, Bess Sadler, Janis Kessler, Sherry Lake, Thorny Staples

Continuation of mapping DescMeta to MODS (DLF Implementation)

Continuation of adding our feedback on the DLF Aquifer document "MODS Implementation Guidelines for Cultural Heritage Materials"
We picked up where we left off from the 1/5/06 meeting (discussing the elements in the order they appear in the above documents Table of Contents).
In the guidelines, the sub-element <placeTerm> does not offer TGN as an authority source. There are no notes to suggest what authority files they would like. For the <date> element, the guidelines do not specify how to handle date ranges. The guidelines say to use as many dates as needed, but choose one to be the "keydate". This "keydate" is to be used for indexing, sorting, and display. Our DescMeta to MODS mapping program will need to have a priority list to choose one date as a keydate. We will not be mapping any date qualifiers (approximate, inferred, etc.) just the date string.
For <language>, the type="code" is all that we can map. There is a type="text", but our mappings to DescMeta has converted all textual languages to codes, so all DescMeta has is the language code.
The DLF'ers have mixed up digital and original descriptions with the <physicalDescription> element. In their context, this element is to describe the "portion" of the original work that is digital. There are no examples or guidance as to how to describe objects "digitized in its entirety". The document further states that the physical description of the original work be described in <relatedItem>. But the original publication and origination information be put in the element <originInfo>, not in the <relatedItem> element.
There is a direct mapping between MODS <abstract> and DescMeta. There is no corresponding DescMeta element to map to <tableOfContents> or <targetAudience>. The MSG would like some guidance as to how the later element is to be used.
As for the <note> element, parsing general notes & determining what is important in an Aquifer context (apart from our local context) is going to be difficult. The MSG has decided to give DLF all of our notes & then we can reconsider the profile is tested. The guidelines say: "Also, not all notes in existing MARC21 records provide information about the intellectual content of the digital resource being described; these need not be mapped into the MODS record." While we appreciate this problem, our records have gone through various transformations & identifying what would be relevant & what would not in the Aquifer context is not necessarily worth the effort.
There are direct mappings between MODS <subject> and DescMeta. It was suggested that UVa put genre-type information in <subject>. The MSG had a question about whether our LC authority "lcsh" (lower-case) would cause problems (as the guidelines use upper-case, LCSH).
As for the element <relatedItem>, I quote "BAD! BAD! BAD!". The MSG really dislikes the use of <relatedItem> the way it is described in the guidelines. There needs to be a better way to distinguish between which elements are describing the digital object and which are describing the original object. The element <identifier> is required and again the DLF guidelines mix up digital and original by allowing types to be doi and handles as well as ISSN, ISBN, etc. Not sure we can require <identifier>. I imagine there will be some resources that only have our local UVa identifier, but we believe that fits better in <recordInfo><recordIdentifier>. What will the metadata aggregators do with the <identifier> field? Is it to match & dedup or to identify records that are new (not existent in the system before)? Knowing the answer to this question would help drive what to put in here.
The guidelines state that <accessCondition> must use the type "useAndReproduction" and further states is preferred over "restrictionOnAcess". We consider access notes (who can use the resource) & use notes (what one can do with a resource) to be two separate things. Our DescMeta records all have multiple instances of <rights> typed accordingly. We can string our data together into one <accessCondition type="useAndReproduction"> as required, but we believe that to be mixing concepts that would be better kept separate. We'd prefer to be able to use both useAndReproduction and restrictionOnAccess.

January 19, 2006

Present: Erin Stalberg, Bess Sadler, Janis Kessler, Sherry Lake, Thorny Staples

Continuation of mapping DescMeta to MODS (DLF Implementation)

Continuation of adding our feedback to the DLF Aquifer document “MODS Implementation Guidelines for Cultural Heritage Materials”
We picked up where we left off from the 1/12/06 meeting with the last element to discuss <part>.
The DLF guidelines make a distinction between structural & intellectual parts of a resource. MODS has a top level element <part> which is to be used “where the part of a resource being represented is a physical or structural part of a resource”. The <title> element has sub-elements <partName> and <partNumber> to be used “where a part is an intellectual part of a resource. This is being carried over into MODS from MARC, but we really doubt that this distinction is useful to carry over. What will an aggregator do with these fields & is the distinction worthwhile to carry forward? For anyone not coming from an AACR/MARC environment, the distinction is fairly mystifying & is not even widely understood in there. Anytime users have to read the instructions over & over to remember what to do & how to distinguish, errors are likely to ensue. We recommend using <titleInfo><partName> & <titleInfo><partNumber> in all cases where part information needs to be recorded.
Looking at “part” information led us to the fact that TEI uses volume, issue information in the <biblScope> element, but this is not being mapped to DescMeta, so it can't be mapped to MODS. This led to further discussion that due to the lack of volume information in DescMeta “getCitation” cannot display this information in the Digital Library interface. The MSG will revisit whether to put the <biblScope> information in Descmeta <title> or create new elements in DescMeta. We decided that DescMeta needed this information and it would be mapped like this:

<title type="main">The journeys of Lewis & Clark</title>
<title type="partnumber">Volume 1</title>
<title type="partname">the first part of Lewis & Clark's journeys</title>

and when strung together for getCitation, etc., it should be:

<title type="main">--period--space--<title type="partnumber">--comma--space--<title type="partname">--period.

The journeys of Lewis & Clark. Volume 1, the first part of Lewis & Clark's journeys.

Erin will discuss this with Perry and Leslie.
Discussing serial and multi-volume sets for DLF, led us to discuss what should be displayed with DescMeta and Cross-collection search. Currently, volume and issue numbers are not displayed as they are not in DescMeta but in the TEI record. It is good to see only 1 record for a collection object, but it would be good to see the children of the collection. The idea then is that ONLY the metadata for the parent be exposed to the cross-collection search & out for OAI harvesting. We'd need an additional workflow step in the ingest process or in the DescMeta extraction scripts to indicate which record's metadata should be exposed & which not. If a TEI individual header has a corresponding independent header, only the DescMeta for the independent header should be exposed to the cross collection & DC/MODS for OAI harvesting.

January 26, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

Finalizing feedback on the DLF Aquifer document "MODS Implementation Guidelines for Cultural Heritage Materials"

The MSG prioritized our comments explicitly noting which elements (and descriptions) we had problems with (the elements <relatedItem>, <nonSort>, <accessCondition>, <genre>, and <physicalDescription>) and noting the general confusion as to which elements to use for the digital object and for the original.
We verified that all DLF MODS required elements are included in UVa's list of Minimal Metadata Requirements, except for <physicalDescription> which UVa lists as an Optional Requirement. UVa also does not require <genre> (it's not even an option), but we don't like this element and have included our objection in the feedback to DLF Aquifer. For a future meeting topic, the MSG will review the list of minimal required elements and the optional elements to see if more optional elements need to be required.
If the element <genre> is kept as a required element in the DLF Guidelines, we discussed possible ways to put the information in DescMeta such that it would be mappable to MODS. One suggestion was to add the element <genre> to DescMeta and include "type" such as "style" and "worktype". This would have to be worked out later.

Discussion of advantages feasibility of using MODS in place of DescMeta

Now that the MSG has gone through mapping DescMeta to MODS, should UVa use MODS so that our discovery metadata would be in a form that others may benefit from and so we wouldn't have to map DescMeta again? The MSG discussed various scenarios: changing from DescMeta to MODS or generating on the fly with a disseminator from the native metadata (more mapping i.e., from TEI to MODS, EAD to MODS, GDMS to MODS). Waiting for a time when all the DL objects needed to be "re-touched" and replaced would be based on lots of other DL priorities. The MSG will be waiting to see the results from the mapping to Aquifer MODS to see if MODS would be good for UVa.
During MSG's discussion and mapping from DescMeta to MODS a few things came up that need to be reconsidered for DescMeta:
- Title type="uniform" – are we using this? Janis will check
- DescMeta loses the authority schemes for names (ok for subjects, but not for names)
- UVa would have to require physicalDescription & genre to be compliant (not currently in our minimal requirements
- Need to reconsider how DescMeta handles subject strings (they are not currently parsed properly into separate elements for easy further manipulation)
After the meeting, the group reviewed the feedback documents one last time and sent out the final comments. The finalized version of MSG's feedback on the DLF Aquifer document "MODS Implementation Guidelines for Cultural Heritage Materials" is attached. The outline of our comments corresponds to the order the elements are presented in the Aquifer document.

February 2, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples, Judy Thomas

Discussion and Feedback on SnapDragon Technical Assessment Group's performance and support recommendations

A group consisting of Judy Thomas, Leslie Johnston, Guy Mengel, Bradley Daigle, and Jack Kelly had previously met to discuss Snapdragon technical issues, in regards to performance, support and general “tool” selection in the Library. The report was given to the MSG for review and feedback.
For the performance concerns, the MSG along with Smith will be gathering usage and load statistics. Jack will be investigating Filemaker benchmarks and testing Filemaker performance comparing different versions.
As for support concerns, the MSG is proposing that support any tool creation and customization of the CCT database be outsourced. Updates, backups, import/export of data would be handled in-house.

February 7, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples, Judy Thomas

Discussion of the Draft SnapDragon functionality doc, Data Dictionary, and VRA Core 4 mapping from SnapDragon for the request for comment

The SnapDragon subcommittee of the MSG has had many discussions, mainly via conference calls, over the last several months with Smith College regarding use of their image cataloging tool, SnapDragon. Together UVa & Smith are going forward for a request for information & pricing request to take SnapDragon to the next generation.
The SnapDragon subcommittee brought all their documents to the full MSG for full review. Asset management (work flow) differences between Smith and UVa were also discussed.
No official agreement or commitment has been reached with Smith. Once the above documents have been finalized they will be sent out to developers for comments/quotes. After comments/quotes, a recommendation will be brought to Martha's Managers.

February 9, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg

Discussing Jackson Davis Photo Collection in preparation for inclusion in the Central Repository

The Jackson Davis Photo Collection is available online through Special Collections: http://www.lib.virginia.edu/small/collections/jdavis/index.html
In converting the Jackson Davis database content to DescMeta, the MSG discussed how to catalog this collection while preserving Jackson Davis' personal classifications and cataloging. This collection will initially go into IRIS and like all other image collections in IRIS eventually go into the new CCT (Central Cataloging Tool).
As we searched the online collection, observed the results, and read, on the web page, about the organization of the database, we made a list of questions for Bradley and Edward. There seemed to be a discrepancy between data that Sherry had gotten from Bradley in 2004 to what Erin was showing in filemaker. (It was later discovered that by changing the layout view to “MoreInfo” we would have seen the other fields on the screen that Sherry had on her print out.)
It was decided that each photograph (or negative) would have its own record in IRIS. One big problem was that none of the pictures had a title. A “title” field is mandatory in IRIS, as is in the DL. An early decision was to create a title in the form:
- Untitled Photo: PLACE-DATE
For inclusion in IRIS the photo records would need enhancement: subject access, people information, and Jackson Davis' subject classification.

February 16, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

Continuation of discussion on Jackson Davis Photo Collection in preparation for importing to IRIS

Mapping Jackson Davis FileMaker database fields to IRIS
The previous week's discussion resulted in many questions about the content, digitization and history of the images. Erin reported on her clarifications with Edward. The MSG discussed a few of the responses. The content, as in the current database, was corrected as it was entered. The original textual data from Jackson Davis's card catalog system, if corrected, was not preserved. All but 11 photographs in the collection were photographed by Jackson Davis. These 11 were photographed by Frances Benjamin Johnston and will be noted as such manually in the IRIS database.
An authority for subject headings for the collection will be made up from the topical headings list found on the collection's web page. Liz will review the information on the web pages to determine the source of the digital images (materials and technique too) and consult with Edward if needed. And of course, the MSG came up with new questions for Erin to ask Edward.
As for IRIS organization, each image will have its own “work” record. Then each image will be linked to corresponding work records for “Institutions” and for “People”. Special Collections researched places that Jackson Davis Photographed and that information should not be lost. There is no “good” place to put this information in the DL. Thus, the need for creating IRIS work records for people and institutions and setting up relationships through GDMS. Authority records for the people and institutions will be created.
The earlier decision on creating titles for the images was modified to:
- Untitled Photo: GENERAL COMMENTS
- If there are no “General Comments,” then PLACE-DATA information will be used in place. For this collection the Negative Number is important and there isn't a good place for that currently in IRIS. A new field for “Other identifier” (or “Original IDs”) needs to be created as well as the “Type” of identifier (such as Jackson Davis Negative Number, Herbarium Barcode Number, etc.). More mapping next meeting.

February 23, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg

Continuation of Mapping Jackson Davis FileMaker database fields to IRIS

Each image in the Jackson Davis database will be a “single” work. Erin created new database fields for the “Institutions” (buildings) for these images as well as “Unique Events”. In IRIS work records based on institutions and events will be created. The images will be linked to their appropriate institution and event. The MSG questioned what should really be counted as an event?
There were a few more materials questions and negative size questions Erin will ask Liz about.
Erin created locality and subject authorities based on the place information included in the FileMaker database (those places that could be verified through the source information in the database). She also created name authorization fields and parsed multiple names into separate “people” fields. She used LCNath names if they existed.
IRIS has 1 note field. The images in the Jackson Davis collection have lots of information on institutions and people based on the research by Special Collections. The MSG does not want to lose this information. All these “types” of fields will be put in the IRIS “note” field prefixed with the Jackson Davis Database field name. For example, Curriculum: Graded- or elementary-level coursework, often religiously oriented.
Back to the decision on creating titles for the images:
- Untitled Photo: GENERAL COMMENTS If there are no “General Comments,” then PLACE-DATA information will be used in the title.
- The MSG was concerned that the title in the above format was one generated by a cataloger, not one the creator gave the image. <title type=”cataloger”> seemed to be appropriate, but Erin will ask Liz what would be best, maybe type=”constructed”? Current cataloging practices with creating titles should not be changed. This may mean changes to the style sheet.

Discussion of Herbarium Collection (Biota Database) in preparation for inclusion in the Central Repository

Sherry brought in an ASCII dump of the data fields in the Biota (Herbarium) database. Looking at the fields, it appeared that there were sufficient fields and data for inclusion in the repository. The discussion then went to talking about the best way to organize the images, according to Collection or Species. The Collection is based on a manmade organization developed by UVa's Mountain Lake department and would not change. But if the images were grouped by species, the species could possibly change. Sherry will contact Eric Nagy of Mountain Lake to ask which organization is best for his group, as well as how often species change and how are the specimen species determined (is an authority file used, which one(s) ).
The MSG also discussed how to title the images (specimens):
- Collection of specimens by COLLECTOR on COLLECTION DATE at LOCATION, or
- SPECIES collected by COLLECTOR on COLLECTION DATE at LOCATION
As with Jackson Davis, each image has a local identifier which needs to be included in any database the records go in to. IRIS or any central cataloging tool would need to include species, genus, family, order, class, etc. in a subject list.

March 16, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg

Discussion of Response to Request fro Comment on SnapDragon II proposal

The MSG discussed a quote and a response from a developer (who has had been working on the current version of SnapDragon, as a consultant on minor changes, for a couple of years) based on the Request for Comment; which included a Functional Overview, Data Dictionary and background statistics for numbers of records and users. This was a detailed document with many comments and analysis.
The MSG also reviewed Jack's FileMaker Performance Analysis and sent questions about the usability of ODBC with FileMaker 8.0 to the responding developer.
Erin will take the MSG's concerns to the Smith College SnapDragon team so they can reply to the developer. Erin will take the quote to the Budget Allocation Committee and present our request.

Brief overview of 3/23 MSG meeting on Content Model for Finding Aids for the Digital Library

Next week Bradley and Edward will be attending the MSG meeting to discuss the content model for Finding Aids for the Digital Library. RMDS scan “items” from collections. There is a Virgo record for the collection-level, but not for the individual items. This will be a discussion on what/how to set up metadata templates for RMDS to capture item-level metadata (XML format) for DLPS and cataloging QA.

Redux on Jackson Davis

Erin created authority names and places for the Jackson Davis collection. These entities will be put into IRIS through programming.

March 23, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples, Edward Gaynor, Bradley Daigle

Discussion of guidelines and templates for XML file creation to accompany RMDS scanned images (part 1)

The MSG invited Edward and Bradley to the meeting to discuss guidelines and rules for cataloging scanned images from the Manuscript and Archival collections. RMDS would like to be able to capture information at the time of the scan (possibly with a digital fill-in-form), combine it with the collection-level Virgo information to create a XML metadata file.
Bradley went over the workflow based on a Patron's request. The MSG discussed what information was contained in/on the “folders” that held the particular requested item(s) and what type of information a student should (could) be able to include on a digital form. The captured information would go into a TEI header with GDMS markup for the scanned images.
After much discussion, it was decided that the title for the scanned item would be the “folder name” (what is physically written on the outside of the folder).
TEI <biblScope> would be used to denote the Box #, Folder #, and item #.
Other information entered from scanning student:
- Folder Call No.
- General folder description from folder or EAD guide
- Physical description Extent (may need to define selectable parameters for this)
- Genre (letter, photo, plus others from a “master list”)
- Subject names (from a drop down list, selecting only those names that appear on the folder label.
- Date
Virgo captured information:
- Author (1XX)
- Put 245 title as Series title for item
- Use the VIU# (found in the 856 link) and the Virgo Control number as ids
- As an aside, Special Collections items have an UVa Special Collections accession number (MSS#) and an UVa EAD id (viu##). This confirms the fact that ID typing is a must for DL items.

March 30, 2006

Present: Liz Gushee, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

Discussion for feedback on the Digital Collections Tools now that it is available via lab.lib.virginia.edu.

Now that the Digital Collection Tools are available on the Library Lab with requests for feedback, the MSG felt that they too needed to send feedback. The MSG took the opportunity to revisit some decisions & note some issues. A list will be given to Leslie.

April 6, 2006

Present: Liz Gushee, Janis Kessler, Bess Sadler, Erin Stalberg, Thorny Staples, Edward Gaynor, Bradley Daigle

Discussion of guidelines and templates for XML file creation to accompany RMDS scanned images (part 2)

Edward and Bradley joined the MSG for a second meeting to discuss guidelines and rules for cataloging scanned images from the Manuscript and Archival collections. We reviewed a template made up as a result of meeting number one and resolved a number of outstanding issues. We then created a TEI header for an item Bradley brought to the meeting so that we could test out our decisions. Again, further refinements were made.
- Operator will also need to enter rights information (from a dropdown).
- Operator will also need to enter language information (although English can be the default).
- Broadside will be added to the list of form types.
Clarification from last meeting: Physical description note is for the condition of the item (letter torn & missing text, etc.)
To be followed up upon:
- <idno type="uva-set"> We need to think more about a set code. To make sure they are also included in the text collection, our generic code is in there now. But, we probably do want to add something for: University of Virginia Library, Special Collections manuscript collection or archival collection or somesuch.
- Edward & Bradley will discuss content rules for counting manuscript pages in <extent>
- Erin will write up content guidelines for entering dates.
- Erin will check the DTD validity for <seriesStmt><biblScope>. The box & folder enumeration is particular to the collection, not to the title, so it should move from <titleStmt> to <seriesStmt> [NOTE: <seriesStmt><biblScope> is valid in the DTD].
- Erin will ask Greg to add broadside to the uva-form list & Erin will add it to the controlled vocabulary list on the website. [NOTE: this is done, thanks Greg!]
- Erin will check with Greg on the phrase: "TEI XML markup in conformance with the uva-dl-tei DTD". [NOTE: Greg brought up a couple of issues. If these are page book only, he suggests we take the line out entirely. Since these will be going through DLPS at some point in the process, we want to credit them with something, but maybe just q/a?]
- Bradley will talk to Melinda re: programming.

April 20, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

Discussion of Francis Benjamin Slides/Photos for inclusion to IRIS

Liz described a grant she wrote to the Arts Council to digitize the photographs of Frances Benjamin Johnston which are held by the Fine Arts Library. Johnston took photographs of architecture all around the south. Many of her photographs are at the Library of Congress, but the Fine Arts library has the photos of Virginia. The grant would provide funding to scan & create metadata for the photos as well as to physically house & preserve the originals. The photographs are currently cataloged in VIRGO and so this will be a mapping project to IRIS/CCT. Ann Burns & Ann Whiteside created a VIRGO/IRIS map long ago for the Barcelona images that are in the DL. We will take a look at that mapping and see whether adjustments are needed. Liz will keep everyone apprised about the success of the grant application.

Re-hash over rights, is it an “attribute” or its own element; how to enforce, is it necessary?

The question came up as to the best way to enforce rights. Should it be left up to a style sheet (as DLPS is doing now), or be enforced by the DTD. The MSG discussed this at length & decided to wait until a change is made to no longer pre-extract the metadata. We decided to change the DTD when we start to extract the metadata on demand, since there will be implications for the data already existent in the DL. The element values can be enforced through stylesheets and we decided to table this issue until a later time. The stylesheet rules will soon be updated on the Metadata “Best Practices” web page: http://www.lib.virginia.edu/digital/metadata/bestpractices.html

One more look at the DL Collection interface before sending Leslie comments

The MSG reviewed our DL feedback list and added a few more suggestions. The list will be given to Leslie.

April 27, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

Demonstration of Collection Objects by Thorny

Using the Catlin collection, Thorny demonstrated a collection aggregation model that Ross is working on. Such an aggregation model could be used to gather DL objects based on a set of “rules” that then could search and display the DL objects in that aggregation.

May 18, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples
Guest: Leslie Johnston

DL lab feedback with Leslie & enhancements/fixes for fall

Leslie shared a list of Repo tasks and their priorities based on the DL lab feedback. She highlighted the tasks that would be implemented in the fall. A redo of searching capabilities and the search results is the main focus for the fall. The redesign of the look and feel is planned for January 2007.
Leslie asked for several clarifications on the feedback from the MSG. Leslie asked that the MSG provide her with the specifications for the search results for all 3 “types” (text, images, and finding aids). Date and publication information was requested to be included in the search results.

Correction regarding the April 27, 2006 minutes:

The demonstration that Thorny gave was to show a “practice” of a content model for collection aggregation. It was NOT a tool, but a demonstration of an approach and how it could be rendered.

May 25, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

NC State and Endeca Briefing

Erin shared her thoughts and description of the “Field Trip” to NC State Library. She gave a demo of the NC State online catalog and discussed their use of Endeca.

Specifications for DL search forms & hit lists

At the previous MSG meeting, Leslie asked that the MSG provide her with the specifications for the search results for the 3 “types” (EAD, TEI, and GDMS) of DL collections:
1. Cross-collection Hit List Results. Currently only the title and author is displayed. Punctuation will be fixed. Style change to the display: title will be bold. Contents for the hit list results:
  - Title (main), all BiblScope content, subtitles
  - Author
  - Date
2. The Search Collections boxes have radio buttons for searching “all words” and “any words”. The MSG will investigate what phrases would be best to use here.
3. For Texts, brief search, the MSG would like the “Choose scope of search” removed from the search box.
4. The advanced search box would be best if there were separate fields searching like Virgo's advanced search.
The MSG will continue discussing Search box re-design and hit list results at a future meeting.

June 1, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples Guest: Cyril Oberlander, Terry Reese

Visit with Terry Reese, Head of the Digital Production Unit for Oregon State University Library

Terry Reese joined the MSG during his visit to the University Library. We had a great time telling Terry about the Metadata Steering Group, what it does and how it is integrated through the library. Terry shared his digital collections and all things metadata at Oregon State.

June 8, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

Continuation of Specifications for DL search forms & hit lists

All hit lists should display title/creator/date.
- All hit lists should pull info directly from the descmeta making the specs for each collection type (images, text, Finding Aids) the same. Search results will be: title, author, date. In order to pull information from Descmeta so it can be used for proper display, the type “hitlistdisplay” (for <agent> and <title) will be added to the Descmeta. The <title type=hitlistdisplay”> will include: title-proper+sub-titles+volume/issue
All advanced search forms should look like web advanced search forms with drop-down selectable index fields.
- Each advanced search form will have drop-down selectable index fields in addition to “limit by” fields.
The MSG also will recommend that the page titled “Cross Collection search” be changed to “Cross Collection Catalog Search” to emphasize that this is a metadata search.
Erin will send Leslie details of our discussions.

June 29, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

DescMeta changes for sorting/display etc. (continuation of previous display conversations)

To make it easier to “grab” and sort hitlist information, the MSG discussed putting display (and sort) title, agent, and date in a special section within descmeta. Thorny and Erin will take the MSG's suggestion to DLPS and Leslie for their feedback.
For the Image Advanced Search, the MSG discussed changing and adding search display terms that would be meaningful to the users:
- Include “date” in the “Limit By” section and give examples of a correct date format next to the field.
- Use the word “location” in place of “place created or housed”
- Use “materials” in place of “physical description”
- Add the search field: subject (name)
- The MSG would like to use another term in place of “person's name” to reflect the “agent” (such as creator or institution) as to not imply a name that is a subject. The MSG will ask for suggestions.

July 5, 2006

Present: Janis Kessler, Sherry Lake, Erin Stalberg, Thorny Staples

Herbarium mapping to GDMS

Brown Science and Engineering Library and Mountain Lake Biological Station (UVa's Dept. of Biology) are working on a project to catalog Herbarium specimen. The specimen are very fragile plants mounted on 11x17 sheets of construction paper. Some were collected back in 1895. BSEL is cataloging the specimen using software designed specifically for biodiversity data (plant and animals). Sherry has been working on converting the data in this database to flat files and then creating GDMS XML files.
The MSG is reviewing Sherry's mappings.

July 13, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

Finalization of hit list specs and new DescMeta element

To make it easier to “grab” and sort hit list information, it was decided to create a top level element <presentation>. Sub elements will include those fields to display (<displayTitle>, <displayAgent>, <displayDate>) and those to use for sorting (<sortTitle>, <sortAgent>, <sortDate>). Rules on populating these fields will be similar to those already used for other DescMeta mappings. Erin will send Leslie the MSG's complete report.

Herbarium mapping to GDMS, continuation

Continuation of June 29, 2006 discussion: The MSG continued reviewing Sherry's mappings. Once finalized, Sherry will contact Jack Kelly about the Art&Architecture (IRIS to GDMS) scripts in order to do attempt something similar.

July 20, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

SnapDragon

Erin announced that the funding for SnapDragon (UVa’s part) has been approved. Erin is working on a memo of understanding and formal agreements.

Disseminator discussion

Thorny tried to show several of the disseminators for our discussion, but the server was having troubles. It was fine earlier in the morning, but not for our meeting.
The MSG did decide that for text objects the disseminators “getPreview” and “getLabel” will display the same text:
- DisplayTitle, DisplayAuthor, and DisplayDate.
Image objects will display:
- a thumbnail for “getPreview” and
- display the DisplayTitle, DisplayAuthor, and DisplayDate for “getLabel”.

July 27, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Erin Stalberg, Thorny Staples
Guest: Holly Robertson

Reviewing Image AdminMetadata

Jack reported that scripts that were devised to capture the image AdminMeta broke with an ImageMagick version change. Since the scripts have to be redone, Holly came and talked the MSG through what we need from a preservation standpoint. With Holly, the NISO standard for Technical Metadata for Digital Still Images (MIX) and Harvard's Guide for Technical Metadata, the MSG looked at re-do the mappings so that Jack can fix the scripts.
Holly outlined what MIX metadata is mandatory and suggested that our AdminMetadata have all those elements. One section we do not have is on the scanning system hardware/software. The MSG will research which of these elements can be captured.
Before the mappings can be finalized, examples of ImageMagick for tiffs, jpegs, for various images are needed so we can see what output fields (and the values) are available for the different types.

August 3, 2006

Metadata Steering Group Minutes
August 3, 2006

Present: Liz Gushee, Janis Kessler, Sherry Lake, Erin Stalberg, Thorny Staples

Continuation on Review of Image AdminMetadata

From the previous meeting's discussion, Erin created a draft mapping of TIFF and JPEG Image Headers to AdminMeta (including the new elements discussed with Holly last week). Many questions came up during the discussion. To better map AdminMeta the MSG needs good ImageMagick examples (and the background on the scanning of the images; i.e., original scanning colorspace – true grey scale, or converted, etc.). Bess is to investigate JHOVE to see if it would be a better image header “dump” program to use (instead of ImageMagick).
The exact mappings between an image header dump and AdminMetadata still need to be worked out. In the mean time, Sherry will write up the MIX-like elements for the AdminMeta DTD. These elements were decided on at the last MSG meeting. Erin will send the additions on to Greg to update the DTD.

August 17, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples

AdminMeta for audio & video

We discussed how to proceed with Administrative Metadata for audio and video: who needs to be involved and at which step. A small group of “experts” will be chosen to look what is being done in the field and to research formats. The small group will then bring their results back to the MSG for final decisions on technical metadata for audio and video.

Continuation of Image AdminMetadata

Bess presented her output from JHOVE. JHOVE does a good job at generating MIX xml elements for some images. The problems we saw were more in not knowing how the images were created in the first place. None of the examples had any scanner information in the results. We had questions on how the scanner information gets in the tiff header. We saw scanner info in the imagemagick examples from the first week we discussed image AdminMeta.

August 31, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Ross Wayland

Aggregation Objects

Ross came for an update & demo on the aggregation objects & a discussion of the structural metadata files that will support them. The MSG was all very interested & impressed with the work thus far.
After working in this area, Ross & Thorny have determined that the efficiency of aggregation objects would be improved if they all work off the DescMeta indexes, rather than the native GDMS/TEI/etc. This will also allow for consistency for the user experience across formats. Once again, there are elements missing from the DescMeta to facilitate the creation of aggregation objects. The MSG recently updated the mappings to help with display & sorting issues in the DL, but enumeration & chronology (mostly coming out of the TEI <biblScope>'s) are still not parsed apart adequately for this purpose. The MSG decided to add a <scope> element to the DescMeta to address enumeration & chronology. Like the TEI, it will be typed as necessary "volume", "issue", "date", etc. The structural metadata stylesheets can then call XPATH queries on those values. The need for an element to address enumeration & chronology was deemed important across all formats & therefore appropriate to add to DescMeta.
Follow-up: Erin will request from Greg that <scope> be added to the DescMeta and GDMS DTDs & will update the last revised TEI mapping accordingly for DLPS & Leslie.

September 7, 2006 (virtual)

In case you actively follow the MSG minutes, you may be interested to know that the MSG electronically amended last week's decision to add a <scope> element.

From last week:
> The MSG decided to add a
> <scope> element to the DescMeta to address enumeration & chronology.
> Like the TEI, it will be typed as necessary "volume", "issue", "date", > etc.

We have decided that <scope> is overly broad & may be misinterpreted in practice, so we are going with <numbering> instead. The typing above still applies.

September 14, 2006

Present: Janis Kessler, Sherry Lake, Bess Sadler, Erin Stalberg, Thorny Staples, Liz Gushee

PIDs

The Group discussed the idea of using PIDs also as interim unique identifiers for materials destined for the DL but not quite on their way there yet. This came out of the Bill Elwood video discussion. The video will be put somewhere temporarily, until it can get in the DL, and Cataloging will also be cataloging the DVDs with pointers to the temporary home for the digital video. Since we'll need to change the URLs when the data gets into the DL, would it make sense to assign PIDs now that we can use in the temporary home & put in the VIRGO records? For ease of global updating later. While PID-generation is possible earlier in the workflow (currently being used for IRIS & Herbarium & Jackson Davis), we decided it probably was not a good idea in this case because the "unit of content" hasn't been settled on yet. The DVDs were made with a one-to-one correspondence with the original tape (i.e. 3 beta tapes for one interview, 3 DVDs), but how we'll deliver that in the DL has yet to be determined. Assigning PIDs now, therefore, to each DVD seems dangerous. Decided: where the unit of content is unclear, PID-generation for interim purposes is not a good idea. Cataloging will revisit the other idea on the table (using the RMC DVD# in the filenaming) and we can later put together a conversion table of DVD#s & PIDs to update VIRGO. Erin will talk to Judy.

* DescMeta structure for subjects

In order to move towards better functionality for the aggregation objects & also to support faceted searching, the Group agreed there needs to be better granularity in the DescMeta for subjects. The MARC rules currently embedded in the <subject> tag will make life more difficult later. Mixing MARC rules with XML rules seems worrisome for processing efficiency. Instead of this:

<subject scheme=”LCSH”>Granada (Kingdom)|xHistory|ySpanish Conquest, 1476-1492|vFiction.</subject>

we will MOVE TOWARDS this:

<subject scheme=”LCSH”>
<term type=”geographic”>Granada (Kingdom)</term>
<term type=”topic”>History</term>
<term type=”temporal”>Spanish Conquest, 1476-1492</term>
<term type=”genre”>Fiction</term> </subject>

The type list, controlled by best practice (not by the DTD), will be taken from the MODS type list:
- topic
- geographic
- temporal
- titleInfo
- name
- genre
<subject> accepts only <term>
<subject> not required & repeatable
<term> required & repeatable

In IRIS, there is no granularity in the subject data, so the above processing will be impossible. IRIS strings are accepted with the "--" and with no subfield coding, i.e.:

Granada (Kingdom)--History--Spanish Conquest, 1476-1492--Fiction.

Erin & Liz will take this back to the SnapDragon group, where we hope we could do this more successfully.

Ramifications:

delivery stylesheets will need modifications

TEI-DescMeta will need modifications

DescMeta will need to be re-run both for TEI & for GDMS, since <subject> will no longer allow PCDATA.

The MSG has no need to do this immediately, but would like to get this on the radar. Erin will talk to Leslie.

NOTE: After the MSG, Erin & Leslie met. Leslie was in agreement with all the changes & also happy because that this moves us closer to faceted browsing, but she doesn't have the resources to do this now -- mostly rerunning the GDMS & the display implications. Perry is currently in the process of updating the TEI-to-DescMeta & they will rerun that DescMeta, but because of the other ramifications (rerunning the GDMS-Descmeta & modifying the display stylesheets), we don't want to wrap these changes in with the other work. We will wait until January.

October 12, 2006

Present: Janis Kessler, Sherry Lake, Erin Stalberg, Thorny Staples, Liz Gushee

"Unknown" creators redux

In the DescMeta mappings, we had been populating "Unknown" where <agent type="creator">'s were blank & we had required (by best practice) an<agent type="creator">. This was largely as a request from the Art folks who were interested in actively being able to search for "unknown" artists. This is causing problems in other areas, however, particularly texts with no author "main entry", like the Cavalier Daily. We decided that we can't populate Unknown in the mappings & we can't require an<agent type="creator"> across the board. This policy does not make sense across the board, it has to be community specific. The Art community can actively use unknown, but we will not use it for the texts just because they lack a MARC 1XX main entry. In the new <presentation> tag, non-existent <agent type="creator">'s will result in empty<displayAgent> & <sortAgent> tags in the DescMeta. In a browse list on author, those with empty <sortAgent>'s should sort to the top.

<presentation> in image objects redux

Perry asked us to revisit the decision to not require <presentation> in the DTD. We had made this decision because the image objects don't have full metadata, they only have a title, rights, and their <pid>s. It had seemed not worth the bang for the buck to add the other fields just to enable their use in the <presentation> element. The image objects don't populate the discovery index & the purpose is largely for sorting/display in hit lists. Image objects don't appear in the hit lists, they are found through their parents who do have the<presentation> tag. Requiring <presentation> in the DTD, therefore, may buy us consistency in the data, but not for any clearly useful purpose.

Mary Prendergast to join the MSG

Mary is interested in immersing herself back into cataloging now that she will no longer be Head of the Music Library. She will be doing a staff share in the Cataloging department working on TEI headers and she is interested in doing more non-MARC-metadata work. The MSG decided to ask Mary to join the group.

October 31, 2006

Present: Janis Kessler, Sherry Lake, Erin Stalberg, Mary Prendergast, Thorny Staples, Ross Wayland, Leslie Johnston, Ronda Grizzle

This was Mary's first MSG meeting. Welcome Mary.

Aggregation objects

Ross, Leslie, & Ronda came for a demo of the aggregation objects and a discussion of functionality requirements. The technology was behaving badly -- the repository was down -- so the discussion surrounding functionality was pretty theoretical. We also spent time looking at the underlying XML files & structure. Discussion to be continued when the we can look at the examples live.

November 16, 2006

Present: Janis Kessler, Sherry Lake, Erin Stalberg, Mary Prendergast, Bess Sadler, Liz Gushee

Aggregation objects

Since the technology was behaving badly for the last meeting & Liz & Bess were both out, we had a second discussion of functionality for the aggregation objects. Full comments will be written up for Thorny & Ross. (Thorny was not at this MSG meeting). Highlights include:
- need to be able to search within the collection
- layout is misleading in a number of areas (Thorny & Ross were looking for comments on functionality, but we couldn't help also discussing interface issues).
- we'd prefer a faceted navigation-style approach to the dropdown list choices. We need to give more information to the users up front about what is in the collection, so hit numbers in parens following the options, i.e. portraits (156) landscapes (206)
- visual displays. Date choices, geography choices would be more useful presented in a visual format.
- list members for images should take you to the light table view with options to refine. --need ability to mix & match dimensions
- we need to think through collection descriptions because we noticed that sometimes the collection descriptions highlight elements of the collection that are not browse-able using the dimensions structured in the metadata. This is not a functionality/technology issue for Thorny & Ross, but needs to be noted & thought through.

November 30, 2006

Present: Janis Kessler, Sherry Lake, Erin Stalberg, Mary Prendergast, Bess Sadler, Thorny Staples

Aggregation objects

The group filled Thorny in on the discussion of the previous meeting. Erin still needs to write up the formal notes for him & Ross.

SnapDragon update

Erin gave an update on the status of the SnapDragon Memorandum of Understanding. It is in its final stages & hopefully will be finished shortly when Madelyn returns next week. Erin will send out updates to lib-metadata & ul-imaging when the details are finalized.

Projection attributes

Perry asked us to reconsider the default value of projection on DescMeta/GDMS place/covplace.
In the GDMS DTD. <geometry> and <boundedby> have the "projection" attribute (with default as "geographic"). <covplace> and <place> also have the "projection" attribute.
Should the default value of the "projection attribute be removed? YES.
The attribute itself should be also removed from <covplace> and <place>. It only makes sense to have this attribute on <geometry> and <boundedby>. We have been misusing this by putting it on place/covplace.
Questions/requests for DLPS:
- Will it "break" all our current GDMS files if the "projection" attribute is removed from <covplace> and <place>?
- If the answer to this is yes, we'd need to fix the stuff in the repo to implement this change. Thorny says this can be done via the "back-door" and we wouldn't have to rerun the extraction scripts. Low priority, however. Erin will check with Perry.
- Greg would have to change the DTD for GDMS/DescMeta.
- Jack should move projection="geographic" from his IRIS/GDMS mapping scripts for covplace/place.
- Erin will check with Perry/Jack/Greg about all of the above.

Thorny also requests an <attribute> tag inside agent, with the type attribute. He's gotten this request from a group at Hull University that is interested in DescMeta. This is potentially useful for institutional repository uses, but attribute data more properly belongs in a name authority record, not embedded in the descriptive <agent> tag. We agreed to add this optionally to both DescMeta & GDMS, but we will pursue the question of authority records locally. Erin will ask Greg to make the DTD updates. This also reminds us of the need to be pulling/storing standard codes (i.e. LC-NAF & ULAN) into our <agent> tags. Topic for future discussion.

May 10, 2007

Present: Sadler, Gushee, Prendergast, Kessler, Lake, Johnston

Leslie presented an issue that had raised in the mapping between EAD and the <presentation> elements in DescMeta.

The mapping specified <corpname> as the source for the Institution's name in <agent><name>, but encoding practice has varied over time, and it turns out that the Institution name can occur in either <corpname> or in <eadid>. When the presentation elements were generated, only 1208 out of 3960 records actually had names in them. MSG agreed that the scripts can and should be updated to pull the Institution name from either location in the EAD files.

Set Codes

Leslie presented three set codes for EAD approval:

ARCHIVISION-Architecture
UVA-LIB-JacksonDavis
UVA-LIB-HolsingerStudio
- All were approved.
There was some discussion of the set code for the Herbarium project. As a general rule, the first portion of the set code refers to the source of the content, e.g., UVA-LIB, SI-SAAM, or ARCHIVISION. The previously discussed set code for the Herbarium project WAS UVA-LIB-HerbProject. BUT, these aren't Library collections. Suggestion provided by Sherry after the meeting for consideration are:

MountLakeBioStat-Herbarium
MLBS-Herbarium
UVA-BIO-Herbarium
UVA-Bio-Herbarium
UVA-BIO-HerbProject
UVA-BIO-MLBS-Herbarium

This requires more discussion.

Janis and Leslie provided a very brief overview of the discussions under way about workflows for creating item-level metadata for manuscripts.

It's early days, and the proposed test cases are the Jefferson Correspondence and the Jefferson Architectural Drawings, because they do have item-level descriptions in the finding aids that can be programmatically extracted. A prototype project created shadowed item-level records for the correspondence last year. Liz noted that there are some applicable records in Virgo for the architectural drawings created by Ann Burns when she cataloged slides. There are no real plans yet for everything that does not have item-level descriptions, which is by far the majority of the materials.

Leslie gave the MSG a head's up that the DLF Aquifer project has requested that UVA make MODS records available via OAI.

Now that the Aquifer project has a revised set of guidelines out, at some point we'll need to attack the mapping between DescMeta and Aquifer MODS again.

June 14, 2007

Present: Janis Kessler, Bess Sadler, Thorny Staples, Mary Prendergast, Erin Stalberg

Blacklight demo

Bess did a demo of Blacklight and talked about current development status. Highlights of the discussion:
- demo of both Blacklight for VIRGO and BlacklightDL
- discussion of metadata/functionality for music implementation
- discussion of back-end tools which would be useful to catalogers to do corrections on records identified for cleanup.

June 21, 2007

Present: Janis Kessler, Bess Sadler, Thorny Staples, Sherry Lake, Mary Prendergast, Erin Stalberg

Academic Information Space

Thorny gave a intro talk on the "Academic Information Space". He used a diagram to talk about how users are to create/manage their own content. When (if) ready, the faculty project could then easily be moved to the Scholar's Repository (UVa Library DL).
We talked about how Collab was going to use 'collectus' and have a "page comber" to easily grab images and put into collectus. With the "On Demand Digitization", images would be put into a repository and try to ask for batch metadata from the users. Then the batch (images and metadata) could be delivered to a specified Collab site. We talked generally about batch metadata and what users would likely be willing to fill in (very little!). Clearly, we'd need identifying information about the creator of the batch (requester) and the date of request, and we could provide fields for keywords or textual descriptions describing the batch as a whole. Many questions surrounded whether or not the images in the batch are likely to have any internal coherence. Much more discussion obviously needs to be had as on demand digitization moves forward.

Gordon Books

The French department has a grant for markup & enhanced metadata for the Gordon collection, a selection of sixteenth-century books which have already been imaged Bradley's unit. Bradley & Leslie had met with the folks in the French department. Cataloging is going to create TEI headers for a sample set (5) that we'll take back to the French department to discuss. The idea is that we would give them TEI (out of VIRGO) and they would do enhanced metadata creation using Oxygen on the raw XML. Other potential discussion points will be the use of MODS.

July 5, 2007

Present: Janis Kessler, Bess Sadler, Thorny Staples, Liz Gushee, Sherry Lake, Erin Stalberg

Blacklight & authority control

Bess talked through ideas for implementing authority records in Blacklight. Since we have yet to implement authority records in the DL, options that make use of existing authority files from VIRGO -- using them on top of DL data as well through Blacklight -- is quite attractive.
Brainstorming about authority files currently in use at UVA:
- Library of Congress -- names, geography, subjects (can be exported out of VIRGO in MARC/MARCXML or available also from LC in MADS. Webservices?)
- AAT -- Art & Architecture Thesaurus (can be purchased and downloaded from the Getty in XML. Webservices?)
- TGN -- Thesaurus of Geographic Names (can be purchased and downloaded from the Getty in XML. Webservices?)
- ULAN -- Union List of Artist's Names (can be purchased and downloaded from the Getty in XML. Webservices?)
- MeSH -- Medical Subject Headings (can be exported out of VIRGO in MARC/MARCXML or downloaded from NLM. Webservices?)
- Iconclass -- Iconography (we have a locally built Access database of all the Iconclass codes used by the Art department (as of 2005))
- GSAFD -- Guidelines on Subject Access to Individual Works of Fiction, Drama, etc. (available electronically?)
Homework: are there others that we use not on this list? (Email Erin if any of you out there in lib-metadata-land know of others.)

Later entity issue

We thought we had resolved a display issue for later entity titles, but in discussing this more (with many slightly-off-topic tangents), we decided to table this question until the new interface design work is completed by Open Source Connections.
It also became apparent that we are not using the concept of "larger entity" consistently. Sometimes a larger entity is a larger building (or complex) in which the resource-being-described is contained. Other times, the larger entity field is being used somewhat like a series (or set) title for a collection of images.

The MSG decided to start meeting every 2 weeks (rather than every week).