Minutes for 02/08/2012

Database Task Force meeting Agenda Feb. 8, 2012

Jimmy started the meeting with a brief explanation of our mission for this year, to improve the quality of the Marmot database. He stated that the Marmot budget has $18,000 allocated for this fiscal year to put towards this goal. There is another $6,000 that currently goes to LTI for quarterly authority control updates. The DBTF can decide if that is a good use of the funds or if it would be better to use it towards something else to help us achieve our goal. He also provided a brief update regarding the Policy Committee. (see that bullet below)

TOPICS of INTEREST

Quality of the Marmot database

• Mary Katherine displayed on the screen the document entitled “Improving the quality of the Marmot database.” Jimmy and Mary Katherine had created the talking points of the first 2 sections. There was much discussion as we went through the document as a group. That document will be sent to the DBTF group for revisions and additions before it is sent to Jimmy prior to the Board meeting later this month. The section of Proposals for 2012 and Measures of Success will be completed with input from this meeting and also from the DBTF via email after the meeting.

What was recommended and agreed upon during the meeting:

• 1. De-Dup the database [which will require hiring part time workers]
• 2. Send records to LTI as appropriate (both to catch up and continue regular contributions)
• 3. Hire someone for ongoing processes
  • a. Take care of routine de-duping, perhaps on a daily basis
  • b. Take care of LTI error reports.
• 4. Ask Triple I if it would be possible to add the 024 (UPC code) marc tag to the

Headings Reports

• De-dupers and database watchdogs
  • The question was asked, “What is expected of member libraries in respect to cleaning up the database?”
  • Should all libraries, particularly those who load records into the database, be expected to take ownership for making the database better?
  • This group feels those are fair expectations. It is true that a few members don’t have enough staff to be able to do much. Could members of the DBTF “buddy up” with one of those libraries to help with their de-duping and other database cleanup projects?
  • Shelly stated that she would be willing to help the other school districts since she does a great deal of deduping and the schools have many of the same titles. Everyone on the DBTF (with one or two exceptions) has been trained in the process of comparing and analyzing records, transferring items from one bib to another and deleting the extra bib.
  • Many libraries already have staff members who alert the TS staff to record problems, misspellings, bad codes, etc. so the “watchdog” program is already happening and just needs some formalization and recognition.
  • A request was made for more information about the “basic discovery of duplicates.”
  • Right now, a report is generated when batch loads of bib records are done and it lists when records are added to the database. This report isn’t generated for OCLC libraries that use direct export.
  • The Headings Report functionality is one way to have the system create a report of duplicates. This is a functionality that has not received much attention in MilCat training sessions. It needs to be included in all trainings from now on.
  • Is there a way to use create lists to get a report of duplicate records? Mary Katherine will work on this.
  • The process for removing duplicates needs to be standardized and documented and all TS staff needs to be trained. Another MK task.
  • Database Policy The Board appointed committee, chaired by Sherry Holland, is charged with the task of producing a statement regarding the Marmot database.
  • It could be something along the lines of …”Marmot libraries agree to abide by the cataloging standards as developed by the Database Task Force…” Authority control The Marmot database is viewable to the world.
  • It is necessary and important to continue with authority control so that the data as regards to author names and subject headings is accurate.
  • RDA Jamie offered a very brief definition of RDA. He requested that specific fields in the bib records be suppressed from view in the classic oPac. The 336, 337, and 338 marc tags contain RDA codes that make no sense to the general public and also they don’t display in VuFind. We don’t want the data to be removed from the bibs, just suppressed, so Mary Katherine will work towards this goal. Jamie has also agreed to be our “resident expert” on RDA and will consider doing a session at MUG2012 in September. We need to be aware that these changes are coming, so that we’re up-to-speed on the issues with LC does make the changes.
  • VuFind, icons, and cataloging codes - codes in fixed fields and 007 tags Library collections contain materials in many different formats. Icons in the public catalog help patrons figure out what they are viewing. The icons that display are dependent on codes in various fields of the bib records.
  • Bib records for non-print materials generally (but not always) contain a 007 marc field. Codes from within the 007 help determine which icon is used.
  • CJ has written dozens of scripts to determine what codes are harvested for icon choices. He will create a chart for us that will be a broad overview. This may take him a few weeks, as there are several pressing issues to be resolved.
  • Prospector and special use codes Something recently discovered....a bib with only one item attached will contribute to Prospector even when the item icode2 is set to "not contribute." The bib basically becomes an "itemless bib," as far as Prospector is concerned. It reverts to the original box code, which means the title displays in Prospector as being at Colorado Mesa University with no local holdings available.
  • Triple I has indicated that it is very difficult to change this original box code. One work-around is to set the special use code in the bib record to "p" which will keep the bib from contributing to Prospector while allowing it to display in your local catalog. This code should be used in this instance only when your library's item is the only one attached to the bib and you don't want your item to contribute to Prospector.
  • Please don't use this code for bibs that have items attached that belong to other Marmot libraries.
  • If you attach an item to a bib with this code and only 1 other item attached, change the special use code from "p" to - (dash) so that it will contribute to Prospector.
  • This is problematic for catalogers in the logistics of checking the special use code any time they add a record. It is a customer service issue, primarily for CMU, but something we all need to be aware of. Cataloging digital collections (OverDrive, SpringerLinks, CO online state gov docs, ebrary, etc.) 856 fields - bibs vs. items

Mary Katherine gave a brief history of 856 marc tags in Marmot records.

• 1) They used to be moved from the bib record to the item record, via the load tables.
• 2) Two years ago, with the implementation of VuFind, that needed to change.
• 3) Research showed that standard practice is to keep the 856 in the bib and not move it to the item. Prospector libraries confirm this practice. 856 tags in the item records cause confusion in the Prospector catalog.
• 4) Load tables have been edited to keep the url in the bib and one has been created to move the 856 to the item.
• 5) In summer 2011, after a discussion with the academic libraries, the decision was made to do a bit of both. Digital collections with “open urls” will retain the 856 in the bib and not in the item record. Digital collections that are a subscription to a specific member and have a library specific url will be loaded with a load table that removed the url from the bib and moves it to the item record.
• Examples of “open url” collections: OverDrive, Colorado state electronic government documents, the Gutenberg ebook collection. Examples of subscription digital collections: ebrary, SpringerLinks. This discussion generated the request that Mary Katherine provide the DBTF with a list of the load tables, a description of what each one does, and the primary settings of each.