source: documented-examples/trunk/isis-e/resources/ 36265

Last change on this file since 36265 was 36265, checked in by anupama, 18 months ago

First commit of GS3 version of DEC's isis-e collection: I still want to figure out where the text of each page (nodeContent) is coming from, why it's pre-filled and formatted, instead of using the language strings in resources. In bibtex-e, I overrode the display Format Feature, but that was because it didn't look right by default. This mostly looks correct, although it seems hardcoded to use English strings in document display. I haven't yet figured out why because I don't know where doc display is coming from (yet).

File size: 5.0 KB
1name=CDS/ISIS example
3HideCDSrecord=Hide CDS/ISIS record
4CorporateAuthors=Corporate authors
5ShowCDSrecord=Show CDS/ISIS record
8OtherLanguageTitles=Other language titles
15CDSrecord=CDS/ISIS record
16AddedTitle=Added title
21.PersonalAuthors^all=personal authors
22.AddedTitle^all=added title
24.ConferenceMainEntry^all=conference main entry
25.CorporateBodies^all=corporate bodies
27.OtherLanguageTitles^all=other language titles
31.text=raw record
35shortDescription=<p>This collection shows a <a href=";URL_DO=DO_TOPIC&amp;URL_SECTION=201">CDS/ISIS</a> database of bibliography entries. <a href="?a=d&amp;d=_sampleoid_= Here</a> is an example record.</p>
37description1=<h3>How the collection works</h3><p>The <a href="_httpcollection_/etc/collect.cfg" target="collect.cfg">collection configuration file</a> specifies the ISISPlugin plugin, which processes CDS/ISIS databases. These databases have several files, but ISISPlugin uses just three: CDS.fdt (where CDS is the name of the database), containing the field names used in the database, CDF.xrf (a cross-reference file), and CDS.mst, containing the actual records. Whenever ISISPlugin encounters an ".mst" file, it looks for the corresponding ".fdt" and ".xrf" files. In this case the plugin has been given an <i>input_encoding</i> argument because some entries in the database contain extended characters (in a form that was used in early versions of the DOS operating system). It has also been given a subfield separator argument, whose purpose is explained below. The <i>-OIDtype incremental</i> plugin option was used to give identifiers that are consistent across different operating systems (which may not happen with HASH identifiers), so that we can link to a document in this description.</p>
39description2=<p>Like the <a href="?a=p&amp;sa=about&amp;c=documented-examples/bibtex-e">bibliography collection</a>, this collection incorporates a <a href="?a=q&amp;ct=1&amp;qto=3&amp;qt=1">form-based search interface</a> that allows fielded searching. This is specified by the line <i>format SearchTypes "form,plain"</i> in the configuration file; the <i>plain</i> argument ensures that there is a plain textual full-text search feature as well (which can be selected from the <a href="?a=p&amp;sa=preferences">Preferences</a> page). The <i>groupsize 100</i> line puts documents together into groups of 100 (as explained in the <a href="?a=p&amp;sa=about&amp;c=documented-examples/bibtex-e">bibliography collection</a>).</p>
41description3=<p>Some fields in CDS/ISIS databases have subfields. For example, in this case the <i>Imprint</i> field has subfields <i>Imprint.a</i> for place, <i>Imprint.b</i> for publisher and <i>Imprint.c</i> for date. For each field and subfield, ISISPlugin generates a metadata element -- in this case there will be metadata called <i>Imprint^a</i>, <i>Imprint^b</i> and <i>Imprint^c</i>. (There could be a field called just <i>Imprint</i>, although in this case there is not.) ISISPlugin also generates a metadata element called <i>Imprint^all</i> that gives all subfields concatenated together, separated by the character string that was specified as a plugin argument (in this case ", ").</p>
43description4=<p>The designer of this collection has decided to create searchable indexes on all the <i>^all</i> metadata fields, as well as one on <i>text</i> which makes the raw records searchable too. Of course, the designer could have created searchable indexes on any of the subfields instead -- or as well.</p>
45description5=<p>There are two browsing classifiers, an <i>AZList</i> based on <i>Title</i> metadata and an <i>AZCompactList</i> based on <i>Keyword</i> metadata. Recall that the <i>AZCompactList</i> classifier is like <i>AZList</i> but generates a bookshelf for duplicate items. The <i>VList</i> format specification applies to both the search results list and the <i>Title</i> classifier, while the <i>CL2VList</i> puts the number of documents associated with each keyword as described in the <a href="?a=p&amp;sa=about&amp;c=documented-examples/marc-e">MARC example collection</a>. In Greenstone, and in CDS/ISIS, any metadata item can have several different values. The <i>VList</i> specification <nobr><i>sibling(All'; ')</i></nobr> gathers together all the values, separated (in this case) by semicolon.</p>
47description6=<p>The <i>DocumentText</i> format specification incorporates the same mechanism for hiding and showing raw records as explained for the <a href="?a=p&amp;sa=about&amp;c=documented-examples/bibtex-e">Bibliography collection</a>, using the <i>DocumentHeading</i> to show the formatted record and <i>DocumentText</i> to show (or hide) the original database entry.</p>
Note: See TracBrowser for help on using the repository browser.