Changeset 36517
- Timestamp:
- 2022-08-26T19:05:01+12:00 (20 months ago)
- Location:
- documented-examples/trunk
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
documented-examples/trunk/authen-e/resources/collectionConfig.properties
r36437 r36517 1 1 name=Authentication demo 2 textdate=publication date :3 textnumpages=no. of pages :4 textsource=source ref :2 textdate=publication date\: 3 textnumpages=no. of pages\: 4 textsource=source ref\: 5 5 section_chapter=chapter 6 6 document_book=book … … 16 16 shortDescription=Collection demonstrating document-level collection authentication in Greenstone 3. 17 17 18 description1=<p>This demonstration collection contains the same material as the original Greenstone demo collection, but it includes some basic authentication commands. Two documents are publicly available (Farming snails 1 & 2), while the others require logging in to view.</p> <p><center><b> To access this collection try user :</b> <i>demo</i> <b>and password:</b> <i>demo</i></center></p>18 description1=<p>This demonstration collection contains the same material as the original Greenstone demo collection, but it includes some basic authentication commands. Two documents are publicly available (Farming snails 1 & 2), while the others require logging in to view.</p> <p><center><b> To access this collection try user\:</b> <i>demo</i> <b>and password\:</b> <i>demo</i></center></p> 19 19 20 20 description2=<h3>How the collection works</h3><p> The collection configuration file is exactly the same as for the original demo collection apart from the authentication directives, one plugin option (and this description).</p> … … 22 22 description3=<p>The authentication scheme controls access to the collection. It works in two steps. First it determines whether to restrict access to the collection as a whole or to individual documents in it, and in the latter case which documents those are (either by giving a list of private documents for which access is to be authenticated, or specifying that all documents are private except for a given list of public documents). Then for access-restricted documents it determines which user groups are to have access.</p> 23 23 24 description4=<p>Authentication is activated using the <i><security></i> XML element in the collectionConfig.xml file. In the example of the authen-e collection, all <i>document</i>s are set to <i>private</i> access by default, with the <i>exception</i> that they are accessible to logged in members of a <i>group</i> called <i>"demo"</i>. The <i>security</i> element further defines a set of documents (<i>documentSet</i>) called "always-public" which contains 2 documents denoted by their document identifiers/OIDs (fb33fe and fb34fe). This documentSet specifies an exceptional case : the documents in the documentSet are <i>not</i> private access like other documents in the collection are by default, but can instead be accessed by anyone in <i>any</i> group, as no group is specified for their access. \n\24 description4=<p>Authentication is activated using the <i><security></i> XML element in the collectionConfig.xml file. In the example of the authen-e collection, all <i>document</i>s are set to <i>private</i> access by default, with the <i>exception</i> that they are accessible to logged in members of a <i>group</i> called <i>"demo"</i>. The <i>security</i> element further defines a set of documents (<i>documentSet</i>) called "always-public" which contains 2 documents denoted by their document identifiers/OIDs (fb33fe and fb34fe). This documentSet specifies an exceptional case\: the documents in the documentSet are <i>not</i> private access like other documents in the collection are by default, but can instead be accessed by anyone in <i>any</i> group, as no group is specified for their access. \n\ 25 25 <pre><security default_access="private" scope="document"> \n\ 26 26 <exception> \n\ … … 44 44 description7=<p>For more information on authentication in GS3, the different possibilities when using the <i>security</i> element in a GS3 collectionConfig file, and creating new users and adding them to groups, refer to the following pages on the Greenstone wiki \n\ 45 45 <ul> \n\ 46 <li><a href="http ://wiki.greenstone.org/doku.php?id=en:user:authentication">Authentication in Greenstone</a></li> \n\47 <li><a href="http\://wiki.greenstone.org/doku.php?id=en :user_advanced:security">Security in Greenstone Collections</a></li> \n\48 <li><a href="http\://wiki.greenstone.org/doku.php?id=en :user_advanced:gs3_user_management">Greenstone 3 User Management</a></li> \n\46 <li><a href="http\://wiki.greenstone.org/doku.php?id=en\:user\:authentication">Authentication in Greenstone</a></li> \n\ 47 <li><a href="http\://wiki.greenstone.org/doku.php?id=en\:user_advanced\:security">Security in Greenstone Collections</a></li> \n\ 48 <li><a href="http\://wiki.greenstone.org/doku.php?id=en\:user_advanced\:gs3_user_management">Greenstone 3 User Management</a></li> \n\ 49 49 </ul> \n\ 50 50 </p> -
documented-examples/trunk/bibtex-e/resources/collectionConfig.properties
r36516 r36517 29 29 sampleoid_text=13/2004 30 30 31 shortDescription=<p>This collection, which contains 135 BibTeX entries, is a collection of working papers published from 1997 to 2006 at <a href="http ://www.cs.waikato.ac.nz/">Department of Computer Science</a>, <a href="http://www.waikato.ac.nz/">the University of Waikato</a>.</p>31 shortDescription=<p>This collection, which contains 135 BibTeX entries, is a collection of working papers published from 1997 to 2006 at <a href="http\://www.cs.waikato.ac.nz/">Department of Computer Science</a>, <a href="http\://www.waikato.ac.nz/">the University of Waikato</a>.</p> 32 32 33 33 description1=<h3>How the collection works</h3><p>The collection configuration file (the collection\'s <tt>etc/collectionConfig.xml</tt>) begins with the specification <i>groupsize 200</i>. This groups 200 documents together into a single archive file. Bibliography collections typically have many small documents, and grouping them together prevents Greenstone\'s internal file structures from becoming bloated and occupying more disk space than necessary.</p> 34 34 35 description2=<p>Apart from the standard plugins, this collection uses <i>BibTexPlugin</i>, which processes references in the BibTeX format (well known to computer scientists). Two options have been set for BibTexPlugin : <i>-OIDtype assigned -OIDmetadata Number</i>. This means the metadata element "Number" will be used as the record identifier, instead of Greenstone\'s default hash identifiers. These options are available for all plugins.</p>35 description2=<p>Apart from the standard plugins, this collection uses <i>BibTexPlugin</i>, which processes references in the BibTeX format (well known to computer scientists). Two options have been set for BibTexPlugin\: <i>-OIDtype assigned -OIDmetadata Number</i>. This means the metadata element "Number" will be used as the record identifier, instead of Greenstone\'s default hash identifiers. These options are available for all plugins.</p> 36 36 37 37 description3=<p>Fielded searching, with a form-based interface, is selected by <i>format SearchTypes "form,plain" </i> in the configuration file. In fact, a plain textual full-text search index is included in this collection as well (since <i>form</i> comes first, it is the default interface; you reach the <i>plain</i> search through the <i>Preferences</i> page).</p> … … 45 45 description7=<p>This collection contains <i>Title, Author</i>, and <i>Date</i> browsers. The <i>AZCompactList</i> classifier used for the <i>Author</i> browser is like <i>AZList</i> but generates a bookshelf for duplicate items. The BibTeX plugin records each author as <i>Author</i> metadata; it also puts a list containing all authors into the <i>Creator</i> metadata element. Consequently the <i>AZCompactList</i> classifier is based on <i>Author</i>. However, Greenstone has a standard button reading <i>authors</i> whose name is (confusingly) "Creator", so this button name is specified for the classifier.</p> 46 46 47 description8=<p>The format statements for the search results list and the title browser are both determined by the <i>VList</i> specification. It gives a document icon that links to the document itself (which in this collection is the full reference); the title in bold; <i>Creator</i> metadata if there is any, otherwise <i>Editor</i> metadata; and <i>Month, Year</i> metadata if there is any. <a href=http ://localhost:8383/greenstone3/library/collection/bibtex-e/search/FieldQuery?a=q&sa=&rt=rd&s1.level=Doc&s1.case=1&s1.stem=0&s1.matchMode=some&s1.sortBy=1&s1.maxDocs=50&s1.fqv=Jain&s1.fqf=TX&s1.fqv=&s1.fqf=NU&s1.fqv=&s1.fqf=NU&s1.fqv=&s1.fqf=NU&s1.hitsPerPage=20">Here</a> is an example.</p>47 description8=<p>The format statements for the search results list and the title browser are both determined by the <i>VList</i> specification. It gives a document icon that links to the document itself (which in this collection is the full reference); the title in bold; <i>Creator</i> metadata if there is any, otherwise <i>Editor</i> metadata; and <i>Month, Year</i> metadata if there is any. <a href=http\://localhost\:8383/greenstone3/library/collection/bibtex-e/search/FieldQuery?a=q&sa=&rt=rd&s1.level=Doc&s1.case=1&s1.stem=0&s1.matchMode=some&s1.sortBy=1&s1.maxDocs=50&s1.fqv=Jain&s1.fqf=TX&s1.fqv=&s1.fqf=NU&s1.fqv=&s1.fqf=NU&s1.fqv=&s1.fqf=NU&s1.hitsPerPage=20">Here</a> is an example.</p> 48 48 49 description9=<p>The format statement for the author browser (<i>CL2VList</i>) is more complex. The <i>AZCompactList</i> classifier generates a tree whose nodes are either leaf nodes, representing documents, or internal nodes. A metadata item called <i>numleafdocs</i> gives the total number of documents below an internal node. This format statement checks whether numleafdocs exists. If so the node must be an internal node, in which case the node is labeled by its <i>Title</i>. But beware : this classifier is generated on <i>Author</i> metadata, so its title -- the title of the classifier -- is actually the author\'s name! This means that the bookshelf nodes <a href="library/collection/bibtex-e/browse/CL2">here</a> are labeled by author\'s name. The leaf nodes, however, are labeled the same way as documents (i.e. references) are in the search results list.</p>49 description9=<p>The format statement for the author browser (<i>CL2VList</i>) is more complex. The <i>AZCompactList</i> classifier generates a tree whose nodes are either leaf nodes, representing documents, or internal nodes. A metadata item called <i>numleafdocs</i> gives the total number of documents below an internal node. This format statement checks whether numleafdocs exists. If so the node must be an internal node, in which case the node is labeled by its <i>Title</i>. But beware\: this classifier is generated on <i>Author</i> metadata, so its title -- the title of the classifier -- is actually the author\'s name! This means that the bookshelf nodes <a href="library/collection/bibtex-e/browse/CL2">here</a> are labeled by author\'s name. The leaf nodes, however, are labeled the same way as documents (i.e. references) are in the search results list.</p> 50 50 51 description10=<p>The documents themselves (here is an <a href="library/collection/bibtex-e/document/98_9">example</a>) are generated by two format statements, one (a long one) called <i>DocumentHeading</i>, and another called <i>DocumentContent</i>. The <i>DocumentHeading</i>, which is the top two-thirds of the page, contains the document\'s <i>Title</i> followed by a table that gives all the metadata elements that the BibTeX plugin can generate. The role of all the <i>gsf :switch</i> statements in the collection cofiguration file, <tt>collectionConfig.xml</tt>, is to determine which elements are defined.</p>51 description10=<p>The documents themselves (here is an <a href="library/collection/bibtex-e/document/98_9">example</a>) are generated by two format statements, one (a long one) called <i>DocumentHeading</i>, and another called <i>DocumentContent</i>. The <i>DocumentHeading</i>, which is the top two-thirds of the page, contains the document\'s <i>Title</i> followed by a table that gives all the metadata elements that the BibTeX plugin can generate. The role of all the <i>gsf\:switch</i> statements in the collection cofiguration file, <tt>collectionConfig.xml</tt>, is to determine which elements are defined.</p> 52 52 53 53 description11=<p>The <i>DocumentContent</i> has been overridden. When the document is displayed initially, only a hyperlink reading <i>Show/Hide BibTex Record</i> appears -- clicking this invokes JavaScript to toggle the display of the raw BibTex record (showing the BibText version of the reference), which is hidden by default.</p> -
documented-examples/trunk/dls-e/resources/collectionConfig.properties
r36514 r36517 4 4 document_text=entire documents 5 5 document=Document 6 textdate=publication date :7 textnumpages=no. of pages :8 textsource=source ref :6 textdate=publication date\: 7 textnumpages=no. of pages\: 8 textsource=source ref\: 9 9 10 10 11 11 shortDescription=<p>The Humanitarian Development Libraries represent a large collection of practical information aimed at helping reduce poverty, increasing human potential, and providing a practical and useful education for all. This subset contains about 25 publications--documents, reports, and periodical articles--in various areas of human development, from agricultural practice to economic policies, from water and sanitation to society and culture, from education to manufacturing, from disaster mitigation to micro-enterprises.</p> 12 12 13 description0=<p>The editors of this collection are Human Info NGO, HumanityCD Ltd, and participating organizations. Contact us at Humanitarian and Development Libraries Project, Oosterveldiaan 196, B-2610 Antwerp, Belgium, Tel 32-3-448.05.54, Fax 32-3-449.75.74, email <a href=mailto :[email protected]>[email protected]</a>.13 description0=<p>The editors of this collection are Human Info NGO, HumanityCD Ltd, and participating organizations. Contact us at Humanitarian and Development Libraries Project, Oosterveldiaan 196, B-2610 Antwerp, Belgium, Tel 32-3-448.05.54, Fax 32-3-449.75.74, email <a href=mailto\:[email protected]>[email protected]</a>. 14 14 15 15 description1=<h3>How the collection works</h3><p>The DLS collection is fairly complex. If you\'re just starting out you might prefer to look at some other collections first (e.g. <a href="library/collection/wrdpdf-e/page/about">Word and PDF demonstration</a>, or the <a href="library/collection/gsarch-e/page/about">Greenstone Archives</a>, or the <a href="library/collection/image-e/page/about">Simple Image collection</a>).</p> … … 21 21 description4=<p>The other plugins, <i>GreenstoneXMLPlugin, MetadataXMLPlugin, ArchivesInfPlugin, and DirectoryPlugin</i>, are used by Greenstone for internal purposes and are standard in almost all collections.</p> 22 22 23 description5=<p><b>Searchable indexes</b>. The block of lines starting with <i>indexes</i> specifies what searchable indexes will be available. In this collection there are three : you can see them when you pull down the "Search for" menu on the collection\'s <a href="library/collection/dls-e/search/TextQuery">search page</a>. The first index is called "chapters", the second "section titles", and the third "entire documents". The names of these three indexes are given by three properties (section_text, section_Title and document_text) in the translatable <tt>collectionConfig.properties</tt> file located in the collection\'s <tt>resources</tt> subfolder.</p>23 description5=<p><b>Searchable indexes</b>. The block of lines starting with <i>indexes</i> specifies what searchable indexes will be available. In this collection there are three\: you can see them when you pull down the "Search for" menu on the collection\'s <a href="library/collection/dls-e/search/TextQuery">search page</a>. The first index is called "chapters", the second "section titles", and the third "entire documents". The names of these three indexes are given by three properties (section_text, section_Title and document_text) in the translatable <tt>collectionConfig.properties</tt> file located in the collection\'s <tt>resources</tt> subfolder.</p> 24 24 25 description6=<p>The contents of the indexes -- that is, the specification of what it is that will be searched -- are defined by the <i>indexes</i> line at the beginning of this block. This specifies three indexes, two at the section level (beginning with <i>section :</i>) and one at the document level (beginning with <i>document:</i>). The difference is that a multi-word query will only match a section-level index if all query terms appear in the same section, whereas it will match a document-level index if the terms appear anywhere within the document (which typically comprises several sections). The first and third indexes are <i>section:text</i> and <i>document:text</i>, and the <i>:text</i> means that the full text of sections and documents respectively will be searched. The second is <i>section:Title</i>, which means that <i>Title</i> metadata will be searched -- in this case, section titles (rather than document titles). The three indexes appear in the order in which they are specified on the <i>indexes</i> line.</p>25 description6=<p>The contents of the indexes -- that is, the specification of what it is that will be searched -- are defined by the <i>indexes</i> line at the beginning of this block. This specifies three indexes, two at the section level (beginning with <i>section\:</i>) and one at the document level (beginning with <i>document\:</i>). The difference is that a multi-word query will only match a section-level index if all query terms appear in the same section, whereas it will match a document-level index if the terms appear anywhere within the document (which typically comprises several sections). The first and third indexes are <i>section\:text</i> and <i>document\:text</i>, and the <i>\:text</i> means that the full text of sections and documents respectively will be searched. The second is <i>section\:Title</i>, which means that <i>Title</i> metadata will be searched -- in this case, section titles (rather than document titles). The three indexes appear in the order in which they are specified on the <i>indexes</i> line.</p> 26 26 27 description7=<p><b>Classifiers</b>. The block of lines labeled <i>classify</i> define the browsing indexes, called "classifiers" in Greenstone. There are four of them, corresponding to four buttons on the navigation bar at the top of each page in the collection (e.g. the <a href="library/collection/dls-e/search/TextQuery">search page</a>) : <i>subjects</i>, <i>titles</i>, <i>organisations</i>, and <i>howto</i> The <i>search</i> button comes first, then come the four classifiers, in order.</p>27 description7=<p><b>Classifiers</b>. The block of lines labeled <i>classify</i> define the browsing indexes, called "classifiers" in Greenstone. There are four of them, corresponding to four buttons on the navigation bar at the top of each page in the collection (e.g. the <a href="library/collection/dls-e/search/TextQuery">search page</a>)\: <i>subjects</i>, <i>titles</i>, <i>organisations</i>, and <i>howto</i> The <i>search</i> button comes first, then come the four classifiers, in order.</p> 28 28 29 description8=<p>The first classifier provides access by subject. It is a <i>Hierarchy</i> classifier whose hierarchy is defined in the file <tt>etc/dls.Subject.txt</tt> (the <i>hfile</i> argument); this file is discussed below. This classifier is based on <i>dls.Subject</i> metadata, and when several books appear at a leaf of the hierarchy they are sorted by <i>dls.Title</i> metadata (as you can see when you open classifier browser <tt>CL1.4.1</tt>). The second classifier provides access by title. It is also a <i>Hierarchy</i> classifier, this time based on <i>dls.AZList</i> metadata, whose hierarchy is defined in <tt>etc/dls.AZList.txt</tt>. This file is discussed below. The third provides access by organization : it is a <i>List</i> classifier based on <i>dls.Organization</i> metadata. The <i>-bookshelf_type always</i> option creates a new bookshelf for each organization, even if only one document belongs to that category. The fourth provides access by "Howto" text: it is a <i>List</i> classifier based on <i>dls.Keyword</i> metadata. The <i>-bookshelf_type never</i> option prevents bookshelves being created even if two documents share the same keywords.</p>29 description8=<p>The first classifier provides access by subject. It is a <i>Hierarchy</i> classifier whose hierarchy is defined in the file <tt>etc/dls.Subject.txt</tt> (the <i>hfile</i> argument); this file is discussed below. This classifier is based on <i>dls.Subject</i> metadata, and when several books appear at a leaf of the hierarchy they are sorted by <i>dls.Title</i> metadata (as you can see when you open classifier browser <tt>CL1.4.1</tt>). The second classifier provides access by title. It is also a <i>Hierarchy</i> classifier, this time based on <i>dls.AZList</i> metadata, whose hierarchy is defined in <tt>etc/dls.AZList.txt</tt>. This file is discussed below. The third provides access by organization\: it is a <i>List</i> classifier based on <i>dls.Organization</i> metadata. The <i>-bookshelf_type always</i> option creates a new bookshelf for each organization, even if only one document belongs to that category. The fourth provides access by "Howto" text\: it is a <i>List</i> classifier based on <i>dls.Keyword</i> metadata. The <i>-bookshelf_type never</i> option prevents bookshelves being created even if two documents share the same keywords.</p> 30 30 31 31 description9=<p><b>Cover images</b>. Greenstone looks for a cover image for each document, whose name is the same as the document\'s but with a <i>.jpg</i> extension. This image is associated with the document, and may be displayed on the document page (see below). Cover images can be switched off by setting the -no_cover_image flag for each plugin.</p> … … 33 33 description10=<p><b>Format statements</b>. The <i>format</i> elements (<format;>, <browse>, <search> and <display> XML elements), called "format statements", govern how various parts of the collection should be displayed. The <i>VList</i> format statement applies to lists of items displayed vertically, such as the lists of titles, subjects and organisations, and the table of contents for the target documents. It is overridden for the search results list by the <i>SearchVList</i> format statement, and also for the <i>Howto</i> classifier by the <i>CL4VList</i> statement (CL4 specifies the fourth classifier).</p> 34 34 35 description11=<p>The <i>DocumentText</i> statement governs how the document text is formatted, with <i>Title</i> metadata ([<i>Title</i>]) in HTML <i>heading</i> format followed by the text of the document [<i>Text</i>]. By default, cover images are shown with each document (<i>DocumentImages</i>), and the <i>DocumentButtons</i> are available : the <i>Expand Text, Expand Contents, Detach</i> and <i>Highlight</i> buttons are shown with each document.</p>35 description11=<p>The <i>DocumentText</i> statement governs how the document text is formatted, with <i>Title</i> metadata ([<i>Title</i>]) in HTML <i>heading</i> format followed by the text of the document [<i>Text</i>]. By default, cover images are shown with each document (<i>DocumentImages</i>), and the <i>DocumentButtons</i> are available\: the <i>Expand Text, Expand Contents, Detach</i> and <i>Highlight</i> buttons are shown with each document.</p> 36 36 37 description12=<p>Greenstone 3 uses XML for format statements, allowing librarians with XML experience to more easily understand and use format statements than Greenstone 2 which worked with a custom way of specifying format statements. For more information on understanding format statements and writing your own format statements for collections, refer to <a href="http ://wiki.greenstone.org/doku.php?id=en:user:gs3_format_statements">Greenstone 3 Format Statements</a> on the Greenstone wiki.</p>37 description12=<p>Greenstone 3 uses XML for format statements, allowing librarians with XML experience to more easily understand and use format statements than Greenstone 2 which worked with a custom way of specifying format statements. For more information on understanding format statements and writing your own format statements for collections, refer to <a href="http\://wiki.greenstone.org/doku.php?id=en\:user\:gs3_format_statements">Greenstone 3 Format Statements</a> on the Greenstone wiki.</p> 38 38 39 39 description13=<p><b>Collection-level metadata</b>. The <i><displayItem></i> elements under the top-level <i><displayItemList></i> in the configuration file are also standard in all Greenstone collections. They give general information about the collection, defining its name, and a description that appears on its home page. The description text (defined in the translatable <tt>resources/collectionConfig.properties</tt> files) can be seen on the DLS collection\'s home page (this text is part of it).</p> … … 41 41 description14=<p><b>Language translations</b>. In the collection configuration file, lines that look like <tt><displayItem assigned="true" dictionary="collectionConfig" key="..." name="..."/></tt> allow for translatable collection-level metadata, that are defined in the <tt>resources/collectionConfig.properties</tt> text files and can be translated in the same location such as by creating French and Spanish versions (in <tt>resources/collectionConfig_fr.properties</tt> and <tt>resources/collectionConfig_es.properties</tt>, respectively). Note that we advise translators to go through the GTI (Greenstone Translation Interface) system if they want to contribute translations to Greenstone as used by everyone, such as translations to Greenstone\'s demo collections and these documented example collections. The properties files allow for accented characters (e.g. French <i>é</i>). The files are in UTF-8, and these characters are represented by multi-byte sequences (<C3><A9> in this case). Alternatively they could be represented by their HTML entity names (like <i>& eacute ;</i>). It makes no difference for how they appear on the screen.</p> 42 42 43 description15=<p><b>Description tags</b>. The description tags recognized by <i>HTMLPlugin</i> are inserted into the HTML source text of the documents to define where sections begin and end, and to specify section titles. They look like this : <pre> <!-- <Section> <Description> <Metadata name="Title"> Realizing human rights for poor people: Strategies for achieving the international development targets </Metadata> </Description> --> (text of section goes here) <!-- </Section> --> </pre> The <!-- ... --> markers are used to ensure that these tags are marked as comments in HTML and therefore do not affect document formatting. In the <i>Description</i> part other kinds of metadata can be specified, but this is not done for the style of collection we are describing here. Exactly the same specification (including the <!-- ... --> markers) can be used in Word documents too.</p>43 description15=<p><b>Description tags</b>. The description tags recognized by <i>HTMLPlugin</i> are inserted into the HTML source text of the documents to define where sections begin and end, and to specify section titles. They look like this\: <pre> <!-- <Section> <Description> <Metadata name="Title"> Realizing human rights for poor people\: Strategies for achieving the international development targets </Metadata> </Description> --> (text of section goes here) <!-- </Section> --> </pre> The <!-- ... --> markers are used to ensure that these tags are marked as comments in HTML and therefore do not affect document formatting. In the <i>Description</i> part other kinds of metadata can be specified, but this is not done for the style of collection we are describing here. Exactly the same specification (including the <!-- ... --> markers) can be used in Word documents too.</p> 44 44 45 description16=<p><b>Metadata Files</b>. Metadata for all documents in the DLS collection is provided in metadata.xml files, one per document folder. In this collection\'s <tt>import/r0087e</tt> is the <tt>metadata.xml</tt> file for one book -- <i>Income generation and money management : training women as entrepreneurs</i> -- which is a block of about ten lines encased in <<i>FileSet</i>> ... <<i>/FileSet</i>> tags. It defines <i>dls.Title</i>, <i>dls.Language</i>, <i>dls.Subject</i> and <i>dls.AZList</i> metadata. More than one value can be specified for any metadata item. For example, this book has two dls.Subject classifications. Both of these are stored as metadata values for this particular document (because <i>mode=accumulate</i> is specified; the alternative, and the default, is <i>mode=override</i>).</p>45 description16=<p><b>Metadata Files</b>. Metadata for all documents in the DLS collection is provided in metadata.xml files, one per document folder. In this collection\'s <tt>import/r0087e</tt> is the <tt>metadata.xml</tt> file for one book -- <i>Income generation and money management\: training women as entrepreneurs</i> -- which is a block of about ten lines encased in <<i>FileSet</i>> ... <<i>/FileSet</i>> tags. It defines <i>dls.Title</i>, <i>dls.Language</i>, <i>dls.Subject</i> and <i>dls.AZList</i> metadata. More than one value can be specified for any metadata item. For example, this book has two dls.Subject classifications. Both of these are stored as metadata values for this particular document (because <i>mode=accumulate</i> is specified; the alternative, and the default, is <i>mode=override</i>).</p> 46 46 47 47 description17=<p><b>Hierarchy files</b>. Hierarchy files contain a succession of lines each of which has three items. The first item is a text string which is matched against the metadata that occurs in the <i>metadata.xml</i> file described above. The second item is a number that defines the position in the hierarchy. The third item is a text string that describes the node of the hierarchy on the web pages that Greenstone generates.</p>
Note:
See TracChangeset
for help on using the changeset viewer.