Docs: virtual index definitions
authorkilsdonka <43423795+kilsdonka@users.noreply.github.com>
Wed, 19 Sep 2018 22:41:45 +0000 (15:41 -0700)
committerJane Sandberg <sandbej@linnbenton.edu>
Thu, 6 Dec 2018 19:48:49 +0000 (11:48 -0800)
Signed-off-by: Jane Sandberg <sandbej@linnbenton.edu>

docs/admin/virtual_index_defs.adoc [new file with mode: 0644]
docs/media/vid1.PNG [new file with mode: 0644]
docs/media/vid2.PNG [new file with mode: 0644]
docs/media/vid3.PNG [new file with mode: 0644]
docs/media/vid4.PNG [new file with mode: 0644]
docs/media/vid5.PNG [new file with mode: 0644]
docs/media/vid6.PNG [new file with mode: 0644]
docs/root.adoc
docs/root_staff_client_admin.adoc

diff --git a/docs/admin/virtual_index_defs.adoc b/docs/admin/virtual_index_defs.adoc
new file mode 100644 (file)
index 0000000..1e35fe0
--- /dev/null
@@ -0,0 +1,56 @@
+Virtual Index Definitions
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Virtual index definitions can be configured in Evergreen to create customized search indexes that make use of data collected by other (real) index definitions.  Real index definitions use an XPath expression to indicate the bibliographic data that should be included in the index.  Virtual index definitions bring together data collected by other index definitions to create a new, virtual index.  They can also use an XPath expression to collect data directly for an index, but they are not required to.
+
+All index definitions can be modified by having other indexes map to them.  For example, Genre could be added to the All Subjects field definition in the Subject index.  This would allow users to search Genre as part of a Subject search.
+
+Keyword Virtual Index Definition
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Evergreen now uses a virtual index definition for the Keyword index.  This allows libraries to customize the keyword search index by specifying which fields are included in the keyword index, as well as how each field should be weighted for relevance ranking in search results. By default, the keyword index contains all of the search fields other than the keyword definition itself.  Each field is assigned a weight of 1, with the exception of Title Proper, which is assigned a weight of 8.  A match on the Title Proper within a keyword search will be given the higher weight and therefore a higher relevance ranking within search results.
+
+. To view the stock virtual index definition for keyword searches, go to *Administration>Server Administration>MARC Search/Facet Fields* and select the *Keyword* Search Class.
+. Locate the field labeled "All searchable fields".  This is the general keyword index. 
+. The weight of a field can be modified by selecting the field and going to *Actions>Edit Record* or right-clicking and selecting *Edit Record*.
+.. The Metabib Field Virtual Map modal will appear.  Increase the weight of the field and click *Save*.
+
+Configuring Virtual Index Definitions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+. To configure a virtual index definition, go to *Administration>Server Administration>MARC Search/Facet Fields*. 
+.. This interface now has a _Search Class_ filter that allows users to easily select which search class they want to view.
+. Next, locate the field for which you want to create a virtual index definition and click *Manage* under the column labeled _Data Suppliers_.
+
+image::media/vid1.PNG[]
+
+. A new tab will open that contains the interface for configuring a virtual index definition.  This interface can be used to map real index definitions for inclusion in the virtual index.
+
+image::media/vid2.PNG[]
+
+. To create a mapping, click *New Record*.  A modal called _Metabib Field Virtual Map_ will appear.
+. Select the _Real_ index definition and the _Virtual_ index definition to which it should be mapped.
+. Assign a _Weight_ to the mapping.  This allows Evergreen to calculate the weight that should be applied to each field when searched using the virtual index.
+.. The weight assigned to a field within a virtual index can be different than the weight assigned when searching that field directly.  For example, the Title Proper field can have a weight of 2 when a user performs a Title search, but a weight of 5 when a user performs a Keyword search (using the virtual index).  This can help move title matches on keyword searches higher up in the search results list.
+. Click *Save*.
+. Repeat steps 4-7 until all desired fields are mapped to the virtual index definition.
+
+image::media/vid3.PNG[]
+
+Note: A service restart is required after definitions and mapping are changed.  Changes to weight only do not require a restart as they are calculated in real time.
+
+Search Term Highlighting in Search Results
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Search terms are now highlighted on the main OPAC search results page, the bibliographic record detail page, and the metarecord grouped results page.  This will help users discern why a certain record was included in the search result set, as well as its relevance to the search.  Search terms will be highlighted in both real and virtual fields that were searched.  Terms that were stemmed or normalized during searching will also be highlighted.  Search term highlighting can be turned off within the OPAC by selecting the checkbox to "Disable Highlighting" in the search results interface.
+
+A keyword search for "piano" returns a set of search results:
+
+image::media/vid4.PNG[]
+
+The search term is highlighted in the search results and indicates why the records were included in the search result set.  In this example, the search results interface shows the first three records had matching terms in the title field.
+
+Within the record detail page for "The five piano concertos", we can see the search term also matched on the General Note and Subject fields within the bibliographic record.
+
+image::media/vid5.PNG[]
+
diff --git a/docs/media/vid1.PNG b/docs/media/vid1.PNG
new file mode 100644 (file)
index 0000000..ed8955f
Binary files /dev/null and b/docs/media/vid1.PNG differ
diff --git a/docs/media/vid2.PNG b/docs/media/vid2.PNG
new file mode 100644 (file)
index 0000000..b22d638
Binary files /dev/null and b/docs/media/vid2.PNG differ
diff --git a/docs/media/vid3.PNG b/docs/media/vid3.PNG
new file mode 100644 (file)
index 0000000..75ec4d5
Binary files /dev/null and b/docs/media/vid3.PNG differ
diff --git a/docs/media/vid4.PNG b/docs/media/vid4.PNG
new file mode 100644 (file)
index 0000000..1369040
Binary files /dev/null and b/docs/media/vid4.PNG differ
diff --git a/docs/media/vid5.PNG b/docs/media/vid5.PNG
new file mode 100644 (file)
index 0000000..1415605
Binary files /dev/null and b/docs/media/vid5.PNG differ
diff --git a/docs/media/vid6.PNG b/docs/media/vid6.PNG
new file mode 100644 (file)
index 0000000..58940d1
Binary files /dev/null and b/docs/media/vid6.PNG differ
index 20d6ae6..88adf29 100644 (file)
@@ -264,6 +264,8 @@ include::admin/multilingual_search.adoc[]
 
 include::admin/infrastructure_auth_browse.adoc[]
 
+include::admin/virtual_index_defs.adoc[]
+
 include::admin/Org_Unit_Proximity_Adjustments.adoc[]
 
 :leveloffset: -1
index 93ae165..0c4c232 100644 (file)
@@ -214,6 +214,8 @@ include::admin/multilingual_search.adoc[]
 
 include::admin/infrastructure_auth_browse.adoc[]
 
+include::admin/virtual_index_defs.adoc[]
+
 :leveloffset: 0