...
1.
...
Introduction
...
Document
...
Store
...
is
...
a
...
Document
...
storage
...
repository
...
system
...
with
...
features
...
like
...
checkin,
...
checkout,
...
Ingest
...
,
...
Delete
...
etc
...
for
...
library
...
records
...
such
...
as
...
Bibliographic,
...
Instance
...
(Holdings
...
and
...
Items)
...
etc.
...
Most
...
of
...
the
...
records
...
are
...
in
...
XML
...
format
...
but
...
the
...
Document
...
Store
...
is
...
format
...
agnostic
...
in
...
that
...
it
...
stores
...
the
...
content
...
as
...
is
...
without
...
any
...
type
...
conversion.
...
Furthermore
...
indexing
...
of
...
the
...
stored
...
data
...
is
...
also
...
supported
...
for
...
efficient
...
search
...
and
...
retrieval.
...
Although
...
the
...
Document
...
Store
...
is
...
an
...
independent
...
system
...
that
...
comes
...
with
...
basic
...
UI
...
to
...
enable
...
supported
...
operations,
...
majority
...
of
...
interaction
...
happens
...
from
...
within
...
the
...
code
...
of
...
OLE
...
such
...
as
...
ingest
...
of
...
new
...
records,
...
editing
...
of
...
existing
...
records,
...
search
...
and
...
retrievals.
...
The functionality of Docstore is mostly used by other processes like OLE.
However, for demonstration and testing docstore, a screen is provided with different tabs for different functions of docstore and information about docstore.
Please refer to the docstore application deployed on Dev server:
http://dev.docstore.ole.kuali.org/
...
2.
...
Operations
2.1
...
Summary
Shows the summary of record count for each category, type and formath
2.2 Ingest
Allows storing of documents in the document store. The input should be a Request XML with a standard schema and returns the Response XML with a list of ingested UUIDs.
2.2.1 Sending the request
URL: http://dev.docstore.ole.kuali.org/document
Method: POST
Parameters:
docAction=ingestContent
stringContent=<request.xml as described in the next section>
2.2.2 Request XML
Information about the ingest operation to be performed.
| No Format |
|---|
<request>
<user>ole-khuntley</user>
<operation>ingest</operation>
<requestDocuments>
<ingestDocument id="1" category="work" type="bibliographic" format="marc">
<content>
See section "Sample Input XML for Ingest".
</content>
</ingestDocument>
</requestDocuments>
</request>
|
2.2.3 Receiving the response
HttpResponse should be read and interpreted as given in the next section below.
2.2.4 Response XML
Information about the response from the service for the given request
| No Format |
|---|
<response> <documents> <document id="1" category="work" type="bibliographic" format="marc"> <content> See section "Sample Input XML for Ingest". </content> </ingestDocument> <uuid>10000004</uuid> </document> </requestDocuments>documents> <<user>ole-khuntley</request> {noformat} h3. 2.3.3 Receiving the response HttpResponse should be read and interpreted as given in the next section below. h3. 2.3.4 Response XML Information about the response from the service for the given request {noformat} <response> <documents> <document id="1user> <operation>ingest</operation> <status>Success</status> <message>Documents ingested</message> </response> |
Each document that is ingested will be given a UUID as specified in the response.
2.3 Check-in
Check-in functionality allows to modify the content and metadata (additional attributes) of a document identified by its UUID (Universally Unique Identifier).
2.3.1 Sending the request
URL: http://dev.docstore.ole.kuali.org/document
Method: POST
Parameters:
docAction=checkIn
stringContent=<request.xml as described in the next section>
2.3.2 Request XML
Information about the check in operation to be performed
| No Format |
|---|
<request> <user>ole-khuntley</user> <operation>checkIn</operation> <requestDocuments> <ingestDocument id="10000004" category="work" type="bibliographic" format="marc"> <uuid>8675a422-b6ad-440e-bc0d-9f0dc1526ed2</uuid> </document> </documents> <user>ole-khuntley</user> <operation>batchIngest</operation> <status>Success</status> <message>Documents ingested</message> </response> {noformat} Each document that is ingested will be given a UUID as specified in the response. h2. 2.4 Get UUIDs User can get a sample of UUIDs of documents of any {category, type, format} already ingested. It is useful mainly for demo purposes. h2. 2.5 Check-in Check-in functionality allows to modify the content and metadata (additional attributes) of a document identified by its UUID (Universally Unique Identifier). h3. 2.5.1 Sending the request URL: [http://localhost:9080/oledocstore/document] Method: POST Parameters: docAction=checkIn stringContent=<request.xml as described in the next section> h3. 2.5.2 Request XML Information about the check in operation to be performed {noformat} <content> See section "Sample Input XML for Check in". </content> </ingestDocument> </requestDocuments> </request> |
2.3.3 Receiving the response
HttpResponse should be read and interpreted as given in the next section below.
2.3.4 Response XML
Information about the response from the service for the given request
| No Format |
|---|
<response>
<documents>
<document id="1" category="work" type="bibliographic" format="marc">
<uuid>10000004</uuid>
</document>
</documents>
<user>ole-khuntley</user>
<operation>checkIn</operation>
<status>Success</status>
</response>
|
2.4 Check-out
This operation retrieves the content of a document given its UUID.
2.4.1 Sending the request
URL: http://dev.docstore.ole.kuali.org/document
Method: POST
Parameters:
docAction=checkOut
uuid=<uuid of the document to be retrieved>
2.4.2 Receiving the response
HttpResponse should be read and interpreted as given in the next section below.
2.4.3 Response XML
Content of the document with the given UUID.
2.5 Delete
Deletes a record from DocumentStore based on the given UUID.
2.5.1 Sending the request
URL: http://dev.docstore.ole.kuali.org/document
Method: POST
Parameters:
docAction=delete or deleteWithLinkedDocs
requestContent=<request.xml as described in the next section>
2.5.2 Request XML
Information about the delete operation to be performed. The "Id" attribute of <ingestDocument> should be a valid UUID of a previously ingested document.
| No Format |
|---|
<request> <user>ole-khuntley</user> <operation>checkIn<<operation>delete</operation> <requestDocuments> <ingestDocument id="5325d77a-8221-4fda-a78f-6d2f96e0b059" category="work" 10000004"></ingestDocument> </requestDocuments> </request> |
2.5.3 Receiving the response
HttpResponse should be read and interpreted as given in the next section below.
2.5.4 Response XML
Information about the response from the service for the given request.
| No Format |
|---|
<response> <documents> type="bibliographic" format="marc"> <content> See section "Sample Input XML for Check in". </content> </ingestDocument> </requestDocuments> </request> {noformat} h3. 2.5.3 Receiving the response HttpResponse should be read and interpreted as given in the next section below. \\ h3. 2.5.4 Response XML Information about the response from the service for the given request {noformat} <?xml version="1.0" encoding="UTF-8"?> <OLEDocstore-call> <request> <command>Check-in</command> <params/> </request> <response> <status>Success</status> <message>Successfully checked in </message> </response> </OLEDocstore-call> {noformat} h2. 2.6 Check-out This operation retrieves the content of a document given its UUID. \\ h3. 2.6.1 Sending the request URL: [http://localhost:9080/oledocstore/document] Method: POST Parameters: docAction=checkOut uuid=<uuid of the document to be retrieved> \\ h3. 2.6.2 Receiving the response HttpResponse should be read and interpreted as given in the next section below. h3. 2.6.3 Response XML Content of the document with the given UUID. h2. 2.7 Delete Deletes a record from DocumentStore based on the given UUID. h3. 2.7.1 Sending the request\\ URL: [http://localhost:9080/oledocstore/document] Method: POST Parameters: docAction=delete or deleteWithLinkedDocs requestContent=<request.xml as described in the next section> \\ h3. 2.7.2 Request XML \\ Information about the delete operation to be performed. The "Id" attribute of <ingestDocument> should be a valid UUID of a previously ingested document. {noformat} <request> <user>ole-khuntley</user> <operation>delete</operation> <requestDocuments> <ingestDocument id="715e92f0-b3ab-4263-96d9-58183a23e6d5"><linkedIngestDocuments></linkedIngestDocuments></ingestDocument> </requestDocuments> </request> {noformat} h3. 2.7.3 Receiving the response HttpResponse should be read and interpreted as given in the next section below. \\ \\ h3. 2.7.4 Response XML Information about the response from the service for the given request. {noformat} <response> <documents> <document id="715e92f0-b3ab-4263-96d9-58183a23e6d5"></document> </documents> <user>ole-khuntley</user> <operation>delete</operation> <status>Success</status> </response> {noformat} h2. 2.8 BagIt Requests When the document content is of (non-text or binary) format PDF, DOC etc, (as in the case of License Agreement documents) it is difficult to send it to docstore through a web page. And when the request has to deal with more than one of such documents, it is even more difficult. So, BagIt packaging standard is used to bundle such requests along with the files of these formats. The request can be for ingest, checkin, checkout or delete. This functionality can be demonstrated using the "BagIt Requests" tab in the[http://docstore.dev.ole.kuali.org/oledocstore/|http://docstore.dev.ole.kuali.org/oledocstore/] screen. *To submit a request of this type follow these steps:* 1. Create a folder (e.g. /opt/docstore/upload/bagItRequests/ingest) {link to an attachment of zipped bagItRequests folder with ingest, checkin, checkout, delete folders} (Make sure this folder has write permission for all users.) 2. Create and copy the request.xml and the corresponding binary files into it. 3. Enter the full path of this folder in the text box for "BagIt Requests Directory". 4. Click the Submit button. *How a bagIt request is processed?* The utility code for handling BagIt request creates a 'Bag' (as per BagIt standard) out of the "BagIt Requests Directory". The content of the bag is sent to Docstore via an HTTP connection. Docstore unbags the received content into a temp folder, uses the request.xml to process the files in the temp folder if any. Docstore creates a respose.xml file to record the outcome of the processed request and copies it along with any files that are part of response (in case of checkout) to a temp folder. Then a 'Bag' is created out of the temp folder and sent back to the client. The utility code receives the content from Docstore, unbags the content to a temp folder (e.g. /opt/docstore/upload/bagItRequests/ingest/response). The response.xml along with the temp folder name is to the browser. h2. 2.9 Appendix h3. 2.9.1 Sample Input XML for Ingest {noformat} <request> <user>ole-khuntley</user> <operation>batchIngest</operation> <requestDocuments> <ingestDocument id="1" category="work" type="bibliographic" format="marc"<document id="10000004"></document> </documents> <user>ole-khuntley</user> <operation>delete</operation> <status>Success</status> </response> |
2.6 Bulk Ingest (Admin function)
Bulk ingest process is used for loading the docstore repository with large amounts of document information.
It is usually done by an admin user during off-peak hours to avoid end-users experiencing slow down of docstore.
The input data is copied to a "ole-batchUpload" directory on the server (specified by documentstore.properties)
Go to http://dev.docstore.ole.kuali.org/admin.jsp and 'Bulk Ingest' tab.
Click the button to start the process. Once started, the process runs in background and waits for input files to become available in the "ole-batchUpload" directory.
As soon as a file is available, it is picked up for processing. After a file is ingested it is moved to a ".done" sub-directory and the next available file is picked up.
NOTE: Make sure that input directory ("ole-batchUpload") has the "rwx" permissions for the Tomcat process to create ".done" sub-directory and files. (If unix, run "chmod -R 777 ." in the input directory.)
To verify that the data is stored in DocumentStore, go to URL
http://dev.docstore.ole.kuali.org
Click "Refresh Summary" button in the Summary tab.
Note the count for each DocType.
To verify that the data is indexed in DocStore, go to URL
http://dev.docstore.ole.kuali.org/discovery
Click "Refresh" button in the Summary tab.
Note the count for each DocType.
2.7 Rebuild indexes (Admin function)
Sometimes the indexed data in Docstore may get corrupted. Or the data may need to be reindexed due to changes in indexing criteria and search/sort/facet rules.
In these cases the Docstore data can be re-indexed. This is also done by the Admin user.
Go to http://dev.docstore.ole.kuali.org/admin.jsp and 'Reindex' tab.
Click the 'Start' button to start the process.
Click the 'Status' button to view the status of the process.
Click the 'Stop' button to stop the process. The process is stopped after the current batch of data is reindexed.
To verify that the data is indexed in DocStore, go to URL
http://dev.docstore.ole.kuali.org/discovery
Click "Refresh" button in the Summary tab.
Note the count for each DocType and verify with DocStore count.
2.8 Ingest Binary data (BagIt Requests)
When the document content is of (non-text or binary) format PDF, DOC etc, (as in the case of License Agreement documents) it is difficult to send it to docstore through a web page.
And when the request has to deal with more than one of such documents, it is even more difficult.
So, BagIt packaging standard is used to bundle such requests along with the files of these formats.
The request can be for ingest, checkin, checkout or delete.
This functionality can be demonstrated using the "BagIt Requests" tab in thehttp://dev.docstore.ole.kuali.orgscreen.
To submit a request of this type follow these steps:
1. Create a folder (e.g. /opt/docstore/upload/bagItRequests/ingest) (link to an attachment of zipped bagItRequests folder with ingest, checkin, checkout, delete folders)
(Make sure this folder has write permission for all users.)
2. Create and copy the request.xml and the corresponding binary files into it.
3. Enter the full path of this folder in the text box for "BagIt Requests Directory".
4. Click the Submit button.
How a bagIt request is processed?
The utility code for handling BagIt request creates a 'Bag' (as per BagIt standard) out of the "BagIt Requests Directory".
The content of the bag is sent to Docstore via an HTTP connection.
Docstore unbags the received content into a temp folder, uses the request.xml to process the files in the temp folder if any.
Docstore creates a respose.xml file to record the outcome of the processed request
and copies it along with any files that are part of response (in case of checkout) to a temp folder.
Then a 'Bag' is created out of the temp folder and sent back to the client.
The utility code receives the content from Docstore, unbags the content to a temp folder (e.g. /opt/docstore/upload/bagItRequests/ingest/response).
The response.xml along with the temp folder name is to the browser.
3.0 Appendix
3.0.1 Sample Input XML for Ingest
| No Format |
|---|
<request> <user>ole-khuntley</user> <operation>batchIngest</operation> <requestDocuments> <ingestDocument id="1" category="work" type="bibliographic" format="marc"> <content><![CDATA[ <collection xmlns="http://www.loc.gov/MARC21/slim"> <record> <leader>#####nam#a22######a#4500</leader> <controlfield tag="001">3</controlfield> <controlfield tag="003">OCoLC</controlfield> <controlfield tag="005">20090213152530.7</controlfield> <controlfield tag="008">131031s########xxu###########000#0#eng#d</controlfield> <datafield tag="035" ind1=" " ind2=" "> <subfield code="a">(OCoLC)ocm62378465</subfield> </datafield> <datafield tag="040" ind1=" " ind2=" "> <subfield code="a">DLC</subfield> <subfield code="c">DLC</subfield> <subfield code="d">DLC</subfield> <subfield code="d">HLS</subfield> <subfield code="d">IUL</subfield> </datafield> <datafield tag="022" ind1=" " ind2=" "> <subfield code="a">1729-1070|20</subfield> </datafield> <datafield tag="029" ind1="1" ind2=" "> <subfield code="a">AU@|b000040176476</subfield> <subfield code="b">000040176476</subfield> </datafield> <datafield tag="037" ind1=" " ind2=" "> <subfield code="b">The Managing Editor, BIAC Journal, P.O. Box 10026, Gaborone, Botswana</subfield> </datafield> <datafield tag="042" ind1=" " ind2=" "> <subfield code="a">lc</subfield> </datafield> <datafield tag="043" ind1="1" ind2="0"> <subfield code="a">f-bs---</subfield> </datafield> <datafield tag="050" ind1="0" ind2="0"> <subfield code="a">HD70.B55|bB53</subfield> </datafield> <datafield tag="049" ind1=" " ind2=" "> <subfield code="a">IULA</subfield> </datafield> <datafield tag="210" ind1="1" ind2=" "> <content><![CDATA[ <collection xmlns="http://www.loc.gov/MARC21/slim"><subfield code="a">BIAC j.</subfield> <record> </datafield> <leader>01142cam 2200301 a 4500</leader> <datafield <controlfield tag="001222">92005291</controlfield> ind1=" " ind2="0"> <controlfield tag="003">DLC</controlfield> <controlfield<subfield tagcode="005">19930521155141.9</controlfield>a">BIAC journal</subfield> <controlfield tag="008">920219s1993 caua j 000 0 eng</controlfield></datafield> <datafield tag="010245" ind1=" 0" ind2=" 0"> <subfield code="a">92005291</subfield>>The administration of justice. BIAC journal</subfield> </datafield> <datafield tag="020246" ind1=" 1" ind2=" 3"> <subfield code="a">0152038655 :</subfield> <subfield code="c">$15.95<>Botswana Institute of Administration and Commerce journal</subfield> </datafield> <datafield tag="040260" ind1=" " ind2=" "> <subfield code="a">DLC<>Gaborone, Botswana :|bBotswana Institute of Administration and Commerce</subfield> <subfield code="c">DLC<b">Botswana Institute of Administration and Commerce</subfield> </datafield> <subfield code <datafield tag="d300">DLC</subfield> ind1=" " ind2=" "> </datafield> <subfield <datafield tagcode="042a" ind1=" " ind2=" "> >v. ;</subfield> <subfield code="a">lcac<c">24 cm.</subfield> </datafield> <datafield tag="050300" ind1="0 " ind2="0 "> <subfield code="a">PS3537>v.A618< ;</subfield> <subfield code="bc">A88>24 1993<cm.</subfield> </datafield> <datafield tag="082300" ind1="0 " ind2="0 "> <subfield code="a">811/>v.52</subfield> ;</subfield> <subfield code="2">20<c">24 cm.</subfield> </datafield> <datafield tag="100310" ind1="1 " ind2=" "> <subfield code="a">Sandburg, Carl,<>Semiannual</subfield> <subfield code="d">1878-1967.</subfield> </datafield> <datafield tag="245362" ind1="1" ind2="0 "> <subfield code="a">Arithmetic /> Began in 2004.</subfield> </datafield> <subfield<datafield codetag="c500"> ind1=" " ind2=" "> Carl Sandburg ; illustrated as an anamorphic adventure by Ted Rand. <subfield code="a">Description based on: Vol. 1, no. 1 (May. 2004); title from cover.</subfield> </datafield> <datafield tag="250500" ind1=" " ind2=" "> <subfield code="a">1st ed>Latest issue consulted: Vol. 3, no. 1 (May 2006).</subfield> </datafield> <datafield tag="260650" ind1=" 0" ind2=" "> <subfield code="a">San Diego :<>Industrial management</subfield> <subfield code="b">Harcourt Brace Jovanovich,</z">Botswana</subfield> <subfield code="cv">c1993>Periodicals.</subfield> </datafield> <datafield tag="300650" ind1=" 0" ind2=" "> <subfield code="a">1 v. (unpaged) :<>Occupational training</subfield> <subfield code="b">ill. (some col.) ;<z">Botswana</subfield> <subfield code="cv">26 cm>Periodicals.</subfield> </datafield> <datafield tag="500710" ind1=" 2" ind2=" "> <subfield code="a">One>Botswana MylarInstitute sheetof includedAdministration inand pocketCommerce.</subfield> </datafield> <datafield tag="520850" ind1=" " ind2=" "> <subfield code="a">>DLC</subfield> </datafield> A poem about numbers and their characteristics. Features anamorphic, or distorted,<datafield tag="891" ind1="2" ind2="0"> <subfield code="a">9853|81.1</subfield> drawings which can be <subfield code="a">v.</subfield> <subfield restored to normal by viewing from a particular angle or by viewing the image'scode="b">no</subfield> <subfield code="u">2</subfield> <subfield code="v">r</subfield> reflection in the provided Mylar cone. <subfield code="i">(year)</subfield> </datafield> <datafield tag="650" ind1=" " ind2="0"><subfield code="j">(month)</subfield> <subfield code="aw">Arithmetic<>f</subfield> <subfield code="x">Juvenile poetry.<>05</subfield> </datafield> <datafield tag="650891" ind1=" 4" ind2="01"> <subfield code="a">Children's poetry, American.<>9863|81.1</subfield> </datafield> <subfield code="a">1</subfield> <datafield tag="650" ind1=" "<subfield ind2code="1b">>1</subfield> <subfield code="ai">Arithmetic<>2004</subfield> <subfield code="xj">Poetry.<>05</subfield> </datafield> <datafield tag="650596" ind1=" " ind2="1 "> <subfield code="a">American poetry.<>1</subfield> </datafield> </record> </collection> <datafield tag="650" ind1=" " ind2="1"> ]]> <subfield code="a">Visual perception.</subfield> </datafield>content> <datafield tag="700" ind1="1" ind2=" " <!--optional --> <subfield code="a">Rand, Ted,</subfield><additionalAttributes> <subfield code="e">ill.</subfield> <dateEntered></dateEntered> </datafield> </record> <<lastUpdated></collection>lastUpdated> ]]><fastAddFlag></fastAddFlag> </content> <supressFromPublic></supressFromPublic> </ingestDocument> </requestDocuments> </request> {noformat} <harvestable></harvestable> h3. 2.9.2 Sample Input file for Check In The "Id" attribute of <ingestDocument> should be a<status></status> valid UUID of a previously ingested document. {noformat} <request> <user>ole-khuntley</user><createdBy></createdBy> <operation>checkIn</operation> <requestDocuments> <updatedBy></updatedBy> <ingestDocument id="1" category="work" type="bibliographic" format="marc"> <statusUpdatedOn></statusUpdatedOn> <content><![CDATA[ <collection xmlns="http://www.loc.gov/MARC21/slim"> <record> <statusUpdatedBy></statusUpdatedBy> <leader>01142cam 2200301 a 4500</leader> <controlfield tag="001">92005291</controlfield> <staffOnlyFlag>true</staffOnlyFlag> <controlfield tag="003">DLC</controlfield> </additionalAttributes> <controlfield tag="005">19930521155141.9</controlfield> <linkedIngestDocuments></linkedIngestDocuments> <controlfield tag="008">920219s1993 caua j 000 0 eng</controlfield> <datafield tag="010" ind1=" " ind2=" "> </ingestDocument> </requestDocuments> </request> |
3.0.2 Sample Input file for Check In
The "Id" attribute of <ingestDocument> should be a valid UUID of a previously ingested document.
| No Format |
|---|
<request> <user>ole-khuntley</user> <operation>checkIn</operation> <subfield code="a">92005291</subfield><requestDocuments> </datafield> <datafield tag="020" ind1=" " ind2=" <ingestDocument id="1" category="work" type="bibliographic" format="marc"> <subfield code="a">0152038655 :</subfield> <content><![CDATA[ <collection xmlns="http://www.loc.gov/MARC21/slim"> <record> <leader>01142cam 2200301 <subfield code="c">$15.95</subfield>a 4500</leader> </datafield><controlfield tag="001">92005291</controlfield> <datafield<controlfield tag="040" ind1=" " ind2=" "> <subfield code="a">DLC</subfield>003">DLC</controlfield> <subfield code<controlfield tag="c005">DLC<>19930521155141.9</subfield>controlfield> <subfield code<controlfield tag="d008">DLC</subfield>>920219s1993 caua j 000 0 </datafield>eng</controlfield> <datafield tag="042010" ind1=" " ind2=" "> <subfield code="a">lcac<>92005291</subfield> </datafield> <datafield tag="050020" ind1="0 " ind2="0 "> <subfield code="a">PS3537.A618<>0152038655 :</subfield> <subfield code="b">A88 1993<c">$15.95</subfield> </datafield> <datafield tag="082040" ind1="0 " ind2="0 "> <subfield code="a">811/.52<>DLC</subfield> <subfield code="c">DLC</subfield> <subfield code="2d">20<>DLC</subfield> </datafield> <datafield tag="100042" ind1="1 " ind2=" "> <subfield code="a">Sandburg, Carl,</subfield> <subfield code="d">1878-1967.<>lcac</subfield> </datafield> <datafield tag="245050" ind1="10" ind2="0"> <subfield code="a">Arithmetic /<>PS3537.A618</subfield> <subfield code="c"> b">A88 1993</subfield> </datafield> <datafield tag="082" ind1="0" ind2="0"> Carl Sandburg ; illustrated as an anamorphic adventure by Ted Rand.<subfield code="a">811/.52</subfield> < <subfield code="2">20</subfield> </datafield> <datafield tag="250100" ind1=" 1" ind2=" "> <subfield code="a">1st ed.>Sandburg, Carl,</subfield> <subfield code="d">1878-1967.</datafield>subfield> </record> </collection>datafield> <datafield tag="245" ind1="1" ind2="0"> ]]> <subfield code="a">Arithmetic /</subfield> </content> </ingestDocument> <subfield code="c"> </requestDocuments> </request> {noformat} h3. 3. Search This functionality allows documents to beCarl searchedSandburg for; byillustrated givingas an keywordsanamorphic oradventure phases.by SearchingTed canRand. be based on category, type, format, search fields. h4. *3.1 Quick Search* Select Doc Category : Work Doc Type : Bibliographic Doc Format : ALL Searching on default condition(click search button without specifying any conditions) will give all the records in search result page. Select Doc Category : Work Doc Type : Bibliographic Doc Format : MARC Type one or more keywords in a text box. System shows records with any field matching one or more keywords. h4. *3.2 Advanced Search* Select Doc Category : Work Doc Type : Bibliographic Doc Format : MARC The drop down for search fields will be populated based on the category selected above. User specifies a search condition: Selects a field. Enters one or more keywords. Specifies whether the keywords should be searched for as "All of these", "Any of these" or "As a phrase". "All of these" - Any record with the selected field having all the entered keywords is included in the search results. "Any of these" - Any record with the selected field having at least one of the entered keywords is included in the search results. "As a phrase" - Any record with the selected field having all the entered keywords in same order is included in the search results. User adds another condition: Chooses whether to apply this condition in addition to the previous one ("AND") or to apply this condition as an alternative to the previous one ("OR") ("NOT"???), "AND" - the conditions before and after this operator should be satisfied. "OR" - one of the conditions before and after this operator should be satisfied. "NOT" - the condition after this operator should not be satisfied. User repeats previous step as many times as needed using the ADD and DELETE links. \[+\]ADD : click on this link to add fields for a new search condition. \[-\]Delete : click on this link to delete the last search condition. Search is performed based on the conditions entered by the user. For more information refer to the "Search" section in the document :[ </subfield> </datafield> <datafield tag="250" ind1=" " ind2=" "> <subfield code="a">1st ed.</subfield> </datafield> </record> </collection> ]]> </content> </ingestDocument> </requestDocuments> </request> |
4. Search
This functionality allows documents to be searched for by giving keywords or phases. Searching can be based on category, type, format, search fields.
4.1 Quick Search
Select Doc Category : Work
Doc Type : Bibliographic
Doc Format : ALL
Searching on default condition(click search button without specifying any conditions) will give all the records in search result page.
Select Doc Category : Work
Doc Type : Bibliographic
Doc Format : MARC
Type one or more keywords in a text box.
System shows records with any field matching one or more keywords.
4.2 Advanced Search
Select Doc Category : Work
Doc Type : Bibliographic
Doc Format : MARC
The drop down for search fields will be populated based on the category selected above.
User specifies a search condition:
Selects a field.
Enters one or more keywords.
Specifies whether the keywords should be searched for as "All of these", "Any of these" or "As a phrase".
"All of these" - Any record with the selected field having all the entered keywords is included in the search results.
"Any of these" - Any record with the selected field having at least one of the entered keywords is included in the search results.
"As a phrase" - Any record with the selected field having all the entered keywords in same order is included in the search results.
User adds another condition:
Chooses whether to apply this condition in addition to the previous one ("AND") or to apply this condition as an alternative to the previous one ("OR") ("NOT"???),
"AND" - the conditions before and after this operator should be satisfied.
"OR" - one of the conditions before and after this operator should be satisfied.
"NOT" - the condition after this operator should not be satisfied.
User repeats previous step as many times as needed using the ADD and DELETE links.
[+]ADD : click on this link to add fields for a new search condition.
[-]Delete : click on this link to delete the last search condition.
Search is performed based on the conditions entered by the user.
For more information refer to the "Search" section in the document :https://wiki.kuali.org/display/OLE/OLE+Search+Technical+Documentation
...