Microsoft SharePoint 2007 Technologies

128 6.3 Consuming Search

Just a word of caution before we move on from managed properties:

remember that there is only one definition of a property as far as the index

goes. Therefore, if you have two properties that have the same name but serve

different purposes, then you have some thinking to do! A simple example

will help explain here. Let’s assume we have two site collections and each one

contains a custom list with a column that the site administrator has created

called “Band.” The result of this is a single crawled property called

ows_Band. Now, in the first site collection, Band may refer to a rock group,

whereas in the second it might be being used for salary bands—so what do

you do if one site collection wants to do a property-based search on band but

the other doesn’t?

There is no easy answer to this, especially since end users are empowered

to create any metadata they like. The only suggestion we have is to think

carefully about where crawled properties are actually being used before you

attach them to a managed property.

6.3 Consuming Search

Search can be consumed from multiple places and in multiple ways—a

search Web service and a full object model are available to allow you to

exploit the index from within your own applications. We are now going to

take a look at the various ways that you can consume search out of the box,

starting with a look at the different ways you can formulate and execute a

search query.

Figure 6.9

Administering a

crawled property.

6.3 Consuming Search 129

Chapter 6

6.3.1 Search Query Syntax

There are three main ways in which you can formulate and execute search

queries: via a keyword search, Structured Query Language (SQL) full-text

extensions, or a URL search. The functionality that is ultimately delivered to

end users depends on how these queries are formulated by the calling appli-

cation. For example—in fact, for what is probably a very disappointing

example to most folks—the search engine supports wildcard searches

through the SQL syntax by using the CONTAINS predicate. But is there

anywhere out of the box with SharePoint that actually formulates such a

query? I’m afraid the answer is no, so either writing your own or finding a

third-party (such as Ontolica) may be in the cards if you need this function-

ality. A very good community tool that can be used to generate queries is

called the MOSS Query Tool and is available at www.wssdemo.com/Lists/

Resources/DispForm.aspx?ID=893.

Keyword searches are the most straightforward and are used by the basic

search Web Parts in SharePoint. As the name suggests, the query itself is a

list of key words that should either be present or not be present in an item

if it is deemed to have matched the search query. As well as constraining

the result set based on key words, you can also add additional constraints

based on managed property values. So, for example, you can execute a

query that looks for certain words contained in the FirstName managed

property, as we saw in Figure 6.8. Although I said earlier that wildcard

searches do not surface in SharePoint, there is an exception here, as wild-

cards do work when you use a property filter constraint in your query.

Thus entering “FirstName:Pa” would return all first names that begin with

“Pa.” There are also special inbuilt property filters that can be used, as we

will see later with the use of the duplicate filter.

A keyword search supports multiple terms, which can either be a sin-

gle word or a phrase (enclose the phrase in quotation marks: “”). A key-

word search executes an implicit AND, which is different from that of SPS

2003, which executed an implicit OR. This means all the terms you specify

must be in the item for it to be returned as a search result. But you can fur-

ther constrain your keyword search by using + or - in front of a term. The +

indicates that the term must exist in the content, and a - indicates that a

term must not exist in the content.

Stemming—the ability to return content containing words that are

closely related to the key word using inflectional variants—is supported, but

has to be enabled in the Search Core Results Web Part. As an example, when

stemming is enabled, a search for the word “Share” would also return hits on

“Sharing” but not on “SharePoint.”

SQL syntax queries give the most flexibility, with a rich syntax that allows

you to perform very complex and specific searches including wildcards. You