NAME: Definition of Existing Bibliographic Data Elements in the Community Information Format
SOURCE: NWOET Foundation; Queens Borough Public Library
SUMMARY: This proposal suggests defining field 658 (Index Term-- Curriculum Objective) and field 856 (Electronic Location and Access) in the USMARC Community Information Format. It also recommends a new procedure for the across-format adoptions of data elements when no changes to the elements are required.
KEYWORDS: Across-Format Adoption Procedure; Curriculum Objective; Electronic Location and Access; Field 658 (Community Information); Field 856 (Community Information)
RELATED:
STATUS/COMMENTS:
12/1/95 - Forwarded to the USMARC Advisory Group for discussion at the January 1996 MARBI meetings.
1/21/96 - Results of USMARC Advisory Group discussion -
Approved.
The procedure for incorporating an existing field exactly
as is in one format into another is:
2/15/96 - Results of final LC review - Agreed with the MARBI decisions.
PROPOSAL NO. 96-6: Definition of Existing Bibliographic Data Elements 1. BACKGROUND Primarily, this proposal suggests defining two fields in the USMARC Format for Community Information exactly as they are already defined in the USMARC Format for Bibliographic Data. It follows by just two years the definition of these data elements in the Bibliographic format. As the adoption of new data elements from one format to another within a short span of time becomes commonplace, this proposal also suggests a new procedure by which the definition of new data elements by adoption could avoid the delays of the MARBI discussion paper and proposal process. 2. DISCUSSION The USMARC Format for Community Information (CIF) has been used for three years after having been published as a provisional format in 1992. As with any of the USMARC formats, use has revealed a few problems, some of which have already been dealt with in other proposals (e.g., 95-7 Change of tag 301 to 307 in the USMARC Format for Community Information). One of the shortcoming brought to MARBI's attention by CIF users recently was the failure to define field 658 (Index TermþCurriculum Objective) and field 856 (Electronic Location and Access) in the CIF at the same time they were defined in the USMARC Bibliographic format. The USMARC Bibliographic and Community Information formats have always had a lot in common. Initial drafts of the CIF treated community information records as falling within the scope of the bibliographic format since many of the bibliographic data elements were needed. It was only late in the process of defining new data elements specifically for community information records that MARBI recommended that the CIF be developed as a separate format. At that time a decision was made to carry over intact as many USMARC bibliographic data elements as were needed. This was done primarily at the field level. A principle was thereby reaffirmed that when different formats share data elements, those data elements should be defined the same, as much as is possible. The principle already had precedents in the other USMARC formats. Field 658 The need for field 658 in the CIF results from the recent growth in community information control in school systems. Events, programs, and services have played an important role in the learning process. Librarians in many states are now creating community information records to provide educators with information about resources available to support various curricula. It is the desire to record curriculum objectives in community information records that resulted in several written requests to have field 658 defined in CIF as well. The requirements for CIF records are the same as those for the bibliographic format users. In most cases, the same thesauri can even be used. A request to validate existing USMARC source codes for use in the CIF for thesauri identified in field 658 should be considered part of this proposal. Although treated as different record types, CIF users consider bibliographic and community information resources to work together in terms of their support for educators. They are still investigating whether there are other bibliographic data elements which they need to use in CIF records. Field 856 The growth of the Internet and the provision of high-tech documentation such as World Wide Web home pages has also led to the need to define field 856 in the CIF. Although electronic location and access information in CIF records does not have the exact same relationship to information in field 245 as field 856 data has to items identified in the bibliographic field 245, the Universal Resource Locator (URL) related electronic access information have become part of community information too. Investigation into the requirements for electronic location and access information in CIF records has revealed the need to record essentially the same pieces of information as is done in records for bibliographic items. Even though some field 856 data elements appear to be slightly redundant (for example, the CIF already uses field 307 (Hours) which could be confused with the use of subfield $v (Hours access method available) in field 856), there seems to be justification for defining all field 856 data elements in the CIF. New Across-Format Adoption Procedure For the moment, with the exception of the new data element described in proposal 96-05 (Enhancements to field 007 in the Community Information Format), no additional data elements are needed in the CIF. It is likely, however, that other data elements from the Bibliographic format will be needed in the future. Bibliographic field 655 (Index TermþGenre/Form) could easily be the next data element needed if in the future CIF users wish to record genre/form terms applicable to events, programs, and services. In light of that and similar possibilities, it would be useful to simplify the adoption process. The process of preliminary discussion, consensus building, and approval of MARC Advisory Group proposals for entirely new data elements is very valuable. During this process various options are considered for meeting the needs of USMARC format users. The optimum "MARC" technique for dealing with data encoding requirements is found and the result is often a new USMARC data element. New data elements are then implemented in thousands of systems. A procedure to simplify the processing of "adoption" changes with respect for existing data elements would be very limited. It would only apply to cases where a data element could be "adopted" by a different format with out changes to the tag, indicators, subfield codes, or other encoding-related aspects. Any changes to these (such as the addition of a new subfield) would require the normal MARC Advisory Group process. "Adopted" data elements would still be required to be published in an update to the affected format(s) before being implemented; that is, implementation would still be government by the usual process of a 90-day period after official notice before implementation and use by anyone. The avantages of this are twofold. MARC Advisory Group would be spared the time-consuming and mechanical process of approving data element adoptions between the growing family of USMARC formats. Secondly, the definition of existing data elements in other formats would be delayed only by the publication schedule of format updates and official notices of change. 3. PROPOSED CHANGES The following is presented for consideration: -- Define field 658 (Index TermþCurriculum Objective) in the USMARC Format for Community Information exactly as it is defined in the USMARC Format for Bibliographic Data. Also validate USMARC codes defined for use in the Bibliographic format for use in the CIF. 3. PROPOSED CHANGES (continued) -- Define field 856 (Electronic Location and Access) in the USMARC Format for Community Information exactly as it is defined in the USMARC Format for Bibliographic Data. -- Establish the principle to be used in maintaining the USMARC formats whereby the definition of an existing USMARC data element in a different format can be done with notification and not require a discussion paper or proposal, providing the data element is not changed in anyway from the way it is defined in the format from which it is taken and no other negative impact would result.