Assuming the BH.SE site ever gets out of BETA, is there any chance that part of the customization of the site could include a specialized "search" feature, so that one can do verse level searching? That is, suppose one wanted to search for any references to Leviticus 3:2. Then...

Search input could be various forms of input (including as well some of the common notations used for Hebrew Scriptures by Jewish commentators):

  • Leviticus 3:2
  • Lev. 3:2
  • Lev 3:2
  • Lv 3:2

Search output would yield hits in Q & As with similar abbreviations used, along with hits where it appears in the range (perhaps giving them lesser priority), so:

  • Hits for any of the above possible search values
  • Hits in chapter range, such as Q & As having Lev 3:1-5, Leviticus 3, etc.
  • Hits in book range, such as Leviticus chapters 2-4, Lev. ch. 2-4, Lev 2-4, etc.

Since this site is so text focused, and therefore reference focused (most questions need a reference text) being able to search from the main search query field and yield more precise textual results would be highly beneficial. Tags only help so much, since obviously will yield many results that are not related to Lev 3:2.

Does any such customization of search ever occur on SE sites? Does Christianity.SE have such? Or Mi Yodeya? Neither appears to. So I am wondering if such functionality could/would be implemented for the customization a site receives when it does graduate.


Given Caleb's answer as to the plausibility of being implemented through users, I want to expand this question to not just be about the possibility of it occurring, but thoughts about (ultimately anyway) the best implementation to make it robust and useful for visitors. Any level of implementation would be "useful," but here I am referring to other search factors that could make it exceptionally useful (though may not be as easy to implement as the basic features Caleb referred to).


4 Answers 4


I doubt SE will ever implement something like this as in has so little impact on their bottom line, but this actually wouldn't be hard to implement ourselves.

  1. Man handle a copy of the data dump onto somebody's local machine.
  2. Use a reference parser to find every verse mentioned. It's not that hard to find verse references in any format, ranges included.
  3. Create a custom index that cross references verse references to post ID's.
  4. Write an interface (as a user-script sidebar or stand alone site) that queried that index and linked the results directly to the relevant posts.
  5. Periodically catch the latest data dumps and update the index.

This isn't actually isn't that much work, but somebody would have to do it. I can do some parts of it, but probably don't have the time for all of it. If somebody else is interested in contributing ping me here.

  • That sounds far from simple to me, but then, I have only rudimentary programming and database knowledge :-). If it is "easy" and capable of being done, would it not then be easy for SE to take that work (if such is done) and simply incorporate it as part of the site? Thanks for your thoughts.
    – ScottS
    Jan 5, 2016 at 20:00
  • @scotts No. It's hard to explain why, but technologically this would be much easier to implement as a stand alone item that an integrated piece. SE has the constraint of deploying one code base across all sites and the maintenance nightmare that exceptions introduce. Even if they were to make something for us it would almost certainly be isolated from the main workings of the site because mechanically the things that need to happen aren't a good fit for the rest of the software stack that powers the site.
    – Caleb
    Jan 5, 2016 at 20:51
  • That makes sense (the exceptions handling issue).
    – ScottS
    Jan 5, 2016 at 21:13
  • Are you talking about these data dumps? Even the "3–4 months" part seems like a long time, and from the comment it doesn't sound like SE has been very committed to this schedule recently. Jan 7, 2016 at 13:29
  • 1
    @Nathaniel The current data dumps are a couple days old and the release process has been streamlined a bit since those meta discussions. There is still some lag, but we don't really have another viable way to do this. If the lack of recency becomes a problem we can query the API for posts newer than the last post in the data dump and stuff those in the index too. I'm already designing the system with that [likely] eventuality in mind.
    – Caleb
    Jan 7, 2016 at 13:39

I started an open source project on Github as a place to house a community driven implementation of this. Anyone with ideas is invited to submit them as issues or discuss existing ones. Anyone with the chops to code any of this up is invited to fork and hack away.


Since Caleb's answer indicates this may be more plausible than I thought, and even sooner than I might have expected (depending on support), perhaps some answers about how this might function are in order as well, since this is a "discussion."

I would like to see a prioritizing of the search like so (some of which may make constructing the search a bit more complex than the ease that Caleb noted):

  1. Any direct hit ranks higher than a hit within a range (Lev 3:2 matches any direct reference to that verse and ranks such a hit higher than a match to Lev 3:1-5, but 3:1-5 ranks higher than Lev 3, which still ranks higher than Lev 2-4, etc.).
  2. Hits rank higher for questions or answers where the book in the search matches to the tag-name of a question associated to it; so for Lev 3:2, if that is found in a question or answer to a question tagged as , then it ranks higher, since it is more likely to be directly relevant to Lev 3:2 as opposed to just an off-hand reference to Lev 3:2.
  3. Hits in questions rank higher than hits in answers, only because if the question is being asked with reference to the verse, then all (or at least most) of the answers are likely to involves discussion about the verse. The question controls the topic content more than answers with respect to the text.
  4. Related to #3, hits in titles rank higher than hits in just the question body, only because if the verse reference was deemed important enough to go in the title, then that question bears directly upon the verse for which information is being sought.
  5. Related to all the above, the number of hits to the same reference within (a) a question or answer, and (b) the set of a question and its answers, ranks higher than lesser hits. The idea being that if any one question or answer, i.e. (a), ends up referencing a verse multiple times, it is likely that information about that verse is more of a primary topic to that particular posting, even if it may not have been the primary topic itself. Then with (b), if two questions have in their title/body the same verse reference, have the book tag match, the combined total of one question & its answers = 10 hits and the other = 50 hits, then the the 50 hit should rank higher in the query. However, this may create more challenges to constructing the query.

Any other possibly relevant prioritizing factors anyone can think of?


I hadn't seen this post when I added my suggestion to implement:


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .