TemaSearch Teknisk Dokumentasjon

Introduksjon til TemaSearch

TemaSearch er et system for å finne søkeord-aliaser. Den har som mål å forbedre effektiviteten til ditt eksisterende søkesystem ved å finne tilleggord som er relatert til ordene som gis i et søkespørsmål. Ut av boksen kommer det med bøyningsordbøker, lister over stavevarianter, nære og generelle synonymer, og oversettelseslister – tilgjengelig på både Bokmål og Nynorsk. De innebygde applikasjonene lar deg legge til utvalgte typer ord til søkespørsmålet, med mulighet for interaksjonsmoduser, fra helt automatisk tillegg av nye ord, til full manuell valg av brukeren, eller en kombinasjon av disse to.

Vær oppmerksom på at denne dokumentasjonen diskuterer alle funksjoner tilgjengelig i TemaSearch. Noen funksjoner kan være utilgjengelige for visse typer lisenser.

Generelle funksjoner

• Database av en rekke typer ordalternativer
• Inkluderer relaterte ord automatisk i søk
• Manuell valg av ord å inkludere i søk.
• Funksjoner som kan konfigureres av administrator, og administratoren kan velge funksjoner som skal konfigureres av bruker.
• Tilpassbar brukergrensesnittstil, layout og innhold.
• Implementerte HTTP-tjenester som følger REST mønster, egnet for caching.
• Mer enn 50 forespørsel per sekund på en enkelt CPU-kjerne.
• Lavere nivå tjenestegrensesnitt for å bygge tilpassede applikasjoner.

Implementeringssteg

1 Installer tjenesten (kun for interne tjenestebrukere).

2 Bestem hvilke applikasjoner du planlegger å bruke (direkte søk, assosiasjonssøk) og hvilke funksjoner du trenger.

3 Gjør nødvendige endringer på nettstedet ditt.

4 Test og finjuster tjenesten.

Dokumentasjonen er organisert rundt disse stegene. Først, hvordan installere tjenesten, etterfulgt av en høy-nivå diskusjon om applikasjonene som er tilgjengelige. Hver applikasjon beskrives deretter i detalj, og til slutt er det en referansedel.

Installasjon

Denne seksjonen beskriver trinnene som er nødvendige for å få TemaSearch opp og kjøre for disse tilgangstypene.

TemaSearch er tilgjengelig enten som en hostet tjeneste eller som en intern tjeneste. Den hostede tjenesten administreres eksternt av en tredjepart. Den interne tjenesten installeres, distribueres og administreres av din organisasjon.

Hostet tjeneste

Ingen installasjon eller distribusjon kreves, da dette allerede er gjort for deg. For å få tilgang til tjenesten trenger du kontonavn og URL til TemaSearch-tjenesten. For noen tjenester trenger du også kontogruppe og kontopassord.

Intern tjeneste

Din organisasjon håndterer oppsett og drift av den interne tjenesten, og har full kontroll over hvordan tjenesten er konfigurert, distribuert og vedlikeholdt. Denne seksjonen beskriver hvordan du installerer og konfigurerer tjenesten, og hvordan du verifiserer at tjenesten kjører.

Maskinvare- og programvarekrav

TemaSearch er en webapplikasjon bygget med Servlet-teknologi. Den krever beskjedne ressurser, og for mange nettsteder kan den distribueres i en delt applikasjonsserver som kjører dine eksisterende webapplikasjoner.

En typisk serverkonfigurasjon er

• 1GHz CPU eller raskere
• 256MB RAM (eller nok for servlet-containeren pluss 100MB.)
• 30MB diskplass for den installerte appen.
• En servlet-container kompatibel med servlet spesifikasjon 2.3.

Med denne konfigurasjonen kan tjenesten behandle rundt 10 til 100 spørringer per sekund, avhengig av hvilke funksjoner som brukes. Maskinvarebehovet for nettstedet ditt kan variere med forventet belastning og nødvendig kapasitet. Nettsteder som trenger vedvarende kapasitet på mer enn 50qps, kan trenge en dedikert applikasjonsserver, eller en klynge av servere ved enda større belastning.

Tjenesten er helt selvforsynt og krever ikke ekstra eksterne ressurser eller databaser.

Distribusjon

Den interne tjenesten leveres som en komprimert webapplikasjon (WAR) fil. For at den skal fungere korrekt, må den distribueres til din servlet-container i en ukomprimert form. Hvordan dette gjøres varierer fra en servlet-container til en annen, selv om prosedyren vanligvis er noe som dette

1 Bruk unzip eller et lignende verktøy for å trekke filene ut av WAR-filen til en katalog på serveren

2 Konfigurer containeren til å laste webapplikasjonen i den katalogen.

Hver webapplikasjon krever en unik kontekstbane innen containeren. TemaSearch kan installeres til enhver gyldig kontekst. I URL-eksemplene som er gitt, antar vi at kontekstbanen er /ts.

Konfigurere tjenesten

Nå har tjenesten blitt distribuert til servlet-containeren, den må konfigureres før første bruk. Konfigurasjonen omfatter:

1 oppretter distribusjonskataloger

2 oppretter konfigurasjonsfiler

3 installerer lisensfilen

Opprette distribusjonskataloger

Alle distribusjonsfiler som er spesifik for din egen distribusjon av tjenesten, lagres under \WEB-INF\distribuer. Du må bruke denne katalogen etter første installasjon. Når applikasjonen oppgraderes eller installeres på nytt, vil filene i denne katalogen ikke bli overskrevet, slik at konfigurasjonsinnstillingene dine blir bevart.

Logginformasjon lagres under \WEB-INF\deploy\logs. Denne katalogen bør også opprettes.

Konfigurasjonsfiler

Opprett konfigurasjonsfilen \WEB-INF\deploy\deploy-conf.properties og legg til denne linjen

ps.install.url=<URL for installasjonskontekst>

For eksempel,

ps.install.url=http://www.myserver.com/apps/ts

for en HTTP-server under domenet www.myserver.com, der servletcontaineren er under apps stien og TemaSearch ble installert under ts. Merk at ingen avsluttende skråstrek er nødvendig.

Installer lisensfil

Som en del av den interne distribusjonen av tjenester, vil du ha mottatt en lisensfil kalt licence.bin. Denne filen bør kopieres til \WEB-INF\deploy\a. Det vil si at lisensfilen lagres i distribusjonskatalogen og omdøpes til filnavnet 'a'. Den uvanlige navngivningen er en sikkerhetsfunksjon for å beskytte lisenssystemet.

Distribusjonen inkluderer også en fil kalt suac.xml. Denne bør kopieres til \WEB-INF\deploy katalogen.

Autentisering

Den interne tjenesten er konfigurert med en enkelt konto som brukes for å autentisere tilgang til tjenesten. Kontodetaljene lagres i suac.xml filen. Brukeren, området og passordet som brukes for å autentisere kontoen (puser, prealm, ppwd parametere) skal settes til navnet på kontoen som vises i suac.xml filen.

Verifisering av installasjon

Etter at tjenesten er implementert og konfigurert, er du klar til å verifisere at tjenesten er operativ. Du kan sjekke om tjenesten kjører ved å gå til /version.xml under distribusjons-URL-en til applikasjonen (for eksempel http://www.myserver.com/apps/ts/version.xml), som viser versjonsnummeret for programvaren.

TemaSearch-applikasjoner

TemaSearch tilbyr to hovedapplikasjoner, direkte søk og assosiasjonssøk. Begge applikasjoner gir alternative ord for søkespørsmål, men har forskjellige måter å samhandle med brukeren på:

• Direkte søk er stort sett transparent – ord legges til søket uten å involvere brukeren, og krever ingen endringer i brukergrensesnittet. Valgfritt kan skjema kontroller legges til for å la brukeren konfigurere funksjoner for direkte søk.
• Assosiasjonssøk er brukerorientert – ord presenteres for brukeren å velge for inkludering i søket. Assosiasjonssøk har et rikt, tilpassbart brukergrensesnitt for å vise og velge alternative ord.

Begge applikasjoner kan konfigureres statisk av administratoren, og/eller konfigureres av nettstedbesøkeren ved hjelp av skjemaelementer lagt til det eksisterende søkeskjemaet.

Tekniske forskjeller

Bortsett fra den viktigste forskjellen mellom automatisk vs. manuell valg av ord, har søknadsapplikasjonene disse hovedtekniske forskjellene, som kan påvirke hvilken applikasjon du implementerer.

Om tjenesteparametere

Tjenesteparametere brukes for å gi konfigurasjonsdetaljer og søkespørringsdata til tjenesten. TemaSearch er implementert som en HTTP-tjeneste, og disse parameterne er enten formkodet, med enten en GET-metode spørring på URL-en, eller sendt som POST-data.

Parametere til tjenesten faller inn under to hovedkategorier: søkemotorparametere og TemaSearch-parametere.

Søkemotorparametere: Disse parameterne er til slutt ment for søkemotoren din og forbrukes ikke av tjenesten. De blir sendt inn i tjenesten, muligens modifisert, og deretter sendt ut igjen i søkeresultatene.

TemaSearch-parametere derimot, forbrukes av tjenesten og er ikke til stede i resultatene, og dermed ikke videreført til søkemotoren din.

For å informere tjenesten om hvilke parametere som er tjenesteparametere, brukes en parameterliste (px-parameteren.). Denne lister opp alle tjenesteparametere, og kun parametere i denne listen regnes som tjenesteparametere. Parametere som ikke er i listen, er som standard søkemotorparametere.

Dermed, når du legger til nye parametere i en forespørsel til tjenesten, vær sikker på at du husker å oppdatere parameterlisten! Hvis du glemmer å gjøre dette, vil ikke tjenesten gjenkjenne parameteren som en tjenesteparameter, og den vil dermed ikke bli brukt. Hvis parameteren er obligatorisk, vil dette gi en feil, mens standardparametere vil anta standardverdien sin, og ikke verdien som ble sendt inn.

Forespørselssyntaks

En kjernefunksjon ved tjenesten er innførsel av spørringshodene, der ord legges til eller byttes ut for å produsere en ny forespørsel. For at den nye forespørselen skal bli forstått av søkemotoren din, må eventuelle modifikasjoner selvfølgelig gjøres ved hjelp av syntaksen som forventes av søkemotoren din. TemaSearch støtter flere populære forespørselssyntakser, beskrevet i forespørselssyntaksreferansen . Hvis syntaksen som brukes av søkemotoren din ikke støttes, kontakt Nynodata for å diskutere mulige implementeringsvalg.

Boolsk søk

De standardapplikasjonene fungerer best når søkemotoren støtter boolsk søk. TemaSearch benytter ikke alle boolske funksjoner, men krever at søkemotoren har en syntaks for å indikere "ELLER": det vil si, for to ord A og B, skal motoren hente dokumenter som inneholder ord A eller ord B eller begge. Noen søkemotorer støtter denne typen forespørsel ved faktisk å skrive "ELLER" mellom ordene, eller ved å skrive ordene rett etter hverandre.

Når du har fastslått syntaksen som forventes av søkemotoren din, bør du sjekke at det er en som støttes av TemaSearch. De tilgjengelige forespørselssyntaksene er beskrevet i referansen seksjonen.

Ytelse

På vårt testsystem, en 2.4GHz Intel-boks som kjører Windows, fikk vi disse gjennomsnittlige forespørselstidene:

• Direkte søk: mindre enn 20ms per forespørsel (50 qps)
• Assosiasjonssøk: 50ms per forespørsel (20 qps)

Den direkte søkeapplikasjonen er omtrent 5 ganger raskere enn assosiasjonssøk. Dette skyldes i hovedsak XSLT-transformasjonene som brukes for å produsere brukeren av assosiasjonssøket. Om denne ytelsesforskjellen er betydelig eller ikke, avhenger av ønsket gjennomstrømning og hvordan tjenesten er vert.

Alle HTTP-grensesnitt til tjenesten er RESTful, og er dermed gode kandidater for caching. Caching kan forbedre ytelsen betydelig når vanlige søkespørringer ofte blir forespurt av besøkende.

Søk Innsendingsmetode

Direkte søk (integrasjon av webskjema) og assosiasjonssøk krever at søkeforslag kan sendes ved hjelp av GET-metoden. Selv om ditt nåværende søkeskjema bruker POST, kan GET-metoden fortsatt være støttet, da søkemotorer som bruker POST ofte også støtter GET. For å se om søkemotoren din støtter GET, endre skjemaets metode til GET, og prøv det. Hvis søket fungerer som vanlig, er GET støttet. Merk at endringen av skjemaets metode bare er for testing – du forventes ikke å endre skjemaets metode når du implementerer TemaSearch.

Direkte søk implementert via server-side skripting sender ikke inn nye søk til HTTP-grensesnittet, og er derfor fri for dette kravet.

Direkte søk

Direkte søk-applikasjonen legger til ekstra ord i en søkeforespørsel, og kan gjøre dette uten å involvere brukeren. Når den er konfigurert til å være helt automatisk, fungerer tjenesten helt transparent for brukeren – den eneste endringen brukeren bør være klar over er forbedrede søkeresultater.

Forutsetninger

Direkte søk kan kun implementeres med søkemotorer som støtter en syntaks for boolsk "ELLER". (Se Boolsk søk.) Hvis søkemotoren din ikke støtter syntaks for å uttrykke "ELLER", kan du ikke bruke direkte søk. I stedet kan du bruke assosiasjonssøk i ord-erstatningsmodus.

Integrasjonsoversikt

Direkte søk kan implementeres på to måter:

• Webskjema: HTML-koden for søkeskjemaet brukeren sender inn endres. Dette er en enkel integrasjonsmetode som krever enkle HTML-endringer.
• Server-side skripting: Server-side skriptet eller programmet som serverer siden produsert fra søkeskjemaet endres for å inkludere anrop til direkte søk. Dette krever mer programmering enn integrering av webskjema, selv om det tilbyr mer fleksibilitet og mulighet for å introdusere elegant degradering for best mulig pålitelighet. Server-skripting gir også mulighet for å gå til kombinasjonssøk.

Webskjema-integrasjon

Å legge til direkte søk til et eksisterende søkeskjema krever at det gjøres noen endringer i skjemaets HTML-kode. Før du begynner må du ha tilgang til å redigere den eksisterende HTML-siden der søkefeltet finnes. Hvis du ikke kan eller ikke ønsker å endre HTML-koden på nettstedet ditt, kan du fortsatt teste direkte søk ved å bruke en frittstående testside, som beskrevet her.

Webskjema-integrasjon krever at en søkeforespørsel kan sendes ved hjelp av GET-metoden (se Søk Innsendingsmetode). Hvis dette ikke er mulig, kan direkte søk implementeres ved hjelp av server-side skript.

Hvordan det fungerer

Handlings-URL-en for eksisterende søkeskjema endres for å peke til den direkte søketjenesten. Ytterligere INPUT-elementer legges til med konfigurasjonsverdier brukt av tjenesten. Når skjemaet sendes inn, omskriver tjenesten forespørselen ved å bruke skjulte eller bruker-valgbare konfigurasjonsverdier, og omdirigerer deretter nettleseren til den opprinnelige søkesiden for å kjøre søket med den omskrevne forespørselen.

Enkel oppsett

Koden nedenfor viser et enkelt søkeskjema

<FORM method=GET action="/search">
<INPUT type="text" name="q" size="30" value="">
<INPUT type="submit" name="submit" VALUE="Søk">
</FORM>

For å aktivere TemaSearch, legger du til en håndfull skjulte input-elementer i skjemaet. INPUT-elementene tilsvarer tjenesteparametere. For eksempel legger koden nedenfor til tjenesteparameteren "pq" med verdien "boolsk".

<INPUT type="hidden" name="pq" value="boolean">

Du må legge til minst disse parameterne som vist i tabellen under. (Du kan klikke på parameternavnet for å hoppe til delen som gir detaljer om den parameteren.)

Hvis vi antar at eksempel skjemaet er vert til http://www.myhost.com/search, at brukernavnet vårt er “jsmith”, og at “standard” spørringsyntaks brukes, så vil vi legge til disse parameterne:

Etter å ha lagt til disse parameterne som skjulte inndataelementer, ser eksempel skjemaet slik ut (nye eller endrede deler vises med fet skrift.)

<FORM method=GET action="search">
<INPUT type="hidden" name="puser" value="jsmith">
<INPUT type="hidden" name="pu" value="http://www.myhost.com/search">
<INPUT type="hidden" name="px" value="pu px pq pqsntx puser">
<INPUT type="hidden" name="pq" value="q">
<INPUT type="hidden" name="pqsntx" value="standard">
<INPUT type="text" name="q" size="30" value="">
<INPUT type="submit" name="submit" VALUE="Søk">
</FORM>

Merk:

• Rekkefølgen parameterne opptrer i skjemaet er ikke viktig; alt som kreves, er at de vises mellom <form> og </form>-taggene.
• Den pu verdien er den fullstendige URL-en til søkresultatsiden. Normalt vil action-attributten indikere URL-en til søkresultatene, selv om den kan trenge å være fullt kvalifisert ved å legge til “http://” og deretter din servers domenenavn, hvis ikke allerede til stede. I eksemplet var action-attributten /search, som vises fullt kvalifisert som http://www.myhost.com/search i pu inndatafeltet.
• Hvis skjemaet ditt allerede inneholder et inndataelement med samme navn som ett av de nye elementene, se avsnittet omdøpe konfliktfylte parametre.

Nå som parameterne er lagt til, er den siste steget å endre action-attributten til URL-en til TemaSearch-tjenesten. For eksempel, endre

<FORM method=GET action="search">

til

<FORM method=GET action=”http://www.temasearch.no/form”>

Når du har lagret siden til nettstedet ditt, vil direkte søk bli aktivert. Hvis søkresultatsiden viser den sendte spørringen, vil du se at det kan inkludere flere ord. Hvis du har andre søkefelt på nettstedet ditt, kan du aktivere direkte søk i dem ved å gjenta disse trinnene for de andre feltene. Hvis disse feltene bruker en annen mål URL for søkresultatene, må URL-en registreres med kontoen din. Se avsnittet om autentisering for detaljer.

Konfigurasjonsalternativer

TemaSearch tilbyr ulike konfigurasjonsalternativer som du kan bruke for å angi hvilke typer alternative ord som skal legges til i spørringen

Som standard er alle disse valgene aktive. Ikke alle kontoer inkluderer tilgang til de ulike konfigurasjonsalternativene. Sjekk kontodetaljene dine for å sikre at du har tilgang.

I det enkleste tilfellet er tjenesten konfigurert ved å gi faste verdier for tjenesteparameterne. Som vanlig er konfigurasjonsparameterne kodet som skjulte inndataelementer. For eksempel, for å ekskludere synonymer og bøyninger, psynn og pifl parameterne blir lagt til skjemaet, satt til verdien “0”:

<INPUT type="hidden" name="psynn" value="0">
<INPUT type="hidden" name="pinf" value="0">

Selv om det ikke er vist her, må du legge til “psynn pinf” i px parameteren som allerede er lagt til skjemaet. Dette er nødvendig for å sørge for at alle parameterne blir gjenkjent av TemaSearch.

Når du søker, vil du se at TemaSearch legger til oversettelser, men ikke synonymer eller alternative bøyninger.

Autentisering

TemaSearch-kontoen som ble brukt for å fullføre forespørselen bestemmes fra URL-en gitt i pu-parameteren. For øyeblikket kreves ingen andre parametere. En fremtidig versjon av tjenesten vil kreve forhåndsinformasjon og brukernavn parametere, så du kan legge til disse hvis ønskelig.

Vanlige spørsmål

Generelt

Sikkerhet

Feilsøking

Server-side Scripting

Den grunnleggende tilnærmingen til å integrere direkte søk server-side er å legge til et kall til den direkte søketjenesten før spørringen sendes til søkemotoren din. Tjenesten endrer spørringen med ekstra ord som deretter sendes videre til søkemotoren for å kjøre søket som vanlig. Søkingen kører dermed med nye ord foreslått av TemaSearch automatisk inkludert.

Integrasjonstrinnene er:

• Konstruer URL-en for tjenestekall. Direkte søkresultater tilgås via en URL som lokaliserer den direkte søketjenesten og gir konfigurasjonsparametere til tjenesten.
• Ekstraher den omskrevne spørringen fra innholdet hentet fra invokasjons-URL-en.
• Bruk den omskrevne spørringen til å kalle på søkemotoren din.

Konstruer URL-en for tjenestekall

For å hente den omskrevne spørringen, konstruer en URL for å utføre direkte søk. Den grunnleggende URL-en er

http://<temasearch-service-location>/ts/svc/rewrite?<configuration-params>&<search-params>

<configuration-params> er en liste over formkodede parametere for den direkte søketjenesten. Den <search-params> er søkeparameterne sendt av søkeskjemaet. Dette kan hete hva som helst – navnet du bruker gis til tjenesten via pq konfigurasjonsparameteren.

Hvis spørringsparameteren din kalles query, kan du bygge en URL som ser slik ut:

http://<temasearch-service-location>/ts/svc/rewrite?pq=query&pu=&pqsntx=standard&
pcharset=UTF-8&px=px+pq+pqsntx+pcharset+prealm+puser+ppwd+pu&
query=somequerytext

(Parameterne prealm, puser og ppwd er ikke inkludert for korthet. Verdiene for disse parameterne vises med kontoinformasjonen din.) Vær oppmerksom på at også parameteren 'pu' bør spesifiseres for å unngå en feil, selv om verdien ikke er brukt.

Merk at URL-ene vises med GET-stil formparametre for enkelhets skyld. Hvis du foretrekker, kan du bruke POST-metoden for å påkalle tjenesten. POST bør brukes hvis hele URL-en sannsynligvis vil overstige 2K i lengde.

Hent data fra resultatet

Innholdet i kroppen som returneres av URL-en inneholder resultatet, som er en liste over parametre og verdier, én parameter og verdi per linje. For eksempel:

queryParamName: ord eller alternativ1 eller alternativ2 ….
otherParam: verdi

I det enkleste tilfellet inkluderer resultatet kun én linje med den omskrevne søkeparameteren for søkemotoren din. Men hvis du sender inn andre søkemotorparametre (parametre som ikke er oppført i px-parameteren), vil de også inkluderes i resultatet. Til slutt, hvis du har aktivert historikkparameteren, vil denne bli lagt til som den siste parameteren i listen.

Parameterne vises i samme rekkefølge som de var i URL-en som ble brukt for å påkalle tjenesten.

Påkall søkemotoren

Dette går stort sett som uten direkte søk. Den eneste forskjellen er at søkemotoren påkalles ved hjelp av den nye spørringen hentet fra de direkte søkeresultatene, i stedet for spørringen sendt inn av søkeskjemaet.

Hvilken spørring skal vises til brukeren?

Hvis resultatsiden din inkluderer et søkeskjema for å sende inn et søk på nytt, er det vanlig praksis å vise spørringen brukeren skrev inn som standardverdi for søketeksten. Men etter å ha integrert direkte søk, vil spørringen som vises til brukeren være den reviderte versjonen produsert av direkte søk.

Hvis dette ikke er hva du ønsker, kan det være mulig å vise den opprinnelige spørringen når du genererer resultatsiden. Hvis du har tilgang til skriptet som produserer skjemaet i resultatsiden, kan du deretter endre verdien av søketekstboksen fra den omskrevne spørringen (den som ble sendt til søkemotoren) til den opprinnelige spørringen sendt inn av brukeren.

Autentisering

TemaSearch-kontoen som brukes til å autorisere forespørselen bestemmes av autentiseringsparametrene: prealm, puser og ppwd. Disse parametrene må inkluderes sammen med forespørselen.

Sluttbrukerkonfigurasjon

Integreringstrinnene som så langt er beskrevet setter opp direkte søk med en statisk konfigurasjon – konfigurasjonen var hardkodet inn i skjemaet eller URL-en som ble brukt til å påkalle tjenesten.

Synlige skjemaelementer kan brukes til å la nettstedbesøkende kontrollere hvordan direkte søk fungerer. Praktiske eksempler inkluderer:

• La brukeren velge typene ord som direkte søk vil legge til i spørringen, eller til og med om direkte søk er aktivert eller ikke.
• La brukeren indikere ønsket spørrespråk eller ønskede mål-språk.

Med Webform Integrasjon

Brukerkonfigurasjonen under webformintegrasjon gjøres ved å legge til nye INPUT-elementer i skjemaet for å gi synlige kontroller som avkrysningsbokser og listebokser for brukeren. Navnene på disse nye inndatakonseptene settes til den tilsvarende direkte søkeparameteren de kontrollerer.

For eksempel, for å la brukeren aktivere eller deaktivere bruk av oversettelser, legger du til

<INPUT type="checkbox" name="povs" value="1" CHECKED>

(Uten å glemme selvsagt å sørge for at povs er oppført i px parameterverdien, definert andre steder i skjemaet.) Når det vises i en nettleser, inkluderer skjemaet en avkrysningsboks som kontrollerer om oversettelser legges til spørringen. CHECKED-attributtet sjekker boksen som standard, så oversettelser ville være aktive inntil brukeren spesifikt slår dem av ved å fjerne hukingen fra avkrysningsboksen. De andre på/av-type parameterne, som psynn, pifl og penab kan også kontrolleres på denne måten.

Andre parametere, som plangin, plangout, pmax1, pmax2 kan kontrolleres ved hjelp av radioknapper eller en VALG-boks.

Når brukeren sender inn skjemaet, sendes disse parameterne til tjenesten akkurat som om de var skjulte parametre statisk konfigurert av administratoren.

Konfigurasjonsendringene gjort av brukeren blir ikke opprettholdt fra et søk til det neste. Ved hvert søk blir konfigurasjonen tilbakestilt til standardverdiene spesifisert i skjemaet. For å få endringene husket fra et søk til det neste, kan du bruke server-side skriptintegrasjon.

Med server-side skript

Å legge til brukerkonfigurerbare funksjoner for direkte søk via server-side skripting er mer omfattende enn å redigere det grunnleggende nettskjemaet, men gir mer fleksibilitet. Her er en oversikt over prosessen:

1 Legg til nye INPUT-elementer til søkeskjemaet for hvert element brukeren kan konfigurere.

2 I server-side skriptet ditt som håndterer skjemaet, sørg for at disse parameterne er inkludert i URL-en du konstruerer for å påkalle direkte søk.

3 Hvis du ønsker å vise innstillingene igjen på resultatsiden, skriver du ut et nytt sett med INPUT-elementer på resultatsiden, med standardverdier hentet fra det innsendte søkeskjemaet. Typisk blir søkespørsmålet husket fra et søk til det neste, og å huske brukerinnstillingene vil følge samme mønster.

Foreningsøk

Oversikt

Assosiasjonssøkapplikasjonen henter ord relatert til søkespørsmålet, og presenterer disse for brukeren, slik at de kan velge hvilke ekstra ord som skal inkluderes i søket.

Assosiasjonssøk implementeres slik:

1 Etter at brukeren har sendt inn et søkespørsmål, foreslår assosiasjonssøket ekstra ord, som presenteres sammen med søkeresultatene.

2 Hvis brukeren mener at søket ikke fant det de lette etter, kan de klikke på ett av ordene foreslått av assosiasjonssøket for å legge det til spørsmålet.

3 Ordet legges til spørsmålet, og nye søkeresultater som inkluderer det nye ordet vises.

Utvalg av et ord eller en gruppe ord krever et enkelt klikk, og med hvert klikk genereres et nytt sett med søkeresultater. De foreslåtte ordene kan legges til ett og ett, eller i grupper. For mer presis kontroll brukes en to-trinns tilnærming der alle ønskede ord først velges, og deretter klikkes på en sendeknapp for å sende det nye spørsmålet til søkemotoren.

De foreslåtte ordene kan vises med tilleggsinformasjon, som språk, type alternativ (synonym, staving variasjon, oversettelse osv…) Videre kan denne informasjonen brukes til å gruppere og sortere ordene i henhold til konfigurerte kriterier.

Til slutt, for å finjustere brukergrensesnittet for assosiasjonssøk for å matche stilen til nettstedet ditt, er det tilgjengelig en rekke tilpasninger, fra å velge fra en rekke ferdiglagde stiler, til komplett kontroll over brukergrensesnittet via tilpassede XSL-transformasjoner.

Assosiasjonssøk krever at et søkespørsmål kan sendes ved hjelp av GET-metoden (se Søk Innsendingsmetode). Hvis dette ikke er mulig, kan du ikke implementere assosiasjonssøk. Vurder i stedet å implementere direkte søk ved hjelp av server-side skripter.

Integrasjonsoversikt

For å integrere Assosiasjonssøk, gjør du endringer i server-side skriptet (eller programmet) som håndterer søkeskjemaet og produserer resultatsiden brukeren ser etter å ha sendt inn et søkespørsmål. Her er en oversikt over endringene som kreves:

• Legg til en LINK-tag i HEAD-en av HTML for å lenke til en CSS-fil for brukergrensesnittet til assosiasjonssøk. (Valgfritt, men anbefalt.)
• Legg til en dynamisk server-side inkludering som inkluderer assosiasjonssøk forslagene i resultatsiden. URL-en for inkluderingen konstrueres dynamisk fra de innsendte søkeskjemaparametrene.

Disse trinnene er beskrevet mer detaljert nedenfor. Hvis du ønsker å få en rask start, legg til følgende elementer på resultatsiden for søket, erstatte server.com med servernavnet der temasearch er installert:

I hodet på resultatsiden for søket, legg til

<LINK href="http://server.com/ts/css/base.css”>
<LINK href="http://server.com/ts/css/color.css”>
<LINK href="http://server.com/ts/css/links1.css”>
<LINK href="http://server.com/ts/css/css3.css”>

Legg til kode i dokumentkroppen som implementerer denne pseudokoden

service = “http://server.com/ts/svc/querypresfrag.html?”
tsparams = <configuration parameters for service>
searchparams = <params and values passed from the search form>
url = service + tsparams + searchparams
include-content-from(url)

Du kan også endre denne URL-malen og

TODO: eksempel på URL for assosiasjonssøk

Pseudokoden ovenfor lager en URL ved å kombinere en fast konfigurasjon med informasjon som blir tilgjengelig under kjøring (for eksempel søkespørringen). Deretter hentes innholdet fra denne URL-en og settes inn på søkeresultatsiden.

Disse parameterne er bare ment å hjelpe deg i gang. Noen av dem må kanskje endres for å fungere med søkemotoren din. (Se tipsene nedenfor.) Du bør i det minste kunne se boksen for assosiasjonssøk på resultatsiden.

Tips og råd

• Parameterne du sannsynligvis må endre for å få assosiasjonssøket til å fungere riktig, er pq, pqsyntx og pcharset.
• Hvis søkemotoren ikke støtter boolske søk, setter du parameteren pqbld til «r», som aktiverer word-replace modus.
• Når tjenesten er i drift, kan du finjustere den med flere parametere. Parameterne ovenfor har generelle standardverdier som du kan tilpasse til dine behov. Alle parameterne er oppført i referansedelen.
• Det kan være nyttig å legge det inkluderte innholdet i et containerelement (for eksempel DIV eller TABLE), slik at det blir enklere å plassere og formatere det.

Når den grunnleggende tjenesten fungerer, kan du lese avsnittene nedenfor for mer detaljert informasjon om integrasjonen.

Koble til CSS-filer

HTML-koden fra assosiasjonssøket inneholder lite formatering for farger, oppsett og andre visuelle detaljer. Du kan legge inn lenker til én eller flere CSS-filer på resultatsiden for å tilpasse de foreslåtte ordene til nettstedets utforming. Bruk en av CSS-filene som følger med tjenesten, eller lag dine egne. Tabellen nedenfor beskriver de ferdige CSS-filene. Alle ligger i /css-mappen under URL-en til TemaSearch-tjenesten.

Når du bruker de ferdige CSS-filene, inkluderer du vanligvis base.css først, deretter color.css og link1.css, og til slutt én av cssX.css-filene.

Plassering av foreslåtte ord

De foreslåtte ordene produsert av assosiasjonssøk legges til på søkeside via en server-side inkludering. Du kan ønske å plassere inkluderingen slik at ordsuggestjonene vises på et sted som passer med eksisterende innhold på resultatsiden og med typiske bruker søkemønstre. Her er noen foreslåtte plasseringer:

• Over eller ved siden av søkeresultatene: Dette er nyttig når brukerne raskt skanner de første resultatene og avgjør om de har funnet det de ønsket. Hvis ikke, er alternativordene innenfor samme synsfelt.
• Under søkeresultatene: Dette er nyttig når brukerne ofte leser gjennom hele resultatene, som kan være tilfelle på en stor side med mangfoldig informasjon.
• Under søkeboksen for gjentatt søk: Ved å være nær søkefeltet, blir brukerne minnet om at de kan klikke på foreslåtte ord i stedet for å måtte skrive inn nye ord manuelt.

Når du har bestemt hvor assosiasjonssøkeordene skal vises, finner du det tilsvarende stedet i skriptet som produserer HTML for siden. Du skripter så server-side inkluderingen på det punktet, slik at assosiasjonssøkeresultatene tekstuelt inkluderes på rett sted.

Nå som du har bestemt hvor på siden det inkluderede innholdet vil være, må du konstruere URL-en for innholdet som skal inkluderes. URL-en som brukes for å hente det inkluderede innholdet består av URL-en for assosiasjonssøketjenesten og flere parametere.

http://<temasearch-server-domain>/<service-path>?<search-engine-params>&<temasearch-params>

• Parametere for din søkemotor. Søkemotorparametere inkluderer søkefrasesparameter, og kan også inkludere andre konfigurasjonsparametere som forventes av søkemotoren din og sendes inn fra søkeskjemaet. Disse parameterne bør videreformidles til assosiasjonssøk slik at de kan inkluderes når en ny søk startes. (URL-ene som utløser et nytt søk, vil da inkludere de originale søkeparameterne, som holder etterfølgende søk konsistente.)
• Assosiasjonssøkparametere: disse gir detaljer som er nødvendige for assosiasjonssøk tjenesten og konfigurasjonsverdier for å tilpasse resultatene. Disse parameterne er alle oppført innen proxy parameterlisten (px) for å angi at disse er tjenesteparametre og ikke vanlige søkemotorparametre. Disse parameterne konsumeres av tjenesten og ikke deretter sendes tilbake til søkemotoren din når brukeren velger ytterligere ord.

I pseudo-kode kan du konstruere inkludere URL-en slik:

searchEngineParams = …; // ekstraher parametrer fra den nåværende URL-en, f.eks. fra etter ‘?’ fra den nåværende URL-en som serveres
temaSearchParams = “px=px pu pq&pq=<queryParamName>&pu=<search-submit-uri>”
temaSearchLocation = “http://temasearch-server.com/ts/svc/querytemafrag.html”
temaSearchURL = encodeURL(temaSearchLocation+”?”+searchEngineParams+”&”+temasearchParams);

Når URL-en er bygget, skripter du deretter inkluderingen av innholdet som returneres fra denne URL-en.

pu-parameteren settes til URL-en til søkespørringsbehandleren (dvs. den nåværende siden), ettersom dette er mål-URL-en for nye forespørsel til søkemotoren. Den brukes også av assosiasjonssøk for å autentisere forespørslene til tjenesten.

Henting av den opprinnelige spørsmålet.

Som standard, når assosiasjonssøk legger til ord i spørringen, er spørringen som vises for brukeren den fulle spørringen som inneholder alle ordalternativene som er lagt til.

Hvis du ønsker å vise den originale spørringen, kan du hente den originale spørringen fra parameteren history (ptshist). Denne parameteren sendes til søkemotoren din av assosiasjonssøk. Parameteren har følgende format:

Versjon “:” SekvensNum “/” nøkkelordliste “/” original spørring “/” spørringsspråk “/”

Uttrekking av den originale spørringen skjer ved å hente ut substrengen mellom den andre og tredje skråstreken.

Den fulle formatet av history-parameteren er gitt i referansedelen.

Ord Erstatningsmodus

Assosiasjonssøk fungerer best når søkemotoren støtter Boolean-søk. (Se XXX.) Imidlertid kan assosiasjonssøk også brukes med motorer som ikke støtter Boolean-søk. I stedet for å legge til ord i spørringen (som krever Boolean OR-funksjonen) kan assosiasjonssøk konfigureres til å erstatte det originale ordet i spørringen med det foreslåtte ordet valgt av brukeren. Hovedfordelen er at erstatning ikke krever noe ekstra syntaks eller betydelig endring til spørringen, noe som gjør det egnet for alle søkemotorer, spesielt de uten Boolean-søk, og motorer som søker etter ett ord om gangen.

For å aktivere denne funksjonen, sett parameteren pqbld til “r”.

Spørringsvalgs typer

Assosiasjonssøk tilbyr to brukergrensesnittstyper for å velge ord som skal legges til i spørringen, umiddelbar valg og forsinket valg.

Umiddelbar valg, også kalt en-trinns valg: ord og spørringer er representert som hyperlenker. Med denne representasjonen velges et ord og legges til i søket umiddelbart når lenken klikkes.

Forsinket valg, også kalt to-trinns valg: ord er valgbare elementer (f.eks. avmerkingsbokser, radioknapper, eller enkelt/multi-valg listeelementer) hvor valg av et ord ikke automatisk sender inn søket. Brukeren må bruke en knapp eller annen kontroll for å starte et søk med de valgte ordene.

Valgtypen i spørringen oppgis av parameteren psm. Se parameterreferansen for flere detaljer.

Sluttbrukerkonfigurasjon

Ved å bruke integrasjonstrinnene beskrevet ovenfor, er konfigurasjonen av assosiasjonssøk statisk koblet inn i forespørselen som brukes til å påkalle tjenesten. Det er naturligvis mulig at konfigurasjonsparameterne produseres dynamisk, for eksempel fra søkeskjemaet.

Å tilby elementer brukeren kan konfigurere gjøres ved å legge til flere INPUT-elementer til søkeskjemaet. Parameterne sendes inn av disse INPUT-elementene er inkludert i tjenestelenken på samme måte som søkespørringsparameteren, og andre søkemotorparameter.

• Legg til nye INPUT-elementer i søkeskjemaet for hvert element brukeren kan konfigurere.
• I skriptet på serversiden som håndterer skjemaet, sørg for at disse parameterne inkluderes i den URL-en du konstruerer for å påkalle assosiasjonssøk. I tillegg, legg til parameteren pp med en verdi som lister opp alle TemaSearch-parameterne som skal utgis. Tjenestekonfigurasjonsparameterne vil bli inkludert i URL-er til søkemotoren, noe som sikrer at nye søk som startes av assosiasjonssøk er konsistente med det opprinnelige søket ved å bruke de samme konfigurasjonsparameterne.
• Hvis du ønsker å vise de brukervalgte innstillingene på nytt på resultatsiden, skriv ut et nytt sett med INPUT-elementer på resultatsiden, med standardverdier hentet fra parameterne sendt til skriptet. Vanligvis blir søkespørringen bevart fra et søk til det neste, og bevaring av brukerinnstillingene vil følge det samme mønsteret.

Avanserte integrasjonsstrategier

Alternative Tjenester

I de tjenestesti som er gitt så langt, har querytemafrag.html blitt brukt for å produsere et HTML-fragment som kan inkluderes direkte i søkeresultatsidene dine. For å bygge tilpassede applikasjoner, gir assosiasjonssøk et antall andre tjenestepunkter, valgt ved hjelp av en sti.

XML-tjenestepunktene autentiserer ved hjelp av parameterne: prealm, puser og ppwd. HTML-tjenestepunktene bruker URL-en til målsøkemotoren som autentisering.

querytemapres0.xml

Returnerer ubehandlet XML-data fra assosiasjonssøktjenesten. Ingen XSLT-transformasjoner er påført, så dette er tjenestepunktet med best ytelse.

querytemapres.xml

Bruker data fra querytemapres0.xml og legger til flere nivåer av transformasjoner. Nivået som brukes, velges av plevel-parameteren. Utdataene er alltid gyldig XML, uansett hvilken transformasjon som brukes. Hvis nivåene 5 og over benyttes, returneres et HTML-grensesnitt som XHTML. Disse er funksjonene til de forskjellige nivåene.

• Nivå 0: ingen transformasjon – produserer assosiasjonssøk XML uten et namespace.
• Nivå 1: Legger til namespace-erklæringer til de rå dataene.
• Nivå 2: Flytter qalt-noder til samme nivå som tilsvarende alt-node. Dette plasserer ordalternativene og den tilsvarende søkespørsmålet på samme nivå.
• Nivå 3: Konverterer alternative orddata til en abstrakt brukergrensesnittsbeskrivelse. Beskrivelsen inkluderer meldinger betegnet med meldings-ID.
• Nivå 4: Løser meldings-ID-er ved å se opp den tilknyttede meldingen for gjeldende forespørsel-lokalisering.
• Nivå 5: Genererer en XHTML-side fra den abstrakte brukergrensesnittsbeskrivelsen.
• Nivå 6: Rydder opp XHTML-utdataene ved å fjerne eventuelle unødvendige namespaces, som kan forvirre noen nettlesere.
• Nivå -1: Påfør alle transformasjoner. Dette er for fremtidig kompatibilitet dersom ekstra transformasjoner blir lagt til.

Dette tjenestegrensesnittet kan brukes til å lage tilpassede applikasjoner, slik som å tilpasse standard brukergrensesnittet. Stegene for å lage et tilpasset grensesnitt er:

• Hent XML på det nivået som best passer dine behov. Mindre endringer kan bruke utdata fra nivåene 5/6. Mer substansielle endringer vil starte med XML fra lavere nivåer.
• Transformere XML-en, for eksempel ved å bruke XSLT. Resultatene vil være i hvilket som helst format du bruker for å beskrive brukergrensesnittet. Dette er vanligvis XHTML, selv om du kan bruke et hvilket som helst format, f.eks. WML, VML, SVG osv.
• Inkluder det transformerende innholdet der det er nødvendig (f.eks. søkeresultatsiden).

Hvis dataene blir konsumert av andre programmer, for eksempel når du bygger TemaSearch inn i indeksereren til en søkemotor, er nivåene 0-3 typisk mest nyttige.

querytemapres.html

Produserer hele HTML-brukergrensesnittet for assosiasjonssøk. Dette er en HTML-serialisering av den fullstendige XML-en (nivå -1) produsert av querytemapres.xml. HTML-en produseres som en selvstendig side, og er egnet for inkludering via innebygd IFRAME eller lignende.

querytemafrag.html

Produserer assosiasjonssøk brukergrensesnitt som et HTML-fragment for direkte inkludering i nettsider. I utgangspunktet en HTML-serialisering av ‘Nivå - 1’ XML produsert av ‘querytemapres.xml’, med HTML-dokumentstruktur-elementene fjernet.

Skalerbarhet og Pålitelighet

Når tilgjengelighet og ytelse er kritisk, kan det være lurt å vurdere disse strategiene som en utvidelse til den grunnleggende server-side inkluderingen.

• Feilhåndtering: fangst/fang opp eventuelle feil fra server-side inkluderingen slik at søkingen ikke blir avbrutt dersom tjenesten er utilgjengelig eller mislykkes av en eller annen grunn.
• Timeouts: legge til en timeout på URL-inkluderingen slik at søkeresultatene ikke blir forsinket dersom tjenesten er tungt belastet.
• Lastbalansering: hvis et visst antall feil eller timeouts oppstår, stopp midlertidig sendingen av forespørselene til tjenesten. Kjør sjekker på en bakgrunnstråd og aktiver tjenesten når den blir tilgjengelig/mere responsiv.

Tilpasning av Brukergrensesnittet

Brukergrensesnittet er konstruert med HTML+CSS, produsert via en serie XSL-transformasjoner. Dette gir mulighet for at brukergrensesnittet kan endres på følgende måter:

• Gjør mindre endringer til den eksisterende fargepaletten og layouten: bruk en overstyrings-CSS-fil for å overstyre selektorer for spesifikke funksjoner og stiler i standard CSS-filene.
• Mer radikale farge- og layoutendringer: opprett en ny tilpasset CSS-fil.
• tilpass grensesnitttekstmeldinger ved å lage nye tekstfiler.
• Omdefiner strukturen og driften av brukergrensesnittet: ved å bruke tilpasset XSLT for å produsere markup for grensesnittet fra en mellomliggende representasjon.
• Definer hele brukergrensesnittet ved å bruke XSLT for å transformere rådataene fra assosiasjonssøktjenesten.

Ved å jobbe med CSS kan du endre mange presentasjonsdetaljer, men strukturen til UI forblir stort sett den samme. Ved å bruke XSLT kan UI fullstendig omstruktureres og redesignes, eller målrettes mot et annet presentasjonsformat, som WML for mobile enheter, SWF for svært interaktive brukergrensesnitt eller DHTML+javascript for et rikere HTML-grensesnitt.

Hvordan vise ingen melding når det ikke finnes resultater for det gitte ordet

Som standard, når det ikke foreligger foreslåtte ord for en forespørsel, inkluderer resultater for assosiasjonssøk en melding som “Ingen alternativer for <query>.”

Du kan foretrekke ikke å vise noen melding dersom ingen forslag er tilgjengelige. Dette gjøres ved å definere stilen

.tsresultsnone { display:none; }

Med denne stilen definert, vil det ikke bli vist noen melding når det ikke finnes resultater.

Se CSS-stiler for flere detaljer.

Tilpassing av Grensesnittmeldinger

[Intern Tjeneste Bare]

Meldingene for brukergrensesnittet kan utvides på følgende måter:

• Oversettelser for nye språk kan legges til. For eksempel, hvis nettstedet ditt er flerspråklig, kan du ønske å gjøre assosiasjonssøk grensesnittet tilgjengelig på alle språkene som støttes av nettstedet ditt.
• Endre eksisterende meldinger.

Nye filer som inneholder tilpassede tekstmeldinger plasseres i /WEB-INF/deploy/i18n. (Denne katalogen må kanskje opprettes.) De nye ressursene navngis temasearch_<locale>.properties.

De eksisterende meldingene finnes i \WEB-INF\lib\parasearch-core-impl-<versjon>.jar-filen, navngitt messages_<locale>.properties. Disse bør brukes som en mal for å opprette nye språk eller tilpasse eksisterende meldinger.

Legg til støtte for et nytt språk ved

4 kopiere en eksisterende meldingsfil inn i meldingsressurskatalogen, omdøpe den til temasearch_<newlocale>.properties.

5 I den nye filen, oversett alle meldingsstrenger til det nye språket.

For eksempel, ved å oversette den engelske teksten til tysk, ville du

6 kopiere messages_en.properties fra innsiden av parasearch-core-impl.jar til /WEB-INF/deploy/i18n/temasearch_de.properties.

7 oversette all teksten i temasearch_de.properties, og passe på å holde alle meldingsnavn intakte (meldingsnavnet er alt før det første '=' på hver linje).

Du kan tilpasse en eksisterende melding ved

8 For det lokalet du vil tilpasse meldingen i, opprett /WEB-INF/deploy/i18n/temasearch_<locale>.properties fil hvis den ikke allerede eksisterer.

9 Finn meldingsnavnet i de eksisterende ressursene og kopier dette til den tilsvarende temasearch_<locale>.properties filen du befant deg i forrige trinn. Legg til et '=' etter meldingsnavnet etterfulgt av din nye tekst for meldingen.

10 Hvis du ønsker å tilpasse meldingen for flere lokaler, gjenta for hvert lokale.

Testing og Feilsøking

I de fleste tilfeller er det vanligvis umiddelbart åpenbart hvis tjenesten ikke er satt opp korrekt, da den bare ikke fungerer eller du får en feilmelding. Det er imidlertid noen problemer som lett kan gå ubemerket. De følgende seksjonene beskriver hva disse problemene er og hvordan du kan identifisere og fikse dem.

Tegnkoding

En feil i tegnekodingen kan føre til at noen tegn vises feil. Utfør disse testene for å sjekke at tegnekoding er korrekt satt:

• Skriv inn spørringer som inneholder tegn som ikke er en del av det normale ASCII-tegnsettet, f.eks. aksenttegn, skandinaviske vokaler osv. Bekreft at disse blir gjenkjent korrekt av søkemotoren og at påfølgende søk fra foreningens søk også fungerer som de skal.
• Skriv inn et ord som kun inneholder ASCII-tegn og gir resultater med ikke-ASCII-tegn. Igjen, bekreft at disse blir gjenkjent korrekt av søkemotoren og at påfølgende søk fra foreningens søk også fungerer korrekt.
• Se pcharset for detaljer om riktig innstilling for tegnekoding.

Historikkparameteren

Når det genereres URL-er for nye søk, legger tjenesten til en historikkparameter for å opprettholde tilstand mellom forespørslene, som den opprinnelige spørringen og inndata språk. Denne parameteren sendes til skriptet for søkeresultatsiden, og bør inkluderes i invokasjons-URL-en for tjenesten for foreningens søk. Selvfølgelig, hvis du har sørget for at alle forespørselparametere sendes til tjenesten, så vil dette skje automatisk. I andre situasjoner bør du sende parameteren eksplisitt.

Som historikkparameteren behandles som en tjenesteparameter, bør den legges til listen over tjenesteparametere (px-parameteren) som vanlig.

For å sjekke at historikkparameteren blir sendt gjennom søkelisterene dine, skriv inn en spørring for å generere noen foreslåtte ord. Inspiser URL-ene knyttet til de foreslåtte ordene: de vil inkludere en ptshist-parameter, med en verdi som starter med 1,1. Det første tallet er en versjonsidentifikator, og kan ignoreres for nå. Det andre tallet er invokasjonsantallet. Ettersom flere foreslåtte ord legges til en spørring, bør du se at senere URL-er inkluderer et stadig økende invokasjonsantall.

Hvis dette ikke skjer, sjekk at

• Invokasjons-URL-en som du konstruerer, inkluderer ptshist-parameteren. Denne parameteren vil bli sendt inn til søkemotoren når tjenesten utfører et nytt søk, som når brukeren klikker på ordene som foreslås av tjenesten.
• Parameteren ptshiston er ikke satt til 0. Å gjøre det vil deaktivere bruken av historikkparameteren.

Hvis søkehistorikkparameteren ikke sendes gjennom, som brukeren velger ord fra listen over forslag, kan den neste listen med forslag faktisk vokse, da den nå inkluderer forslag for ordene som nylig ble lagt til søket. I verste fall, når du bruker språkautomatisering (standard, se plangin) kan det oppdagede språket endres. Dette vil ofte resultere i et helt nytt sett med alternativord som produseres, og den resulterende inkonsekvensen kan være forvirrende for brukeren.

Kombinasjonssøk

Oversikt

Kombinasjonssøk bruker både direkte søk og foreningens søk sammen for den samme søkesiden. For eksempel, du kan konfigurere direkte søk til automatisk å legge til ord til spørringen som har samme mening, som nære synonymer, stavevariasjoner og bøyningsvariasjoner, mens du bruker foreningens søk for å la brukeren velge fra ord som kan være mer fjernt relaterte, som generelle synonymer og oversettelser.

Implementering

Kombinasjonssøk er implementert ved å bruke direkte søk og foreningens søk til de samme søkeresultater. Det er implementert som endringer til server-scripts for søkeresultatsiden. (Webform-stil integrasjonen for direkte søk bør ikke brukes når kombinasjonssøk implementeres.)

Det meste av implementeringsdetaljene for kombinasjonssøk er nøyaktig de samme som for implementering av direkte søk og assosiasjonssøk. Hovedforskjellen er at noen håndtering av historikkparameteren er nødvendig; historikkparameteren sendes fra direkte søk til assosiasjonssøk.

Når du håndterer et originalt spørsmål fra brukeren, kall direktesøk på spørsmålet for å omskrive spørsmålet før du bruker det til å kjøre et søk. Du kan bestemme når et spørsmål har kommet fra brukeren når det ikke er noen ptshist-parameter sendt til siden. (Re-spørsmål fra brukeren som klikker på tilleggord, inkluderer alltid en ptshist-parameter.) Direktesøk kalles på et originalt spørsmål slik.

1 Bestem hva slags typer ord du ønsker å legge automatisk til spørsmålet, og bruk dette til å konfigurere direktesøk. Konfigurasjonen vil indikere hvilke typer ord som skal inkluderes, inn/ut-språk osv. Du må inkludere endringer i standardkonfigurasjonen, ettersom standarden inkluderer alle ordtyper, og dermed vil legge til alle ord automatisk, uten å la noen være tilgjengelige for brukeren å velge fra, noe som motarbeider hensikten med kombinasjonssøk.

2 Basert på din bestemte konfigurasjon, bygg en URL for å kalle direktesøk. Dette gjøres nøyaktig som ved vanlig direktesøk, men du inkluderer også ptshiston-parameteren, satt til verdien "1". Dette instruerer direktesøk til å generere en ptshist-parameter, som er nødvendig ved senere kall til assosiasjonssøk.

3 Hent den nye spørringen fra resultatet og bruk dette til å kalle søkemotoren din og produsere søkeside med resultater. Hent også ptshist-parameteren fra resultatet og lagre for bruk når du kaller assosiasjonssøk senere.

På et tidspunkt når du produserer resultatsiden, kall assosiasjonssøk (følg mye det samme mønsteret som ved vanlig assosiasjonssøk):

1 Bestem konfigurasjonen for assosiasjonssøk. Dette vil typisk inkludere mindre restriktive innstillinger sammenlignet med dem som brukes av direktesøk, som mer typer alternativer aktivert, eller flere ord tillatt.

2 Bygg en URL for å kalle assosiasjonssøk. Sørg for å inkludere historikkparameteren ptshist. Hvis direktesøk ble kalt, kan verdien av ptshist-parameteren tas fra direktesøksresultatene. Ellers vil parameteren ha blitt sendt til scriptet som en sideparameter og verdien kan tas derfra.

3 Hent innholdet fra assosiasjonssøk-URL-en og inkluder innholdet på siden.

Fordi kombinasjonssøk i hovedsak er et ekteskap mellom direkte og assosiasjonssøk, er alle konfigurasjonsdetaljer tilgjengelig for direkte og assosiasjonssøk (f.eks. sluttbrukerkonfigurasjon, tilpasning av brukergrensesnitt) også tilgjengelig ved implementering av kombinasjonssøk.

Tilpassede applikasjoner

Både direktesøk og assosiasjonssøk-applikasjoner gir et lavere nivå tjenestegrensesnitt som kan brukes til å integrere TemaSearch i dine egne applikasjoner. Hvilken tjeneste du velger styres av hvor mye detaljer du trenger.

• Direktesøk gir en søkespørsmål som inneholder alternativene, eller enkel liste over ordalternativer for et gitt ord.
• Assosiasjonssøk gir varierende nivåer av kategorisering av alternativene, og har fasiliteter for å støtte konstruksjon av et brukergrensesnitt.

Noen eksempler:

• Å legge ordalternativer til søkeindeksen (grunnleggende): tjenesten for direktesøk brukes til å hente alternativer for ordene i indeksen. Disse legges til indeksen som aliaser til det originale ordet.
• Å legge ordalternativer til søkeindeksen (avansert): Ved å bruke tjenesten for assosiasjonssøk, kan alternative ord legges til indeksen som ovenfor, og det inkluderes informasjon som beskriver typen alternativ. Dette kan tillate per-språk eller ellers mer finjustert valg av ordalternativer fra indeksen.
• Database Søk: en SQL-spørringsprosessor som endrer SQL-spørringen (f.eks. WHERE-klausulen) for å inkludere flere ord.

Referanse

Konfigurasjon av Ord Alternativer

TemaSearch tilbyr disse typene ordalternativer for både assosiasjon og direkte søk:

Ytterligere kontroll over alternativene er tilgjengelig med disse parametrene:

Tjenesteparametere

Spørringsparametere

Språkparametere

Søkeparametere for foreninger

Brukergrensesnittparametere

Støttede spørringssyntakser

Tabellen under viser de støttede spørringssyntakser. Disse syntaksene brukes av tjenesten for å bestemme betydningen av spørringen og for å legge til nye elementer til spørringen using riktig syntaks.

Ikke alle elementer av søkemotorens syntaks trenger å være støttet av tjenesten. Velg den som passer best til syntaksen. Hvis applikasjonen din krever boolsk søkesyntaks, bør syntaksen til OR-operatøren samsvare med det som forventes av søkemotoren din. Støtte for andre operatorer er valgfritt, da eventuelle ukjente syntaks elementer vil bli ignorert og forbli uendret av tjenesten.

Løse parameternavnkonflikter

HTTP-grensesnittet til TemaSearch-tjenester forventer at konfigurasjonsparametere sendes som spørringsparametere i URL-en eller som POST-parametere. I mange tilfeller spesifiseres disse parametrene sammen med parametrene til søkemotoren.

Hvis dette skjer, kan du omdøpe TemaSearch-parameteren for å unngå to parametere med samme navn. Omdøping gjøres ved å legge til et understrekingstegn ‘_’ foran parameter navnet.

For eksempel, hvis parameteren puser allerede ble brukt av søkemotoren din, bør TemaSearch-parameteren omdøpes til _puser. px-parameteren lister opp alle TemaSearch-parameterne i forespørselen, og inkluderer hver parameter med navnet slik det vises i skjemaet. For eksempel, etter å ha omdøpt puser til _puser, ville px-parameteren da være definert som “px=px … _puser …”. (Ellipsis brukes for andre parametere som ikke er vist her.)

Tjenesteparametere

Vanlige parametere

Pnoerr = instruerer tjenesten til å degraderes elegant når det oppstår feil. Hvis en feil oppstår, for eksempel autentiseringsfeil, feil parameter osv., returnerer serveren vanligvis en 500-feilkode og en feilmelding. Ved å sette pnoerr til 1 gjør at tjenesten degraderer elegant ved å returnere den opprinnelige forespørselen uendret.

Dette er hovedsakelig ment for direkte søk med webskjema-integrering, ettersom søket ikke ville gå videre hvis tjenesten ikke klarte å sende tilbake HTTP-omdirigeringen. For server-side integrering kan feil fanges og håndteres, så denne parameteren er mindre nyttig da.

ptshiston – aktiverer/deaktiverer historikkparameteren. Når den er satt til 1, legges en historikkparameter til resultatet. Når den er satt til “0” produseres ingen historikkparameter. Standardverdi er “0” for direkte søk, og “1” for foreningssøking. Du endrer typisk bare denne parameteren når du implementerer kombinasjonssøk (se XXX.).

Versjon: Beskriver versjonsidentifikatoren for resten av historikkparameteren. Nåværende versjon er versjon 1.

SekvensNum: Indikerer hvor mange ganger foreningssøk er blitt brukt til å legge til i forespørselen.

Nøkkelordsliste: de opprinnelige nøkkelordene hentet fra forespørselen. Dette er dataene som brukes av foreningssøk når de gjenoppbygger en forespørsel.

Original forespørsel: den opprinnelige forespørselsteksten i sin helhet.

Spørringsspråk: språket som brukes for å generere alternativer til forespørselen.

plangin, en liste over språk som forespørselen er skrevet på. Hvis ikke satt, default til automatisk oppdagelse av språk.

plangpref Hvis automatisk språkidentifikasjon er aktiv (plangin-parameter ikke definert), gir dette prioritet til språkene som er definert her. Det første språket i listen får høyest prioritet, etterfulgt av det andre osv.

pqt – forespørselstekst. Dette brukes til å spesifisere forespørselsteksten i direkte tjenestekall, når tjenesten returnerer resultatet direkte, i stedet for som en omskrevet søke-URL.

pprof – velger en ferdigprofil. Dette kan unngå å spesifisere mange forskjellige parametere.

padjlic – Kontrollerer hva som skjer når funksjoner som brukes ikke er gyldige for den gjeldende lisensen. Standardverdien er “1”, som enkelt inaktiverer funksjoner som ikke er lisensiert uten å produsere noen feil. Når den er satt til “0”, vil bruk av en ikke-lisensiert funksjon medføre at tjenesteanropet mislykkes med en feilmelding.

Pp – propagere parametere. Som standard blir tjenesteparametere angitt av px-parameteren forbrukt av tjenesten, og ikke sendt videre til resultatene. Hvis TemaSearch-tjenesteparametere også brukes eksternt (av søkemotoren din for å presentere konfigurasjonskontroller, logging eller annen bruk), bør de også inkluderes i URL-ene generert av tjenesten.

For tjenester som returnerer et direkte resultat, som direkte søk / omskriv, utføres autentisering ved å inspisere kontoopplysningene som er gitt i parameterne. prealm, puser og ppwd. Disse detaljene brukes til å autentisere bruken av tjenesten, og bestemme hvilke funksjoner som er lisensiert.

Psort – For foreningssøk spesifiserer denne parameteren sorteringsrekkefølgen av alternative ord. Sortering av ord kan skje på flere nivåer – parameteren er en komma-separert liste av sorteringsnøkler. For eksempel, “l,w,t” sorterer etter språket til det alternative ordet, deretter etter indeksen til det opprinnelige ordet, og så ordteksten selv.

Standardverdien er “”, som indikerer at ordene ikke er sortert, og vil fremstå i ingen spesiell rekkefølge. Rekka er ikke garantert å være den samme hver gang tjenesten kalles, så det anbefales å bruke en sorteringsrekkefølge.

De tilgjengelige sorteringsnøklene er gitt i tabellen under.

Å sette et utropstegn foran sorteringsnøkkelen reverserer rekkefølgen. For eksempel, "1,!t" sorterer ord etter språk og deretter i reversert alfabetisk rekkefølge.

Pgroup – Definerer hvordan alternative ord grupperes. Når alternative ord vises, kan de vises som en enkel liste over ord (rekkefølgen i denne listen spesifisert av psort-parameteret). Alternativt kan ordene grupperes under ulike overskrifter. For eksempel, angir gruppering som "l" (språk), vil vise språket for alternativene.

Gruppering fungerer ved å samle ord som har samme verdi for grupperingstasten (språk, ordtekst osv.). Dermed er gruppering og sorteringsrekkefølge relatert – hvis du grupperer på en attributt (si språk), så vil du også bruke en sorteringsnøkkel for den attributten. (Hvis sorteringsrekkefølgen er forskjellig fra grupperingsrekkefølgen, kan noen overskrifter vises mer enn en gang, noe som kan være forvirrende.)

Sortering og gruppering

De alternative ordene produsert av assosiasjonssøk kan sorteres og grupperes for enklere lesing og strukturert presentasjon. Sortering av ordene gjøres ved å sammenligne ulike attributter av hvert ord med de andre i listen. For eksempel, sortering etter ordtekst vil sortere ordene alfabetisk.

Gruppering tar alle ord med gruppeattributtet (ordtekst, språk, poeng osv.) og plasserer disse under en gruppeoverskrift.

I detalj

Som du kanskje forventer, er sorteringsrekkefølgen og grupperingsstrukturen nært beslektet. For eksempel, hvis du ønsker å gruppere alternativene først etter språk og deretter etter originalord, så bør sorteringsnøkkelen inkludere minst sortering etter språk og deretter originalord.

Det er mulig å ha gruppering og sortering som ikke følger samme mønster, men resultatene er kanskje ikke hva du forventer.

Det kan virke overflødig å spesifisere sortering og gruppering separat. Årsakene til å gjøre dette er:

• antallet nivåer av sorteringsnøkler kan være forskjellig fra antallet grupper. De ekstra sorteringsnøklene kan brukes til å styre rekkefølgen til grupper ved å bruke et ikke-gruppert attributt, eller kan brukes til å sortere ord innen en gruppe.
• grupperingsnøkkelen krever kun kunnskap om attributtet, sortering krever også kunnskap om den spesifikke sorteringsrekkefølgen – noen attributter kan sorteres etter ulike kriterier (for eksempel har språk to forskjellige sorteringsnøkler, l og l2).

Et eksempel. Vi ønsker å vise alternativene gruppert etter språk og originalord. Vi ønsker at språket skal sorteres etter relevans for den originale forespørselen. I tillegg skal listen over ord for hvert originalord sorteres alfabetisk. Dette gjøres ved å sette:

• psort=l2,w,t – sorter etter språkrelevans deretter originalordnummer og deretter ordtekst.
• pgroup=l,w – grupper etter språk og deretter originalord.

Spørringsbygger

Når assosiasjonssøket har bestemt de alternative søkeordene som er tilgjengelige, bruker det disse til å produsere en rekke søkespørringer basert på disse søkeordene. For eksempel, når en bruker klikker på et ord for å generere et nytt søk, bruker det en ny spørring produsert av en spørrebygger.

m- og ms-spørringstypene produserer spørringer som inneholder flere ord. Sett av alternative ord settes inn i en flerordspørring bestemmes av parameteren pqgrpidx. Som standard plasseres alle ordalternativene som produseres i en enkelt flerordspørring. Ved å sette parameteren pqgrpidx kan en flerordspørring opprettes for hver gruppe på et gitt gruppering nivå.

pqgrpidx – Sett gruppenivået for å gjøre ord om til spørringer.

NB: Hvis parameteren er satt til en verdi større enn antall grupperingsnivåer, vil ingen advarsel bli gitt, men ingen alternativer vil bli produsert. Dette skyldes at spørrebuilderen aldri finner det spesifiserte gruppenivået, og derfor blir ingen spørringer produsert.

psm – Ordvalgmodus

• Forsinket (enkelttrinn) – Dette er to-trinns valgmodus, hvor brukeren kan klikke for å velge eller fjerne ord. En ny søk blir kjørt først når brukeren sender inn valget.
• Umiddelbar (to-trinn, standard) – Dette er enkelttrinns valgmodus. Når brukeren velger et ord eller en gruppe ord, er valget umiddelbart, og en ny søk startes.

Hvis du bruker forsinket valg, må du sørge for at resultatene fra assosiasjonssøket ikke plasseres inni en eksisterende FORM. Brukergrensesnittet for valg i to trinn implementeres selv ved hjelp av en FORM. Å inkludere dette i en eksisterende FORM vil resultere i nestede former. Dette er ikke tillatt i henhold til W3C HTML-standardene og bør unngås, da støtte og oppførsel varierer fra nettleser til nettleser.

Plevel – Angir rørledningsnivået

Kontrollerer hvor lang transformasjonsrørledningen er som omformer XML-utdata fra assosiasjonssøket.

Plocale – Angir språket for brukergrensesnittet.

Assosiasjonssøk inkluderer ulike meldinger som en del av standard brukergrensesnittet. Språket som brukes for disse meldingene spesifiseres av denne parameteren. Meldingene er tilgjengelige på disse lokalene som standard:

Hvis du bruker den lokalt installerte tjenesten, kan du også legge til støtte for ekstra språk. (Se XXX.)

Hvis det ikke spesifiseres noen verdi for parameteren, bestemmes standardverdien slik:

• Hvis språket i den originale forespørselen ble gitt, eller bestemt automatisk, settes grensesnittets språk til det.
• Ellers brukes språket som er satt i vertsoperativsystemet.

pqtrunc – Setter maksimum antall tegn som skal brukes for forespørselen i brukergrensesnittet. Når brukeren skriver inn en lang forespørsel, kan dette føre til at tittelboksen for assosiasjonssøk blir betydelig større enn resten av grensesnittet. Siden forespørselen ofte vises andre steder på siden, kan forespørselen bli avkortet for å spare plass.

Standardverdien er 30 tegn.

Obligatoriske parametere er parametere som ikke har en standardverdi. Slike parametere må defineres, ellers vil forespørselen mislykkes med en feilmelding som angir den manglendeparameteren.

‘paltlic’ parameter

‘pbase’ parameter

‘pcharset’-parameter

‘penab’-parameter

‘pifl’-parameter

‘plangin’-parameter

‘plangout’-parameter

‘plemifl’-parameter

‘pmax1’-parameter

‘pmax2’-parameter

‘pnoerr’-parameter

‘povs’-parameter

‘pq’-parameter

‘pqsntx’-parameter

‘pstem’-parameter

‘psyng’-parameter

‘psynn’-parameter

‘pu’-parameter

‘puser’-parameter

‘px’-parameter

CSS-velgere

CSS-velgerne som brukes av assosiasjonssøket er beskrevet nedenfor. Velgerne og strukturen som brukes i brukergrensesnittet er mer komplisert enn hva som ville vært nødvendig hvis alle nettlesere støttet CSS 2-velgerne.