in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

Life of a Hungarian SharePoint Geek

I've got a lot of help from the SharePoint community, so at the spring of 2007 I decided to create a blog of my own and share my SharePoint experiences.

November 2007 - Posts

  • Creating Keywords and Best Bets for MOSS Search programmatically

    You can administer keywords and best bets on the MOSS admin UI at Search keywords at Site Collection Administration.

    Stefan Goßner gave a code snippet about How To: create Keywords and Best Bets for MOSS Search programmatically. A similar code can be found in the very useful SharePoint Server 2007 Presentations: Enterprise Search Deep Dives presentation series, Customizing and Extending Search in Office SharePoint Server 2007.

    Based on my experiments there might be a little but important problem with this code. When creating the new Keyword instance, you should use DateTime.UtcNow instead of DateTime.Now to enable the Keyword immediately:

    keywords.AllKeywords.Create("myKeyword", DateTime.UtcNow);

    When you create the keyword through the UI, you can specify only the date part, no hours and minutes. In this case the keyword is created with a start date (StartDate property) 0:00 AM UTC for the specified date. For example, currently our local time is GMT+1, so the start date would be 23:00 PM for the previous day.

    When I used the code samples “as is”, the keywords were not displayed in the results. After one hour, the repeated search already displayed the keyword matches. When I used the DateTime.UtcNow, the results were displayed immediately. Of course, if your configured time zone is west from the GMT time line, then DateTime.Now should work also, as it is refers to a time in the past if you interpret it as UTC time.

    If you try to create a best bet on the UI that refers to an URL already used in an existing best bet you cannot save the new best bet. I found another interesting behaviour of creating keywords and best bets from code. The code that creates the best bets with a common URL but different titles and descriptions will run without errors:

    Keyword keyword1= keywords.AllKeywords.Create("keyword1", DateTime.UtcNow);
    BestBet bestBet1 = keyword1.BestBets.Create("BestBet1", "Description1", new Uri(http://www.company.com));
    keyword1.Update();
    Keyword keyword2= keywords.AllKeywords.Create("keyword2", DateTime.UtcNow);
    BestBet bestBet1 = keyword2.BestBets.Create("BestBet2", "Description2", new Uri(http://www.company.com));
    keyword2.Update();

    In the example above the best bet for keyword2 will refer to the BestBet with title BestBet1 created for keyword1.
  • High Confidence Results in MOSS 2007

    At the MSDN forum I found an interesting question that asks what high confidence results are. After some investigation I think I have the answer for this question.

    First of all, high confidence results are displayed by the Microsoft.Office.Server.Search.WebControls.HighConfidenceWebPart (Microsoft.Office.Server.Search assembly). On the standard search result page (results.aspx) there are two instances of this web part. One is Search High Confidence Results, the other is Search Best Bets. If you check the properties of the HighConfidenceWebPart either by modifying the shared web part, or by using Reflector, you can see that this web part can display keyword matches with best bets and the mysterious high confidence results. By default the Search High Confidence Results web part instance is configured to display the high confidence results and the Search Best Bets web part instance is configured to display keywords and best bets (as one can guess from their name).

    The SDK contains information about that when the Enterprise Search returns the results there is a HighConfidenceResults table that is “The result set containing high-confidence results”. Well, it is not very descriptive, is it?

    Let’s see the formatting XSL for the HighConfidenceWebPart. You can check it in the XSL Editor in the Data View Properties section of the tool part. Fortunately, there is a template for the HighConfidenceResults, displayed below:

    <xsl:template match="All_Results/HighConfidenceResults/Result"> 
     <xsl:if test="$DisplayHC = 'True' and $IsFirstPage = 'True'" >
      <xsl:variable name="prefix">IMNRC('</xsl:variable>
      <xsl:variable name="suffix">')</xsl:variable>
      <xsl:variable name="url" select="url"/>
      <xsl:variable name="id" select="id"/>
      <xsl:variable name="pictureurl" select="highconfidenceimageurl"/>
      <xsl:variable name="jobtitle" select="highconfidencedisplayproperty1"/>
      <xsl:variable name="workphone" select="highconfidencedisplayproperty2"/>
      <xsl:variable name="department" select="highconfidencedisplayproperty3"/>
      <xsl:variable name="officenumber" select="highconfidencedisplayproperty4"/>
      <xsl:variable name="preferredname" select="highconfidencedisplayproperty5"/>
      <xsl:variable name="aboutme" select="highconfidencedisplayproperty8"/>
      <xsl:variable name="responsibility" select="highconfidencedisplayproperty9"/>
      <xsl:variable name="skills" select="highconfidencedisplayproperty10"/>
      <xsl:variable name="workemail" select="highconfidencedisplayproperty11"/>

    You can see, that all of the properties are related to persons. I found that if you search for a person specifying the full name, and there is match, then it is displayed as a high confidence result. In the web part properties you can specify if the title, image, description and other properties should be displayed for a high confidence match. There is a ResultsPerTypeLimit property (“Maximum matches per High Confidence type ”) that similar to the BestBetsLimit property (“Best Bets limit ” on the user interface). Based on my experience, the BestBetsLimit works as expected but the ResultsPerTypeLimit seems to have no effect on the displayed results. Checking the default formatting XSL shows that the BestBetsLimit property is used (BBLimit parameter), but the ResultsPerTypeLimit is not used, although it is declared as an XSL parameter with the same name.

    You should include the following condition in the HighConfidenceResults template (see above) after checking the "$DisplayHC = 'True' and $IsFirstPage = 'True'" condition:

    <xsl:if test="position() &lt;= $ ResultsPerTypeLimit " >

    Remark: The XSL parameter values are populated in the ModifyXsltArgumentList method of the HighConfidenceWebPart web part.

Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts