Ek is besig om hierdie week op 'n argitektuur oorsig dokument en dit dui daarop, onder andere, that the client consider using the thesaurus to help improve the end user search experience. Having never done this myself, I wanted to do a quick hands-on test so that my suggestion is authentic.

Dit was verbasend moeilik om uit te vind hoe om dit te doen, alhoewel dit, in werklikheid, quite easy. There’s a pretty good bit of information on the thesaurus (gaan hier en hier, byvoorbeeld). Egter, dié dokumente word óf WSS 2.0 / SPS 2003 oriented or they don’t actually spell out what do to after you’ve made your changes in the thesaurus. They provide a great overview and fair bit of detail, maar dit is nie genoeg om die wenstreep oor te steek.

Hierdie stappe het vir my gewerk:

1. Make the changes to the thesaurus. (Kyk hieronder vir 'n belangrike noot)
2. Gaan na die bediener en weer begin die "Office SharePoint Server Soek" diens.

'N wenk van die hoed Mnr. J. D. Wade (bio). He provided the key bit about restarting the search service and rescued me from endless, time consuming and unnecessary iisresets and full index crawls. This episode bewys, weer, dat Twitter is the awesome. (Volg my op Twitter. I follow any SharePoint person that follows me).

I don’t know if this functionality is available in WSS. If it is or is not, los 'n kommentaar of e-pos my asseblief en ek sal hierdie post werk.

Belangrike nota: There’s conflicting information on which XML thesaurus file to change. There’s this notion of "tsneu.xml" as synde die "neutrale" tesourus. I wasted some time working with that one. In my geval, Wat ek nodig het om die "tsenu.xml te verander" lêer is onder die gids van die app ID self: \\win2003srv c $ Program Files Microsoft Office Servers 12,0 Data Office Server Aansoeke 3c4d509a-75c5-481c-8bfd-099a89554e17\Config. I assume that in a multi-farm situation, jy sou hierdie verandering oral 'n navraag bediener loop.

</einde>

Skryf in op my blog.

Ek het klaar op dag 2 van FAST opleiding in sonnige Needham, MA, en ek bars met idees (wat al die goeie opleiding klasse aan my doen). One particular aspect of FAST has me thinking and I wanted to write it down while it was still fresh and normal day-to-day "stuff" druk dit uit my kop.

Ons SharePoint WSS 3.0 / MOSS implementeerders dikwels 'n moeilike probleem met 'n redelik-grootte SharePoint-projek in die gesig staar: Hoe kry ons al die ongemerkte data gelaai in SharePoint so dat dit alles inpas in ons perfek inligting argitektuur?

Dikwels genoeg, dit is nie so 'n moeilike probleem omdat ons onsself omvang uit die moeilikheid: "Ons gee nie om nie oor enigiets meer as 3 months old." "We’ll handle all that old stuff with keyword search and going-forward we’ll do it the RIGHT way…" Etc.

Maar, what happens if we can’t scope ourselves out of trouble and we’re looking at 10’s of thousands or 100’s of thousands (of selfs miljoene) van Dokumente — die laai en Die kodering waarvan is ons toegewyde wens?

Vinnig kan die antwoord wees.

FAST se soek-proses sluit in 'n baie bewegende dele, maar een vereenvoudigde siening is dit:

• 'N kruiper lyk vir die inhoud.
• Dit vind inhoud en gee dit aan 'n makelaar wat die bestuur van 'n poel van die dokument verwerkers.
• Broker proses oorhandig dit aan een van die dokument verwerkers.
• Die dokument verwerker analiseer die dokument en via 'n pypleiding, analiseer die bejeezus van die dokument en gee dit af tot 'n indeks bouer tipe.

Op op die skip vinnig, we have a lot of control over the document processing pipeline. We can mix and match about 100 die pyplyn komponente en, baie interessant, we can write our own components. Like I say, FAST is analyzing documents every which way but Sunday and it compiles a lot of useful information about those documents. Those crazy FAST people are clearly insane and obsessive about document analysis because they have tools and/or strategies to REALLY categorize documents.

So … die gebruik van vas, in kombinasie met ons eie persoonlike pyplyn komponent, we can grab all that context information from FAST and feed it back to MOSS. It might go something like this:

• Die dokument word gevoed in vinnig van Moss.
• Normale Crazy-obsessiewe vinnige dokument parsing en kategorisering gebeur.
• Ons eie persoonlike pyplyn komponent val 'n paar van daardie konteks inligting aan 'n databasis.
• 'N proses van ons eie ontwerp lees die konteks inligting, maak 'n paar besluite oor hoe dit mos dokument te pas binne ons IA en merk dit met behulp van 'n web-diens en die voorwerp model.

Natuurlik, geen so 'n outomatiese proses kan perfek wees nie, maar te danke aan die obsessiewe (en moontlik stapelgek-maar-in-'n-goeie-manier FAST mense), ons kan 'n ware gevegte geskiet op 'n werklik effektiewe massa-vrag proses wat doen meer as net 'n SQL databasis vul met 'n klomp van skaars soekbare dokumente.

</einde>

Skryf in op my blog.

Ek het rede om vandag te speel oor met die CodePlex fasette soek project today.

Dit was vir 'n rukkie, maar ek huiwer om af te laai en dit gebruik om die gewone redes (hoofsaaklik 'n gebrek aan tyd), plus outright fear 🙂

As jy soek om jou soektog te verbeter en om nuwe opsies te ondersoek, download it and install it when you have an hour or so of free time. I followed the installation manual’s instructions and it took me less than 20 minutes to have it installed and working. It provides value minute zero.

It does look pretty hard to extend. The authors provide a detailed walk-through for a complex BDC scenario. I may be missing it, but I wish they would also provide a simpler scenario involving one of the pre-existing properties or maybe adding one new managed property. I shall try and write that up myself in the next period of time.

Bottom line — in minute, jy kan installeer, instel, use it and add some pretty cool functionality to your vanilla MOSS search and be a hero 🙂

</einde>

Skryf in op my blog.

Op die MSDN forum, Mense vra dikwels 'n vraag soos hierdie:

"I have a document named ‘Programming Guide’ but when I search for ‘Pro’ soek nie dit vind."

Dit mag dalk nie so voel, but that amounts to a wildcard search. The MOSS/WSS user interface does not support wildcard search out of the box.

As jy grawe in die search web dele, vind jy 'n boks, "Enable search term stemming". Stemming is a human-language term. It’s not a computer language substring() tipe funksie.

Hierdie is 'n paar stingels:

• "fish" is a stem to "fishing"
• "major" is a stem to "majoring"

Dit is nie spruit:

• "maj" is not a stem to "major"
• "pro" is not a stem to "programmer"

The WSS/MOSS search engine does support wild card search through the API. Here is one blog article that describes how to do that: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2008/03/06/how-to-use-the-moss-enterprise-search-fulltextsqlquery-class.aspx

'N 3de party produk, Ontolica, provides wild card search. I have not used that product.

</einde>

Skryf in op my blog.