docs/RELEASE_NOTES_NEXT/Architecture/search-display-infrastructure-improvements.adoc

   1 Virtual Index Definitions
   2 ^^^^^^^^^^^^^^^^^^^^^^^^^
   3 The practical purpose of Virtual Index Definitions is to supply an Evergreen
   4 administrator with the ability to control the weighting and field inclusion of
   5 values in the general keyword index, commonly referred to as "the blob,"
   6 without requiring tricky configuration that has subtle semantics, an
   7 over-abundance of index definitions which can slow search generally, or the
   8 need to reingest all records on a regular basis as experiments are performed
   9 and the configuration refined. Significant results of recasting keyword indexes
  10 as a set of one or more Virtual Index Definitions will be simpler search
  11 configuration management, faster search speed overall, and more practical
  12 reconfiguration and adjustment as needed.
  13
  14 Previous to this commit, in order to provide field-specific weighting to
  15 keyword matches against titles or authors, an administrator must duplicate many
  16 other index definitions and supply overriding weights to those duplicates. This
  17 not only complicates configuration, but slows down record ingest as well as
  18 search. It is also fairly ineffective at achieving the goal of weighted keyword
  19 fields. Virtual Index Definitions will substantially alleviate the need for
  20 these workarounds and their consequences.
  21
  22   * A Virtual Index Definition is not required supply any configuration for
  23 extracting bibliographic data from records, but instead can become a sink for
  24 data collected by other index definitions which is then colocated together to
  25 supply a search target made up of the separately extracted data. Virtual Index
  26 Definitions are effectively treated as aggregate definitions, matching across
  27 all values extracted from constituent non-virtual index definitions.  They can
  28 further make use of the Combined class functionality to colocate all values in a
  29 class together for matching even across virtual fields.
  30
  31   * Configuration allows for weighting of constituent index definitions that
  32 participate in a Virtual Index Definition. This weighting is separate from the
  33 weighting supplied when the index definition itself is a search target.
  34
  35   * The Evergreen QueryParser driver returns the list of fields actually
  36 searched using every user-supplied term set, including constituent expansion
  37 when a Virtual Index Definition is searched. In particular, this will facilitate
  38 Search Term Highlighting described below.
  39
  40   * Stock configuration changes make use of pre-existing, non-virtual index
  41 definitions mapped to new a Virtual Index Definition that implements the
  42 functionality provided by the keyword|keyword index definition. The
  43 keyword|keyword definition is left in place for the time being, until more data
  44 can be gathered about the real-world effect of removing it entirely and
  45 replacing it with Virtual Index Definition mappings.
  46
  47   * New system administration functions will be created to facilitate
  48 modification of Virtual Index Definition mapping, avoiding the need for a full
  49 reingest when existing index definitions are added or removed from a virtual
  50 field.
  51
  52 Increased use of Metabib Display Fields
  53 +++++++++++++++++++++++++++++++++++++++
  54 In extention of changes proposed in other available branches, we here use
  55 Metabib Display Fields to render catalog search results, intermediate metarecord
  56 results, and record detail pages.This will requires the addition of several new
  57 Metabib Display Field definitions, as well as Perl services to gather and render
  58 the data.
  59
  60 Search Term Highlighting
  61 ++++++++++++++++++++++++
  62 This commit enables Search Term Highlighting in the OPAC on the main search
  63 results page, the record detail page, and intermediate pages such as metarecord
  64 grouped results page. Highlighting search terms will help the user determine why
  65 a particular record (or set of records) was retrieved.
  66
  67 Highlighting of matched terms uses the same stemming used to accomplish the
  68 search, as configured per field and class.
  69
  70 This feature will help the user more quickly determine the relevance of a
  71 particular record by calling their attention to search terms in context. Lastly,
  72 it will help familiarize the user with how records are searched, including which
  73 fields are searched as well as exposing concepts like stemming.
  74
  75 Interfaces
  76 ++++++++++
  77 A new AngularJS "MARC Search/Facet Fields" interface has been created to replace
  78  the Dojo version, and both have been extended to support Virtual Index
  79 Definition data supplier mapping and weighting.
  80
  81 Settings & Permissions
  82 ++++++++++++++++++++++
  83 The new Virtual Index Definition data supplier mapping table,
  84 config.metabib_field_virtual_map, requires the same permissions as the
  85 MARC Search/Facet Fields interface: CREATE_METABIB_FIELD, UPDATE_METABIB_FIELD,
  86 DELETE_METABIB_FIELD, or ADMIN_METABIB_FIELD for all actions
  87
  88 There is a new template-level global configuration variable in config.tt2 called
  89 search.no_highlight which disables highlighting for users of that config.tt2
  90 instance.
  91
  92 Public Catalog
  93 ++++++++++++++
  94 The public and staff catalog will make use of new APIs to identify and display
  95 highlight-augmented values for those Display Fields used to render the search
  96 result pages, intermediate metarecord constituent pages, and record detail
  97 pages.  Highlighting of terms will be performed using the application of
  98 Template::Toolkit-driven CSS. A generic CSS class identifying a highlighted
  99 term, along with CSS classes identifying the search class and each search field
 100 will be available for use for customization of the highlighting. A stock CSS
 101 template is provided as a baseline upon which sites may expand.
 102
 103 When highlighting is generally enabled, it may be turned on or off on a per-page
 104 basis through the use of a UI component which will request the page again
 105 without highlighting.
 106
 107 Backend
 108 +++++++
 109 There now exist several new database tables and functions primarily in support
 110 of search highlighting. Additionally, the QueryParser driver for Evergreen has
 111 been augmented to be able to return a data structure describing how the search
 112 was performed, in a way that allows a separate support API to gather a
 113 highlighted version of the Display Field data for a given record.
 114
 115 Re-ingest or Indexing Dependencies
 116 ++++++++++++++++++++++++++++++++++
 117 With the addition and modification of many Index Definitions, a full reingest is
 118 recommended.  However, search will continue to work as it did before the changes
 119 in this commit for those records that have not yet been reingested during that
 120 process.  Therefore a slow, rolling reingest is recommended.
 121
 122 Performance Implications or Concerns
 123 ++++++++++++++++++++++++++++++++++++
 124 Because the Metabib Display Fields infrastructure will eventually replace
 125 functionality that is significantly more CPU-intensive in the various forms of
 126 XML parsing, XSLT transformation, XPath calculation, and
 127 Metabib Virtual Record construction, it is expected that the overall CPU load
 128 will be reduced by this development, and ideally the overall time required to
 129 perform and render a search will likewise drop. It is unlikely that the speed
 130 increase will be visible to users on a per-search basis, but that search in
 131 aggregate will become a smaller consumer of resources.
 132
 133
 134
 135