X-Git-Url: http://git.indexdata.com/?p=idzebra-moved-to-github.git;a=blobdiff_plain;f=doc%2Fexamples.xml;h=ebbac178df224830168ebc8367c93f26a4136753;hp=9ceab4d2dfc3ab404f98bf81fd3f92b17acb694c;hb=31b0ba1ecb737f9db4cf3340e93964c6679897fd;hpb=0381d7dc936e74ac2fb55ad217b760c97ace0d5b diff --git a/doc/examples.xml b/doc/examples.xml index 9ceab4d..ebbac17 100644 --- a/doc/examples.xml +++ b/doc/examples.xml @@ -1,12 +1,12 @@ - Example Configurations - + Overview - zebraidx and zebrasrv are both + zebraidx and + zebrasrv are both driven by a master configuration file, which may refer to other subsidiary configuration files. By default, they try to use zebra.cfg in the working directory as the @@ -14,7 +14,7 @@ option to specify an alternative master configuration file. - The master configuration file tells Zebra: + The master configuration file tells &zebra;: @@ -28,7 +28,7 @@ - What record schemas to support. (Subsidiary files specifiy how + What record schemas to support. (Subsidiary files specify how to index the contents of records in those schemas, and what format to use when presenting records in those schemas to client software.) @@ -60,14 +60,14 @@ - Example 1: XML Indexing And Searching + Example 1: &acro.xml; Indexing And Searching - This example shows how Zebra can be used with absolutely minimal + This example shows how &zebra; can be used with absolutely minimal configuration to index a body of - XML + &acro.xml; documents, and search them using - XPath + XPath expressions to specify access points. @@ -80,20 +80,20 @@ records are generated from the family tree in the file dino.tree.) Type make records/dino.xml - to make the XML data file. - (Or you could just type make dino to build the XML + to make the &acro.xml; data file. + (Or you could just type make dino to build the &acro.xml; data file, create the database and populate it with the taxonomic records all in one shot - but then you wouldn't learn anything, would you? :-) - Now we need to create a Zebra database to hold and index the XML + Now we need to create a &zebra; database to hold and index the &acro.xml; records. We do this with the - Zebra indexer, zebraidx, which is + &zebra; indexer, zebraidx, which is driven by the zebra.cfg configuration file. For our purposes, we don't need any special behaviour - we can use the defaults - so we can start with a - minimal file that just tells zebraidx where to + minimal file that just tells zebraidx where to find the default indexing rules, and how to parse the records: profilePath: .:../../tab @@ -101,8 +101,8 @@ - That's all you need for a minimal Zebra configuration. Now you can - roll the XML records into the database and build the indexes: + That's all you need for a minimal &zebra; configuration. Now you can + roll the &acro.xml; records into the database and build the indexes: zebraidx update records @@ -120,8 +120,8 @@ . - Now you can use the Z39.50 client program of your choice to execute - XPath-based boolean queries and fetch the XML records that satisfy + Now you can use the &acro.z3950; client program of your choice to execute + XPath-based boolean queries and fetch the &acro.xml; records that satisfy them: $ yaz-client @:9999 @@ -175,7 +175,7 @@ significantly because it ties searching semantics to the physical structure of the searched records. You can't use the same search specification to search two databases if their internal - representations are different. Consider an different taxonomy + representations are different. Consider a different taxonomy database in which the records have taxon names specified inside a <name> element nested within a <identification> element @@ -186,18 +186,18 @@ How, then, can we build broadcasting Information Retrieval applications that look for records in many different databases? - The Z39.50 protocol offers a powerful and general solution to this: - abstract ``access points''. In the Z39.50 model, an access point + The &acro.z3950; protocol offers a powerful and general solution to this: + abstract ``access points''. In the &acro.z3950; model, an access point is simply a point at which searches can be directed. Nothing is said about implementation: in a given database, an access point might be implemented as an index, a path into physical records, an algorithm for interrogating relational tables or whatever works. - The only important thing point is that the semantics of an access - point are fixed and well defined. + The only important thing is that the semantics of an access + point is fixed and well defined. For convenience, access points are gathered into attribute - sets. For example, the BIB-1 attribute set is supposed to + sets. For example, the &acro.bib1; attribute set is supposed to contain bibliographic access points such as author, title, subject and ISBN; the GEO attribute set contains access points pertaining to geospatial information (bounding coordinates, stratum, latitude @@ -206,7 +206,7 @@ (provenance, inscriptions, etc.) - In practice, the BIB-1 attribute set has tended to be a dumping + In practice, the &acro.bib1; attribute set has tended to be a dumping ground for all sorts of access points, so that, for example, it includes some geospatial access points as well as strictly bibliographic ones. Nevertheless, this model @@ -214,21 +214,21 @@ records in databases. - In the BIB-1 attribute set, a taxon name is probably best + In the &acro.bib1; attribute set, a taxon name is probably best interpreted as a title - that is, a phrase that identifies the item - in question. BIB-1 represents title searches by - access point 4. (See - The BIB-1 Attribute Set Semantics) + in question. &acro.bib1; represents title searches by + access point 4. (See + The &acro.bib1; Attribute + Set Semantics) So we need to configure our dinosaur database so that searches for - BIB-1 access point 4 look in the + &acro.bib1; access point 4 look in the <termName> element, inside the top-level <Zthes> element. - This is a two-step process. First, we need to tell Zebra that we - want to support the BIB-1 attribute set. Then we need to tell it + This is a two-step process. First, we need to tell &zebra; that we + want to support the &acro.bib1; attribute set. Then we need to tell it which elements of its record pertain to access point 4. @@ -264,13 +264,13 @@ xelm /Zthes/termModifiedBy termModifiedBy:w - Declare Thesausus attribute set. See zthes.att. + Declare Thesaurus attribute set. See zthes.att. - Declare Bib-1 attribute set. See bib1.att in - Zebra's tab directory. + Declare &acro.bib1; attribute set. See bib1.att in + &zebra;'s tab directory. @@ -283,13 +283,13 @@ xelm /Zthes/termModifiedBy termModifiedBy:w Make termName word searchable by both - Zthes attribute termName (1002) and Bib-1 atttribute title (4). + Zthes attribute termName (1002) and &acro.bib1; attribute title (4). - After re-indexing, we can search the database using Bib-1 + After re-indexing, we can search the database using &acro.bib1; attribute, title, as follows: Z> form xml @@ -304,7 +304,7 @@ Elapsed: 0.106896 Z> s Sent presentRequest (1+1). Records: 1 -[Default]Record type: XML +[Default]Record type: &acro.xml; <Zthes> <termId>2</termId> <termName>Eoraptor</termName> @@ -374,7 +374,7 @@ rendering engine can handle. I generated the EPS version of the image by exporting a line-drawing done in TGIF, then converted that to the GIF using a shell-script called "epstogif" which used an appallingly baroque sequence of conversions, which I would prefer not to pollute -the Zebra build environment with: +the &zebra; build environment with: #!/bin/sh