Just start typing to find documents containing all entered words, exactly as spelled, anywhere in the document, in any order. Search is not case-sensitive. Additional results will appear as you scroll down.

* at the end of a word is a sliding match. Example: cocc* matches "coccidiosis" and "coccidia" but not "streptococcus" (*cocc* does not work; the * at the beginning matches only an actual asterisk).

The options near the top allow you to specify content sources and sort order. Articles from the Journal of Swine Health and Production tend to show up multiple times. This is shown with a dashed left border on subsequent listings and a copy of any previous URLs you might already have viewed.

You can resize and move this info to the side if you'd like to refer to it as you search.

Advanced options

AND, OR, NOT, and NEARcontrol how the following term (a word, quoted phrase, or search expression in parentheses) is combined with the search results retrieved so far.

<...> AND <term>: the current results are searched for <term>; documents matching both are returned. This is the default; you can omit and from your searches.

<...> OR <term>: the current results are merged with the results of a new search for <term> and all results are returned

<...> NOT <term>: any of the current results that match <term> are dropped; anything left from the current results is returned.

<...> NEAR#<term>: the current results are searched for <term> within # words of the location at which the previous term was matched; the # must be replaced by an integer, e.g., PRRS NEAR4 ELISA finds "ELISA" and "PRRS" within four words of each other..

Searches work term-by-term from left-to-right, but you can change this with parentheses. For example, weight loss prrs or pdns adds any result matching "pdns" to results that contain all of "weight," "loss," and "prrs." A search for weight loss (prrs or pdns) is probably what was intended.

To search for the literal words "and," "or," "not," or "near," put them in double quotes.

Now are these results sorted?

The default sort puts the most relevant results first. The top result always gets a score of 100%. However, I'm not sure that comparisons are very meaningful between sources. If you see two JSHAP abstracts in your search results, you can be confident that the first is more relevant than the second. If you see a news article and a Swine Information Library paper, it's entirely possible that the item listed later would be more relevant to you.

The options to sort by date also vary by source. For news articles, the date sort should be reliable as it is taken from the news database. Regular web pages are date indexed according to the time the file on the server was last modified; this is usually close. Annoyingly, the method currently available to us for indexing all the items in the Swine Information Library fails to extract any meaningful date from the PDFs; the date displayed is when that conference was indexed.

Things you probably don't need to know...

For search engine geeks: you may have guessed that it is faster to put less common terms first, e.g., search for flu swine instead of swine flu -- "flu" has about 250 matches while "swine" has well over 9000, so the second term has much less to search through. Unfortunately, the few milliseconds saved are inconsequential compared to the time it takes to send you the results over the web.

For even more information about searching, you're welcome to take a look at the swish-e documentation, in particular you might find the section on ranking of interest. (As of January 2011, we are using the default ranking scheme, but I am considering reindexing everything to try the newer scheme that considers inverse document frequency. Should probably figure out how to get a meaningful date into PDFs first.)

You must enable JavaScript to use the search capability of this web site.