MARBI Meetings
ALA Summer 2002


Additional codes in 007/10 for type of material for sound recordings Passed, with small change to value r (cylinder base with a lacquer or ferrous oxide coating)

Music Library Association rep asked about cellulose? Is that to be treated as other? Itís not in the list. Their rep included that in their response to the proposal; it didn't make it into the list. To be looked into.

Karen Coyle asks if the list will have to keep expanding, as new materials are used? Rebecca Gunther: Itís intended more for older material MLA rep: The list of terms also includes contemporary materials.


Changes in Field 008 in MARC Holdings
Passed. Includes new definitions for type of purchase, and for lending policy and for expected acquisition end date

PROPOSAL 2002-10

Defining URI subfields in 506 (Restrictions on Access) and 540 (terms Governing Use and Reproduction)

Passed with very little discussion.

PROPOSAL 2002-11

Repertoire Expansion in Universal Character Set for Canadian Aboriginal Syllabics


PROPOSAL 2002-12

Coding for publication pattern at the first level of enumeration


Most serials people opposed. They didnít like MARBI legislating to fix a system problem. They suggested that the solution to the problem was to treat years as ennumeration data instead of chronological data, since that is how they are being used in the examples given,

PROPOSAL 2002-13

Changes to Authority records for FAST subject Headings
Passed with changes
Rich Greene (OCLC, proposer): This won't affect LCSH headings, just FAST headings. FAST headings do not decompose $a subfields, but they do decompose everything else, creating separate headings for what would be a $x or a $z in an LCSH. They create separate FAST authority records for each of these facets except for chrono terms. The idea is to simplify, since FAST headings are intended to be applied by the creators of the electronic resources. Someone else comments:: we can't get the publishers to put in the ISSN, you think the creators of webpages are going to provide subject headings? Rich: well, more of them are creating metadata. We want to make it easier for them; then we can use their cataloging.

Discussion of proposal to change the definitons in Leader/05 of record status codes:

NLM doesn't like "d" value (delete); prefers "o" for obsolete. It's shortsighted to assume that records will never be distributed. Most systems are programmed to reject authority records with a "delete" value in the record status field. Rich Greene agrees to use the term "obsolete" instead of "deleted".

The proposal defines a new 148 field for chronological terms. This is needed because there is s no way currently to process a chronological heading (because it's not defined as a separate field). However, they will not create authority records for chrono terms, just for topical terms, place terms, and $v and $x terms. These terms are all created as separate headings.

Karen Coyle: Aren't you going to get a lot of false drops?
Attig: It's designed for post-coordinate searching.
Crosby: Users don't do post-coordinate searching. How are you going to get them to do this?
Rich G: CORC users want it.
Crosby: But the providers of web content won't put in these headings.
Rich: It needs a good front end. FAST won't work without it.
Weiss: It's not the role of MARBI to evaluate requests in terms of need; its role is to evaluate whether the proposal works in terms of the format.

MARBI agrees to define new field for chrono subterms.

The proposal also defines a new position in subfield $w (Control subfield) on the 7XX fields in the authority record. This is indicate whether a heading can be replaced automatically, or whether it needs manual review (because, for example, the old heading has been split into two separate headings). This is passed.

PROPOSAL 2002-14

Changes for UKMARC format (includes 10 separate proposals, numbered 14-1 through 14-10)

14-1: Revision of 008/22 (Target audience values)--needed because different countries have different school systems, and current values apply only to US)
Passed (with change, to make c=9-13, d=14-17 years)

14-2: Definition of value in Ė8/22
Passed (though we would like at some point to redo this whole field and do it right (as things now stand, we canít support the entire list of codes)

14-3: Reinstates character positions 008/21 for Music parts Music parts
Passed (though US librarians donít use, and have made it obsolete; but they donít mind UK librarians using these codes)

14-4: Defines character positions 008/33 (006/16) (Music) for transposition, arrangement, and pitch information

14-5: Definition of code u (standards, specifications) for 008/24-27 (nature of work)

14-6: Definition of field 038 (Record Content Owner)
Background: BL and CURL in UK both derive revenues through payment of royalties on reuse of bib data. They use the 038 field to identify records they have created.
Passed after a lively discussion. Sherman reads a message from the PCC about the killing effect on record sharing and copy cataloging. PCC for recommend not using for bibco and NACO records.
BL rep is asked how they enforce their ownership rights. He says they use the field to identify their records, but they don't hunt down people who use the records without paying.
LC people: we might use it to indicate LC records are in the public domain. John Attig: We won't use it, but we should allow the field to exist.
Christina Myers: She was originally anti-the proposal. But many libraries track records we can't redistribute; it would be nice to have a standard field to record ownership.
Gary Strawn asks about tracking fields within a record (e.g. Contents notes). General horror at the prospect.
Rich Greene for OCLC: It will make a difference. OCLC does a lot of data merging; will they have to start enforcing licensing agreements? Will rights management of records become needed?

14-7: Definition of 026 (Fingerprint Identifier)
Some discussion of the way data in this field is used. It mixes parsed and unparsed data. The rules differ hugely from scheme to scheme. [EOK: are their comparable schemes for id'ing art objects? probably not, because they are unique--but what about china, or prints?]

14-8: Definition of field 563 (Binding Information)
Passed, with changes: needs addition of$3 for parts, and an example of a binding note for an artists' book, or other non-rare book
Discussion: Sherman describes need for binding info for artists books. Ellen Crosby notes that her catalogers asked for it for artists' books. Liz says it's very useful for rare book cataloging; she points out that binding info is not copy-specific for trade books, or for multiple copies of an artist's book. Concern about field being misused for instructions to binder of periodical (how many issues per volume, what color, etc.). But people will misuse any field, unless properly trained.

14-9: Defines fields 363 (Trade Price) and 364 (Trade Information)
Tabled, after much discussion. There was a lot of concern about defining a field for info that would so quickly become obsolete, and that would be useful only to vendors (for a very brief window of time). The use of indicators to define "Domestic price" and "Foreign price" (foreign to who?) was criticized. Eventual agreement that the proposal needed a lot more work

14-10: Add Euro and Eszett to MARC character set
Passed, except that Eszett needs to be mapped to something other than what was proposed (that is already in use)

PROPOSAL 2002-15
Defining field 065 (Other Classification Number) in MARC Authority Format


MARBI ALA Summer 02 notes

CCDA/MARBI joint meeting, June 17

FRBR is topic of meeting

Sally McCallum, LC: Tom Delsey did a study for MARBI, mapping MARC to FRBR entities and attributes. It's been on the MARBI website since January. It classifies MARC data into FRBR entitties and maps user taks to all the elements. It also related FRBR and MARC to AACR.

MARC grew by warrant, as fields were needed. The cataloging rules in use at the time were the basis of MARC. These have changed over time; it's a good thing to reanalyze MARC in relation to some external scheme. Delsey's study does this, grouping data elements logically.

LC has also developed some downloadable transformations, which transform MARC into MARCXML and then into a FRBZ-ized versoin of MARC. They would like various communities to play around with this data, see how it works for different types of material.

At present they are studying the critical data elements that allow one to make FRBR distinctions.

MARC is all about the exchange of information. How does FRBR related to this? What are the goals of FRBR? What are the end user goals, the technical service goals, and the goals for staff?

When investigating FRBR, it's important to look into our experience with record clustering (FRBR depends largely on machine processing to identify relationships). We will need to talk to RLG, which has had record clustering algoriths for many years. WLN developed its own algorithms. OCLC has a lot of experience with matching records, merging records, de-duping. And individual libraries have done a lot of work with holdings records.

Relationship between FRBR and ISBD (at the manifestation level) is important Will there continue to be cataloging consistency? We will have to identify key elements that we agree on so we can share each others' records Record independence and dependence issues. For some uses, records must be able to stand alone.

MARC independence: MARC has to be independent of AACR2. It is used by many libraries that do not use AACR2. ISBD is at the core of MARC. But MARC has to be able to support different approaches to ISBD, and therefore different approaches to FRBR. Don't freeze MARC by committing it to one approach to FRBR FRBR has the potential for great changes. This may require changes to AACR2

Glenn Patton speaks on FRBR:
He talks about four key areas related to cataloging rules and procedures. FRBR transforms the OPAC from a replica of the card catalog to a network of related data. The traditional card catalog actually does some things that FRBR will do (bring out relationships). But FRBR in an online environment will do much more.

1. Relationships are the big thing in FRBR. We've brought them out for years in our catalogs. But FRBR will do it more effectively. The problem will be translating what is in our catalogs. We use many different fields to bring out relationships: notes, uniform titles, edition statements, linking fields. For some records, machine processing will be able to bring related works together. For example, the Harry Potter books are easily brought together. But it's surprisingly difficult to bring all records related to Hamlet together. The data just isn't there in older records. Or take the fact that we don't use uniform titles for revised editions; or for much of anything, beyond liturgical works, scriptures, music, law, and literary classics. A report by a Norwegian/French project looking into FRBR called attention to cases where data just isn't there on the records, or it's buried.

2. Our practice with regard to roles or functions doesn't fit into FRBR. AACR2 defines a very few role relator terms-but they are used mainly for law books, or illustratiors of kiddie books. The information is there in the record (e.g. 245$c translated by X; edited by Y), but it's difficult to extract.

3. The attribute "form of expression" is very closely related to the discussion of the general material designator (GMD) and its role. How that discussion moves forward will have an impact on FRBR. People complain of the "unprincipled" mix of comtent and carrier in GMD. It's on the table.

4. We catalog the manifestation and the work at the same time. We start with the description, and then provide access points that bring together the different manifestations of the work. This approach was a big change from earlier cataloging practice: choice and form of entry rules were given first in older codes. But for catalogers who work in shared databases, and who have to derive or create records, the decision on whether to derive or create requires creating, in one's own head, a record for the work/expression for purposes of comparision with the existing record.

Why map FRBR to MARC? It's an exercise in semantics. We're trying to understand the data in that format. The MARC format has evolved for 30 years; it's time to re-assess it. It originated in a card world; MARC was used to produce cards. Since then, there have been many changes, to accommodate serials, archives, objects, community info, etc. Now we are having to deal with interoperability and data cross-sections.

We are having to think about exporting and importing data. Our records have to go to the rest of the world, which includes many non-AACR2 users, and users of other formats [non-MARC]
We need to import data from publishers, using god knows what standards
We have to be able to explain our data to others.
Analysis helps us answer questions about migrating to new structures (whether relational or object-oriented)
Some conclusions from mapping:
Lots of correspondence between FRBR and MARC models (after all, FRBR derived from bibliographic conventions)
2300 data elements identified in MARC.
1200 map to FRBR pretty directly
200 could be mapped (the FRBR attributes didn't capture all the MARC elements; FRBR required redefining)
150 "wild cards" (too loosely defined to map, e.g. miscellaneous info in a 500 note. You could map it intellectually, but not automatically)

There are a number of anomalies and uncertainties. Sometimes you have to go down to the code value to get the mapping. There are also some subfields that are tricky: for example, subfields defined in terms of data type, for processing purpose, e.g. dates (which could be date a treaty was signed, or date of publication, or whatever).
Some subfields just couldn't be mapped (e.g. 500 note, or the "remainder of title" field)
Some subfileds aren't clearly enough defined to be mapped. For example, the access restriction field: do the restrictions apply at the manifestation or item level or the work/expression level?
A few subfields contain a bunch of data all jammed into one: e.g. the 534, or the linking entry fields.
A third of the data is outside the scope of FRBR. They had to add new entities that were related to, but didn't show, in FRBR. For example, the name of program/project from which a work emanates. You could link thousands of records to a program. But do you want to?
Bibliographic entities that are part of the internal logic of AACR2 have an impact on MARC structure. AACR2's classes of material: 006 and 008. They create problems within AACR2 and MARC.
Headings reflect AACR2 concepts. Even when we map to FRBR concept of a work, we are still dealing with the AACR2 concept of a work. This won't transfer to the concept used by other cataloging communities, or to, e.g. the property rights management community.
Our 1XX and 7XX fields are designed to reflect relationships. But they are designed to support the display of main and added entries, not other types of relationship.

John Attig: The concept of the authority record is another issue. A lot of relationships are articulated not just in bib records, but in relationships between authority records [references, as opposed to added entries]

John Espley, VTLS (which has developed a FRBR model; it's just a mockup, but they can take MARC records and FRBR'ize them with programming): more guidance is needed. When is something a new expression? A revised ed. Is a new expression; is 1st American ed. A new expression? (depends on whether it's been rewritten-the Harry Potter books were revised for the American audience) Is a screenplay a new work, or just a different expression of the movie? Serials are an endless problem. Does a title change constitute a new work? What about serials that issue regional versions?

Tom Delsey: We are going to define work and expression differently, relative to whatever cataloging rules we use.
Lots of questions are raised about the definition of "work" In AACR, literary works by a single author are not defined according to t.p. cataloging; everything else is [EOK: visual images aren't either; basically, anything that doesn't have a t.p. is defined differently]. By contrast, FRBR distinguishes between version designations (2nd draft, rev ed). There could also be an edition designation. Recognizing that some edition statements are not version designation,s, just packaging. Or there may be differences not reflected in edition statements. We only differentiate to the extent that the user needs to be able to discriminate. We don't have to bring out ALL differences. For example, our headings for uniform titles go down to the language level, but don't distinguish between different French translations. Or differences based on the use of different typefaces, or different collations; bibliographies make these fine distinctions; our catalogs need not (unless we want them to).

Attig: It would require a lot more research by the cataloger (what rare book catalogers do now) to bring out some of these distinctions. They may not be worth making.

The Italians are very into expression-level distinctions. They feel too many different kinds of things are conflated in expression level records. For example, they want to be able to distinguish between different performances of the same work by the same performer. They would like three or four levels of expression defined.

Ed Glazier: now that we can go ahead with future developments, how can we cope with legacy records? Information in these records is not adequate. How to cope?

Tom Delsey: A lot of legacy records do have the data somewhere in the record. It may be difficult to mine. FRBR lists the most important needed to identify expressions. Our work should focus on the most important differences. One big difference: the form of expression (e.g. text or sound). This is brought out in the leader or 006 or 008. These may be most important for organizing the displays. If you read down through record you;ll find out what form the material takes. But if you are trying to organize, it's a different story. Language is another important differentiation. It is made in headings; or in the fixed field in the 008; or the 041.
Our computer screens are more amenable to a display like what is offered by book catalogs (but have the added advantage of allowing you to drill down to the more detailed display)
We are going to have to decide on the order of precedence: performer? Version? Date? [of course, you could let the user choose the sort order]

Mitchell: Uniform titles for serials are used to distinguish between identical sounding titles. It is used to differentiate, not collocate. Collocation will be more complex for serials.

Everett: The CONSER task force on FRBR will look into this

Tom D: There are elements that pertain to the work, some to the expression, some to the manifestation. Repository designations for mss. Box the compass.

Paul Weiss: Our catalogs support other uses than cataloging. E.g. circulation (to distinguish between the rare book copy and the ordinary trade book). ILL. Acq. And Coll. Dev. (sometimes the library just wants to get the cheapest copy, not the exact one requested). Preservation info may factor in. Someone in audience: Could we identify the work as a citation, not as a uniform title?

Tom: There are deficiencies in the way AACR2 handle work. We would like more freedom to interpret relationships apart from main entry. A working group on format variation is working on this.

Matthew Beacom: What defines a work and a expression can vary, depending on your cataloging philosophy. It needs to be defined within various communities.

Marti Scheel: It's crucial to define our terms. And what is the goal? We haven't changed our record structure? How will FRBR serve users? It's possible we can't do this in MARC.

FRBR could solve two problems: distinguishing between multiple versions; and the problem of complex works (could help with duplicate detection, clustering; various algorithms to detect relationships could be helped by changes.)

Sherman: MARC is a communications format. Display and indexing collocate works, not granular works. My work isn't necessarily your work.

Matthew Beacom: Goal is to brng out bibliographic relations in our databases for multiple versions. It's a conceptual model at this stage.

Elizabeth O'Keefe