Searches

Server side

Generally speaking searches are handled by the SearchController and delegated to the SearchService (namely SearchServiceImpl).

Text Search

Summary

Conducts a straight text search against a Bible text/commentary

Algorithm

  1. Take user input
  2. Construct query syntax (usually in browser)
  3. Search all user-given versions  (i.e. supports multiple versions) - searching is done in sequence.
  4. Retrieve all keys (verses) for these searches
  5. Merge the key sets from each version search
  6. Retrieve the bible texts for each version given by the user

Defaults to ESV, if no version is specified. Same code applies to advanced search.

Original Word Search

Summary

The user is given the ability to lookup a Greek / Hebrew word from its lexical form (default) or from a specific form as found in the text. The checkbox in the dropdown toggles the dataset used to retrieve suggestions. "specific forms" refers to forms actually present in a text, whereas a lexical form (as stored in the lexicon_<language>.txt files) are the forms of the root word. The user is also given the ability to search by meaning, which uses the "translation" and/or the 'stepGloss' field for lexicon definition entries.

Algorithm

Suggestions are made from the lexicon

Searches are done:

  1. By resolving the input to a lexicon entry:
    1. if a strong number, no resolving
    2. if a accented greek/hebrew, look up appropriate field in lexicon
    3. if an non-unicode text, assume a transliteration for 'Hebrew' or 'Greek' word (step b and c may be done at the same time - need to check).
    4. if a meaning search is desired, look across the step gloss field. (this is going to change in the case of someone selecting an entry from the dropdown vs someone entering free-text field)
  2. second expanding the input to include related words (another field in the lexicon)
  3. Constructs a text search based on the strong number field (ie. strong:H0001 strong:H0002). 
  4. Runs text search (see above, summarized below) with query syntax from above point (including retrieving any verse from other versions), i.e.
    1. use tagged text or ESV if missing
    2. run search against all versions
    3. complete the results with the texts from non-tagged texts.

Dropdown completion

The "original word search" offers the user the ability to search a text by referring to the original word. The suggestions can be given in Greek, Hebrew or by English Meaning. The data behind those suggestions is an indexed copy of the lexicon_greek.txt, lexicon_hebrew.txt, specific_forms. OriginalWordSuggestionServiceImpl is used to provide the relevant data. In particular, the data in the lexicon comes from:

  • strong number
  • unicode greek/hebrew fields
  • Transliteration files (such as strong transliteration, strong's pronunciation, ...)
  • STEP transliteration (generated by code, developed in conjunction with Tyndale House)
  • Expansions of the user input (taking the user input and working out combinations of input to expand our suggestions in the auto-complete).

Subject search

Summary

Help the user find a particular passage by listing subjects based on the search query. Currently operates on 2 datasets, and three types of search: ESV headings, Nave concordance (top headings), Nave concordance (all headings)

Algorithm

Take the search query. 

  1. For ESV headings search (level 1, s=):
    1. Construct the Lucene  query syntax (e.g. heading:love)
    2. Run query against ESV (currently hard-coded - because it is the only English Bible with good headings - this needs to change)
    3. Retrieve verse that occurs just after the heading
  2. For 'Further searches', operates over the Nave concordance
    1. Construct query to run against Nave concordance data choosing 'root' field or 'fullHeader'
    2. Run query against Nave data
    3. Retrieve linked verses to Nave data entries
    4. Return results grouped by their Nave topic

 

Client side

The code for the search layout can be found under advanced_search.jsp. This defines the layout of the text boxes into which the user keys in his search criteria. Handlers and other UI components are found in js/search/*ui.js. A few key areas warrant special mention:

Tracking state of the application

trackState() adds a handler to textbox which tracks every time a value is committed to a textbox/checkbox (e.g. a blurring event, or the user hits the Enter key). This is then stored in the local storage, made available by HTML5. Values in the local storage for search can be found by calling the following method:

step.state.<searchTypeNamespace>.<textboxClass>(passageId) 

For example step.state.simpleText.simpleTextCriteria(0) would retrieve the value stored for the "simpleTextCriteria" textbox in the left-hand column.

Query syntax

Generally, a ui.js will contain its own evaluateQuerySyntax method. For example, for the original word search, this is step.search.ui.original.evaluateQuerySyntax(). This method is responsible for creating a query syntax that the server can understand. The query syntax is re-evaluated on each key stroke. .ui.js files call the step.util.ui.trackQuerySyntax(classNameOfParentElement, searchTypeNamespace) method in order to set up the event handlers for key strokes.

step.util.ui.trackQuerySyntax(".wordSearch", "original");