CONFIGURATION FILE CONTENTS

Configuration File Tags for the Main File Definition

Tags for the Main File Definition (Continued)

Tags for the Index File Definition

Tags for the Index File Definition (Continued)

Sub-Tags for Component Definition

Sub-Tags for Cluster Definition

Sub-Tags for Display Specification

Sub-Tags for Z39.50 Explain Information

ACCESS attribute Codes and Their Meanings

EXTRACT attribute Codes and Their Meanings

NORMAL attribute Codes and Their Meanings

Date Format Patterns and Their Interpretations

LAT_LONG and BOUNDING_BOX Format Patterns and Their Interpretations

MARC 008 Field Sub-Elements

Sub-Tags for Z39.50 Index Mapping Definition

Z39.50 BIB-1 USE Attributes

Z39.50 GILS USE Attributes

Z39.50 BIB-1 Relation Attributes

Z39.50 BIB-1 Position Attributes

Z39.50 BIB-1 Structure Attributes

Z39.50 BIB-1 Truncation Attributes

Z39.50 BIB-1 Completeness Attributes

SGML Catalog Entry formats

SGML Catalog Entry formats (Continued)

Sub-Tags for Index Extraction Elements Definition (tagspec)

Tag Specifications

Configuration File DTD

Sample Configuration File

Cheshire Processing Instructions in SGML/XML files

This document describes the format used in the Cheshire II configuration files and their contents.

Configuration files provide the specifications for indexing of SGML elements and sub-elements by the Cheshire II server and search engine. There may be multiple configuration files for each "file" maintained by the server, or the configuration specifications for multiple files may be included in a single configuration file.

Configuration files are themselves SGML documents (The DTD is appended). The following table describes each element (tag) for the configuration file and it's contents. There are matching end tags (beginning with "</" for each of the tags described below. Everything between a begin tag and end tag is processed as the value of the tag, all "white space" (blanks, tabs, carriage returns, newlines) and SGML comments (anything beginning with "<!--" and ending with "-->") are ignored in processing. The exception to this is blank spaces in QUOTED file names under Windows to permit multiword file and directory names

        <from>
                <tagspec>
		<ftag>archdesc</ftag><s>repository</s><s>address</s>
                <ftag>archdesc</ftag><s>repository</s><s>corpname|name</s>
                <ftag>archdesc</ftag><s>unitdate</s>
                </tagspec></from>
        <to>
                <tagspec>
                <ftag>260</ftag>
		<ftag>a</ftag>
		<ftag>b</ftag>
		<ftag>c</ftag>
                </tagspec></to> 

EXTRACT Codes and Their Meanings

Code	Affects	Meaning
KEYWORD	key type	Indicates that keywords are to be extracted from the elements specified for this index. (In external DBMS files this is used to match character or text fields using the "like" operator)
KEYWORD_EXTERNAL	key type	Indicates that keywords are to be extracted from the elements specified for this index some of which are indications of external non-SGML text files or of URLs of external HTML files.
KEYWORD_PROXIMITY	key type	Indicates that keywords are to be extracted from the elements specified for this index and that proximity (character position information) is to be maintained in the index. PROXIMITY and KEYWORD_PROX are synonyms for this specification. Note that indexes including proximity information will be much larger than simple keyword indexes.
KEYWORD_EXTERNAL_PROXIMITY	key type	Indicates that keywords are to be extracted from the elements specified for this index some of which are indications of external non-SGML text files or of URLs of external HTML files and that proximity (character position information) is to be maintained in the index. KEYWORD_PROXIMITY_EXTERNAL, KEYWORD_EXTERNAL_PROX, and KEYWORD_PROX_EXTERNAL are synonyms for this specification. Note that indexes including proximity information will be much larger than simple keyword indexes.
EXACTKEY	key type	Indicates that exact keys are to be extracted from the elements specified for this index. Nota Bene: if a pattern is used for the tags specified for exact key extraction all items that match that pattern at the same level of nesting will be extracted and concatenated to form the exact key -- see tag specifications below. (In external DBMS files this is used to match text or character fields using "=").
FLD008_KEY	key type	Indicates that sub-elements of a MARC 008 field are to be extracted from the field tag specified for this index. The particular sub-elements are listed in the "008 elements" table below. (Only applicable for SGML MARC records)
FLD008_DATE	key type	Indicates that sub-elements of a MARC 008 field are to be extracted from the field tag specified for this index. This is used in conjunction with one of the date formats for the NORMAL attribute(see below). The particular sub-elements are listed in the "008 elements" table below. (Only applicable for SGML MARC records)
FLD008_DATERANGE	key type	Indicates that sub-elements of a MARC 008 field are to be extracted from the field tag specified for this index. This is used in conjunction with one of the date range formats for the NORMAL attribute(see below). The particular sub-elements are listed in the "008 elements" table below. (Only applicable for SGML MARC records)
URL	key type	This is used to indicate that the contents to be extracted are URLs.
FILENAME	key type	This is used to indicate that the contents to be extracted are filenames (for example, full unix pathnames).
DATE	key type	This is to indicate that the extracted values should be parsed for date values based on the pattern provided in the NORMAL attribute (see below).
DATE_RANGE	key type	This is to indicate that the extracted values should be parsed for date range values based on the pattern provided in the NORMAL attribute (see below).
DATE_TIME	key type	This is to indicate that the extracted values should be parsed for date and time values based on the pattern provided in the NORMAL attribute (see below).
DATE_TIME_RANGE	key type	This is to indicate that the extracted values should be parsed for date and time range values based on the pattern provided in the NORMAL attribute (see below).
INTEGER_KEY	key type	This is used to extract a single integer value, which should be the first data within the tag/field being extracted (white space will be ignored, but non numerical characters will not be indexed). The index entry is currently a zero-padded string of 10 digits with an optional leading minus sign. It is also used with DBMS files to indicate that the external DBMS type for this field is an integer.
DECIMAL_KEY	key type	This is used to extract a single decimal value, which should be the first data within the tag/field being extracted (white space will be ignored, but non numerical characters will not be indexed). The number may include a decimal point and fractional part (for example "100.4356". The index entry is currently a zero-padded string of 16 digits with an optional leading minus sign and 6 digits after the decimal point. This specification is also used with DBMS files to indicate that the external DBMS type for this field is an decimal number.
LAT_LONG	key type	This is to indicate that the extracted values should be parsed for Latitude and Longitude values based on the pattern provided in the NORMAL attribute (see below).
LATITUDE_LONGITUDE	key type	Same as LAT_LONG above.
LATITUDE/LONGITUDE	key type	Same as LAT_LONG above.
GEO_POINT	key type	Same as LAT_LONG above.
BOUNDING_BOX	key type	This is to indicate that the extracted values should be parsed for a pair of Latitude and Longitude values based on the pattern provided in the NORMAL attribute (see below).
GEO_BOX	key type	Same as BOUNDING_BOX above.
GEOTEXT	key type	This normalization relies on an external cheshire database containing a gazetteer, candidate terms in the document are compared against this gazetteer database and only terms/phrases that match gazetteer entries are actually entered into the index. The EXTERN_APP tag (see above) must be used to specify the config file, database name and index to be used in matching. The NORMAL tag should indicate one of the text processing normalization methods below (BASIC) is simplest. The generated terms are, by default, keywords derived from the Gazetteer entry names, using EXACTKEY or EXACTKEY_NOMAP uses the exact phrase from the Gazetteer. DO_NOT_NORMALIZE retains the exact capitalization, spacing, etc. from from Gazetteer entry.
GEOTEXT_LAT_LONG	key type	This normalization relies on an external cheshire database containing a gazetteer, candidate terms in the document are compared against this gazetteer database and only terms/phrases that match gazetteer entries are actually included, but the (point) coordinates from the gazetteer are used as the generated keys. The EXTERN_APP tag (see above) must be used to specify the config file, database name and index to be used in matching. Lat_long NORMAL specifications should be used to indicate how queries should be parsed when matching to the generated index.
GEOTEXT_BOUNDING_BOX	key type	This normalization relies on an external cheshire database containing a gazetteer, candidate terms in the document are compared against this gazetteer database and only terms/phrases that match gazetteer entries are actually included. In this case bounding box coordinates from the gazetteer are used directly or generated from point data for the generated keys entered into the index. The EXTERN_APP tag (see above) must be used to specify the config file, database name and index to be used in matching. Bounding_box NORMAL specifications should be used to indicate how queries should be parsed when matching to the generated index.

NORMAL Codes and Their Meanings

Code	Affects	Meaning
STEM	normalization	Indicates that the Porter stemming algorithm should be used to normalize the keywords extracted.
STEM_FREQ	normalization	Indicates that the Porter stemming algorithm should be used to normalize the keywords extracted. This normalization type assumes that each keyword is paired with frequency information in the form "{word 20}", where 20 is the frequency. THIS IS PRIMARILY USED FOR COLLECTION-LEVEL DOCUMENTS IN DISTRIBUTED SEARCH.
SSTEM	normalization	Indicates that a simple plural-removal algorithm should be used to normalize the keywords extracted.
SSTEM_FREQ	normalization	Indicates that a simple plural-removal algorithm should be used to normalize the keywords extracted. This normalization type assumes that each keyword is paired with frequency information in the form "{word 20}", where 20 is the frequency. THIS IS PRIMARILY USED FOR COLLECTION-LEVEL DOCUMENTS IN DISTRIBUTED SEARCH.
FRENCH_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the French language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
GERMAN_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the German language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
ENGLISH_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the English language (porter2 stemmer) should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
PORTER_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the English language (original porter stemmer) language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
DUTCH_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Dutch language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
SPANISH_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Spanish language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
ITALIAN_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Italian language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
SWEDISH_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Swedish language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
PORTUGUESE_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Portuguese language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
RUSSIAN_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Russian language (in UTF-8 encoding) should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
RUSSIAN_UTF8_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Russian language (UTF-8 Encoding) should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ). (alias of the previous code)
RUSSIAN_KOI8_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Russian language (in KOI-8 encoding) should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
DANISH_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Danish language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
NORWEGIAN_STEM	normalization	Indicates that a Snowball-stemmer generated stemmer for the Norwegian language should be used to normalize the keywords extracted. (Note: FREQ form is also supplied as ..._STEMFREQ).
WORDNET	normalization	Indicates that WordNet "morphing" should be used to normalize the keywords extracted.
EXACTKEY	normalization	Indicates that spacing should be normalized, punctuation and stopwords the removed from the key extracted. (XKEY is an alias for EXACTKEY).
XKEY_FREQ	normalization	Indicates that spacing should be normalized, punctuation and stopwords the removed from the key extracted. This normalization type assumes that each exact key is paired with frequency information in the form "{exact key value 20}", where 20 is the frequency. THIS IS PRIMARILY USED FOR COLLECTION-LEVEL DOCUMENTS IN DISTRIBUTED SEARCH.
CLASSCLUS	normalization	Indicates that LC class number normalization for classification clustering should be used to normalize the key extracted.
BASIC_NOMAP	normalization	No term normalization will be done. _NOMAP indicates that the default character mappings done during normalization in indexing and retrieval should NOT be used
STEM_NOMAP	normalization	Indicates that the Porter stemming algorithm should be used to normalize the keywords extracted. _NOMAP indicates that the default character mappings done during normalization in indexing and retrieval should NOT be used
WORDNET_NOMAP	normalization	Indicates that WordNet "morphing" should be used to normalize the keywords extracted. _NOMAP indicates that the default character mappings done during normalization in indexing and retrieval should NOT be used
EXACTKEY_NOMAP	normalization	Indicates that spacing should be normalized, punctuation and stopwords the removed from the key extracted. (XKEY_NOMAP is an alias for EXACTKEY_NOMAP).
CLASSCLUS_NOMAP	normalization	Indicates that LC class number normalization for classification clustering should be used to normalize the key extracted. _NOMAP indicates that the default character mappings done during normalization in indexing and retrieval should NOT be used
DATE PATTERN VALUE	normalization	Indicates that the key extracted will be a date (the EXTRACT attribute must be one of the date types) and the date pattern will be used in matching the elements of the dates that appear in the database records. See the table Date Format Patterns and Their Interpretations for DATE_TIME format patterns. Date parsing is fairly flexible, and as long as the order of elements is correct, dates should be correctly extracted. (NOTE: date patterns for cluster key normalization is not currently supported)
LAT_LONG PATTERN VALUE	normalization	Indicates that the key extracted will be a Latitude and Longitude value (the EXTRACT attribute must be one of the LAT_LONG types) and the LAT_LONG pattern will be used in matching the elements of the coordinates that appear in the database records. LAT_LONG parsing is fairly flexible, but the order of elements is important. See the table LAT_LONG and BOUNDING_BOX Format Patterns and Their Interpretations for the specific codes that can be used.
BOUNDING_BOX PATTERN VALUE	normalization	Indicates that the key extracted will be a pair of Latitude and Longitude values (the EXTRACT attribute must be one of the BOUNDING_BOX types) and the LAT_LONG pattern will be used in matching the elements of the coordinates that appear in the database records. Parsing is fairly flexible, but the order of elements is important. See the table LAT_LONG and BOUNDING_BOX Format Patterns and Their Interpretations for the specific codes that can be used.
BASIC	normalization	Indicates that the key extracted should simply be converted to lower case and have punctuation, extraneous spaces and stopwords removed.
NONE	normalization	Same as BASIC, this is the deprecated name for this option. Indicates that the key extracted should simply be converted to lower case and have punctuation, extraneous spaces and stopwords removed. NONE can be used just as BASIC is use (including in the compounds below).
BASIC_FREQ	normalization	Indicates that the key extracted should simply be converted to lower case and have punctuation and stopwords removed. This normalization type assumes that each keyword is paired with frequency information in the form "{word 20}", where 20 is the frequency. THIS IS PRIMARILY USED FOR COLLECTION-LEVEL DOCUMENTS IN DISTRIBUTED SEARCH.
DO_NOT_NORMALIZE	normalization	This mean NO normalization, including the simple normalization done by BASIC is to be performed. The terms are put into the index exactly as they appear in the document with capitalization, etc. intact. NOTE that if SGML/XML tags appear in the extracted data, they WILL be included in the generated key.
REMOVE_TAGS_ONLY	normalization	This mean NO normalization, including the simple normalization done by BASIC is to be performed, EXCEPT FOR REMOVAL OF EMBEDDED SGML/XML TAGS in the data. The terms are put into the index exactly as they appear in the document with capitalization, etc. intact.
REMOVE_TAGS_ONLY_FREQ	normalization	This mean NO normalization, including the simple normalization done by BASIC is to be performed, EXCEPT FOR REMOVAL OF EMBEDDED SGML/XML TAGS in the data. The terms are put into the index exactly as they appear in the document with capitalization, etc. intact. This normalization type assumes that each key is paired with frequency information in the form "{exact key value 20}", where 20 is the frequency. THIS IS PRIMARILY USED FOR COLLECTION-LEVEL DOCUMENTS IN DISTRIBUTED SEARCH.

DATE FORMATS and Their Interpretation

FORMAT	Type	Meaning
YYMMDD	date	Fixed format dates, e.g.: 980223. Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
YYYYMMDD	date	Fixed format date, e.g.: 19980223
MM/DD/YY	date	slash style dates, e.g.: 2/23/98 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
MM/DD/YYYY	date	slash style dates with full year, e.g.: 2/23/1998.
DD/MM/YY	date	slash style dates, e.g.: 2/23/98 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
DD/MM/YYYY	date	slash style dates with full year, e.g.: 2/23/1998.
MM.DD.YY	date	dot style dates, e.g.: 2.23.98 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
MM.DD.YYYY	date	dot style dates with full year, e.g.: 2/23/1998.
DD.MM.YY	date	dot style dates, e.g.: 22.02.98 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
DD.MM.YYYY	date	dot style dates with full year, e.g.: 2/23/1998.
DD MMM YYYY	date	Dates with month abbreviations, e.g.: 23 Feb 1998
DD MMM YEAR	date	Dates with month abbreviations, e.g.: 23 Feb 1998. This form may be used if the data contain years with less (or more) than 4 digits, but are not in the Twentieth century. For example "13 Apr 856 AD", or "25 Dec 1 B.C." are legal dates for this format.
DD MMM YY	date	Dates with month abbreviations, e.g.: 23 Feb 98. Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
DD MONTH YY	date	Dates with month abbreviations or full month names, e.g.: 23 February 98. Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
DD MONTH YYYY	date	Dates with month abbreviations or full month names, e.g.: 23 February 98.
DD MONTH YEAR	date	Dates with month abbreviations or full month names, e.g.: 23 February 98. This form may be used if the data contain years with less (or more) than 4 digits, but are not in the Twentieth century. For example "13 Apr 856 AD", or "25 Dec 1 B.C." are legal dates for this format.
MONTH DD, YY	date	Dates with month abbreviations or full month names, e.g.: February 23, 98. Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
MONTH DD, YYYY	date	Dates with month abbreviations or full month names, e.g.: February 23, 1998.
YYMMDD HH:MM	date_time	Fixed format date and time, e.g.: 980223 12:04 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
YYYYMMDD HH:MM	date_time	Fixed format date and time, e.g.: 19980223 12:04
MM/DD/YY HH:MM	date_time	slash style dates with time of day, e.g.: 2/23/98 12:02 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
MM/DD/YYYY HH:MM	date_time	slash style dates with time of day, e.g.: 2/23/1998 12:02
DD/MM/YY HH:MM	date_time	slash style dates with time of day, e.g.: 23/2/98 12:02 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
DD/MM/YYYY HH:MM	date_time	slash style dates with time of day, e.g.: 23/2/1998 12:02
MM.DD.YY HH:MM	date_time	dot style dates with time of day, e.g.: 2.23.98 12:02 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
MM.DD.YYYY HH:MM	date_time	dot style dates with time of day, e.g.: 2.23.1998 12:02
DD.MM.YY HH:MM	date_time	dot style dates with time of day, e.g.: 23.2.98 12:02 Note that the system will assume that dates in this form are for the Twentieth century ONLY -- 98 becomes 1998
DD.MM.YYYY HH:MM	date_time	dot style dates with time of day, e.g.: 23.2.1998 12:02
YYYY	date	fixed format, year only, e.g.: 1998, 1754, 1292, 1056
YEAR	date	Variable length years, e.g.: "1998", "24 B.C.E.", "57 A.D.", "500000 B.C.", "1852 C.E."
YYDDD	date	Julian Dates (not currently supported)
DECADE	date_range	Decades within a century, e.g. "1940's" is interpreted as the range from 1940-1949, "20's" is interpreted as 1920-1929, 1870's is interpreted as 1870-1879.
CENTURY	date_range	Centuries, e.g.: 20th is interpreted as 1900-1999, "4th century b.c." is interpreted as 400B.C.-301B.C.
MILLENNIUM	date_range	Millennia, e.g.: "4th millenium B.C." is interpreted as 4000B.C.- 3001B.C.
MIXED YEAR	date	Extracts year from mixed data which may include full dates and years. Assumes that only 3 and 4 digit numbers in the string is the year, so it may error if there are decade, century or millenium specifications. Checks for era also. Any text (except for era specifications following the year -- e.g.: 924 B.C.--) or non-numeric characters are ignored.
MIXED_YEAR	date	Same as above
UNIX_TIME	date	Dates as returned by the UNIX ctime function, for example "Wed Apr 12 10:18:21 2000 EDT" the trailing zone information is ignored.
UNIX_CTIME	date	Same as above
DAY MONTH DD HH:MM:SS YEAR	date	Same as UNIX_TIME above
DAY MMM DD HH:MM:SS YYYY	date	Same as UNIX_TIME above
YYYY-YYYY	date_range	Range of years in fixed (4 digit) form, e.g.: 1920-1945
YYYY to YYYY	date_range	Range of years in fixed (4 digit) form, e.g.: "1920 to 1945"
YYYY through YYYY	date_range	Range of years in fixed (4 digit) form, e.g.: "1920 through 1945"
YEAR-YEAR	date_range	Range of years without fixed format, e.g.: "22 B.C - 12 A.D.", 1950-1990, "50000 BCE - 100 CE"
YEAR to YEAR	date_range	Range of years without fixed format, e.g.: "22 B.C to 12 A.D.", 1950 to 1990, "50000 BCE to 100 CE"
YEAR through YEAR	date_range	Range of years without fixed format, e.g.: "22 B.C - 12 A.D.", 1950-1990, "50000 BCE to 100 CE"
DECADE-DECADE	date_range	Range of decades, e.g.: "20's-50's" is interpreted as 1920-1959.
DECADE to DECADE	date_range	Range of decades, e.g.: "20's to 50's" is interpreted as 1920-1950.
DECADE through DECADE	date_range	Range of decades, e.g.: "20's through 50's" is interpreted as 1920-1959.
CENTURY-CENTURY	date_range	Range of Centuries, e.g.: "3rd cent bc - 8th century ad" is interpreted as 300B.C.-700A.D.
CENTURY to CENTURY	date_range	Range of Centuries, e.g.: "3rd cent bc to 8th century ad" is interpreted as 300B.C.-700A.D.
CENTURY through CENTURY	date_range	Range of Centuries, e.g.: "3rd cent bc through 8th century ad" is interpreted as 300B.C.-799A.D.
MILLENNIUM-MILLENNIUM	date_range	Range of Millennia, e.g.: "8th millennium bc through 1st millenium AD" is interpreted as 8000B.C.-999A.D.
MILLENNIUM to MILLENNIUM	date_range	Range of Millennia, e.g.: "8th millennium bc through 1st millenium AD" is interpreted as 8000B.C.-999A.D.
MILLENNIUM through MILLENNIUM	date_range	Range of Millennia, e.g.: "8th millennium bc through 1st millenium AD" is interpreted as 8000B.C.-999A.D.
MIXED YEAR RANGE	date	Extracts one or a pair of years from mixed data which may include full dates and years. Assumes that 3 and 4 digit numbers in the string are the year specifications. The first two three and four digit numbers are used to determine the date range, so it may error if there are decade, century or millenium specifications. Checks for era also. If the data contains only a single (3 or 4 digit) year, the range is created for the that year only. Any text (except for era specifications following the year -- e.g.: 924 B.C.--) or non-numeric characters are ignored.
MIXED_YEAR_RANGE	date	Same as above

LAT_LONG and BOUNDING_BOX FORMATS and Their Interpretation

FORMAT	Type	Meaning
DDoMM'SS''NS DDDoMM'SS''EW	LAT_LONG	Latitude and Longitude using "DD" (degrees), "MM" (minutes) and "SS", separated by "o" (lower case O) for degrees, a single quote for minutes and two single quotes for seconds, followed by EITHER "N" or "S" for Latitudes or "E" or "W" for Longitudes. For example, Latitude and Longitude for San Francisco, California can be expressed as "37o45'53''N 122o24'36''W" and parsed using this format.
DD-MM-SS NS DDD-MM-SS EW	LAT_LONG	Latitude and Longitude using "DD" (degrees), "MM" (minutes) and "SS", separated by hypens, followed by one or more spaces and EITHER "N" or "S" for Latitudes or "E" or "W" for Longitudes. For example, Latitude and Longitude for San Francisco, California can be expressed as "37-45-53 N 122-24-36 W" and parsed using this format.
DD-MM-SS-NS DDD-MM-SS-EW	LAT_LONG	Latitude and Longitude using "DD" (degrees), "MM" (minutes) and "SS", and EITHER "N" or "S" for Latitudes or "E" or "W" for Longitudes, separated by hypens. For example, Latitude and Longitude for San Francisco, California can be expressed as "37-45-53-N 122-24-36-W" and parsed using this format.
DECIMAL_LAT_LONG	LAT_LONG	Latitude and Longitude using degrees and decimal fractions of degrees with positive numbers indicating NORTH latitudes or EAST longitudes, and negative numbers indicating SOUTH latitudes and WEST longitudes. For example, Latitude and Longitude for San Francisco, California can be expressed as "37.765 -122.41" and parsed using this format.
DECIMAL_LONG_LAT	LAT_LONG	Latitude and Longitude using degrees and decimal fractions of degrees with positive numbers indicating NORTH latitudes or EAST longitudes, and negative numbers indicating SOUTH latitudes and WEST longitudes. For example, Longitude and Latitude for San Francisco, California can be expressed as "-122.41 37.765" and parsed using this format.
DECIMAL_BOUNDING_BOX	BOUNDING_BOX	A pair of Latitudes and Longitudes using degrees and decimal fractions of degrees with positive numbers indicating NORTH latitudes or EAST longitudes, and negative numbers indicating SOUTH latitudes and WEST longitudes. The first latitude and longitude represent the North-West corner of the bounding box and the second latitude and longitude represent the South-West corner. For example, a bounding box around peninsula of California can be expressed as "37.815834 -122.498886 37.601112 -122.318611" and parsed using this format.
FGDC_BOUNDING_BOX	BOUNDING_BOX	A set of Latitude and Longitude coordinates using degrees and decimal fractions of degrees with positive numbers indicating NORTH latitudes or EAST longitudes, and negative numbers indicating SOUTH latitudes and WEST longitudes. These coordinates follow the order for bounding boxes in the FGDC guidelines. That is, the first coordinate is the West bounding coordinate (BC), followed by the East BC, the North BC, and the South BC. For example, a FGDC bounding box around peninsula of California can be expressed as "-122.498886 -122.318611 37.815834 37.601112" and parsed using this format. Note that whitespace and XML tags are ignored when extracting the data, so a recommended FGDC XML bounding box definition like: <bounding> <westbc>-122.71456201</westbc> <eastbc>-122.19128542</eastbc> <northbc>38.00205344</northbc> <southbc>37.68397727</southbc> </bounding> can be parsed correctly without pre-processing.
DDoMM'SS''NS DDDoMM'SS''EW DDoMM'SS''NS DDDoMM'SS''EW	BOUNDING_BOX	A pair of Latitude and Longitude coordinates using "DD" (degrees), "MM" (minutes) and "SS", separated by "o" (lower case O) for degrees, a single quote for minutes and two single quotes for seconds, followed by EITHER "N" or "S" for Latitudes or "E" or "W" for Longitudes. For example, a bounding box for the peninsula of San Francisco, California can be expressed as "37o48'57''N 122o29'56''W 37o36'4''N 122o19'7''W" and parsed using this format
DDoMM'SS''NS DDDoMM'SS''EW DDoMM'SS''NS DDDoMM'SS''EW	BOUNDING_BOX	A pair of Latitude and Longitude coordinates using "DD" (degrees), "MM" (minutes) and "SS", separated by "o" (lower case O) for degrees, a single quote for minutes and two single quotes for seconds, followed by EITHER "N" or "S" for Latitudes or "E" or "W" for Longitudes. For example, a bounding box for the peninsula of San Francisco, California can be expressed as "37o48'57''N 122o29'56''W 37o36'4''N 122o19'7''W" and parsed using this format
DD-MM-SS NS DDD-MM-SS EW DD-MM-SS NS DDD-MM-SS EW	BOUNDING_BOX	A pair of Latitude and Longitude coordinates using "DD" (degrees), "MM" (minutes) and "SS", separated by hyphens, followed whitespace and by EITHER "N" or "S" for Latitudes or "E" or "W" for Longitudes. For example, a bounding box for the peninsula of San Francisco, California can be expressed as "37-48-57 N 122-29-56 W 37-36-4 N 122-19-7 W" and parsed using this format
DD-MM-SS-NS DDD-MM-SS-EW DD-MM-SS-NS DDD-MM-SS-EW	BOUNDING_BOX	A pair of Latitude and Longitude coordinates using "DD" (degrees), "MM" (minutes) and "SS", and EITHER "N" or "S" for Latitudes or "E" or "W" for Longitudes, all separated by hyphens. For example, a bounding box for the peninsula of San Francisco, California can be expressed as "37-48-57-N 122-29-56-W 37-36-4-N 122-19-7-W" and parsed using this format
Note on Format Parsing:		In the above described formats (other than format keywords "DECIMAL_LAT_LONG", "DECIMAL_LONG_LAT" and "DECIMAL_BOUNDING_BOX", which require things in an appropriate decimal form), the elements used in the DATA itself as separators need only be one of any of the separators in all of the above formats. This means that, for example, the format specification "DDoMM'SS''NS DDDoMM'SS''EW" could be used to correctly parse data that looked like "37-48-57-N 122-29-56-W" or "37o48-57 N 122'29'56'W", or even " 37 48 57 n 122 29 56 w", etc. However, the one of the formats, as shown above, should appear in the EXTRACT attribute for the index for correct configuration file processing.

Approved Extensions to bib-1 Attribute Set

The attributes listed below are added to the bib-1 attribute set, 1.2.840.10003.3.1.

104: Within

When this relation attribute is supplied the intent is to select records where the value of the access point as determined by the Use attribute is within the bounds specified by the term (where the term itself may be composed of several terms). A profile or implementor agreement may specify precisely what form a term should take when this relation attribute is used, and how the term specifies bounds. As an example, see the implementor agreement Linear Range Searching