2.2.1 Booleans, Grouping, Phrase Searching

Boolean Operators

Each term in the query box must be joined together with a boolean operator. Three boolean operators are supported:

Note that there is no implicit Boolean operation occurring. So while you might type two terms next to each other such as:

you’ll notice that the siRNA is a syntax error. This is because LifeQuest wants you to be explicit – did you mean “dsRNA AND siRNA,” “dsRNA OR siRNA”, or simply the phrase “dsRNA siRNA,” with the two terms occurring one right after the other?

In some cases LifeQuest will attempt to infer implicit boolean operators. For instance, you may attempt to type two words next to each other and LifeQuest will insert an implicit AND automatically:

Note that in such cases the AND is a lighter grey and italicized, indicating that it was inserted implicitly. You won’t be able to edit it – you’ll have to put the cursor to the left of the rightmost term and then hit the backspace key. Best practice is to be explicit with all boolean operators.

2.2.2 Wildcard Operators

There are two wildcard operators in LifeQuest, namely * and ?.

You can get arbitrarily complicated with wildcard use. As an example, they don’t have to occur at the end of a word. For instance, fol*ox? would hit to FOLFOX, FOLFOX4, and FOLFIRINOX. However, using either of the two wildcard symbols, ? or *, as the first character in your query greatly increases the complexity of the search and therefore the time it may take to return results.

Combining Wildcard Operators with Other LifeQuest Functions

Wildcard operators can be used in combination with other operations. For instance, you can combine wildcards with boosting:

The above query will match any word with the root antibod and boost the relevance of the document by a factor of 4 in comparison with matching the H1N1 term. See the documentation on Boosting for more information.

Another example of the use of wildcard operators in conjunction with other LifeQuest functions is its use in a field-constrained search. For instance, the below image shows how to find documents that start with any character and end with the word test but only in the Abstract. More on constraining searches to specific fields here.

The ? is an Overloaded Character

Be advised that the ? character acts as a single character wildcard in the context described here. However, by hitting the ? key outside of a word you can bring up the field list to constrain your field search. Just keep typing and the field list will go away.

2.2.3 Ontologies and Your Word Lists

A key part of the LifeQuest system is its use of ontologies to allow you to search for concepts rather than just terms. The complete list of ontologies used by LifeQuest is available here.

2.2.3.1 Using Ontology Terms

LifeQuest automatically suggests ontology terms as you start typing. The default ontology selected is MeSH, or Medical Subject Headings, and as you type, LifeQuest suggests terms in that ontology. Watch this movie to see how this works in action.

As the user mouses over the ontology term s/he wants to search for, a window pops up indicating the different phrases that will be searched. While LifeQuest only displays the entry in the ontology, Alcoholism, it is in fact searching for every phrase enclosed in that term. By holding the mouse over the term one can see all of the phrases that will be searched.

Indeed, searching this one ontology term is equivalent to the following search:

Alcoholism OR “Addiction Alcohol” OR “Chronic Alcoholic Intoxication” OR “ALCOHOLIC INTOX CHRONIC” OR “Alcoholic Intoxication Chronic” OR “Intoxication Chronic Alcoholic” OR “Dependence Alcohol” OR “Alcohol Addiction” OR “Alcohol Dependence”

Multi-Word Ontology Terms

Let’s say you want to find the MeSH Term for dimethyl fumarate. If you type dimethyl and then hit the bar and start typing fumarate, you’ll get an error, and the MeSH auto-completion will stop working:

dimethyl fumarate

The reason for this error is explained in the Booleans and Grouping section – LifeQuest doesn’t know whether you are joining these terms by a Boolean operator or whether you want to make this a multi-word string. The error forces you to be explicit.

To address this, start within double quotes! Note how this looks in the below picture. Because the multi-word string is within double quotes, the auto-completion is suggesting possible ontology terms you might mean, and no errors are showing.

2.2.4 Constraining Searches to Specific Fields

Searches that you create will search the entire patent document – all of the title, abstract, description, claims, and bibliographic information. Often, however, you will want to constrain your search to specific fields within the system.

To constrain a search to a field, type the question mark ? key to pop open the field list. (Note that this operator is overloaded and also acts as a single-character wildcard if you use it within a word.) The next term you type will only be searched for in the field you chose.

For instance, the following search looks for the phrase “carbonyl sulfide” and the word mycobacterium in the title:

2.2.5 Proximity Search

Often you may wish to search for the occurrence of a set of words that are in close proximity, but not necessarily right next to each other. LifeQuest allows this with either the ordered or unordered proximity operators, kW and kD, respectively, where k is the number of terms you wish to allow between the two search terms:

The above query finds documents where no more than 10 words occur between the occurrence of the terms diverticulitis and constipation, irrespective of which term is found first.

Similarly, the above query does the same however the term diverticulitis must precede the term constipation.

One way to think about the proximity operator is that exact matches have a proximity of zero, for instance, < h1n1 0W vaccine > is precisely equivalent to “h1n1 vaccine”.

In the same manner, word transpositions are at proximity 1, e.g., < vaccine 1D h1n1 > would find “h1n1 vaccine”.

Amplified AND

A query such as < foo 10000000D bar > is an interesting alternative to foo AND bar. Both queries will return essentially identical sets of documents, however the proximity query will assign a higher score to documents for which the terms foo and bar are closer together. In this way, the order of the documents returned will be different. The proximity query will be more expensive computationally than the straight boolean query, and will take longer to run, but may provide more relevant results at the front of the search.

Wildcards in proximity search

Proximity search supports wildcards directly: < brca? 5D diagnos* > returns documents containing either BRCA1 or BRCA2 within five words of any term starting with the letters diagnos, for instance, diagnose, diagnostic(s), diagnosing, etc.

Ontologies and Proximity Search

Instead of individual terms, you can use ontology entries in proximity search. All of the synonyms for that ontology term will then be used to run the search. For instance:

This will find any documents where any of the synonyms of MECA-79 antigen are found within 10 terms of any term beginning with the word LECAM

Phrases and Proximity Search

Phrases can also be employed in LifeQuest proximity search:

This returns any documents where the exact phrase leukocyte extravasation is found within 10 terms of the exact phrase cellular adhesion.

Constraining Proximity Search to Specific Fields

Proximity searching can be constrained to a specific field in the same manner as any other kind of LifeQuest search.

Multiple Term Proximity Search

You can place multiple terms on either side of proximity search operator. For instance:

This query will find documents where either the term endothelium or the term epithelium is found within 20 terms of either the term COPD or the phrase chronic obstructive pulmonary disease. Note that it functions interchangeably with terms or phrases.

Proximity Search – Putting it all together

All of the ideas described here can be combined to make arbitrarily complex queries.

2.2.6 Fuzzy Search

LifeQuest supports the idea of a fuzzy search, which allows for matches to words that are similar to but not exactly the same as the word you are searching. Fuzzy searching uses the Levenshtein Edit Distance concept to return hits that are equal to or have an edit distance of 1 from your search term.

The operator for fuzzy search is the %. It can only be applied to a single term. It can not be used for phrase searching. It also can not be used inside of a User Word List. However, it can be used in a query that is constrained to a specific field. For instance, consider the following search, which is constrained to the Inventor field.

This will return documents where the word einstein appears, but also where words that can be generated by making a one character insertion, deletion, or substitution in the word einstein. For instance:

This technique is very useful when searching for terms where you suspect there may be minor misspellings due to automated translation into English. It is often used as a double-check to identify documents that might be slightly incorrect, as well as to build your own word lists for such misspellings. For instance, suppose you are seeking documents pertaining to LIDOCAINE. The following search shows all of the documents that refer to misspelled or foreign language spellings of the word, omitting those spellings that are correct:

Edit Distance Parameterization

LifeQuest supports fuzzy searches for terms with Edit Distances of either 1 or 2. The default is 1. To turn it to 2, add the number 2 after the operator:

would match to acidosis, acidosic, acidosises, acidolysis, etc.

Values greater than 2 are not currently supported – they will automatically be adjusted to just 2 edits.

2.2.7 Boosting

Boosting is a way to increase the relevance of certain documents in your search without changing the total composition of the search result. LifeQuest enables you to change the order in which documents are returned by changing the relevance of specific terms in your query. This is done by following a term, phrase, or Boolean group by the boosting operator followed by a number, e.g., tamoxifen OR trastuzumab^2, to mean that TRASTUZUMAB is twice as important in relevance ranking as compared to TAMOXIFEN. Consider the following query:

It asks for all US documents where either TAMOXIFEN or TRASTUZUMAB (or both, of course) are found in the Claims section of the document. When we run this query, we get 3,745 families returned. Note the top result is US20050119188A1 which contains both terms in the claims.

Now, we will boost the importance of the term TAMOXIFEN, making it ten times more relevant than TRASTUZUMAB, by using the Boost operator followed by the number 10:

Notice that the number of families returned does not change. It is still 3,745. However, the first result in the set is no longer US20050119188A1, but rather US8785501B2, which only has TAMOXIFEN in the claims.

It is critical to understand that boosting does not change the ultimate composition of your result set – the exact same documents are returned whether you boost or don’t boost. The only difference is the order of the documents.

You can boost any term, phrase, or Boolean group. You can also boost a term or a group that is part of a constrained search, for instance, Authority:(US^2 OR EP). This operator can not be used inside of a User Word List.

2.6.1 Toggle between Documents and Families

You have the ability to toggle search results to list either every document that matches your search sorted by relevance, or to list the single best representative per family that matches your search. This distinction comes into play when creating Workfiles, particularly those that will be merged with other workfiles, because those operations are performed solely at the Document rather than the Family level.

Note that the below search finds 11,476 families and 16,384 documents within those families. Presently we are viewing the families but by clicking the 16,384 Documents link the search would return all of the individual documents rather than the families.

Note that this toggle uses the Extended Family definition employed by LifeQuest.

2.6.2 Preferred Family Member

When in Family Mode, that is, viewing the search results by family, which document of the family is displayed and saved in a Workfile?

This is a configurable option. By clicking the Preferred family member link under the search box, you can configure the right representative for each family.

LifeQuest will select the representative document for a family based on either a preferred authority or by a set of dates. For instance, in the above example, if there is a US document in the family it will first choose that. If not, it will look for an EP document. If none, a WO. Finally, it will revert to the document with the latest filing date. In the event of more than one document from the highest preferred authority, it will again revert to the preferences around the date, in this case, latest filing date.