home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD2.mdf / doc / mir / marc_rec < prev    next >
Encoding:
Text File  |  1992-05-23  |  5.7 KB  |  182 lines
  1.  
  2.  
  3.             MARC FORMAT RECORDS
  4.             ===================
  5.  
  6.                                         Prepared by Doug Lowry
  7.                                         June 13, 1986
  8.  
  9.  
  10. OBJECTIVE:
  11. =========
  12.  
  13.     To examine the structure of MARC format records with a
  14.     view to writing a preprocessor which will create standard
  15.     format records from MARC records.
  16.  
  17.  
  18. LIMITATIONS:
  19. ===========
  20.  
  21.     What follows is not an exhaustive study.  Harvey Martens
  22.     has done a preliminary analysis.  I have carried it a few
  23.     steps further, aided by discussion with Michael xxxxxx of
  24.     the National Research Council (613 xxx-xxxx) on June 12.
  25.  
  26.  
  27. BASIC RECORD STRUCTURE:
  28. ======================
  29.  
  30.     MARC records occur in blocks.  Each block is preceded by a
  31.     4 byte value; the first two bytes are the high and low order
  32.     bytes respectively of the length of the block.  The next two
  33.     bytes are each null.  For example, octal values
  34.  
  35.             026  270  000  000
  36.  
  37.     indicate a block length of 5816 bytes.  (It is not
  38.     yet clear whether this count includes or excludes the
  39.     four bytes for the block length.)
  40.  
  41.     An individual MARC record consists of these components:
  42.  
  43.         1.  A 4 byte record length indicator
  44.         2.  A 24 byte leader
  45.         3.  A record directory or entries map
  46.         4.  Control fields and variable fields
  47.         5.  A group separator character
  48.  
  49.  
  50. RECORD LENGTH INDICATOR:
  51. =======================
  52.  
  53.     Each MARC record is preceded by 4 bytes... the high order
  54.     byte and the low order byte respectively of the record
  55.     length in bytes, then two null bytes.  For example, octal
  56.  
  57.             001  366  000  000
  58.  
  59.     indicate a record length of 502 bytes. This count 
  60.     includes the four byte indicator.
  61.  
  62.  
  63. RECORD LEADER:
  64. =============
  65.  
  66.     24 bytes as follows:
  67.  
  68.     1...5   ASCII record length in bytes, EXCLUDING the four byte
  69.         record length indicator above.
  70.  
  71.     6   Record status letter (N= new, C= correction,
  72.         D= deletion, ...)
  73.  
  74.     7   Type (codes not currently known)
  75.  
  76.     8   Bibliographic category (A= analytic, M= monograph,
  77.         S= serial, ...)
  78.  
  79.     11  Indicator count (uncertain... not immediately relevant)
  80.  
  81.     13...17 Seems to be an ASCII count of the number of bytes in
  82.         the following directory entries map.
  83.  
  84.     18...24 Uncertain
  85.  
  86.  
  87. RECORD DIRECTORY:
  88. ================
  89.  
  90.     A record directory consists of a series of ASCII numeric
  91.     values:
  92.  
  93.         3 byte field number
  94.         4 byte inclusive length of field in bytes
  95.         5 byte offset in bytes from beginning of field data
  96.  
  97.     The field numbers in the examples examined so far appear in
  98.     numeric order within the directory. A field number may occur
  99.     more than once. The location of the data appears in near
  100.     random order (possibly the order in which fields were added).
  101.     Note the offsets in the following real example:
  102.  
  103.            Field           Length          Offset
  104.         008     0039        00000
  105.         009     0032        00284
  106.         022     0025        00134
  107.         035     0030        00104
  108.         088     0007        00229
  109.         089     0036        00236
  110.         090     0012        00272
  111.         100     0014        00159
  112.         245     0041        00063
  113.         260     0008        00039
  114.         260     0008        00047
  115.         300     0008        00055
  116.         410     0056        00173
  117.          RS
  118.  
  119.     A close examination of the directory shows that it is
  120.     arithmetically coherent. For example, at offset 00000
  121.     above, there is something 39 bytes long. Sure enough,
  122.     the next lowest offset is 00039. There are 8 bytes in
  123.     that field, and the next offset is 00047, etc.
  124.  
  125.     A directory is terminated by an "RS" or record separator
  126.     byte (octal 036).
  127.  
  128.  
  129. FIELD CONTENTS:
  130. ==============
  131.  
  132.     Fields are of two types...
  133.  
  134.         control fields, numbered 001...009
  135.  
  136.         variable fields, numbered 010...999
  137.  
  138.     Control fields are fixed format and specialized.  For
  139.     now, control fields other than 009 can be ignored.
  140.     Field 008 is usually present, but its contents are
  141.     duplicated in 009. We will treat 009 as if it were a
  142.     variable field, except that non-printing characters
  143.     should be replaced by white space.
  144.  
  145.     Variable fields are essentially free text. Sub fields
  146.     may exist within a field. For now, we can indicate new
  147.     sub fields by replacing the separators by a newline
  148.     symbol in the compressed text.
  149.  
  150.     All fields (except the first) and all sub fields begin
  151.     with a "US" (unit separator, octal 037) followed by a
  152.     single lower case character. The significance of
  153.     different characters is not yet known. We do know that
  154.     it is safe to collapse out the "US" byte and the following
  155.     byte as white space for preprocessing, and to replace them
  156.     by a newline for creating compressed text.
  157.  
  158.     All fields end with an "RS" 036 record separator.
  159.  
  160.  
  161. END OF RECORD:
  162. =============
  163.  
  164.     Records are terminated by a single "GS"  byte (group
  165.     separator, octal 035).
  166.  
  167.  
  168. ADDITIONAL NOTES:
  169. ================
  170.  
  171.     Consistent order within records would be reasonably assured
  172.     if we extract data in field number order per the directory
  173.     rather than by actual occurrence within the record.  For
  174.     preprocessing, this would mean that at least the full record
  175.     would be needed in RAM before preprocessing it.
  176.  
  177.     The list of variable field names may be extracted from
  178.     "Composite MARC Format", a tabular listing which has been
  179.     ordered. Individual organizations may utilize unnamed
  180.     fields; until they provide the names, a name such as
  181.     "Field 089" could be used.
  182.