Eu estou a traballar nun documento de análise da arquitectura esta semana e suxire, entre outras cousas, 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.

It was surprisingly difficult to figure out how to do, although it is, de feito, quite easy. There’s a pretty good bit of information on the thesaurus (check aquí e aquí, por exemplo). Con todo, those docs are either 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, but it’s not enough to cross the finishing line.

These steps worked for me:

1. Make the changes to the thesaurus. (See below for an important note)
2. Go to the server and restart the "Office SharePoint Server Search" service.

A tip of the hat to Mr. 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 proves, unha vez, that Twitter is the awesome. (Follow me on twitter here. 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, please leave a comment or email me and I’ll update this post.

Importante: There’s conflicting information on which XML thesaurus file to change. There’s this notion of "tsneu.xml" as being the "neutral" Wikipedia. I wasted some time working with that one. No meu caso, I needed to change the "tsenu.xml" file located under the folder of the app ID itself: \\win2003srv\c$\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications\3c4d509a-75c5-481c-8bfd-099a89554e17\Config. I assume that in a multi-farm situation, you would make this change everywhere a query server runs.

</final>

Rexístrate para o meu blog.

Eu rematar día 2 de adestramento rápido na soleada Needham, MA, e eu estou cheo de ideas (que todos os bos cursos de formación que facer para me). 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" empurrou-o para fora da miña cabeza.

Nós SharePoint WSS 3.0 / Moss implementadores miúdo enfrontan un problema difícil con calquera proxecto SharePoint de tamaño razoable: Como podemos obter todos os datos non marcados cargados no SharePoint de xeito que todo encaixa dentro da nosa arquitectura de información perfectamente deseñado?

Moitas veces, o suficiente, este non é un problema tan difícil, porque nós mesmos ámbito de problemas: "We don’t care about anything more than 3 months old." "We’ll handle all that old stuff with keyword search and going-forward we’ll do it the RIGHT way…" Etc.

Pero, 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 (ou mesmo millóns) de docs — a carga e reserva de que é o noso desexo devoto?

Rápido pode ser a resposta.

Proceso de procura da FAST inclúe unha serie de partes móbiles, pero unha visión simplificada é este:

• Un proceso rastreador busca por contido.
• Atopa contido e entrega-lo a un proceso corrector que xestiona un pool de procesadores de documentos.
• Proceso Broker entrega-lo para un dos procesadores de documentos.
• O procesador analiza o documento e o documento por medio dun proceso de oleoduto, analiza o bejeezus fóra do documento e entrega-lo a un proceso de tipo constructor índice.

O rápido nave, we have a lot of control over the document processing pipeline. We can mix and match about 100 compoñentes de Segmentación e, o máis interesante, 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.

Así … usar o FAST en combinación co noso propio compoñente Segmentación personalizado, we can grab all that context information from FAST and feed it back to MOSS. It might go something like this:

• Documento aliméntase en FAST Moss.
• Normal tolo obsesivo análise de documentos rápida e categorización pasa.
• Noso propio compoñente Segmentación personalizado cae algunhas desas información fóra de contexto para unha base de datos.
• Un proceso de noso propio proxecto le a información de contexto, fai que algunhas decisións sobre como encaixar ese documento Moss dentro do noso IA e marca-lo usando un servizo web eo modelo de obxecto.

Por suposto, ningún proceso automatizado pode ser perfecto, pero grazas ao obsesivo (e, posiblemente, insano-mais-en-un-bo-como a xente rápidas), podemos ter unha loita real filmado nun proceso de subida masiva verdadeiramente eficaz que fai máis que encher unha base de datos SQL con unha morea de documentos mal-searchable.

</final>

Rexístrate para o meu blog.

Eu tiña razón hoxe para xogar sobre o codeplex busca achaflanada project today.

Foi en torno dun tempo, pero eu dubidei en descargar e usalo polas razóns habituais (sobre todo falta de tempo), plus outright fear 🙂

Se está mirando para mellorar a súa busca e explorar novas opcións, 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 — en minutos, pode instalar, configure-lo, use it and add some pretty cool functionality to your vanilla MOSS search and be a hero 🙂

</final>

Rexístrate para o meu blog.

No foro de investigación MSDN, as persoas acostuman facer unha pregunta como esta:

"I have a document named ‘Programming Guide’ but when I search for ‘Pro’ investigación non atopalo."

Non pode sentir como el, but that amounts to a wildcard search. The MOSS/WSS user interface does not support wildcard search out of the box.

Se cavar as pezas busca na web, atoparás unha caixa de verificación, "Enable search term stemming". Stemming is a human-language term. It’s not a computer language substring() función do tipo.

Estes son algúns talos:

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

Estes non son deriva:

• "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

Un produto de terceiro partido, Ontolica, provides wild card search. I have not used that product.

</final>

Rexístrate para o meu blog.