SharePoint 2010 Search : Relevancy and Reporting - Custom Ranking

1. Built-In Models

Generally speaking, the default search algorithm is the best compromise. Microsoft has invested heavily in improving and testing the default ranking algorithm. The default algorithms also have the advantage that distance, minimum span, and document length considerations are included and cannot be modified in the custom models. But should a clear need for a different ranking model be identified, it is possible to change the ranking algorithm. It is most likely that a metadata-rich environment with extraordinary importance for particular properties will drive the use of a custom ranking model.

Out-of-the-box SharePoint 2010 Search contains the following ranking algorithms that can be used without any adjustment:

• Default ranking model (Main Results Default)

• Expertise Social Distance ranking model

• High Proximity ranking

• Main People Social Distance

• Expertise model

• Name Social Distance

• Name model

• Main People model

• No Proximity ranking

To get a list of these default models and their GUIDs, open the SharePoint 2010 Management Shell and call the following PowerShell cmdlet (Figure 1):

Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchRankingModel

					  

Figure 1. Calling the built-in ranking models and their GUIDs

These built-in alternative ranking models cannot be modified. However, we can see their effect on the search results by simply adding the rm parameter and the GUID of the ranking model to the URL of the search results page. For example, the query for SharePoint on our demo site with the No Proximity ranking model would have the URL , where k is the query term and rm is the ID of the ranking model. This technique is useful for testing changes to the ranking model but not practical for production implementations. In such cases, the Web Part should be set to use that custom model. See Figure 2.

Figure 2. The No Proximity ranking model applied using the rm parameter in the URL

2. Custom Models

SharePoint administrators can also create their own ranking models. These ranking models are defined in an XML file that can be added to a new ranking model created in SharePoint by a PowerShell command. The XML descriptor will apply a weighted average of the values that are set in it to the ranking scheme.

Listing 1 shows the sample XML descriptor.

Example 1. The sample XML descriptor.

<rankingModel name="string" id="GUID" description="string"

 xmlns="http://schemas.microsoft.com/office/2009/rankingModel">
    <queryDependentFeatures>
        <queryDependentFeature pid="PID" name="string" weight="weightValue"

lengthNormalization="lengthNormalizationSetting" />
    </queryDependentFeatures>
    <queryIndependentFeatures>
        <categoryFeature pid="PID" default="defaultValue" name="string">
            <category value="categoryValue" name="string" weight="weightValue" />
        </categoryFeature>
        <languageFeature pid="PID" name="string" default="defaultValue"
 weight="weightValue"

  />
         <queryIndependentFeature pid="PID" name="string" default="defaultValue"

   weight="weightValue">
             <transformRational k="value" />
             <transformInvRational k="value" />
             <transformLinear max="maxValue" />
         </queryIndependentFeature>
     </queryIndependentFeatures>
 </rankingModel>

					  

This code is broken into the following:

• Query-dependent features: This element contains managed properties that affect dynamic ranking. This element contains a Property ID (PID) that can be extracted from the managed property list using PowerShell, the name of the property (optional), a weight value to apply to the ranking calculation, and an optional length normalization setting.

• Query-independent features: This element contains adjustment to static ranking values.

  • Category features: This element contains the Property ID, property name (optional), and default value. This adjustment is for properties that have static values (associated with the document) and are small enumerable integers.

  • Language features: This element contains the Property ID, name (optional), default value, and weight value. The default value is either 1 or 0, where 1 is the same as the user's locale ID (regional setting) and 0 is not the same.

  • Query-independent feature This element requires at least one of the following:

  • transformRational

  • transformInvRational

  • transformLinear

  • transformLogarithmic

To set the ranking model on the search center, the core results Web Part needs to be changed or a custom Web Part created that calls the GUID of the desired ranking model.

Use the following PowerShell cmdlet to get the IDs of managed metadata properties. See Figure 3.

Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchMetadataManagedProperty

					  

Figure 3. The list of managed metadata properties and their PIDs

Add the PIDs and the ranking adjustments to the QueryDependentFeature element of the XML, as in the following example:

<queryDependentFeature pid="56" name="Filename" weight="50" lengthNormalization="" />

					  

The lengthNormalization parameter allows for consideration of document length when considering a particular text value. In the case of managed metadata values, the need for length normalization is probably low because multiple occurrences of the terms are less likely in long or short documents. LengthNormalization should take a value between 0 and 1, where 0 is no length normalization and 1 is maximum consideration.

The weight parameter takes a value. There is no clear indication as to what value it should take to increase or decrease relative ranking, as the other ranking weights are not available to compare. A guideline for weighting will be somewhere between a weight value of 1, which is what occurrences in the body text are given by default, and 70, which is what occurrences in a title property are given. It is recommended that several rounds of testing be taken before deciding on the best value.

After the proper ranking values have been applied, a new ranking model needs to be created based on the XML. The XML must be applied as a string when creating or setting the new ranking model. To create a new ranking model, open the SharePoint 2010 Management Shell and call the following PowerShell cmdlet:

Get-SPEnterpriseSearchServiceApplication | New-SPEnterpriseSearchRankingModel

 -rankingmodelxml '{the entire xml string with spaces removed}'

					  

However, it is better to create a a ps1 file with the command and then run it from the command prompt so that it can be more easily edited and re-used. Create a text file, and add the foregoing into the text file. Then save it as CustomRanking.ps1. Drag that file into the PowerShell console.

Listing 2 is an example ranking model. It is only an example and has no useful ranking affect. A GUID is needed. There are several ways to generate a GUID—there are even web sites available to generate one if necessary. When creating a custom ranking, make sure the PIDs match the actual property values.

Example 2. An example ranking model

<rankingModel name='Pro SharePoint Ranking'
              id='D51BD02D-2FE4-4712-9DF1-30AD432AC2A1'
              description = 'Pro SharePoint Ranking Model'
              xmlns='http://schemas.microsoft.com/office/2009/rankingModel'>
        <queryDependentFeatures>
                <queryDependentFeature name='Title' pid='2' weight='0'
lengthNormalization='10.0000000000'/>
                <queryDependentFeature name='Keywords' pid='356' weight='0'
lengthNormalization='5.0000000000'/>
                <queryDependentFeature name='Description' pid='6' weight='0'
lengthNormalization='50.0000000000' />
                <queryDependentFeature name='Status' pid='359' weight='0'
lengthNormalization='20.0000000000'/>
        </queryDependentFeatures>

        <queryIndependentFeatures>
                    <queryIndependentFeature name='DistanceFromAuthority' pid='96'
default='5'                 weight='0.0000000000'>
                             <transformInvRational k='0.1359244473'/>
                    </queryIndependentFeature>

                    <queryIndependentFeature name='URLdepth' pid='303' default='3'
weight='0.0000000000'>
                      <transformRational k='1.2170868558'/>
               </queryIndependentFeature>

					  

<queryIndependentFeature name='DocumentPopularity' pid='306' default='0'
weight='0.0000000000'>
                       <transformRational k='1.2170868558'/>
               </queryIndependentFeature>

               <queryIndependentFeature name='DocumentUnpopularity'pid='307' default='0'
weight='0.0000000000'>
                       <transformRational k='1.2170868558'/>
               </queryIndependentFeature>

               <categoryFeature name='Priority' pid='347' default='0'>
                       <category name='Low' value='3' weight='25.0000000000'/>
                       <category name='Medium' value='2' weight='50.0000000000'/>
                       <category name='High' value='1' weight='100.0000000000'/>
               </categoryFeature>

               <languageFeature name='Language' pid='5' default='1' weight='1.0000000000'/>
       </queryIndependentFeatures>

</rankingModel>

					  

3. Setting the Results Webpart to Use Custom Ranking Models

Now that there is a custom ranking model and it has been tested using the rm parameter and appears to be ranking as desired, the core result Web Part or a custom results Web Part needs to be set to always obey that ranking model. To do this, the Web Part needs to be exported, modified, and imported back into the site. The DefaultRankingModelID property must be applied to the Web Part with the GUID of the custom ranking model, because there is no exposed setting in the Edit Web Part pane.

To add this property to the .webpart file, follow these steps:

Now the results should reflect the new custom ranking. If there is more than one result Web Part on the page, all results Web Parts will display ranking based on the model found in the first results Web Part on the page.