BCC98/C/6

Automation Requirements for Music Materials
Draft #6 8-26-97

Comments from the Bibliographic Control Committee, March 9, 1998

General comments:

The introduction says: "...the database accommodates all the data elements present in the most recent update to the applicable ‘USMARC format’ documents." We think that explicit recognition needs to be made of the need for the database/system to be updated when changes to the USMARC formats are made. This is a task that is never complete.

We thought that some up-front definitions are necessary, such as author-title search. Are you talking about doing an author search and then being able to scan an alphabetical list of titles? Or something where the user specifies the author and title elements before the search is executed?

One BCC member was surprised that overall system architecture (object-oriented vs. relational; client-server vs. mainframe) was not addressed. Except for the last section, this document appears to be more an update of an old version, rather than a re-thinking of the new environment. More "re-thinking" and less tweaking of an old document might be more what is needed at this point. Librarians need guidance from MLA about what to look for in multimedia, distributed systems.

I.A.1.

Do you really mean "terminals?" Would "workstations" be a more appropriate term? Very few of the new systems are terminal-based.

I.A.3.

The system should also ignore case. This seems obvious for the usual searches, but one BCC member discovered that all of the number indexes which might contain alphabetic characters in his local system were case-sensitive (e.g. 010, 020, 028, 086)

Is a truncation symbol an expected part of an online system? What about automatic truncation?

I.A.4.

One BCC member thought that this was stated too strongly, and the sentence should read instead: "A search history should be available..." Another agreed, and thought that it might be fair to mandate that the system display at least the search a user just executed, and, by extension, any modifications made to it up to the point of a new search.

I.B.1.

One member recommended adding the phrase "in all searching interfaces." That person discovered that they sometimes get slightly different results in the GUI and Web interface when executing the exact same search.

I.B.3.

Typo: "chain rection" should read "chain reaction."

I.B.4.

Instead of "Searches in which multiple indexes can be combined on the same search line..." how about "...in the same search argument"? This would then take care of GUI systems as well.

I.B.5.

We were not sure what you were trying to say here. Is the intent to eliminate false drops by "miscombining" author and title information in Boolean searches? Are you trying to say that 700 $a and $t (and $a and $p) data should always remain linked? We note that these concepts do appear elsewhere in the document; here it is unclear.

Perhaps this sentence could be phrased more broadly, for example: the system must have provide ways to improve precision in music searches through the use of Boolean operators.

I.B.9.

Should there be a stronger emphasis on the need to retrieve records based on the Leader/07 or on the first byte of the 006 (or 007)? Some systems do not looks at these secondary characteristics of material at all (so, for example, electronic journals are not retrieved in the periodical title index--nor are non-book serials), but we think that they should.

I.B.10.

Check for typo? "available to patrons" instead of "available o > patrons."

I.B.11.

While this is acceptable, does the example go far enough? At least one local system does not index characters like "&" so perhaps other special characters should be mentioned here as well? How does this relate to truncation symbols?

I.C.2.

Does this last sentence mean that systems should have a separate index for uniform titles (in addition to the general title index)? How would variant titles function (presumably taken from $t portions of authority records) in this environment?

I.C.4.

This might belong conceptually better in section I.D., as single letters are often stopwords. Do you need to add some language to acknowledge the problem of "A" as a single-character search? Is there any way to restrict this single-character search to a single subfield (e.g. $r)? Also, what does "fully searchable" mean? That it will not be ignored within a search argument? Only in a title search? In certain parts of a title ($r)? Keyword?

I.E.

Perhaps you need to add another concept to the list of index attributes: table of contents indexing. What index do you recommend ToC to be in? Are ToC in only the keyword index satisfactory? Add to title index? Notes? Its own separate index?

Did the Automation Committee consider the value of an index for URLs (856 fields)?

Are you recommending that subjects be keyworded? Can this be made more clear?

We strongly recommend a separate search option based on a separate index (655 field and 650 $v) for form and genre terminology.

I.E.1.b.

Did your committee consider adding 490's to the title index? At least 490 0 (probably not 490 1) Would you consider mentioning it specifically as an option for local system implementation?

I.E.1.c.

Comment on editorial style: would "7xx $a/$t" be clearer in meaning than what is currently in the document ("7xx $a/7xx $t")? One member suggests that indexes currently work the way you have it phrased, but asks if that should be codified in this document as an acceptable result. Do we need to make it clearer that we think the link between 7xx $a and $t should always be maintained and not broken?

I.E.3.

"All subfields that contain spelled-out information..." What about $e (relator terms)? Including this is name indexes can be problematic if you are looking for an exact heading match for a known heading. On the other hand, perhaps $e and $4 (relator codes) should be included in indexes; otherwise, what good are they for differentiating various functions?

II.A.

Would you consider adding a statement such as: "The display will include cross references from authority records, filed alphabetically within the bibliographic record citations"?

II.B.2.a.

One member found this list of data elements for brief record displays quite amazing and appropriate, and wondered if any online systems actually do this now. For sound recordings, you might wish to specify the bytes of the 007 field (presumably you want to display LP vs CD types of information). Or, give examples of other uses for these codes on brief record displays, rather than leaving this so vague.

II.B.3.

For full, individual record displays, do you want to say anything here about providing live hotlinks for URLs supplied within a bibliographic record?

II.B.3.a.

We ask the system to display any field that contains bibliographic data. What about going beyond this and saying it should translate codes into eye-readable text? Maybe if this were possible, more people would still code fields like 047 and 048.

II.B.3.b.

One member would like to see this requirement expanded and moved to the general requirements section. Displaying tags in AACR2 order is nice, but how about also storing them that way? At least two local systems sorted the tags numerically when the record was loaded; thus, this is a bigger issue than just display.

II.C.1.

The Requirements assume that all search results are initially displayed as citations. In one system, phrase searches result initially in a heading browse list from which the user must choose a heading (or headings) in order to see the citations. This has caused many indexing/display headaches. For example, this institution found that in order to index subtitles, they must be displayed as extensions of the title proper heading. This means that the existence of other title information prevents the collocation of identical title proper headings. The same can be true for GMDs (but is not for this particular institution, which chose not to index or display 245 $h). This means that there is no easy way for the catalog user to find all of a specific title without losing the ability to search for keywords in subtitles. See the example below:

Online Catalogue - Heading Browse

Browsing Titles: T=rigoletto

II.C.5.

What is meant by "format of the material" here? Book vs. serial? Score vs. recording? Miniature score vs. vocal score? This needs to be clarified. At least one local system lumps all the music formats together, and that vendor might think that they have this requirement covered. However, not being able to limit/search by scores vs. the recordings format is not really acceptable to us.

II.D.

Would your committee care to make a statement (here or elsewhere) about how large files of name headings are sorted, e.g., Smith, John with added initials, qualifiers, dates, titles, etc.? One BCC member expressed a dislike of having headings with dates come last, and also disliked having headings qualified by $c information interfiled with headings with headings that include initials. John Cage is an example that does not always file right in music catalogs.

III.

One significant omission from this section is any mention of requiring systems to deal with public scope notes in authority records. Systems should be required to display any field that the library deems worthwhile for the public to see.

One BCC member expressed concern that this document requires systems to honor information in the $w, particularly codes to suppress linking references. Being forced to refer from Works, organ. Selections is viewed as a step backward.

Shouldn’t systems also be required to support the $w a and b for earlier and later names of corporate bodies? Perhaps system-supplied text for these conditions should be required ("Earlier name:" "Later name:")

III.A.

Should something be added here about the ability to make changes to bibliographic records by staff changing location or holdings data? This is a major problem in several systems; people who change shelf locations within their libraries from "reference" to "stacks" also have the ability to edit the entire MARC record.

III.E.

Please add a statement here that systems must have the ability to protect selected fields (e.g., locally added cross references) on authority records from overlay during the replacement process.

IV.A.

The system must support and interpret the USMARC holdings format. This is a national standard.

V.

While we all know why the feature of "number of pieces" is desirable for display, it is hard to envision where this data would come from in the MARC record. 300 field $a and $e? Sometimes this is in a note in natural language. It may also be contained in item or holdings records.

VI.B.-C.

What is "indexing a document according to user type?" Only students can have access to a document, but not staff or professors? Only students of a particular course? Sometimes access is limited by IP address; is that not relevant in this situation?

We are unsure why these features are special to music materials.

Return to BCC 1998 Documents Menu
Return to BCC Historical Documents Menu
Return to BCC Home Page

Last updated April 18, 2000