Index schema cmdlets (FAST Search Server 2010 for SharePoint)

Gilt für: FAST Search Server 2010

Letztes Änderungsdatum des Themas: 2015-03-09

Microsoft FAST Search Server 2010 for SharePoint provides a full set of cmdlets to customize the administration of metadata extracted from content sources and to make that metadata searchable.

Index schema management

The FAST Search Server 2010 for SharePoint index schema controls which managed properties are indexed, searchable, and available for viewing. The index schema cmdlets work with metadata extracted from content sources. Metadata can be structured content (such as a title or author from a Word document) or unstructured content based on the content of an item (such as a detected language or extracted keywords). When managing metadata, you work with crawled properties and managed properties:

• A crawled property is metadata extracted from content sources when you run a crawler or connector.

• A managed property is a subset of crawled properties that are searchable. To make metadata searchable, map one or more crawled properties to a managed property. You can also create a full-text index and map the content of a managed property into the full-text index.

Crawled properties can be grouped into a category when they share common attributes. The category properties then control the default behavior of the member crawled properties. For example, you may group crawled properties extracted from SharePoint items into one category.

With schema cmdlets, you can also create rank profiles to control the relevancy calculation of queries, and to adjust the components of a rank profile for improving search result relevance. A rank profile defines the sort order of a result set.

In this section:

• Manage crawled properties

• Manage categories

• Manage mapped properties

• Manage managed properties

• Manage full-text indexes

• Manage full-text indexes mapping

• Manage rank profiles

Manage crawled properties

A crawled property is a piece of metadata, either structured or unstructured, that is extracted from content repositories. The main purpose of discovering crawled properties is to discover content that should be searchable. Crawled properties that are searchable are mapped to managed properties.

Crawled properties are automatically discovered and reported to the index schema model when content that contains the property is fed into the system. If you want to map a crawled property before it is discovered (that is, before items are indexed), you can create the crawled property using the New-FASTSearchMetadataCrawledProperty cmdlet. This is useful if you are creating a complete deployment script for a new installation before you start a crawl, or when you are moving a deployment configuration from a staging environment to production.

There are two ways to make a crawled property searchable:

• Use the Set-FASTSearchMetadataCrawledProperty cmdlet to specify that the crawled property will be mapped to the default full-text index.

• Map the crawled property to a managed property. This method provides additional configuration options. They include the following:

  • Map the property to other full-text index fields.

  • Configure the managed property for search result sorting.

  • Configure the property for query refinement.

  • Make the property searchable as metadata.

  • Return the property as part of the query hit list.

Crawled property cmdlets

Use these cmdlets to specify crawled properties:

Manage categories

A category contains several crawled properties that are grouped together for specifying common properties. The properties of the category control the default behavior of the member crawled properties. For example, you can group crawled properties extracted from Lotus Notes databases into one category.

A category can be mapped to a full-text index just as you would map individual crawled properties to a full-text index. This simplifies making all properties from one content repository searchable without mapping each property individually. This also ensures that new properties from a repository are automatically discovered and indexed.

You will not have to create categories often, because they are usually defined by the protocol handler of the connector. However, one common scenario for creating a new category is when you want to handle the same properties from multiple repositories differently, even if the properties were retrieved by the same connector. For example, you may have to map categories to different managed properties.

Category cmdlets

Use these cmdlets to define and manage categories:

Manage mapped properties

A managed property is content or metadata associated with an item that may be searched or used in other ways, such as being displayed in search results or used for query refinement. To define the content of managed properties, you create mappings from one or more crawled properties to a managed property. For example, if you have two crawled properties called author and editor, you may want to map them into a name property so that the source properties are searchable as one field.

You can also map properties in the UI at Central Administration > Search Service Application: FAST Search Administration > Property Management.

Mapped property cmdlets

Use these cmdlets to associate crawled properties with managed properties:

Manage managed properties

A managed property is content or metadata associated with an item that may be searched or used in other ways, such as being displayed in search results or used for query refinement. To make metadata searchable, first define the managed properties. Then, map the crawled properties that should be searchable to a managed property. At this point, the crawled metadata is searchable as a field. To search this metadata automatically as a general part of the item, map the content of a managed property into the default full-text index (known as content) for querying. You can create additional full-text indexes if you only want this mapping to apply to selected queries.

You can also configure managed properties in the UI with Central Administration > Search Service Application: FAST Search Administration > Property Management.

Managed property cmdlets

Use these cmdlets to specify managed properties:

Manage full-text indexes

Full-text indexes are the main searchable content of a FAST Search Server 2010 for SharePoint system (a search system can also include fielded searching).

To specify the content that should be included in the indexes, map managed properties into the full-text indexes.

Full-text index cmdlets

Use these cmdlets to manage full-text indexes:

Manage full-text indexes mapping

To specify the metadata content that should be included in a full-text index for searching, define mappings from managed properties to full-text indexes. You can group properties into a full-text index so that searchers can query over multiple properties at the same time, and so that multiple properties are presented as one unique name in your search application. By mapping multiple properties into one index, you can also facilitate dynamic relevancy ranking of queries.

The default full-text index (known as content) is the target for free-text queries, accessed when a searcher does not specify a property or index in a query. You can create additional full-text indexes if you want selected queries to target a set of properties other than those specified in the default full-text index.

You can also configure individual managed properties for fielded searching. Fielded searching does not contribute to ranking, and is primarily used by searchers to filter or refine a search result set.

Full-text index mapping cmdlets

Use these cmdlets to map managed properties to full-text indexes:

Manage rank profiles

A rank profile defines how relevancy calculations are performed when you search a full text index. A rank profile consists of several components which are weighted when calculating an item's relevance. You can adjust the weights of a profile’s components to improve search result relevance. Rank profile components include the following:

• Freshness: how the age of an item affects rank

• Proximity: how the distance between query terms affects rank

• Authority: how links between Web documents affect rank

• Query authority: how user selections in query results affect rank

• Context: how different managed properties within the associated full text indexes contribute to the rank

When a user conducts a search, if no rank profile is specified in the query, the default rank profile is used. Searchers can sort search results by a selected rank profile.

Rank profile cmdlets

Use these cmdlets to manage rank profiles: