Iguana – Search
1 Introduction
1.1 Supported search applications and components
Iguana supports multiple applications that are related to search functionality, - most of which are interrelated. The supported applications are:
· Search profiles / Search (complete) : Search as a process that stands more or less on its own; this encompasses also the underlying technique of all search applications; this includes searching in the local (bibliographic) collection, searches in the website (content) and searching in external sources
· Search boxes : the capability to include a search box on any page; if the search is submitted, the result hooks in to search (complete); the search boxes can (in principle) be included on any page and at any location on a page; search boxes are defined as an RTI (Rich Text Item) via the RTE (Rich Text Editor)
· Direct search : the capability to include search results on (in principle) any page without the need to formulate a search request first (this is used to include on [e.g.] a news item page a search result set that is related to the news item, e.g. a news item on the author Joey Fagan does not only contain static information, but also includes a result set with books written by Joey Fagan, from the local collection)
· Search trees : these are multi-level “trees” of hyperlinks (often presented as images) that lead to all kinds of information (e.g. to search results or to external sites); the user does not have to actively produce a search term, - he does so by clicking on hyperlinks (text or images)
· Search URL's : the capability to construct URL's, that can be included in Iguana pages as hyperlinks
· Selected for you : this is a non-search application that gives access to new items in the library, which we include in this list because it resembles closely the actual search applications
Apart from Advanced search, there is also the Expert search, as well as customer-defined search methods (using the search method parameter object) where Advanced search has a special, quite extensive, structure while Expert search is actually equivalent to a "pre-cooked" search method supplied by Infor.
1.2 Comparison of search applications and components
The following chart contains an overview of the available components of Search. These can be grouped into two categories: on the left there are multiple search features that allow the customer to define his search request and launch a search. At the right you see multiple Search components and related topics that execute a search based on a predefined search request, - i.e. it is not the user who defines the search term, but the search is executed automatically based on settings in the CMS.
1.3 What Search facilities are there?
“Search” covers a broad range of search facilities. These are:
· Search profiles / Search (complete)
· Search boxes
· Direct search & search filters
· Search trees
· Search URL's
· Selected for you: a non-search application that gives access to new items in the library and is based on Interests. It is included in this list because it resembles the actual search applications.
All these features are described in this section of the documentation, with the exception of Selected for you, which is described in the document on Interests.
1.4 Autocomplete
Autocomplete is that when you type something in a search form, search queries are proposed based upon assumptions about what you could want to type.
It is used more and more in search engines. See also: http://en.wikipedia.org/wiki/Autocomplete
An API has been developed to allow Iguana to query for autocomplete. It is configured via the Vubis client in AFO 616 – API Autocomplete.
How does this work?
We apply the history of search queries as stored on the Vubis system. When somebody types something that has never resulted in a positive search result, we try and find an alternative, and propose queries based on the alternative.
The autocomplete indexes contain all searches except for databases and indexes excluded via the settings.
The API can search without index, or with index, with restrictions, with database and with partial index.
If the API has an index/restrictions/database/partial parameter, the queries in the autocomplete indexes are matched against the bibliographic and authority indexes, according to these criteria. This matching is done via regular queries. A temporary request id is used. This is immediately removed after the search. Left-over entries are removed during the indexing.
Note
Autocomplete is only applicable to simple search.
2 Search flow
2.1 Search flow & Search widgets
In essence, a search typically consists of three steps:
· Step 1: the search box – the user formulates his search
· Step 2: the result set – the result set is displayed and the user selects a record
· Step 3: the full record – the full record is displayed, including data enrichment and mashups
Each of these steps combines a number of widgets. These are:
2.2.1 Step 1 (search box) widgets
The following widgets are available:
· Simple search
· Advanced search
· Expert search
· Other library defined search methods
· Browse search
· Additional widgets (such as Animations, Word clouds or Rich Text Items)
2.2.2 Step 2 (result set) widgets
The following widgets are available:
· Result set
· Facets
· Associations
· Wikipedia word cloud related terms
· Options, with links to the various search results in case a search was done in multiple sources simultaneously
· Links to “external” resources
· 0 hits alternatives
Licence information
Note that Associations (Search) is not a standard part of the Iguana application. It requires a specific license and must be installed and activated separately. Please contact your account manager for pricing and installation information.
2.2.3 Step 3 (full record) widgets
The following widgets are available:
· Brief metadata
· Full metadata
· Link resolver links
· Related works
· Reviews
· Who borrows this, also borrows
· Holdings details
· Mashups
· Image viewer
2.3 Server-side and client-side
The functionality that is offered by Search is a combination of server-side and client-side features.
In general the search functionality depends primarily on server-side configuration. Which indexes are available, which facets are supported, whether or not truncation is supported, etc. – most of these features depend on server-side configuration and functionality, although a number of search parameters can be defined in search profiles and search methods.
In general, the following applies: functionality depends on the server-side, presentation on the front-end (client-side). In practice, there are some exceptions to this “rule”, which will be noted in this chapter of the documentation.
2.4 How to access search from the navigation menu
If you want to create a specific Search page and include it in the main navigation menu, you have two ways to add the link to a menu item:
· add a direct link to the page (e.g. using the page's )
· add a for the page (e.g. www.main.cls?sUrl=search), - assuming you have created this Short URL.
See the chapter Menu property overview & options of the "Pages and Profiles" document for more information on how to add items to a navigation menu.
Search boxes allow the user to define the search request and launch a search. Direct search, Search trees and Search URLs execute a pre-defined search based on settings in the CMS.
Note
It is also possible to call up a specific profile directly in the URL, e.g.:
...?sUrl=search#searchProfile=Myprofile
See the next section for more information on search profiles.
3 Configuration: search profiles
Many of the texts displayed for Search can be modified in the CMS – General & Tools – System texts. The modules start with Search.
3.1 What are Search profiles?
Search profiles can be used to implement multiple instances of Search. A Search Profile contains a number of properties that define how search works (e.g. is there an Advanced Search option, which Search filters are available, - and others).
If no Search profile is defined, a default set of parameters will be used.
Search profiles can be used to offer multiple different search facilities, which may be useful in specific cases. A typical example is e.g. “searching for kids”, which is offered in a Kids website (Kids site profile), and “default searching”, which is offered in the default website (default site profile). In such an example “searching for kids” would have no link to Advanced search, a simpler display of bibliographic metadata, - and others.
3.2 Search profiles overview
If you select the Search profiles option from the Content – applications section of the navigation menu, the list of existing Search profile instances is displayed. This display uses a generic element in the Iguana CMS, - the overview page of instances of a specific data type.
The Search profile instances overview page is described in the chapter Instances overview page of the "Management common workflow" document.
The options on the Search profile instances overview page are described in the chapter Options on the instances overview page of the "Management common workflow" document.
3.3 Overview of property groups and options
Search profiles have the following property groups:
· Basic settings
· Advanced settings
· View permissions and restrictions (*)
· In use by (*)
· Previous versions (*)
The property groups marked with (*) are described in the chapter Generic application properties of the "Management common workflow" document.
Each of these property groups forms a separate section on the Search profile details page. Each section can be collapsed or expanded by clicking on its title. The and buttons can be used to expand or collapse all sections.
3.4 Basic settings
The basic settings of Search profiles are:
Define the basic settings as follows:
Id: The unique ID of the search profile.
WebOpac profile: The WebOpac profile that is linked to the Search profile. This is meant for the API, which uses settings of the WebOpac profile “behind the scenes”.
Search filters: The Search filters that can be used for this Search profile.
Default filter: The default Search filter that should be used.
The Search profile allows you to define which search facilities are available for the profile. This is the case for the following options.
Advanced search option: The ability to link to the Advanced search option.
Expert search option: The ability to link to the Expert search option.
Browse search option: The ability to link to the Browse search option.
Custom search methods: This refers to the defined search methods using the special parameter object Search method (see elsewhere in this document for more information). By selecting them here, they come available as a hyperlink under the search methods.
Available indexes for advanced/expert search: You can indicate which indexes are offered on the Advanced and/or Expert search page.
Available databases for advanced/expert search: You can indicate which databases are offered on the Advanced and/or Expert search page.
Available indexes for browse: You can indicate which indexes are offered on the Browse search page.
Tree storage: The tree storage allows you to organize your content in a hierarchic folder structure. You can define a maximum of five levels in the storage tree. (See below for some more information on Tree storage.)
In use: You can set this search profile to Not in use. (The property is reserved for future use.)
Title (English): This is the title of the Search profile. The title is only relevant in the context of the CMS, but has no implications on the Iguana front-end framework.
Keywords (English): You can define keywords (tags) that are relevant for this Search profile. These keywords will be inserted into the HTML page as meta tag keywords, which can improve your ranking in search engines (SEO).
Notes (English): You can add notes to the application instance. These notes are for internal use only; they are not displayed in the Iguana front-end
|
|
The tree storage allows you to order content in a hierarchical tree structure with a maximum of five levels. If you want to add existing content to a Page e.g., you can select the content from a treeview. The tree storage allows you to organize content that is ordered via the tree storage. The tree storage is optional. Content that is not placed in the tree storage is added at the top level of the treeview. |
3.5 Advanced settings
The advanced settings of Search profiles are:
Created by: This is the person who created the Search profile instance and the date on which it was created. You cannot modify these properties.
Modified by: This is the person who last edited the Search profile instance and the date on which it was modified. You cannot modify these properties.
Unique id: This unique id of the Search profile is used for internal purposes only. You cannot modify it.
Note
Through the Parameter Object Search method you can optionally define search screens in a flexible manner.
See Section 11.
4 Configuring a search box page
4.1 Simple search
4.1.1 Two types of Search boxes
Iguana supports two types of Search boxes, one which we call “Search complete” search box and another one which we call “Rich Text Item” (RTI) search box.
The “Search complete” variant is part of the whole search workflow and loads a significant amount of (JavaScript) files before the widget can be displayed. The RTI search box on the other hand is, as the name says, an implementation of an RTI, and loads no specific software. In the latter case, the JavaScript files for Search are only loaded when the result set is displayed. As such, it is advised to use the RTI search boxes whenever possible, because they are much more lightweight and have a smaller impact on performance.
Please also note that there can only be one “Search complete” search box on a page, while there can be multiple “RTI Search boxes” on a page. A practical use of including multiple search boxes on a single page could e.g. be that you include on a page (a) a search box that searches in the whole collection and (b) another one that performs a search in only a part of the collection.
[ Please note that a similar, but not identical, result can be created if you link to a Search box a Search Profile that has multiple Search Filters attached to it. This is explained later in this chapter. ]
4.1.2 “Search complete” search boxes: client-side configuration
A (simple) search page has the following components:
· a search box and a button (Simple search)
a link to (optional)
· a link to (optional)
links to library specific search methods (optional)
· a link to (optional)
· (optional)
· [optionally] any application instance (e.g. a featured items animation, a word cloud or a Rich Text Item (RTI) ; some restrictions may apply)
Please see below for the configuration aspects of an page.
Example of a Search complete box in the front-end:
4.1.3 “RTI” search boxes: client-side configuration
RTI Search boxes are defined via the Rich Text Editor. You can define them as follows:
1. Select Applications > Rich Text Items, from the navigation menu
2. Create a new Rich Text Item (RTI). Define its standard properties such as In use, Title, Keywords and others.
3. In the Rich Text Editor (Content section), select the Insert button.
4. This will invoke an input form that allows you to define two properties: urlParams (URL parameters) and a Search Profile. The properties are described below.
5. When you submit the form, the text box will be displayed in the Rich Text Item in the Rich Text Editor, but only as a token (i.e. not as its final representation in the actual Iguana front-end). You can now add additional texts to the RTI, e.g. texts that are shown before or after the text box.
You can define the Search box properties as follows.
urlParams : You can define a string of URL parameters that define the values of the search. The valid URL parameters are the ones described in section 8 – Search URL's.
The URL parameters that are defined here will be added to the search term that the user enters. The search term itself will be added to the URL parameters as the “searchTerm” URL parameter. The concatenated parameters are used to construct a .
Example: if the urlParams value is defined as XXX=YYY and the user enters the search term “Beatles”, the URL that is constructed will be:
?sUrl=search#searchTerm=beatles&XXX=YYY
SearchProfile : You can select a Search profile from the list of available search profiles.
There are three cases.
· If the Search Box is linked to a Search Profile that contains no Search Filter, the search will automatically be run in the full bibliographic collection.
· If the Search Box is linked to a Search Profile that contains one Search Filter, the filter will automatically be applied to the search. If the filter defines e.g. “material type = DVD”, then the search will only retrieve DVD's.
· If the Search Box is linked to a Search Profile that contains more than one Search Filter, a dropdown box will be shown in the Iguana front-end. The user can then make a choice from the available options and as such restrict his choice.
Note
|
|
If you define both urlParams and Search Profile, only the Search Profile setting will be evaluated. The urlParams will be neglected. |
Example of an RTI Search box in the front-end:
The dropdown list contains various predefined search filters:
4.2 Advanced search
4.2.1 Client-side configuration
An advanced search page has the following components:
· one or more occurrences of:
- a search box “search for all these words”
- a search box “search for literal text” (phrase searching)
- three search boxes “one or more of these words”, which are combined as a Boolean OR
- a search box “do not include one of these words” (Boolean not)
- a choice of index
· a button to add an additional occurrence of the above fields; the occurrences will be combined as a Boolean AND combination
· a link to
· a link to (optional)
links to library specific search methods (optional)
· a link to (optional)
· a button
· a number of checkboxes for database selection (optional), and another optional checkbox for selection of the website content as search target.
· [optionally] any application instance (e.g. a featured items animation, a word cloud or a Rich Text Item (RTI) ; some restrictions may apply)
Please see above for the configuration aspects of a page.
Of the above components, all except the optional ones are “fixed” at the programmatic level. You have however control over the presence or absence of additional applications such as word clouds, animations, Rich Text Items or others.
See section 4.1 (Simple search) for more information about the client-side configuration.
Example of an Advanced search form in the front-end:
4.3 Browse vs. Find
By default, Iguana supports Find searches. Browse searching is not supported by default, but can be configured via an interactive system setting in the Search Profile (in the CMS).
The Browse search box consists of the following elements:
· search box + submit button
· choice of index
If Browse searching is activated, it uses the server-side settings as for Find searches.
Example of a Browse search form in the front-end:
4.4 Expert Search
It is also possible to offer a so-called Expert Search.
To enable this the parameter Expert search must be activated under Content – applications – Search profiles.
Based on the following example, an explanation is given how Expert search can be configured:
In the above example, a system-search method is used, similar in structure to the specific search methods such as can be defined under the appropriate parameter object.
A Search profile is defined, where:
- the parameter Expert search option is ON
- the appropriate Parameter object has been selected under Custom search methods
Another option is to indicate under Parameters – Parameter setup – Search – Search start screen – Search modes that Expert search must be offered. In that case Expert search is also based on a standard built-in search method.
Under Parameters – Parameter setup – Search – Search start screen you can define the Restrictions for expert search. One of the restrictions you can select is Item statistical category. Specific values can be selected if the total number of values does not exceed the threshold defined in AFO 651 – Miscellaneous cataloguing parameters.
5 Configuring a result set page
Below is a description of the configuration options.
5.1 Client-side configuration
The result set page has the following components:
· Result set (local collection)
· Result set (website)
· Result set (federated search)
· Facets
· Associations
· Wikipedia word cloud related terms
· Options, with links to the various results if a simultaneous search in multiple sources was executed
· Links to “external” resources
· 0 hits alternatives
· any application instance (e.g. a featured items animation or a Rich Text Item (RTI); some restrictions may apply)
All these components are optional. However, in almost all cases it would be quite nonsensical not to include e.g. the actual result set.
You can define the presence or absence of each of the components and their location on the page. Typically, the page would have two “sections”: one containing the actual search result set(s), and a second one containing the actions related to the result set(s), such as facets or associations. There is however no prescribed approach to how you configure the result set page.
The actual layout of the page is determined by the template that is used to render the page.
Please note that the actual order and location of these widgets on the page cannot be modified via the CMS. Such changes will have to be made by Infor.
The client-side templates that are used on the result set page are:
|
resultlist |
used for the “default” result set display (covers and text) |
|
resultlistcover |
used for the “cover only” result set display |
|
resultlisttext |
used for the “text only” result set display |
These can be accessed via Structure & Style, option Templates.
The other widgets on the result set page (such as Facets and Associations) have no template associated to them, i.e. their display is fixed.
5.2 Other configuration
You can configure multiple aspects of the result set and other components on the page as described below.
5.2.1 Result set (local bibliographic collection)
This is described in section 6 (Configuring the full record page).
5.2.2 Facets
This is configured under Direct search & Search filters (see section 9), where restrictions and facets per database can be selected. Also, some restrictions may in fact be a combination of a number of other restrictions, e.g. multiple locations, or multiple years of publication
Warning: facets on item-related data
|
|
Please note that facets are always evaluated at bibliographic record level. This has implications on the way facets on item-related data are evaluated. An example will illustrate this. Record 1001 has genre th (thriller). To record 1001 are attached items 123 (material type A, location X) and 234 (material type B, location Y). I search and record 1001 is in the result set. The facets are now: · genre th · material types A and B · locations X and T As said, the facet storage and evaluation is done at bibliographic level, which implies the following. If a user applies facet “material type = A” and “location = “Y”, record 1001 will still be displayed because this is a bibliographic record for which there is a material type A item and a location Y item. However, as you can see from the above explanation, there is not a record that has both material type A and location Y. |
5.2.3 Default (and alternative) sorting
The default sorting field and sort direction are defined under Parameters – Parameter setup – Search – Search results.
5.2.4 Wikipedia word cloud related terms
The related terms that are included in the Wikipedia word cloud are derived from a Wikipedia site. You can define which site needs to generate the Wikipedia related terms by defining its URL in Parameters – Parameter setup – Search – Search URL's. See the document on Parameters for more information.
5.2.5 Link to “external” resources
The Link to “external” resources is a link that you can add to the Result set page. The link offers the user the option to continue his search in an external site. You can define this link via the CMS, Parameter objects “Internet search link” and next via “Search – Search result – Internet search” (where the appropriate objects can be selected for use).
You can insert a “${1}” replacement token within the URL at the place where the search term should be added, e.g. http://www.google.nl/search?q=${1}.
Example: the search term “beatles” will be transformed to http://www.google.nl/search?q=beatles.
5.2.6 Federated search
Iguana can integrate Federated search targets in its Advanced search or Expert search. Federated search is not a standard part of Iguana and requires an additional license.
The search targets that are “interrogated” operate via so-called connectors, which cannot be defined via the CMS. It is Infor that will have to define the search targets.
Once the connectors have been defined, the external search sources can be defined through the Parameter Objects, and then used as database in a search source parameter object definition, therefore this is a process in three steps.
Federated search is discussed in more detail in the document on Mashups.
Special search sources.
For Dutch customers NBC (BNL) is available as a search source, provided they have a license.
In France there is a supplier of digital information (CVS).
There is also a "full text" search method associated with DAM (Digital Asset Management).
5.3 Searching in multiple sources
The result of searching in multiple sources is displayed only one search results display widget.
The results from the other sources will be clearly visible as links in the options widget - clicking such a link will load the corresponding results into the results display widget.
This has the advantage that you can see at once how many results there are for every searched source.
The search screen will be hidden when the search results are displayed. That way it does not hide the view of (part of) the search results. Clicking a button in the options widgets will show the search screen again – this button is part of the block in which the different results are displayed. If there is just one result, no links to other results are available and only the button is shown.
There is also an parameter in the search method objects: “User can select databases”.
If this parameter is NOT checked, all selected databases of the search method will be used simultaneously and automatically for every search, and there will be no checkboxes with database selection on the search screen.
5.3.1 Combined search results
Search results from multiple sources can be presented in a single result list.
Under Parameters – Parameter setup – Search – Search results the parameter “Combine search results from multiple sources” can be found. This can be set to Yes for advanced / expert searching and also for any definition of a Parameter Object Search Method.
This option shows results from the different sources in a single results list, where the number of records displayed for each source depends upon a “Weight” parameter that can be set in the database object. Its maximum value is 100. For instance, if you search in 3 databases at the same time, and you have assigned weights A=100, B=60, C=40, then the results list will display 5 records for A, 3 for B and 2 for C (provided there are enough records found). The groups of records have a header that indicates the source where they come from.
Records are retrieved in relevance order (this of course is implemented by every source in its own way).
Under Parameters – Parameter setup – Search – Search results (advanced) the parameter “Combined results display timeout in seconds” can be found, which is the maximum number of seconds that the application will wait for the results from the different sources. If a source has not responded within that time, its results (if any) are discarded and the combined results of the other sources are displayed.
Options
For the local database records, not all options from the individual results list are available; the “Reserve” and “Add to readinglist” options are available at the record level though.
Switching between combined search and sources
You can switch at any time between the combined results list and the individual results list for the sources.
Restrictions
Restriction headers that are not from the local database have a suffix indicating the source. Executing a restriction will only modify the results of the source it belongs to.
Website
The web site results can not be shown in the combined list, but the web site can be included in the search and will then be available as a link in the list of sources, just like the other search sources.
5.4 Relevance ranking
Relevancy Sort is a real time sort based primarily on the content of the record, and secondarily on the Performance Sort index.
A special index has been created for this purpose.
When the user searches in the all words index (simple search), a set of queries is performed to establish a weighting factor for the records found:
A string search is done is in the all words index.
A string search is done in other indexes defined in the relevancy settings.
Each record found gets points based upon the presence in the indexes. When enough records are found to display the number of requested records, it stops there. When the user browses in the result set and more records are needed, the rest of the results is retrieved.
For records with the same number of points, the Performance is used as secondary sort. This special Performance sort index is created by the installation process (of Iguana).
The Performance Sort index counts the number of loans and reservations.
6 Configuring a full record page
Below is a description of the configuration options.
6.1 Client-side configuration
The full-record page has the following components:
· Brief metadata
· Full metadata
· Link resolver links
· Related works
· Reviews
· Who borrows this, also borrows
· Holdings details
· Mashups
· Image viewer
The display of metadata is handled via client-side templates for metadata display. These can be accessed via Structure & Style, option Templates. The client-side template determines which information is displayed, in which order and at which location.
The client-side templates that are used on the full-record page are:
|
recorddisplay |
used for the initial bibliographic metadata display |
|
recorddisplayfull |
used for the “full” (or extended) metadata display; if you include only the hash sign (#) in the template, then the widget will not be displayed. |
|
relations |
used for linked records |
|
relatedworks |
used for related works (based on circulation data analysis or metadata analysis) |
Reviews and Items details have a fixed display, i.e. no templates are used for their display.
6.2 Other configuration
6.2.1 Templates to define the metadata content
An Iguana full-record page can have two sections that display (bibliographic [and holdings]) metadata, - typically these are used for a brief display (at the top of the page) and a full, more extensive display (at a lower position on the page). The data elements that are included in both display types are defined in server-side templates.
The template that determines the content of the brief display is called Iguana_Brief[Format], while the one that determines the full display is called Iguana_Full[Format]. (If the format's name is Smart, these are Iguana_BriefSmart and Iguana_FullSmart.) You can change these templates to add data elements to a template, - or to remove them.
6.2.2 Link resolver links
You can include “inline links” that are generated by an OpenURL link resolver on the full-record page. This functionality is supported by V-link, Infor's OpenURL link resolver.
You can define the location of the OpenURL generator by defining the URL of its location in the General settings under General & Tools. See the document on General & Tools for more information.
6.2.3 Rate & Review
The Rate & Review functionality can be configured via Parameters – Parameter setup – Search – Rate & Review.
6.2.4 Holdings
You can configure a number of aspects of the holdings display:
· which shelfmarks are included in the shelfmark display
· the order in which shelfmarks are displayed in the shelfmark display
· which item data elements are displayed in the item details overview.
You can define for which institutions/locations the shelfmarks should be displayed and the order in which they should be displayed via Parameters – Parameter setup – Search – Title display.
6.2.5 Related works
Please contact Infor for assistance in setting this up.
7 Search trees
Search trees are multi-level “trees” of hyperlinks (often presented as images) that lead to all kinds of information (e.g. to search results or to external sites); the user does not have to actively produce a search term, - he does so by clicking on hyperlinks (text or images)
Search trees are defined via WebOpac Preferences, where they can be defined either manually or via import from a spreadsheet (CSV format).
The following screen example shows a search tree widget on an Iguana page. The search tree is visually represented as a set of images, which are clickable and lead to the next level in the tree, to a search result in Iguana or to a web page (inside or outside of the Iguana site).
You can include a search tree on a page by adding a link that has the following structure: http://baseURL/IguanaNamespace/www.main.cls?sUrl=search#app=Tree&treeId=KidsTree&TreePageName=Animals
This URL will open the page “Animals” of the search tree “KidsTree”and display it on the default Iguana search page.
Adding a search tree to a page cannot be done via the CMS; this needs to be configured by Infor.
Note
Browse type searching is not supported for search trees.
8 Search URL's
A search in Iguana can be started directly using a URL string with hash parameters:
www.main.cls?sUrl=search#....parameters....
This link can be integrated into any other page, inside and outside the Iguana website.
8.1 Available hash parameters
The following hash parameters are available:
|
Parameter name |
Type |
Values |
|
app |
application |
Tree, SelectedForYou (default is search) |
|
mode |
search |
force display of search mode on search start screen |
|
hideSearch |
search |
1 = hide search start screen, 0 = show |
|
where |
search |
cat=catalogue (default), cms=website, catcms=catalogue and website |
|
database |
search |
database(s) to use for the search – separate multiple databases with comma's |
|
searchterm# |
search |
(# = sequence number, 1 to 9) term to search on |
|
index# |
search |
(# = sequence number, 1 to 9) index to search in |
|
facet# |
search |
(# = sequence number, 1 to 9) facet, of the form: pseudo-index^value – for instance: !Authlist4305!^40100 Note that this is meant for authority list facets only. Facets based upon authorities can be handled through index search parameters. |
|
restriction# |
search |
(# = sequence number, 1 to 9) restriction, of the form: restrictionname_value – for instance: Language_fre Multiple values are separated by ~, e.g. Language_fre~ita |
|
bool# |
search (expert search only) |
(# = sequence number, 1 to 9) boolean operator, allowed values: AND, OR, NOT For the first operator (bool1) only the value NOT is valid. Default operator for multiple search terms is AND. |
|
userfilter |
search |
“disabled” = avoid application of user filter |
|
displayTerm |
search |
display for search term |
|
repeatLastSearch |
search |
repeat last search (value is always 1) |
|
recordId |
record |
id for record display (database.record, e.g. 2.148722) |
|
savelist |
reading list |
id of savelist (type_user_name, e.g. General_*_TRAVEL) |
|
title |
reading list |
title to display in header |
|
template |
search reading list |
template to use for record list display |
|
pageId |
tree |
page id in the tree |
|
seqNo |
tree |
sequence number on tree page |
|
treeId |
tree selected for you |
the id of the tree to display |
|
topic |
selected for you |
the topic to display |
|
from |
selected for you |
the start date (yyyymmdd) |
|
to |
selected for you |
the end date (yyyymmdd) |
|
location |
selected for you |
the location (inst/loc) |
|
sort |
all |
sort criterion |
|
sortdirection |
all |
sort direction (1 = ascending, -1 = descending) |
Examples
Search
...?sUrl=search#searchTerm1=Agatha Christie&restriction1=Language_eng
...?sUrl=search#searchTerm1=Beatles&restriction1=Language_eng&restriction2=PublicationType_CD~DVD
...?sUrl=search#searchTerm1=Dupont&index1=Index5
...?sUrl=search#database=3&searchTerm1=Gates&index1=Author&searchTerm2=Microsoft&index2=CorpName&hideSearch=1
...?sUrl=search#searchTerm1=Films&where=cms
Record
...?sUrl=search#recordId=1.78443
Savelist
...?sUrl=search#savelist=General_*_FRENCH&title=French novels
...?sUrl=search#savelist=General_*_TRAVEL&title=Travelguides&template=TRV
Tree
...?sUrl=search#app=Tree&treeId=KIDS&pageId=ANIMALS
Selected for you
...?sUrl=search#app=SelectedForYou&treeId=InterestsGrownups&topic=FI:SCAN
8.2 Calling a savelist via URL
You can invoke a savelist via a URL as follows:
…/www.main.cls?sUrl=search#savelist=General_*_NewAVM
You can optionally specify a title and/or template in the URL parameters. This is done via the &title= and &template= URL parameters. The same example, but now with a title and template included:
…/www.main.cls?sUrl=search#savelist=General_*_NewAVM&title=New Audio-Visual material&template=AVM
By default the savelist title and template will be used.
9 Direct search & search filters
Direct search & search filters combines two related, but not totally identical features, one is called Direct Search and the other one Search Filters.
You can switch between these two options by clicking on the Radio button options Direct search and Search filter in the Basic settings section.
9.1 What is Direct search?
Direct search is the functionality to include applications that automatically, without any user intervention, execute a search and show the result list. This functionality can be used to include search results on all sorts of pages. Think of e.g. a page about cooking that contains a search result containing all items containing the word “cooking”; a page about Harry Potter that contains a search result on the author “J.K. Rowling”; or a page about climate change containing all works of a certain Dewey category.
Direct search highlights selections from the collection or website, and is as such functionality that completes the functionality offered by (featured items) animations.
To set up a Direct search instance in the Iguana CMS, you will need to use to Preview section of the Direct search instance to define the actual search request.
This demo page contains a widget with the title “Egypt results” in the middle of the page. This widgets executes the search without any user input. If there is e.g. in the news section a news item on “Egypt”, the direct search widget can be linked to the news item, and the search result will be displayed automatically every time the news item is invoked.
Note
The way Direct Search apps work, means they cannot deal with multiple instances being placed on the same page. The reason for this is that it uses the default search logic (also on the front-end), which cannot deal with multiple instances of the search logic on the same page. So in effect if you had 3 Direct Search instances on a single page, only 1 would actually be executed.
9.2 Direct Search : Overview of property groups and options
If you select the Direct search & search filters option from the Content – applications section of the navigation menu, the list of existing instances is displayed. This display uses a generic element in the Iguana CMS, - the overview page of instances of a specific data type.
Direct search instances have the following property groups:
· Basic settings
· Advanced settings
· Preview
· View permissions and restrictions (*)
· In use by (*)
· Previous versions (*)
The property groups marked with (*) are described in the described in the chapter Generic instance properties of the "Management common workflow" document.
The available options are the standard options (Save, Save as draft, Copy, Cancel, Show all and Hide all). These are described in the chapter Options on the application instances detail page of the "Management common workflow" document
The Published content types overview page is described in the chapter Instances overview page of the "Management common workflow" document.
9.3 Direct Search : Basic settings
The basic settings of Direct search instances are:
Define the basic settings as follows:
Indicate at the top that this is a Direct search definition.
Search URL: This is the search URL that is executed when a Direct search instance is invoked in the Iguana front-end. This search URL is highly technical and it is nearly impossible to enter this manually. Therefore you should use the workflow that is provided to store these searches in an easy and user-friendly way, using the options in the Preview section. This workflow is described in the documentation on the Preview section.
Tree storage: The tree storage allows you to organize your content in a hierarchic folder structure. You can define a maximum of five levels in the storage tree.
In use: You can set an application instance to Not in use. This implies that you cannot link the application to pages. Setting an application instance to Not in use does NOT imply that it is removed from views (pages).
Title (English): This is the title of the Direct Search. It is displayed as the widget title in the Iguana interface.
Keywords (English): You can define keywords (tags) that are relevant for this application. These keywords will be inserted into the HTML page as meta tag keywords, which can improve your ranking in search engines (SEO).
Notes (English): You can add notes to the application instance. These notes are for internal use only; they are not displayed in the actual application.
9.3.1 Direct Search : Advanced settings
The advanced settings of Direct search are:
Created by: This is the person who created the Direct search definition and the date on which it was created. You cannot modify these properties.
Modified by: This is the person who last edited the Direct search definition and the date on which it was modified. You cannot modify these properties.
Unique id: This unique id of the Direct search definition is used for internal purposes only. You cannot modify it.
9.4 Direct Search : Preview & how to create and edit the search URL
When the Direct search details page is invoked for the first time, it displays one of two possibilities:
· when you are creating a new Direct search instance : a blank search page
· when you have selected an existing fully configured Direct search instance : the search page that displays the result list that corresponds to the Search URL as defined in the Basic settings section
The preview is preceded by three buttons:
: This will refresh the current Preview page.
: This will copy the search that was executed to the value of the Search URL property in the Basic settings section.
: The New search button will refresh the Preview page and open the associated search page.
How to define the Search URL
To define the Search URL property, act as follows:
1. Click on the button in the Preview section. This will invoke a search page.
2. Enter your search term. This can be a simple search on keywords, and advanced search using restrictions and Boolean operators, or a keyword search restricted with facets. Continue until the search result that you want is displayed in the Preview section.
3. Click on the button. This will transform your search to a valid search URL and copy this to the Search URL property in the Basic settings section.
9.5 What are Search filters?
Search filters are a set of search restrictions that can be “automatically” or following a user's choice be applied to a search. A few examples will clarify the function of Search filters.
· You define a Search filter that says “Language = English” ; the Search filter is linked to Search profile A ; Search profile A is linked to a Search box à in the user interface the user now types the search term “shakespeare” ; automatically, without any further action from the user, the search result will be restricted to records in English only
· You define a Search filter that says “Material type = DVD” and another one that says “Material type = Map” ; the search filters are tied to Search profile B ; Search profile B is linked to a Search box à in the user interface the user will now have the ability to select the filter from a dropdown list; he can select either DVD or Map ; his choice will be applied to the search
As you can see from these examples, Search filters can be applied automatically to a user's search, or can be offered to the user as an option from a dropdown list.
You can create Search filters based on the following criteria:
· Database
· Index
· Language
· Location
· Material type
· Sublocation
Optionally you can also define the following filters (please contact Infor):
· Content warning (such as violence)
· Target audience
· RDA designation (like medium)
You can select:
· none, one or more databases
· one index (one of the choices is the “Default” index)
· none, one or more languages
· none, one or more locations
· none, one or more material types
· none, one or more sublocations.
The criteria will be processed as an AND Boolean relationship between multiple criteria and as an OR Boolean relationship between the values of a single criterion.
So Locations A and B checked + Material type Z checked means “(Location A OR B) AND Material type Z”.
9.6 Search Filters : Overview of property groups and options
If you select the Direct search & search filters option from the Content – applications section of the navigation menu, the list of existing instances is displayed. This display uses a generic element in the Iguana CMS, - the overview page of instances of a specific data type.
Search Filter instances have the following property groups:
· Basic settings
· Advanced settings
· Search restriction setup
· Preview
· View permissions and restrictions (*)
· In use by (*)
· Previous versions (*)
The property groups marked with (*) are described in the chapter Generic application properties of the "Management common workflow" document.
The available options are the standard options (Save, Save as draft, Delete, Cancel, Show all and Hide all). These are described in the chapter Options on the instance details page of the "Management common workflow" document.
9.7 Search Filters : Basic settings
The basic settings of Search Filters instances are:
Define the basic settings as follows:
Indicate at the top that this is a Search filter definition.
Tree storage: The tree storage allows you to organize your content in a hierarchic folder structure. You can define a maximum of five levels in the storage tree.
In use: You can set an application instance to Not in use. This implies that you cannot link the application to pages. Setting an application instance to Not in use does NOT imply that it is removed from views (pages).
Title (English): This is the title of the Search Filter. It is the wording that is displayed in dropdown lists, etc.
Keywords (English): You can define keywords (tags) that are relevant for this application. These keywords will be inserted into the HTML page as meta tag keywords, which can improve your ranking in search engines (SEO).
Notes (English): You can add notes to the application instance. These notes are for internal use only; they are not displayed in the actual application.
9.7.1 Search Filters : Advanced settings
The advanced settings of Search filters are:
Created by: This is the person who created the Search filter definition and the date on which it was created. You cannot modify these properties.
Modified by: This is the person who last edited the Search filter definition and the date on which it was modified. You cannot modify these properties.
Unique id: This unique id of the filter definition is used for internal purposes only. You cannot modify it.
9.8 Search Filters : search restriction setup and Preview
You can configure a Search Filter by defining one or more Search restrictions from the list of available criteria:
· Database
· Index
· Language
· Location
· Material type
· Sublocation
After you have defined one or more restrictions, click on the button to store the definitions.
You can now test the restrictions via the Test search key option at the bottom of the Search restriction setup section. Type a search term and click on the button. The search will now be executed and the search result will be displayed in the Preview section. The search will take into account the defined search restrictions. (Please take into account that the Preview will only reflect the settings after you have clicked on the button.)
(Alternatively, you can open the Preview section, which will open the Simple search page. You can enter a search term and submit your search. Please note however that the search that is triggered by the button in the Preview section does not take into account the defined search filter.)
10 “Selected for you”
“Selected for you” is a specific implementation of Interest topics, which is described in the document on Interests.
It has however a number of features in common with , which is why it is also covered in this chapter. You can find here the information on how to invoke Selected for you via URL.
10.1 Invoke Selected for you via URL
Selected for you is a non-search application that gives access to new items in the library, which we include in this part of the documentation because it resembles closely the actual search applications.
A description of Selected for you can be found in the chapter on Interests. In this section we only cover how one can invoke Selected for you results via URL.
“Selected for you” can be started directly using a URL string with hash parameters:
www.main.cls?sUrl=search#app=SelectedForYou&....parameters....
This link can be integrated into any other page, inside and outside the Iguana website.
Example:
10.2 Available hash parameters
The following hash parameters are available:
· treeId : the id of the tree to display
· topic : the topic to display
· from : the start date (yyyymmdd)
· to : the end date (yyyymmdd)
· location : the location (inst/loc)
Example:
...?sUrl=search#app=SelectedForYou&treeId=InterestsGrownups&topic=FI:SCAN&location=BLIB/CEN&from=20120101
11 Parameter object Search
Under Parameters – Parameter objects you can also define a search method.
Search methods can be used to define your own search start screen layout. You can create as many search methods as you want. Once created they become available for selection in the CMS parameters.
After selecting Parameter object Search method, you can create a definition via the button in the usual way.
Identifier: A unique code.
Name: The name for this object (as displayed in the list of existing instances of this object).
Number of lines with searchbox: A search method can have 1 or more lines with a search box (and index) that can be combined with boolean operators. Select here the number of lines you want for the method.
Restriction choice at right of searchbox: You can have a restriction dropdown at the right of the search box and index. This option is only valid for search methods with a single search box line and a single restriction type.
Valid databases: Databases that can be selected for this search method. If no database is selected the default database will be used.
User can select databases: The user can select one or more databases. If this option is not checked all databases will be selected automatically.
Valid indexes: Indexes that can be selected for a search box. If no index is selected the default index will be used.
Show indexes as link above searchbox: Indexes can be shown on top as hyperlinks. This option is only valid for search methods with a single search box line.
Valid restrictions: Restrictions that can be applied to the search. They will apply to every line of the search method.
Combine results from multiple sources: If checked, then multi-source searches will be presented in a combined list (with hyperlinks to the individual results).
Compact layout: This layout can be used for small devices. This option is only valid for search methods with a single search box line.
· Document control – Change History
|
Version |
Date |
Change description |
Author |
|
|
1.0 |
September 2011 |
Creation |
|
|
|
1.1 |
September 2011 |
Starting adding server-side configuration information, based on Pieter's configuration document |
|
|
|
1.2 |
September 2011 |
Processed comments and answers from Pieter and Willem |
|
|
|
1.3 |
October 2011 |
Further processed comments from Pieter and Willem |
|
|
|
1.4 |
November 2011 |
Restructured document; added information on Search profiles |
|
|
|
1.5 |
November 2011 |
Added information on Search URL's, Selected for you URL's |
|
|
|
1.6 |
December 2011 |
Added additional information on RTI Search boxes ; Added information on Direct Search & Search Filters |
|
|
|
1.7 |
December 2011 |
Added information on Search trees |
|
|
|
1.8 |
January 2012 |
Added information on syntax of URL parameters for RTI Search boxes |
|
|
|
1.9 |
January 2012 |
Added header |
|
|
|
1.10 |
January 2012 |
Added section on Facets that are based on item-related data |
|
|
|
1.11 |
February 2012 |
Reviewed |
|
|
|
1.12 |
March 2012 |
Processed review |
|
|
|
2.0 |
May 2012 |
Reformat for online help doc |
|
|
|
3.0 |
January 2013 |
Textual improvements; more screen shots & examples |
|
|
|
3.1 |
April 2014 |
Autocomplete; use NO WebOpac profile |
|
|
|
3.2 |
August 2014 |
Textual improvements |
|
|
|
4.0 |
March 2016 |
Rewrite of some chapters due to changes in various procedures and concepts |
|
|