X-Git-Url: http://git.indexdata.com/?p=idzebra-moved-to-github.git;a=blobdiff_plain;f=doc%2Frecordmodel-grs.xml;h=c4ff6c77e148df70cf268c917521097d7a68d43a;hp=c370ded99581b1df4f0c7cead04f275fbe06e687;hb=e4c6861efeeea654bfb00c5f0239ee258629d77f;hpb=5ca4e60e990af6ad6b62ebff855d7b642f37c3ec diff --git a/doc/recordmodel-grs.xml b/doc/recordmodel-grs.xml index c370ded..c4ff6c7 100644 --- a/doc/recordmodel-grs.xml +++ b/doc/recordmodel-grs.xml @@ -1,6 +1,13 @@ - - GRS Record Model and Filter Modules + &acro.grs1; Record Model and Filter Modules + + + + The functionality of this record model has been improved and + replaced by the DOM &acro.xml; record model. See + . + + The record model described in this chapter applies to the fundamental, @@ -11,7 +18,7 @@
- GRS Record Filters + &acro.grs1; Record Filters Many basic subtypes of the grs type are currently available: @@ -25,7 +32,7 @@ This is the canonical input format described . It is using - simple SGML-like syntax. + simple &acro.sgml;-like syntax. @@ -34,17 +41,17 @@ This allows &zebra; to read - records in the ISO2709 (MARC) encoding standard. + records in the ISO2709 (&acro.marc;) encoding standard. Last parameter type names the .abs file (see below) - which describes the specific MARC structure of the input record as + which describes the specific &acro.marc; structure of the input record as well as the indexing rules. - The grs.marc uses an internal represtantion - which is not XML conformant. In particular MARC tags are - presented as elements with the same name. And XML elements + The grs.marc uses an internal representation + which is not &acro.xml; conformant. In particular &acro.marc; tags are + presented as elements with the same name. And &acro.xml; elements may not start with digits. Therefore this filter is only - suitable for systems returning GRS-1 and MARC records. For XML + suitable for systems returning &acro.grs1; and &acro.marc; records. For &acro.xml; use grs.marcxml filter instead (see below). @@ -61,14 +68,14 @@ This allows &zebra; to read ISO2709 encoded records. Last parameter type names the .abs file (see below) - which describes the specific MARC structure of the input record as + which describes the specific &acro.marc; structure of the input record as well as the indexing rules. The internal representation for grs.marcxml - is the same as for MARCXML. + is the same as for &acro.marcxml;. It slightly more complicated to work with than - grs.marc but XML conformant. + grs.marc but &acro.xml; conformant. The loadable grs.marcxml filter module @@ -81,18 +88,18 @@ grs.xml - This filter reads XML records and uses + This filter reads &acro.xml; records and uses Expat to parse them and convert them into ID&zebra;'s internal grs record model. - Only one record per file is supported, due to the fact XML does + Only one record per file is supported, due to the fact &acro.xml; does not allow two documents to "follow" each other (there is no way to know when a document is finished). This filter is only available if &zebra; is compiled with EXPAT support. The loadable grs.xml filter module - is packagged in the GNU/Debian package + is packaged in the GNU/Debian package libidzebra2.0-mod-grs-xml @@ -130,14 +137,14 @@
- GRS Canonical Input Format + &acro.grs1; Canonical Input Format Although input data can take any form, it is sometimes useful to describe the record processing capabilities of the system in terms of a single, canonical input format that gives access to the full spectrum of structure and flexibility in the system. In &zebra;, this - canonical format is an "SGML-like" syntax. + canonical format is an "&acro.sgml;-like" syntax. @@ -215,7 +222,7 @@ contains only a single element (strictly speaking, that makes it an illegal GILS record, since the GILS profile includes several mandatory elements - &zebra; does not validate the contents of a record against - the Z39.50 profile, however - it merely attempts to match up elements + the &acro.z3950; profile, however - it merely attempts to match up elements of a local representation with the given schema): @@ -240,7 +247,7 @@ textual data elements which might appear in different languages, and images which may appear in different formats or layouts. The variant system in &zebra; is essentially a representation of - the variant mechanism of Z39.50-1995. + the variant mechanism of &acro.z3950;-1995. @@ -320,7 +327,7 @@ The title element above comes in two variants. Both have the IANA body type "text/plain", but one is in English, and the other in - Danish. The client, using the element selection mechanism of Z39.50, + Danish. The client, using the element selection mechanism of &acro.z3950;, can retrieve information about the available variant forms of data elements, or it can select specific variants based on the requirements of the end-user. @@ -331,7 +338,7 @@
- GRS REGX And TCL Input Filters + &acro.grs1; REGX And TCL Input Filters In order to handle general input formats, &zebra; allows the @@ -466,7 +473,7 @@ Begin a new record. The following parameter should be the - name of the schema that describes the structure of the record, eg. + name of the schema that describes the structure of the record, e.g., gils or wais (see below). The begin record call should precede any other use of the begin statement. @@ -583,7 +590,7 @@
- GRS Internal Record Representation + &acro.grs1; Internal Record Representation When records are manipulated by the system, they're represented in a @@ -683,7 +690,7 @@ In practice, each variant node is associated with a triple of class, - type, value, corresponding to the variant mechanism of Z39.50. + type, value, corresponding to the variant mechanism of &acro.z3950;.
@@ -707,7 +714,7 @@
- GRS Record Model Configuration + &acro.grs1; Record Model Configuration The following sections describe the configuration files that govern @@ -737,7 +744,7 @@ - The object identifier of the Z39.50 schema associated + The object identifier of the &acro.z3950; schema associated with the ARS, so that it can be referred to by the client. @@ -774,7 +781,7 @@ ask for a subset of the data elements contained in a record. Element set names, in the retrieval module, are mapped to element specifications, which contain information equivalent to the - Espec-1 syntax of Z39.50. + Espec-1 syntax of &acro.z3950;. @@ -788,7 +795,7 @@ Possibly, a set of rules describing the mapping of elements to a - MARC representation. + &acro.marc; representation. @@ -796,7 +803,7 @@ A list of element descriptions (this is the actual ARS of the - schema, in Z39.50 terms), which lists the ways in which the various + schema, in &acro.z3950; terms), which lists the ways in which the various tags can be used and organized hierarchically. @@ -822,7 +829,7 @@ The number of different file types may appear daunting at first, but - each type corresponds fairly clearly to a single aspect of the Z39.50 + each type corresponds fairly clearly to a single aspect of the &acro.z3950; retrieval facilities. Further, the average database administrator, who is simply reusing an existing profile for which tables already exist, shouldn't have to worry too much about the contents of these tables. @@ -847,14 +854,14 @@ The Abstract Syntax (.abs) Files - The name of this file type is slightly misleading in Z39.50 terms, + The name of this file type is slightly misleading in &acro.z3950; terms, since, apart from the actual abstract syntax of the profile, it also includes most of the other definitions that go into a database profile. - When a record in the canonical, SGML-like format is read from a file + When a record in the canonical, &acro.sgml;-like format is read from a file or from the database, the first tag of the file should reference the profile that governs the layout of the record. If the first tag of the record is, say, <gils>, the system will look @@ -892,7 +899,7 @@ (m) The reference name of the OID for the profile. The reference names can be found in the util - module of YAZ. + module of &yaz;. @@ -938,7 +945,7 @@ (o) Points to a file containing parameters for representing the record contents in the ISO2709 syntax. - Read the description of the MARC representation facility below. + Read the description of the &acro.marc; representation facility below. @@ -974,7 +981,7 @@ (o,r) Adds an element to the abstract record syntax of the schema. The path follows the - syntax which is suggested by the Z39.50 document - that is, a sequence + syntax which is suggested by the &acro.z3950; document - that is, a sequence of tags separated by slashes (/). Each tag is given as a comma-separated pair of tag type and -value surrounded by parenthesis. The name is the name of the element, and @@ -1021,8 +1028,8 @@ melm field$subfield attributes - This directive is specifically for MARC-formatted records, - ingested either in the form of MARCXML documents, or in the + This directive is specifically for &acro.marc;-formatted records, + ingested either in the form of &acro.marcxml; documents, or in the ISO2709/Z39.2 format using the grs.marcxml input filter. You can specify indexing rules for any subfield, or you can leave off the $subfield part and specify default rules @@ -1038,7 +1045,7 @@ This directive specifies character encoding for external records. - For records such as XML that specifies encoding within the + For records such as &acro.xml; that specifies encoding within the file via a header this directive is ignored. If neither this directive is given, nor an encoding is set within external records, ISO-8859-1 encoding is assumed. @@ -1135,7 +1142,7 @@ An automatically generated identifier for the record, unique within this database. It is represented by the <localControlNumber> element in - XML and the (1,14) tag in GRS-1. + &acro.xml; and the (1,14) tag in &acro.grs1;. @@ -1237,7 +1244,7 @@ (m) The reference name of the OID for the attribute set. The reference names can be found in the util - module of YAZ. + module of &yaz;. @@ -1250,7 +1257,7 @@ set. For instance, many new attribute sets are defined as extensions to the bib-1 set. This is an important feature of the retrieval - system of Z39.50, as it ensures the highest possible level of + system of &acro.z3950;, as it ensures the highest possible level of interoperability, as those access points of your database which are derived from the external set (say, bib-1) can be used even by clients who are unaware of the new set. @@ -1302,7 +1309,7 @@ This file type defines the tagset of the profile, possibly by referencing other tag sets (most tag sets, for instance, will include - tagsetG and tagsetM from the Z39.50 specification. The file may + tagsetG and tagsetM from the &acro.z3950; specification. The file may contain the following directives. @@ -1323,7 +1330,7 @@ (o) The reference name of the OID for the tag set. The reference names can be found in the util - module of YAZ. + module of &yaz;. The directive is optional, since not all tag sets are registered outside of their schema. @@ -1484,7 +1491,7 @@ (o) The reference name of the OID for the variant set, if one is required. The reference names can be found - in the util module of YAZ. + in the util module of &yaz;. @@ -1542,7 +1549,7 @@ The element set specification files describe a selection of a subset of the elements of a database record. The element selection mechanism is equivalent to the one supplied by the Espec-1 - syntax of the Z39.50 specification. + syntax of the &acro.z3950; specification. In fact, the internal representation of an element set specification is identical to the Espec-1 structure, and we'll refer you to the description of that structure for most of @@ -1583,7 +1590,7 @@ provides a default variant request for use when the individual element requests (see below) do not contain a variant request. Variant requests consist of a blank-separated list of - variant components. A variant compont is a comma-separated, + variant components. A variant component is a comma-separated, parenthesized triple of variant class, type, and value (the two former values being represented as integers). The value can currently only be entered as a string (this will change to depend on the definition of @@ -1683,14 +1690,14 @@ a schema that differs from the native schema of the record. For instance, a client might only know how to process WAIS records, while the database record is represented in a more specific schema, such as - GILS. In this module, a mapping of data to one of the MARC formats is + GILS. In this module, a mapping of data to one of the &acro.marc; formats is also thought of as a schema mapping (mapping the elements of the - record into fields consistent with the given MARC specification, prior + record into fields consistent with the given &acro.marc; specification, prior to actually converting the data to the ISO2709). This use of the - object identifier for USMARC as a schema identifier represents an + object identifier for &acro.usmarc; as a schema identifier represents an overloading of the OID which might not be entirely proper. However, it represents the dual role of schema and record syntax which - is assumed by the MARC family in Z39.50. + is assumed by the &acro.marc; family in &acro.z3950;. @@ -1758,7 +1765,7 @@
- GRS Exchange Formats + &acro.grs1; Exchange Formats Converting records from the internal structure to an exchange format @@ -1770,7 +1777,7 @@ - GRS-1. The internal representation is based on GRS-1/XML, so the + &acro.grs1;. The internal representation is based on &acro.grs1;/&acro.xml;, so the conversion here is straightforward. The system will create applied variant and supported variant lists as required, if a record contains variant information. @@ -1779,34 +1786,34 @@ - XML. The internal representation is based on GRS-1/XML so - the mapping is trivial. Note that XML schemas, preprocessing + &acro.xml;. The internal representation is based on &acro.grs1;/&acro.xml; so + the mapping is trivial. Note that &acro.xml; schemas, preprocessing instructions and comments are not part of the internal representation - and therefore will never be part of a generated XML record. + and therefore will never be part of a generated &acro.xml; record. Future versions of the &zebra; will support that. - SUTRS. Again, the mapping is fairly straightforward. Indentation + &acro.sutrs;. Again, the mapping is fairly straightforward. Indentation is used to show the hierarchical structure of the record. All - "GRS" type records support both the GRS-1 and SUTRS + "&acro.grs1;" type records support both the &acro.grs1; and &acro.sutrs; representations. - + - ISO2709-based formats (USMARC, etc.). Only records with a + ISO2709-based formats (&acro.usmarc;, etc.). Only records with a two-level structure (corresponding to fields and subfields) can be directly mapped to ISO2709. For records with a different structuring - (eg., GILS), the representation in a structure like USMARC involves a + (e.g., GILS), the representation in a structure like &acro.usmarc; involves a schema-mapping (see ), to an - "implied" USMARC schema (implied, + "implied" &acro.usmarc; schema (implied, because there is no formal schema which specifies the use of the - USMARC fields outside of ISO2709). The resultant, two-level record is + &acro.usmarc; fields outside of ISO2709). The resultant, two-level record is then mapped directly from the internal representation to ISO2709. See the GILS schema definition files for a detailed example of this approach. @@ -1845,18 +1852,18 @@
- Extended indexing of MARC records + Extended indexing of &acro.marc; records - Extended indexing of MARC records will help you if you need index a + Extended indexing of &acro.marc; records will help you if you need index a combination of subfields, or index only a part of the whole field, - or use during indexing process embedded fields of MARC record. + or use during indexing process embedded fields of &acro.marc; record. - Extended indexing of MARC records additionally allows: + Extended indexing of &acro.marc; records additionally allows: - to index data in LEADER of MARC record + to index data in LEADER of &acro.marc; record @@ -1868,26 +1875,26 @@ - to index linked fields for UNIMARC based formats + to index linked fields for UNI&acro.marc; based formats In compare with simple indexing process the extended indexing - may increase (about 2-3 times) the time of indexing process for MARC + may increase (about 2-3 times) the time of indexing process for &acro.marc; records.
The index-formula At the beginning, we have to define the term - index-formula for MARC records. This term helps - to understand the notation of extended indexing of MARC records by &zebra;. + index-formula for &acro.marc; records. This term helps + to understand the notation of extended indexing of &acro.marc; records by &zebra;. Our definition is based on the document "The table - of conformity for Z39.50 use attributes and RUSMARC fields". - The document is available only in russian language. + of conformity for &acro.z3950; use attributes and R&acro.usmarc; fields". + The document is available only in Russian language. The index-formula is the combination of @@ -1899,7 +1906,7 @@ - We know that &zebra; supports a Bib-1 attribute - right truncation. + We know that &zebra; supports a &acro.bib1; attribute - right truncation. In this case, the index-formula (1) consists from forms, defined in the same way as (1) @@ -1910,7 +1917,7 @@ - The original MARC record may be without some elements, which included in index-formula. + The original &acro.marc; record may be without some elements, which included in index-formula. @@ -1925,7 +1932,7 @@ - The position may contain any value, defined by - MARC format. + &acro.marc; format. For example, index-formula @@ -1968,7 +1975,7 @@ - All another operands are the same as accepted in MARC world. + All another operands are the same as accepted in &acro.marc; world. @@ -1983,7 +1990,7 @@ (.abs file). It means that names beginning with "mc-" are interpreted by &zebra; as index-formula. The database index is created and - linked with access point (Bib-1 use attribute) + linked with access point (&acro.bib1; use attribute) according to this formula. For example, index-formula @@ -2010,7 +2017,7 @@ . The position may contain any value, defined by - MARC format. For example, + &acro.marc; format. For example, index-formula @@ -2074,7 +2081,7 @@ - All another operands are the same as accepted in MARC world. + All another operands are the same as accepted in &acro.marc; world.
@@ -2107,7 +2114,7 @@ elm mc-008[0-5] Date/time-added-to-db ! - or for RUSMARC (this data included in 100th field) + or for R&acro.usmarc; (this data included in 100th field) elm mc-100___$a[0-7]_ Date/time-added-to-db ! @@ -2119,7 +2126,7 @@ using indicators while indexing - For RUSMARC index-formula + For R&acro.usmarc; index-formula 70-#1$a, $g matches @@ -2135,10 +2142,10 @@ - indexing embedded (linked) fields for UNIMARC based + indexing embedded (linked) fields for UNI&acro.marc; based formats - For RUSMARC index-formula + For R&acro.usmarc; index-formula 4--#-$170-#1$a, $g ($c) matches