January 2009 Archives

• Proposal No. 2009-2:

A code for Legal Deposit was added to 008/07, Method of acquisition, in the Holdings format

 

• Proposal No. 2009-3:

Field 080, Universal Decimal Classification Number, was added to the Authorities format

 

• Proposal No. 2009-4:

Two additional codes for map projections were added to field 008/22-23 for Maps in the Bibliographic format

 

• Discussion Paper No. 2009-DP02:

MARBI agreed that a field for cataloger's notes of various sorts should be added to the Bibliographic format. It would definitely include the Description Based On and Latest Issue Consulted notes, but the exact scope of the field will need further consideration.  It was suggested that rather than suppressing display at the field level, an indicator be provided to control display.  An indicator may also be used to identify the type of note.

 

• Proposal No. 2009-05:

Subfield $u for Uniform Resource Identifier, will be added to field 510, Citation/Reference Note in the Bibliographic format.  The intended use is for rare materials cataloging, to link to a description of the bibliography cited in the note, or to link to the description of the resource in the cited bibliography.

 

• Discussion Paper No. 2009-DP03:

MARBI agreed that the use of field 257 (Country of Producing Entity for Archival Films) should be opened to non-archival films, and a proposal will be prepared.  However, it was also agreed that the intended use of the field -- to be used in conjunction with a genre term in field 655 to identify films produced within a nation -- was not an effective way of achieving this objective, and that catalogers will continue to use a place subdivision with field 655 even though LCSH rules prohibit this.

 

• Proposal No. 2009-01/1:

A number of new fields were approved for the Authorities format to support new RDA elements.  It was decided generally (a) to split $d into two subfields for start period ($o) and end period ($p) and to use the machine-readable date form specified for field 046; (b) to include a subfield (TBD) for Source of information -- to parallel 670$a -- and subfield $u (Uniform Resource Identifier) so that in some instances it may be possible to avoid the need to duplicate this in a 670 field; and (c) to add subfield $0 in order to link the terms in this field to authority records if appropriate.  With these changes the following field were approved:

 

046 -- Special coded dates

621 -- Additional places

622 -- Address

623 -- Field of activity

624 -- Affiliation

625 -- Occupation

626 -- Gender

627 -- Family information

628 -- Associated language [to be recorded as a code, not a term]

 

• Proposal No. 2009-01/2:

Three new fields were approved for the RDA elements:

 

336 -- Content type

337 -- Media type

338 -- Carrier type

 

In addition, new codes were added to a number of 007 and 008 fields to cover RDA values that had not previously been included.

 

• Proposal No. 2009-01/3:

The proposal to add field 883 to identify the FRBR Group 1 entity or entities that were "represented by the majority of the information in the record" was rejected.  It was felt that labeling records created in a scenario 2 implementation would not be helpful and might in fact inhibit development of scenario 1 implementations.

 

• Discussion Paper No. 2009-DP01/1:

MARBI decided that a technique was needed to include URIs in conjunction with individual data elements in order to support linked data on the Web.  There was agreement that subfield $1 should be used and should be added widely to most fields in the Authorities, Bibliographic, and Holdings formats. There will be cases in which there will be URIs associated with more than one subfield in a field, and the proposal that will be prepared should address this issue.

 

• Discussion Paper No. 2009-DP01/2:

The question of the proper encoding for relationship designations from RDA Appendices J and K turned out to be a complicated issue.  The main problem is that relationship designations from Appendix I may be part of the preferred access point for the work, and therefore there may be two relationship designations in a field: (a) the designation indicating the role of the person, family, or corporate body in relation to the work, and (b) the designation indication the relationship of the work (or expression) to a related work (or expression).  As the first category is part of the controlled access point, is recorded in any authority record for the work, and must be used for validating access points, it is unclear that the same subfield(s) can be used for both categories.  Another issue was that the placement of the relationship designation should not be specified too rigidly because it is possible that the display of the information as a note might place the designation before the name of the work, e.g.

 

Related work:     Based on [preferred access point for the related work]

 

Finally, there was agreement that coded equivalents for the designations should be assigned (as is done in subfield $4 for relator codes)

Appendix D-E, MARC mappings: The MARC mapping was done to the formats as they currently exist. Further changes are in fact under discussion and the mapping will be revised to reflect the final decisions.

Appendix F: I did not include the suggestion about Mongolian; as noted, this will require a specific proposal.

John

I have included most of the comments, but tried not to reopen issues that the JSC has already decided. The structural decision that each role must related to one of the Group 1 entities is such an issue.

I would also remind you that designators that are coextensive with the element sub-type are not included in the list.  Thus "creator", "publisher", "owner" etc. are valid relationships, but are handled through the element name rather than a designator.  This will make an interesting challenge for designing displays, but that is how it is supposed to work.

John

I was the author of Appendix J and I tied my mind in knots trying to keep the reciprocals straight and the definitions pointed in the right directions.  Clearly I wasn't uniformly successful!

In addition, I need to apologize for all the copy-and-paste errors.  Those should have been fixed before the text went to the developers.  This appendix is hard enough to keep straight, without having to deal with outright errors.  I'm sorry about that.

I don't have the time or energy to sort all this out, so I'm simply including Kevin's comments, with a note to the JSC that further editorial work is needed.

One specific point: Some reciprocal relationships were omitted because the related entity cannot logically exist.  For example, there is no relationship for "musical arrangement (work)" because an arrangement is by definition an expression and therefore a related musical arrangement must be a related expression -- covered by "musical arrangement (expression)". I hope that makes sense, although at this hour, I wouldn't know!

John

In compiling the comments on the Glossary, I made decisions based on the following considerations:

The JSC made a decision that the names of all elements, element sub-types, and sub-elements, as well as the values of at least some of the embedded vocabularies, should be included in the Glossary, even if the definition is obvious.  I am including a general comment on the unfortunate affect this has on the usability of the Glossary.  However, I have not included any of the specific suggestions to delete terms.

Remember that RDA is being designed as an online product.  In that environment, you don't need explicit references from variant terms, so long as the term is included in the definition of the preferred term.

The definition cannot be generalized beyond what is in the instructions.  For example, while it is true that geographic coordinates may be included in authority records for place names, that element is not included in Chapter 16; the JSC made a conscious decision not to include them at this time, as they are not (yet?) included in the FRBR/FRAD models.

RDA needs to support all of the implementation scenarios; therefore, it is not appropriate to make reference to authority records, as they are only applicable in scenario #2.

In general, I have been reluctant to recommend the addition of terms that are not used in the instructions.  The major exception is "Continuing Resources" which I will attempt one more time to convince the JSC is a useful concept to use -- at least in the Glossary.

John

For some time, I've been wanting a way to communicate quick-and-dirty notes and comments on my activities as the ALA Rep to the JSC.  Last Friday, we had a session on creating blogs on the Penn State webspace and voila! here is my new blog.

As the home page says, I plan to use this blog primarily to send notes and comments to CC:DA and other interested parties.  I have enabled comments and set the system to accept them automatically.  However, at this time (at least), I am not interested in using this as another discussion forum.  Feel free to use it as you wish, talk to each other, but don't expect me to participate.

The first entries -- which I hope to start shortly -- will be related to my work on the ALA response to the RDA full draft.  I'm going to be very busy compiling the response, and I want to capture and report to you some of the decisions I am making as I go through the CC:DA comments.  I really can't afford to be distracted by comments, so I probably won't be paying much attention to them.  If you think I have made a really really bad mistake, please send an email to me directly or the the CC:DA discussion list.

One further note:  I have developed the habit of compiling ALA responses beginning at the end and working slowly backwards to the beginning -- if nothing else, this makes sure that I know what all the general issues are before I try to write that part of the response.  So the first entry that you will see will deal with the Glossary.  I hope to have finished editing that section and post my blog message sometime today.

I hope that you find these notes useful.

John