|
|
|
|
|
|
Harnessing Properties in SharePoint Search
Most users of SharePoint Portal Server rapidly become enamored with the ability to add new fields (containing meta data) to documents in the document library. All of the sudden it becomes possible to associate information to a file beyond the file name that we've been limited to since the beginning of the computing era.
Few users, however, have the opportunity to understand how this meta data is used by SharePoint for searching. This leads to problems when users decide that it's necessary to use SharePoint Portal Server Search to search on information contained in a field that they have added. In this article you'll learn how SharePoint uses document library fields to create properties that are searchable and how to enable searching on those properties.
The Power of Properties
SharePoint Portal Server's search facility really works in two different ways. First, there's the full text search. This searches across all of the text in every document that is in the index. This is the search most people think of when they think of SharePoint's search capability.
Second, there is the property search. During the indexing process, the IFILTERs, which extract the text out of the documents, put property information into special property buckets that are kept separate in the index so they can be searched separately. This allows you to set properties in your Office documents such as department, project number, author, keywords, etc., and then have the ability to search on those fields individually.
You can use the search engine in SharePoint to search for documents where the department is engineering and the project is 123. Where a full text document search for engineering and 123 may find hundreds of entries because the words engineering and the number sequence 123 appears in many documents, a search via properties may yield the 10 or so documents that are truly relevant to your search.
Properties are what most people believe they are creating when they create a new field in a document library. That's not actually true. The meta data fields in a document library don't have anything to do with properties directly.
Office Does a Slight of Hand
During the edit process, however, Office performs a little slight of hand. It takes the information you enter in the meta data fields for the document library and makes corresponding custom properties in the document. The net effect is that, although you've only created fields in a document library, your documents now have custom properties.
These custom properties are picked up by the indexing process (more specifically, the IFILTER for Office documents) and they are placed into the search index. You can then use those properties by making them available via the advanced search page in SharePoint.
But this also means that non-Office documents don't share the same relationship between fields in the document library and the properties of the document itself. So if you're trying to develop a searching mechanism for documents like TIF documents or PDFs, you'll find that setting up a meta data field for those document libraries won't allow you to search for those documents directly via their properties. You'll still be able to organize the information
Setting Up a Test
Putting It to Work
File Properties shows the additional fields from the document library.
Now you have a document in SharePoint with properties so you can go set up the search for them.
Ensure the Document is Indexed
Set Up the Properties for Search
The IntranetJournal property shows up in the properties of crawled documents.
You can now search SharePoint Portal Server for just the field you added in the list . Of course, as you have seen, you're actually searching the property that was added to the Word document, but the effect is the same since Office is managing the transition to the document properties.
|
Intranet Journal's Tutorials |
|
Managing Editor |