Estic treballant en un document de revisió arquitectura aquesta setmana i suggereix, entre altres coses, que el client considera utilitzant el tesaurus per ajudar a millorar l'experiència de cerca de l'usuari final. Haver fet mai a mi mateix, Volia fer una prova ràpida de mans per tal que el meu suggeriment és autèntic.

Era sorprenentment difícil d'esbrinar com fer, encara que és, de fet, bastant fàcil. Hi ha un bon mica d'informació sobre el tesaurus (Registre d'entrada aquí i aquí, per exemple). No obstant això, Aquests documents són tampoc WSS 2.0 / SPS 2003 orientat o en realitat no precisar què fer per després de fer els canvis en el tesaurus. Proporcionen una gran visió de conjunt i una mica justa de detall, però no és suficient creuar la meta.

Aquests passos funcionava per mi:

1. Modifiqueu el tesaurus. (Vegeu a continuació una nota important)
2. Anar al servidor i torneu a iniciar la "oficina de cerca del SharePoint Server" servei.

Una punta del barret per Sr.. J. D. Wade (Bio). Ell sempre la clau mica sobre reprendre el servei de cerca i em va rescatar d'una infinitat, iisresets temps consumint i innecessaris i rastreig complet índex. Aquest episodi demostra, una vegada més, que Twitter és l'impressionant. (Segueix-me a twitter aquí. Vaig seguir qualsevol persona del SharePoint que em segueix).

No sé si aquesta funcionalitat està disponible en WSS. Si és o no és, Si us plau deixar un comentari o e-mail me i Actualitzaré aquest correu.

Nota important: Hi ha informació contradictòria sobre quin fitxer de tesaurus XML canviar. Hi ha aquesta noció de "tsneu.xml" com el "neutre" Tesaurus. Malgastava algun temps treballant amb aquell. En el meu cas, Necessitava canviar el tsenu.xml"" arxiu situat sota la carpeta de l'app ID propi: \\win2003srvc$ Program Servers12.0DataOffice oficina ServerApplications3c4d509a - 75 c 5-481 c-8bfd-099a89554e17Config. Suposo que en situació multi-granja, et vols fer aquest canvi a tot arreu que s executa un servidor de consulta.

</final>

Subscriure's al meu blog.

He acabat el dia 2 de ràpida formació de Needham assolellat, MA, i estic ple d'idees (fer que totes les bones classes d'entrenament per a mi). Un aspecte particular de pressa em té pensant i volia escriure mentre era encara fresc i normal del dia a dia "coses" empès això del meu cap.

Ens SharePoint WSS 3.0 / Executors de molsa freqüentment encarar amb un problema difícil amb qualsevol projecte de SharePoint raonablement mida: Com podem obtenir totes les dades sense etiquetar carregats a SharePoint tal que tot encaixa dins de la nostra arquitectura de la informació perfectament dissenyat?

Amb prou freqüència, això no és un problema difícil perquè nosaltres mateixos abast fora de problemes: "No ens preocupem per res més que 3 mesos d'edat." "Ens en encarreguem coses de tot el que sempre amb cerca per paraula clau i anant endavant ho farem el camí correcte…" Etc..

Però, Què passa si nosaltres no abast-nos fora de problemes i estem buscant a 10 de milers o al 100 de milers (o fins i tot milions) de documents de — la càrrega i Etiquetatge del qual és el nostre desig de devot?

RÀPID podria ser la resposta.

Procés de cerca de ràpid inclou un munt de parts que es mouen, però una visió simplificada és la següent:

• Un procés de rastrejador busca contingut.
• Es troba el contingut i les mans fora a un procés de corredor que gestiona una piscina de processadors de document.
• Procés de corredor és les mans fora a un dels processadors de document.
• El processador de document analitza el document i mitjançant un procés de canonada, analitza la bejeezus del document i les mans fora d'un procés de tipus de constructor d'índex.

En la nau ràpid, tenim un munt de control sobre el document de processament de canonades. Podem barrejar i lligar amb sobre 100 components de canonades i, més interessantment, podem escriure components de la nostra pròpia. Com vaig dir, RÀPID és analitzar documents de totes direccions però diumenge i recull una gran quantitat d'informació útil sobre els documents. Són aquestes persones ràpids boig clarament boig i obsessiu sobre l'anàlisi del document perquè tenen eines i/o estratègies realment classificar documents de.

Així … utilitzant ràpid en combinació amb la nostra pròpia component personalitzat canonada, podem agafar tota aquella informació de context de ràpid i alimentar-lo altra vegada a la molsa. Es podria anar alguna cosa com això:

• Document s'alimenta en ràpid de molsa.
• Normal bojos obsessiu document ràpid analitzar i categorització passa.
• Nostra pròpia component personalitzat canonada cau alguns d'aquella informació de context fora a una base de dades.
• Un procés de producció pròpia llegeix la informació de context, fa algunes decisions sobre com encaixar aquest document molsa dins nostre IA i marca utilitzant un servei web i el model d'objecte.

Clar, cap tal procés automatitzat pot ser perfecte, però gràcies a l'orientalisme (i la gent possiblement insane-but-in-a-good-way ràpid), podem tenir una veritable lluita disparat a un procés de càrrega massa veritablement eficaç que alguna cosa més que omplir una base de dades SQL amb un grapat de documents amb prou feines searchable.

</final>

Subscriure's al meu blog.

Jo tenia raó avui per jugar amb el Cerca Facetades CodePlex projecte avui.

Ha estat al voltant una estona, però em resistia a descarregar i utilitzar-lo per les raons habituals (principalment la manca de temps), plus outright fear 🙂

Si vostè està buscant per millorar la cerca i explorar noves opcions, Descarregar i instal·lar-lo quan té una hora o així temps lliure. Seguia les instruccions del manual d'instal·lació i em prenia menys de 20 minuts que s'instal·li i explotació. Proporciona minut valor zero.

Sembla força dur d'estendre. Els autors oferir un recorregut històric per un escenari complex del BDC. Pot estar perdent-lo, però m'agradaria que també proporcionaria un escenari més simple que impliquen una de les propietats preexistents o potser afegint una propietat administrada nova. Ha provo i escriure que jo mateix es mostra en el següent període de temps.

Bottom line — en minuts, vostè pot instal lar, Configureu-lo, use it and add some pretty cool functionality to your vanilla MOSS search and be a hero 🙂

</final>

Subscriure's al meu blog.

En el fòrum de cerca MSDN, la gent sovint una pregunta com aquesta:

"Tinc un document anomenat" Guia de programació’ però quan vaig buscar "Pro’ Cerca no trobar-lo."

No es pot sentir com es, però que equival a una cerca de comodí. La interfície d'usuari MOSS/WSS admet comodí cerca fora de la caixa.

Si s'aprofundeix en les parts de webs de cerca, hi trobareu una casella de selecció, "Habilitar la lematització de terme de cerca". Derivada és un terme humans-llengua. No és una subcadena de llengua d'ordinador() funció del tipus.

Aquestes són algunes tiges:

• "el peix" és una tija a la pesca»"
• "important" és una tija en "amb especialització"

Aquestes no són les tiges:

• "maj" no és una tija en "important"
• "pro" no és una tija "programador"

El motor de cerca WSS/molsa suport comodí cerca a través de l'API. Aquí està un article del bloc que descriu com fer-ho: http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2008/03/06/how-to-use-the-moss-enterprise-search-fulltextsqlquery-class.aspx

Producte d'una 3a festa, Ontolica, proporciona recerca comodí. No he utilitzat aquest producte.

</final>

Subscriure's al meu blog.