Coronita

Announcement
htld


Selene

Announcement


Malete

DownLoad
Status
OverView
Usage
Structures
Protocol
Query
MultiProcess


formats

FileFormats
character sets
... and converting
CDS/ISIS
IIF/ISO2709


misc

changes from earlier versions
tag numbers


drafts (partly obsolete)

MetaData
object model
Tcl
IIF
IIF, MARC and Z39.50

IIF is the "Information Interchange Format", a record serialization format specified in ISO standard 2709, also published as ANSI Z39.2. IIF is mostly a plaintext format, in that almost any information is encoded using ASCII characters (no binary numbers) and the only control characters used are byte values 29 (record terminator RT), 30 (field terminator FT) and 31 (as subfield delimiter).

MARC ("MAchine Readable Catalogue") is actually a family of largely incompatible standards ( USMARC , UNIMARC , UKMARC, ...) that evolved from MARC I (1965). While the main concern of the MARC standards is to specify actual data models (assigning tags and subfield codes, which can be used perfectly well in Malete, CDS/ISIS or other databases), they also specify a variant of IIF as suggested common format for data exchange, which we here refer to as "MARC". (This file syntax seems to be mostly the same for all MARC standards).

Z39.50 is a network protocol to search and retrieve records. It supports various query "languages", the most commonly used of which is called Type-1 query. Type-1 is similar to the queries as supported by Malete and CDS/ISIS, however, much more general and complex. Terms can be searched for in any indexed field or with restriction to one or more "attributes".
Attributes are basically the tags used in the index, which are almost always different from those used in records. While it is common for records to use any of the various MARCs or even completely different formats, the attributes used in bibliographical systems are typically those specified by the Bib-1 attribute set (e.g. assigning 4 to title).

Z39.50 allows a client to select a record format from various conversions supported by a server. When a MARC format is selected, the data is actually transmitted serialized according to IIF.

IIF and MARC serialized records

IIF specifies a serialization for records. Like the Malete record data file, an IIF file is simply a stream of such records; there is no additional file header.
A record has
  • a 24 byte leader, containing 16 bytes structural data and 8 bytes application data (x, imported as "MARC leader"). The format for MARC is LLLLLxxxxx22BBBBBxxx4500. The Ls and Bs are total record length (including leader and a terminating RT) and start of data (field values, after an FT terminating the dictionary). The first '2' denotes that every field starts with two indicator bytes, the second is the subfield identifier length including the delimiter char.
  • a "dictionary" array with one entry per field containing 3 bytes tag, and n and m bytes for length and offset. n and m are digits at leader offset 20 and 21, MARC uses 4 and 5. In general IIF, leader byte 22 may specify a number of implementation defined entry bytes.
  • the actual field values, each terminated by the FT character.

As opposed to folklore, MARC does NOT use a '$' as subfield delimiter, nor a '#' for unused indicators. Rather, the examples in the specs use a '$' to REPRESENT the subfield delimiter control character 31 (^_), and a '#' to REPRESENT a blank. The RT(29, ^]) is sometimes represented as '\' and the FT(30, ^^) as '^' or '@'.

Malete IIF import and export

The malete tool provides two rather simplistic commands iifimp and iifexp.
The command specific options are:
  • Ffile
    specify full filename for the IIF files. Default is the basename of the Malete database with extension .iif. On UNIX, a filename '-' selects stdin/out.
  • Nomarc (literally)
    do not assume the MARC structure 22/450 on import. Requires proper IIF data.
  • P[iic]
    on export, prepend indicators ii and, where needed, subfield c. A single -P uses two blanks as indicators and subfield '0'. Suggested to produce at least syntactically correct MARC.
  • Rid (literally)
    on import, use a numeric control number (1st field, if it has tag 1) as record id. Note that on export, the record id is always used as control number unless the record already has one, since this is specified as a must not only by MARC, but by IIF.

creating proper IIF from WinIsis

In Database-Export, set the subfield separator to \031 and output line length to 0.
If the fields do not contain valid MARC data, use a reformatting FST like
001 0 MFN
044 0 |00^a|,v44
024 0 |00^a|,v24
026 0 |00|,v26
070 0 (|00^a|,v70/)
Make sure, that
  • the first output field is tag 1 containing some unique id
  • every field (other than tagged 00*) starts with two indicator characters (really should be blank, but that would be stripped during export)
  • the indicators are followed by a delimiter and subfield identifier
Still the output is not 100% correct, since WinIsis sets number of indicators and identifier length to 0, where MARC specifies 2. However, many other MARC processors, including zebraidx, ignore these settings.

making MARC data available via Z39.50

MARC records can be made easily available using indexdata's zebra.
If records in your IIF file use tags and subfields conforming to, say, USmarc, simply check out the test/usmarc example in the zebra distribution. Put your data in the records subdir and run "zebraidx update records; zebrasrv".
If your data was exported from WinIsis, you may want to put a line "encoding Cp850" in the .abs file.

You must use recordType: grs.marc.something, meaning that it's general structured data in some marc file format. The sample usmarc.abs uses the "marc usmarc.mar" statement, and usmarc.mar (in the zebra/tab directory) contains "reference USmarc", stating that the marc input actually IS in USmarc. This need not be the truth, it just means that the records will be served as is, if a client asks for USmarc. However, only the tags listed in "elm" statements in the .abs files will be indexed.

Note that zebra's indexing support is not as flexible as that of CDS/ISIS: you can only select fields or subfields to be indexed in one of a couple of modes (like word or phrase). To take full advantage of sophisticated CDS/ISIS FSTs, include them in your export reformatting FST. Use some otherwise unused field tags to hold the index terms and "elm" statements to map them to bib-1 attributes. Omit those fields from the display mapping.

To keep the data in its native format (say CDS), change the elm statements to map the fields to index to the corresponding bib-1 attributes for searching, e.g. "elm 024 Conference-name !", and, instead of using the "marc usmarc.mar" statement, create one or more maptabs to map the full record to one or more USmarc a/o other presentation formats as applicable. Check out the gils-usmarc.map example in the zebra/tab directory.

Consult the zebra documentation for details.

links


$Id: IIF.txt,v 1.6 2005/05/24 16:44:06 kripke Exp $