An Interesting Search
Last year at SBL, someone remarked about the Accordance booth that it looked like there was actual research going on. I answered that indeed there was. It is not unusual to have users come to the booth and ask for help constructing a complex search.
At this year's SBL, I had someone ask for help in finding every Hebrew verb which appears in the Nifal stem but which never appears in the Qal stem. I was actually impressed with how close he had gotten. In one tab, he did a search for [VERB Nifal] to get all the Nifal verbs in the tagged Hebrew Bible (BHS-W4). Then he opened a second tab, and did a search for [VERB Qal] to get all the Qal verbs. Now he just needed a way to find all the verbs which were found by the first search but which were not found by the second.
To do this, he opened a third tab and used the HITS command. For those of you who are unfamiliar with the HITS command, it basically represents the list of hit words from another search tab. In this case, he needed two HITS commands to use the results of the two previous searches. The trick was how to relate them to each other.
His first thought was to separate the two HITS commands with a NOT command, like this:
Note: Remember that we're searching in Hebrew, so all of these examples should be read from right to left.
However, when he clicked the Details button and looked at the Analysis tab for this search, he saw words listed there which he knew sometimes appear in the Qal stem. Why had this search failed? By using the NOT command, he had set up a search with two elements. The first element was a verb from the list of Nifal verbs. The second element was a verb from the list of Qal verbs. This search would find every verse where a verb from search 1 was not in the same verse as a second verb from search 2. However, this search would not exclude the possibility that the first verb might appear in the results of both search 1 and search 2. What was needed was a way to search for a single group of verbs which met the criteria of being found by the Nifal search but which did not meet the criteria of being found by the Qal search.
Whenever you want to find a single item which meets more than one criteria, you join those criteria together using the at symbol (@). If you want to negate one of those criteria, you do so by using a minus sign (-). So we selected the NOT command and replaced it with -@, like this:
The problem with this search was that we got an error message complaining about our use of the minus sign. I didn't understand what I had done wrong at the time and began wondering if this was a bug or just a limitation of Accordance. Perhaps two HITS commands could not be joined by the at symbol. I promised the user I would discuss this supposed limitation with the programmers and was about to apologize that Accordance couldn't do what he was asking, but after years of working with Accordance, I knew there had to be a way. I decided to try doing this search using the Construct window.
The Construct window lets you define complex word relationships using a simple drag-and-drop interface. There are times when you can accomplish things with the Construct window which you can't accomplish with a text-based search. Each column of the Construct window represents a different word or element of your search, and the space above the columns lets you define relationships between those words. Since the HITS command is available in the Construct window, I tried the following:
This search worked beautifully. By clicking the Details button and looking at the Analysis tab, we were able to get a list of verbs which appear in the Nifal but which never appear in the Qal (at least, never in the Hebrew Bible). We were even able to verify that these verbs never appear in the Qal by choosing Set Analysis Display and specifying that we wanted the search results broken down by Stem.
At that point, the user who had been trying to construct this search just kept saying, "That's beautiful!" It was only after he had left that I discovered why the text-based search using the at symbol had failed. It was due to confusion about the text order of the combined right-to-left and left-to-right text. Because I had selected the NOT command (which is left-to-right English text) and replaced it with -@, Accordance then interpreted these symbols in left-to-right order. That meant that it saw the minus sign as coming before the at symbol, rather than after it as it should. Had I replaced the NOT symbol with @- the search would have worked, though it would have looked like I was negating the first HITS command:
Because of this potential for confusion, it is often best when constructing Hebrew searches to start each search from scratch rather than trying to modify a previous search. Had I just started over and entered [HITS Nifal], the at symbol, the minus sign, and [HITS Qal], the search would have worked correctly and appeared correctly:
If you compare this last screenshot with the screenshot of the search which failed (the second screenshot above), you'll notice a subtle difference: the at symbol and minus sign in the latter search appear in the larger Hebrew font, rather than the smaller English font. For obvious reasons, Accordance interprets text in the Hebrew font from right-to-left, and text in the English font from left-to-right.
Confused yet? I was tempted just to gloss over this mistake of mine because it's somewhat hard to explain, but decided it may be helpful to some of you Hebrew power-users out there. For the rest of us, here are the morals of this story:
1. If you want to create a sophisticated search in Accordance, don't give up and don't be afraid to ask for help. (Okay, so you may not have access to an Accordance employee at a conference, but there's always the user forum).
2. Use the at symbol (@) rather than a search command to define single items which must meet multiple criteria.
3. If you can't get a search to work in the main search window, try using the Construct window.
4. Because of ambiguities in mixed left-to-right and right-to-left text, it is sometimes cleaner to enter a search from scratch rather than trying to modify some previous search.
It's always fun at SBL to try to get a challenging search to work, even when I don't get it right the first time. Once we do get it to work so that users can continue their research, the response is always the same: "That's beautiful."