Archive USMARC, file 93-4.doc. Part 1/1, total size 50918 bytes: PROPOSAL NO: 93-4 DATE: November 20, 1992 PROPOSAL NO. 93-4 Changes to the USMARC Bibliographic Format for Computer Files to Accommodate Online Information Resources NAME: Changes to the USMARC Bibliographic Format (Computer Files) to Accommodate Online Information Resources SOURCE: OCLC Internet Resources Project and Library of Congress SUMMARY: This proposal attempts to accommodate one category of online information resources in the USMARC format for computer files, electronic data resources (software, electronic text and data files, bibliographic databases, etc.). It proposes the following: 1) adding four codes to 008/26 (Type of computer file and changing the definition of two; 2) broadening the use of field 256 (File Characteristics) to include more specific descriptors; 3) making field 516 (Type of File or Data Note) obsolete; and 4) adding a new field 856 to the Holdings/Bibliographic formats for electronic location and access information. It does not cover online systems and services (e.g. campus wide information systems, Telnet sites, bulletin boards, etc.), although some data elements may be applicable to those. KEYWORDS: Field 008/26 (Computer files); Field 256; Field 516; Field 856 (Holdings/Bibliographic); Type of Computer File; File Characteristics; Type of File or Data Note; Electronic Locations (Holdings/Bibliographic) 1. INTRODUCTION As librarians and other information professionals work in increasingly networked environments, the explosion of electronic information has become harder and harder to control. Many different types of online information resources are available to users over one or more networks, and it is highly desirable to provide bibliographic control to this wealth of information. Several projects are being pursued to create directories of these resources. To provide USMARC catalog records for online information resources and to share them between systems is a desirable goal. The USMARC Advisory Group has explored the topic of accommodating online information resources in two previous discussion papers. Discussion Paper No. 49 (Dictionary of Data Elements for Online Information Resources), discussed in June 1991, presented the data elements needed for online information resources and gave a tentative mapping to USMARC bibliographic fields. Participants agreed that USMARC should be expanded to accommodate description and access of machines as resources on the network as well as data files on the machines, and that further work on the data elements and USMARC mapping needed to be done. Discussion Paper No. 54 (Providing Access to Online Information Resources) introduced questions of scope and the use of fields in the USMARC Holdings Format and the new Community Information Format (provisionally approved during Midwinter 1992 ALA). It was agreed that electronic data resources might be more amenable than online systems and services to bibliographic description using AACR2 computer files cataloging rules and the USMARC bibliographic format as they now exist, and that more work needs to be done to accommodate online systems and services. Examples of those falling into the category of electronic data resources are: electronic text, software, data files, bibliographic databases, electronic graphics files. Examples of online systems and services are: FTP sites, Telnet sites, listservs, bulletin boards, campuswide information systems. (Some types of resources may not clearly belong in one or the other category, but have features of both.) As part of its Internet Resources Project, OCLC has been investigating the nature of electronic information available via the Internet. It hosted a meeting in April 1992 with representatives from OCLC, Online Audiovisual catalogers (OLAC), Library of Congress, and MARBI (referred to here as the Internet Resources Cataloging Experiment Advisory Committee) to review work on the project, examine sample documents collected, and plan a cataloging experiment of Internet resources. The experiment was intended to test and verify the applicability of the cataloging rules and the USMARC format for computer files, and provide sufficient data to determine what changes need to be made to AACR2 and USMARC to accommodate these materials. The cataloging experiment was held during May and June 1992 and involved the cataloging of 300 computer files collected from Internet sites, half of which were all types of electronic texts, and the other half randomly-selected text, software and data. Each file was cataloged by three different catalogers. After a call for participation was issued and distributed electronically via the Internet, a group of catalogers was selected to participate and given instructions for cataloging. The catalogers were requested to keep a log file for each item cataloged to record problems or comments as well as the amount of time it took them to catalog the items. Results of the experiment indicate that the USMARC format generally accommodates the description of Internet resources, but that clear guidelines need to be developed to assist catalogers. These guidelines are needed both for AACR2 cataloging rules and the USMARC format. Particular problem areas identified in the experiment were: need for more codes in 008/26 (Type of computer file); guidelines for the appropriate and consistent use of note fields; need for more specific descriptors of the type of file or resource; definitions for what constitutes a published item (which can be questionable when considering data resources on the Internet); specifications for including location and access information to find and retrieve the item. This proposal attempts to compensate for these deficiencies in the USMARC bibliographic format, computer files specifications. It is intended to accommodate those types of resources previously described as "electronic data resources". Of particular interest is the electronic journal or newletter, because of the phenomenal increase in the number being issued. Although some of the data elements (particularly those for location and access) may be applicable to the second category of "online systems and services", the latter will be more fully covered at a later date. II. Types of computer files The cataloging experiment and OCLC's exploration of Internet resources revealed that the list of computer file types in 008/26 did not cover all that were needed to make this data element useful. The relationship between 008/26, 256 (File Characteristics) and 516 (Type of File or Data Note) was explored by the Internet Resources Cataloging Experiment Advisory Committee to determine solutions. It was decided that several steps need to be taken to adequately describe types of computer files and make this information useful for identification and retrieval. A. Add four codes to 008/26. The cataloging experiment revealed that in many cases where the catalogers were unsure how to code in this character position, they used either combined (m) or Other (z). Since users may wish to retrieve on this code, more specific codes are needed. However, the group felt that a fairly short list of types should be available here, with more specificity elsewhere in the record. Those types that are not adequately described by the current list in 008/26 have been identified as: bibliographic data, font, game and sounds. With the exception of bibliographic data, these types of computer files would most likely all be coded now as either program or combination. In the case of bibliographic data, this is intended to satisfy the need to describe bibliographic data, particularly for library catalogs; none of the available codes are appropriate. It was felt that it would be more useful to tell the user up front if a file was one of these types, since it may be desirable to limit searches more effectively, that these are very specific types of resources with specific uses and requirements, and that they are of special interest to libraries. Since more than one of the codes may be applicable for an item, guidelines for coding should specify to code for the most specific code available. For instance, games are computer programs, but the Committee chose to identify them separately, because they are used for a specific purpose. Users who may wish to retrieve games would want only games, and not have to sift through other programs. The 008/26 field is used for retrieval of specific types of computer files, and those with a specific code of particular interest to libraries. B. Change the definitions for three codes. It was felt that in the current electronic world, the term "graphic" would better describe what USMARC has used as "representational" (code c). In addition, the word "text" is confusing because many electronic files include text (instructions for software, etc.). The term "document" would limit the use of this code to textual material that is intended to constitute a document, whether represented as ASCII or image data. The intent of the file (as document, rather than graphic) should be expressed in the code. In addition, it is proposed that "numeric" be changed to "numeric data", so that it parallels the use of the new code "bibliographic data". C. Broaden the type descriptors in field 256. According to current cataloging rules and practice, field 256 (File Characteristics) is used as a collation field for computer files and includes a statement of the type of file. However, only "computer data", "computer program" or "computer data and program" has been used in this field (followed by additional file characteristics), limiting its usefulness in description of a type of file. The Committee agreed that the statement of type in this field should include the specific type, which has generally been recorded in field 516 (Type of File or Data Note). A list of descriptors should be included in the field as guidance to users, although this should not be a closed list. Currently, AACR2 specifies using two types in this field (currently data and programs), and this practice could be continued with two types of more specific descriptors. Field 256 also includes file size. However, in cases where file size is dependent on how the file has been stored (e.g., in a compressed form or not), different file sizes recorded in field 256 could force separate records for the different files. Consequently, the Committee decided that information on file size should be included in the new electronic location field (see below). It is important to remember that the purpose of field 256 is identification, not access. The group felt that the limitation to data and/or program in this field limits its usefulness for identification purposes, and that an expansion of the descriptors would be useful. A nature and scope note (field 500) or abstract (field 520) may be used for more specific description of the resource than this field provides. Access to descriptors of the resource is provided in the 65X fields. Examples of the use of field 256 includes: an item coded as "d" ("document") in 008/26 might include "electronic newsletter" or "electronic book" in field 256; an item coded as "b" ("computer program") in 008/26 might include "executable software" or "source code" in field 256. See Attachment B for examples and comparisons of these two fields. Changes to field 256 require changes to the Anglo-American Cataloging Rules, second edition, so that information other than that identified above can be recorded as File Characteristics. What is being proposed for 008/26 and 256 is being coordinated simultaneously with the ALA Committee for Cataloging: Description and Access (CC:DA) process. D. Make Field 516 obsolete. It is proposed that field 516 be made obsolete. In discussions of this issue, the Committee found that it was difficult to distinguish between 516 data and that which is considered "nature and scope" (as defined in AACR2 rule 9.7B1a), which for all other types of materials is recorded in the general note field 500. Field 516 was not made obsolete with the format integration proposal, because at the time 256 data was limited as described above to "computer data", "computer program", etc., and it was desirable to separately identify the type of file in a specific tag. However, if 256 can be used more broadly, the type of file or data can be separately identified. III. ELECTRONIC LOCATION AND ACCESS Because of the nature of electronic information and its availability, it is necessary to provide information on location and access. An electronic data resource can reside in many directories at any number of hosts in several formats. It might be stored as a compressed file and an uncompressed file with different filenames, yet the end result is the same item. During the initial planning of the OCLC cataloging experiment, participants felt that the capability of machine access to the item should be provided for those items that are self-identifying (i.e., do not require interactive searching). All data elements that a user needs to know to make the connection, locate the document and retrieve it (in the case of files) should be included in the catalog record. In the case of library catalogs or other databases, the information needed to connect should be given, although only site-specific information about the server to which one is connecting (information that everyone would need to know) is included. Information that might be needed about the client (i.e., the system from which the connection is made) is not given, and must be dealt with locally. Data elements should be parsed and transportable between systems and formats. It was felt that location data in the USMARC format properly belongs in a holdings and locations field (85X block), which according to the standard can be embedded in a bibliographic record. The content of this field was developed with Internet resources specifically in mind, as an outgrowth of the OCLC Internet Resources Project cataloging experiment. However, it is expected that the field can be extended to non-Internet resources (e.g., BBS's, dial-up access to Compuserve, etc.). Consideration will be given to online systems and services and a proposal to accommodate these considered in the near future. At that time, non-Internet resources that are found to be of high interest to libraries will be tested. Working groups of the Internet Engineering Task Force have been actively pursuing the establishment of a standardized way of encoding a pointer to a resource for any system (the Universal Resource Locator, or URL) and standardized ways of identifying resources (the Uniform Resource Identifier and Uniform Resource Number--names of these have changed and are current as of November 1992). The Uniform Resource Number is roughly equivalent to an ISBN for a networked resource. The definition of a Uniform Resource Identifier is still under discussion. Once the IETP standards are developed and implemented, it will be necessary to include fields in the USMARC format for some or all of these data elements. The volatility of the electronic location may be a problem if this data is included in a USMARC record. The content designators that follow are being proposed to allow for electronic location and access information to be carried in a USMARC record. At the point when the IETF completes its work in developing a Universal Resource Locator and its implementation is possible, including approporiate links to USMARC systems, this field may no longer be needed. The work of the IETF promises a solution more useful than that being proposed in this paper. However, in the meantime, the data is needed in the USMARC record for electronic resources, even if it is less than a perfect solution. It is expected that the kinds of resources for which USMARC cataloging will be done will likely be less volatile than much of what exists on the Internet as a whole. Content designators. A new field 856 (Electronic Location and Access) could be defined. The following data elements with proposed subfield codes were identified as necessary to provide adequate location and access information for the machine to connect to the host and transfer the file (if appropriate): Indicator 1 - Access method 0 Email 1 FTP 2 Remote login (Telnet) 8 Other The values defined are the main TCP/IP protocols. This indicator defines how the rest of the data in the field will be used. If the resource is available by more than one method, the field is repeated with data appropriate to each method. "Subscribe" (for electronic journals available through Listserv software) would fall under Email. Value 8 is provided and would require the use of a subfield $2 to identify another access method. Given the availability of electronic information through other methods such as WAIS, Gopher, etc. (which currently require using Telnet, but this may change in the future) and whatever else might come in the future, it is desirable to allow for other methods. At this point those listed above will give adequate information for the system to make the machine connection to allow for access to the file. $a - Host name (R) e.g. harvarda.harvard.edu; harvarda.bitnet Includes the Internet address (Fully Qualified Domain Name). For a Bitnet address, use of ".bitnet" could be a convention to identify the network, in case a gateway needs to be added by the computer. This subfield could be repeated if it has an Internet and Bitnet address if all the rest of the information in the field applies. $b - IP address (R) e.g. 141.212.196.79 Because the IP (Internet Protocol) address can change frequently (even within a session), it has been recommended by members of the Internet Engineering Task Force that a field should be provided, but that data should not be statically stored. Rather, it could be generated by the system on demand. $c - Compression information (NR) e.g., Use PKUNZIP to decompress Many files reside on the Internet in compressed form. The compression information is specific to a certain file. The software required to decompress the file could be identified here. Certain file extensions may indicate the type of compression used. This field is not repeatable, since the filename would be different if a different type of compression is used, thus requiring a repeated 856 field. $d - Path (R). e.g. wais/doc; aii/admin/games This subfield is only repeated if the rest of the information in the field (particularly filename) applies to the file as stored in different directories. The path is specific to the operating system specified in $o. $f - Filename (R) e.g. dutils2.sit; stats.c.Z This subfield is used to show the filename on the host machine in the directory stated in $d. If the file is stored with different filenames, it would generally require repetition of the field. However, in the case of having one document divided into two files, it may be repeated, provided the multiple filenames constitute one intellectual item. A wildcard (.*) could be used in this subfield to show that the filename varies for an operating system that allows this. (Then a subfield $z note could explain how files are named.) Filename may be case-sensitive for some systems. $g - Name of publication or conference (NR). e.g. AN2 This may be used when the first indicator is set to 0 (Email) for "subscribe". It is usually the title or a variant of the title in field 245. $h - Processor of request (NR) e.g. listserv, mailserver This includes the username, the data preceding the "@" in a subscription request. $i - Instruction (R) e.g. get; subscribe This would be used with first indicator value 0 (Email). It is an instruction for the remote host to process. $k - Password (NR) e.g. guest Often FTP sites require the user to enter an Internet address. For library catalogs a password may be required. If it does not matter what is entered, the subfield would not be used. This should be used only for general use passwords, not for any requiring security. $l - Logon/login (NR) e.g. anonymous For anonymous FTP, the logon is usually "anonymous". For library catalogs, it may be specific names. Other unique logons will be used for online systems and services (not covered in this proposal, but to be considered later). An account number required for login may also be indicated. As with password, this should be used for general use login, not for any requiring security. $m - Contact person for information, assistance (R) This information might also be included in field 037 (Source of Acquisition after format integration) if at the record level. It is included here if it is applicable only at a particular location. At the time when USMARC deals with online systems and services, other data elements or fields will need to be considered for contact people, addresses, etc. $n - Name of location of host in $a (R) e.g. University of Michigan This is the textual form of the name of host that appears in subfield $a and identifies it geographically. $o - Operating system (NR) e.g. VM, Unix For informational purposes operating system for the host name specified in $a is indicated here. Conventions for path and filenames may be dependent on the operating system. For operating system required at the record level rather than at a particular location, field 753 (Technical Details Access to Computer Files), subfield $c (Operating system) is used. $p - Port (NR) e.g. 3000 (used with madlab.sprl.umich.edu) There are some cases where a port needs to be specified to make a connection. $q - File Mode (NR) e.g. binary, ascII, tenex. This is essential information for transferring a file. It is non-repeatable, because if more than one apply, separate 856 fields would be required to include different filenames (and perhaps directories). Perhaps ASCII should be the default, and this subfield used if another needs to be specified, e.g. binary. $s - File Size (R) e.g. 88916 bytes. File size is given for informational purposes, since it is related to the size of the file as it is stored under the filename identified in subfield $f at the location in subfield $a. Since files may be stored in a compressed format, file size may vary, although the record may represent only one intellectual item. It was considered desirable not to force a separate record when file size varies; instead of recording it in field 256 (File Characteristics), it would be related to the filename in field 856. $t - Terminal emulation (R) e.g. vt100, 3270 This is used when the type of terminal emulation must be specified for remote login (value 2 in first indicator). $x - Non-public note (R) e.g., cannot verify compression information This might be reserved for non-public notes, perhaps for processing purposes. $z - Public note (R) This could be used for general instructions for use. Also included could be connection information in textual form (e.g., special logoff instructions). $2 - Source of access (R) If the source shown in Indicator 1 is "Other", this subfield could be defined to specify. It may be desirable to control this list at some point. Guidelines. Field 856 is a holdings/bibliographic field pertaining to a particular location of an item. For description of the universal item (that which applies to the item regardless of location and copy) the bibliographic fields are used. For instance, in the case of electronic data resources, technical requirements for using the resource will be recorded in field 538 (Technical Details Note) if it applies to the universal item regardless of the way the file has been stored at a particular location. Computer files may be compressed with a different filename than the uncompressed file, and both may be available at the same (or different) locations. In this case two 856 fields would be given with different filenames. Also possible might be a case where the document is broken into multiple files. Often this is done because some systems cannot handle the transfer of very lengthy files. In this case, there is a single intellectual work with different filenames, all at the same location. This document may be at two locations, one which stores it as a single file, and the other as multiple files. One 856 field is given for each location, with repeatable subfields $f (this is the only case where multiple filenames do not require a separate 856 field). The value in the first indicator often determines which subfields might be used. For instance, an electronic journal which uses electronic mail for subscriptions might require the use of (among others) subfields $g (Name of publication or conference), $h (Processor of request), and $i (Instruction). A file available through FTP may require the use of (among others) subfields $c (Compression information), $d (Path), $f (Filename), $k (Password), $l (Logon), $q (File mode), $s (File size). A library catalog record might require the use of (among others) subfields $k (Password), $l (Logon), $m (Contact person), $t (Terminal emulation). IV. Format Integration Considerations. This proposal assumes format integration as detailed in the document Format Integration and its Effect on the USMARC Bibliographic Format. Leader/06 would be coded for form aspects and not control aspects, with Leader/07 indicating control aspects. Thus, an electronic journal would be coded as a computer file in Leader/07, with its seriality indicated in Leader/07. Its 008 would reflect its existence as a computer file, and field 006 is used for seriality aspects, as defined in the format integration document. See also Proposal No. 93-1 (Make Computer Files 008/18-19 Obsolete in the Bibliographic Format). V. PROPOSED CHANGE The following is presented for consideration: - In the USMARC Bibliographic Format, add the following codes in 008/26: e bibliographic data f font g game h sounds Change the definition of the following codes: a numeric data (currently numeric) c graphic (currently representational) d document (currently text) See Attachment A for description of this field if this proposal is approved. - In the USMARC Bibliographic Format, in field 256 (File Characteristics) allow for specific descriptors to be used, with a list of examples. - Make field 516 (Type of File or Data Note) in the USMARC Bibliographic Format obsolete. See Attachment B for a comparison of terms in fields 008/26 and 256. - In the USMARC Holdings/Bibliographic Formats, define field 856 (Electronic Location and Access). See Attachment C for a description of this field if this proposal is approved. See Attachment D for examples. ATTACHMENT A Note: [ ] indicates deletion; < > indicates addition. Format/NLR BK AM CF MP MU VM SE 008/26 TYPE OF COMPUTER FILE M Codes a Numeric A b Computer programs A c [Representational] A d [Text] A m Combination A u Unknown A z Other A CHARACTER POSITION DEFINITION AND SCOPE A one-character alphabetic code indicates the type of computer file being described. The type of file is also described in textual form in field <256 (File Characteristics)> [516 (Type of File or Data Note)]. ----------------------------------------------------------------- GUIDELINES FOR APPLYING CONTENT DESIGNATORS CODES a - Numeric Code a indicates a file that contains mostly numbers or representation by numbers, such as records containing all information on student test scores, all information on football team statistics, etc. The information may be original surveys and/or information that has been summarized or statistically manipulated. 008/26 a [516] <256> $aNumeric [(Summary statistics)] <500 $a Summary statistics> b - Computer program Code b indicates a file containing an ordered set of instructions directing the computer to perform basic operations and identifying the information and mechanisms required. This category includes [videogame and] microcomputer software and computer models. 008/26 b [516] <256> $aComputer programs c - [Representational] Code c indicates a file that contains pictorial or graphic information that can be manipulated in conjunction with other types of files to produce graphic patterns that can be used to interpret and give meaning to the information. It does not include a document in image format. 008/26 c [516] <256> $aGraphic [data (Architectural drawings)] [500 $a Architectural drawings d - [Text] Code d indicates a file that contains mostly alphabetic information (words or sentences) converted into a coded format that can be processed, sorted, and manipulated by machine, and then retrieved in many optional formats. This category includes such information as [bibliographic files and] records containing full text of documents. 008/26 d [516] <256> $a Text [(Law reports and digests)] <500 $a Law reports and digests> h - Sounds Code h indicates that the file contains actual sounds produced by the computer. These are binary files of digitally sampled sounds which require specialized hardware to convert the digital signal to analog. m - Combination Code m is used when the item is a combination of two or more of the above types of files. 008/26 m [516] <256> $aComputer programs and text files u - Unknown Code u indicates that the type of file is unknown. 008/26 u z - Other Code z indicates a type of file for which none of the other defined codes are appropriate. [008/26 z 516 $Audio data (Digital audio file)] <008/26 z 256 Nonbibliographic database> ------------------------------------------------------------------- RELATED USMARC DOCUMENT/FIELD <256 File Characteristics> [[516] Type of File or Data Note] ATTACHMENT B Examples of descriptors used in 008/26 and 256 008/26 256 a numeric data census data survey data b computer program utility program executable software source code c graphic (change graphic from representational) d document electronic document electronic journal electronic newsletter electronic text e bibliographic data library catalog citation database bibliographic database f font computer font g game computer game h sounds computer sounds m combination computer data and programs -or- combine any terms used in 256, e.g.: computer font and text ATTACHMENT C 856 ELECTRONIC LOCATION AND ACCESS Indicators First Access method 0 Email 1 FTP 2 Remote login (Telnet) 8 Other Second Undefined # Undefined Subfield Codes $a - Host name (R) $b - IP address (NR) $c - Compression information (NR) $d - Path (R) $f - Filename (R) $g - Name of publication or conference (NR) $h - Processor of request (NR) $i - Instruction (R) $k - Password (NR) $l - Logon/login (NR) $m - Contact person for information, assistance (R) $n - Name of location of host in $a (NR) $p - Port (NR) $q - File mode (NR) $s - File size (R) $t - Terminal emulation (R) $x - Non-public note (R) $z - Public note (R) $2 - Source of access (NR) ------------------------------------------------------------------ FIELD DEFINITION AND SCOPE This field contains the information required to locate an electronic item. The information identifies the electronic location containing the item or from which it is available. It also contains information to retrieve the item by the access method identified in the first indicator. The information contained in this field is sufficient to allow for the electronic transfer of a file, subscription to an electronic journal, or logon to a library catalog. Field 856 is repeated when the location data elements vary (subfields $a, $b, $d) and when more than one access method may be used. It is also repeated whenever the filenames vary, except for the situation when a single intellectual item is divided into different parts for online storage or retrieval. GUIDELINES FOR APPLYING CONTENT DESIGNATORS INDICATORS First Indicator - Access method The first indicator position contains a value that defines how the rest of the data in the field will be used. If the resource is available by more than one method, the field is repeated with data appropriate to each method. The methods defined are the main TCP/IP protocols. 0 - Email Value 0 indicates that access to the electronic resource is through email. This includes subscribing to an electronic journal or electronic forum through software intended to be used by an email system. 1 - FTP (File Transfer Protocol) Value 1 indicates that access to the electronic resource is through the File Transfer Protocol (FTP). Additional information in subfields of the record may enable the user to transfer the resource electronically. 2 - Remote login (Telnet) Value 2 indicates that access to the electronic resource is through remote login (Telnet). Additional information in subfields of the record may enable the user to connect to the resource electronically. 8 - Other Value 8 indicates that access to the electronic resource is through a method other than the defined values. The specific access method is specified in subfield $2 (Source of access). Second Indicator - Undefined The second indicator position is undefined and contains a blank (#). SUBFIELD CODES $a - Host name Subfield $a contains the host name of the electronic location. It contains a network address which is repeated if there is more than one address for the same host. 856 1 $a harvarda.harvard.edu $a harvarda.bitnet $b - IP address Subfield $b contains the Internet Protocol (IP) numeric address associated with a host. This data changes frequently and should be generated by the system, rather than statically stored. 856 2 $a anthrax.micro.umn.edu $b 128.101.95.23 $c - Compression information Subfield $c contains information about the compression of a file. If a specific program is required to decompress the file, it is noted here. The filename in $f may indicate the type of compression by its extension (portion after the "." or first space). 856 1 $a maine.maine.edu $c Must be decompressed with PKUNZIP $f resource.zip $d - Path Subfield $d contains the path with directory names where the file is stored. Directories are separated by slashes (/). This information is specific to the operating system indicated in subfield $o. 856 1 $a wuarchive.wustl.edu $d /aii/admin/CAT.games $f mac-qubic.22.hqx $f - Filename Subfield $f contains the filename as it exists in the directory indicated in $d, on the host machine in $a. It may be repeated only if a single logical file has been divided into parts and stored under different names, but that together constitute a single intellectual item. In all other cases, A file that may be retrieved under different filenames contains two 856 fields in the record, each with a different $f. A filename may include wildcard characters (*) if applicable (with a subfield $z note explaining how files are named). A filename may be case sensitive for some systems. 856 1 $a wuarchive.wustl.edu $d mirrors/info-mac/util $f color-system-icons.hqx 856 0 $a kentvm.bitnet $f acadlist file1 $f acadlist file2 $f acadlist file3 $g - Name of publication or conference Subfield $g contains the name of the electronic publication or conference. 856 0 $a uicvm.bitnet $g ALCTS $h - Processor of request Subfield $h contains the username, or processor of the request, generally the data which precedes the "@" in the host address. 856 0 $a uicvm.bitnet $g ALCTS $h Listserv $i - Instruction Subfield $i contains an instruction or command needed for the remote host to process a request. 856 0 $a uccvma.bitnet $g IR-L $h Listserv $i subscribe $k - Password Subfield $k contains the password required to access the resource. An FTP site may require the user to enter an Internet address or may require a specific password, or a library catalog may require a password. If a password is required but anything may be used, this subfield need not be used. This should be used for general use passwords, not for any requiring security. 856 1 $a harvarda.harvard.edu $k guest $l - Logon/login Subfield $l contains characters needed to logon to a library catalog or FTP site. Often with anonymous file transfer the logon is "anonymous". An account number required for login may also be indicated. This should be used for general use logins, not for any requiring security. 856 1 $a unmvm.bitnet $l anonymous $m - Contact person for information, assistance Subfield $m contains the name of a contact person for the resource at the host specified in $a. 856 2 $a gopac.berkeley.edu $m Roy Tennant $n - Name of location of host in $a Subfield $n contains the full name of the location of the host in $a. 856 2 $a pucc.princeton.edu $n Princeton University $o - Operating system For informational purposes operating system for the host name specified in $a is indicated here. Conventions for path and filenames may be dependent on the operating system. For operating system required at the record level rather than at a particular location, field 753 (Technical Details Access to Computer Files), subfield $c (Operating system) is used. 856 1 $a seq1.loc.gov $ /pub/soviet.archive $n Library of Congress $o UNIX $p - Port Subfield $p contains the portion of the address that identifies a process or service in the host. 856 2 $a madlab.sprl.umich.edu $n University of Michigan Weather Underground $p 3000 $q - File mode Subfield $q contains the file mode, which determines how it is transferred through the network. A normal ASCII file contains certain characters which are translated between systems to make the text files more readable. A file with non-ASCII characters must be transferred using another file mode. 856 1 $a archive.cis.ohio-state.edu $d pub/comp.sources.Unix/volume 10 $f comobj.lisp.10.Z $q binary $s - File size Subfield $s contains the size of the file as stored under the filename indicated in subfield $f. It is generally expressed in terms of bytes. It may be repeated in cases where the filename is repeated, and is recorded directly following the subfield $f to which it applies. This information would not be given for an electronic journal, since one would not indicate size of particular issues. 856 1 $a wuarchive.wustl.edu $d mirrors/info-mac/util $f color-system-icons.hqx $s 16874 bytes 856 0 $a kentvm.bitnet $f acadlist file1 $s 34,989 bytes $f acadlist file2 $s 32,876 bytes $f acadlist file3 $s 23,987 bytes $t - Terminal emulation Subfield $t contains the terminal emulation supported when necessary to specify for remote login (first indicator contains value 2 (Remote login (Telnet)). 856 2 $a maine.maine.edu $n University of Maine $t 3270 $x - Non-public note Subfield $x contains a note relating to the electronic location of the resource identified in the field. The note is written in a form that is not adequate for public display, or contains processing information about the file at the location specified. 856 1 $a wuarchive.wustl.edu $c decompress with PKUNZIP.exe $d /mirrors2/win3/games $f atmoids.zip $x cannot verify because of transfer difficulty $z - Public note Subfield $z contains a note relating to the electronic location of the resource identified in the field. The note is written in a form that is adequate for public display. $2 - Source of access (NR) Subfield $2 contains the source of access when the first indicator value is set to 8 (Other). This may include access methods other than the three main TCP/IP protocols specified in the first indicator. ATTACHMENT D EXAMPLES 1. An electronic newsletter. To subscribe you have to send email to Christian Bossonious at Cornell (cri@cornellc.cit.cornell.edu). 008/26 d 256 electronic newletter 856 0 $a cornellc.cit.cornell.edu $g ACQNET $h cri $i subscribe $m Christian Bossonious $n Cornell University, Ithaca, NY $z Must send subscription request via email. 2. A text document available for ftp. 008/26 d 256 electronic document (1 file) 856 1 $a um.cc.umich.edu $d /easi $f ADA.FACTS.1 $s 47,380 bytes $n University of Michigan 3. A file available from the USMARC-L listserv. Available by sending an email request to the list, specifying the file desired. 008/26 d 256 electronic document (1 file) 856 0 $a maine.maine.edu $f DP54 doc $s 31,021 bytes $h listserv $i get $m Marilyn Lutz $n University of Maine 4. A computer game, which is available by FTP and must be transferred in binary mode. 008/26 g 256 computer game (1 file) 856 1 $a wuarchive.wust1.edu $d /mirrors3/archive.umich.edu/atari/games $f monopoly.arc $s 83,694 bytes $q binary 5. A library catalog, available by remote login. (Title of resource is GLADIS.) 008/26 e 256 library catalog 856 2 $a gopac.berkeley.edu $m Roy Tennant, rtennant@library.berkeley.edu $n UC Berkeley Online Catalog $z No password required for access $z Information present for signing on/off