La presente pagina di documentazione intende porre l'accento su alcuni comportamenti particolari del server eXtraWay in materia di adiacenza quando essa si esprime tra valori di un attributi indicizzato parola per parola.
Vediamo, passo passo, di che si tratta.
In primo luogo il contenuto degli attributi, per definizione, viene indicizzato come singolo valore a meno che non venga esplicitata una differente modalità, in sostanza la modalità multi valore che assegna una chiave ad ogni termine trovato nel campo secondo i separatori di default.
In questo secondo caso il comportamento canonico consiste nell'assegnare un indice progressivo a ciascun termine, di seguito definito chiave, identificato nell'attributo. Quest'indice progressivo, detto iword, viene assegnato tanto alle chiavi rilevate negli elementi quanto a quelle rilevate negli attributi. In tal modo è possibile stabilire la prossimità dei termini ricercati (ricerca in adiacenza) confrontando le iword delle chiavi oggetto di selezione.
Nonostante questa modalità, per semplificare alcune operazioni, renderle più rapide e la dove non si ritenga necessario avere adiacenze esatte tra le chiavi di simili campi, è stata introdotta un'apposita voce di profilo per disabilitare la modalità standard e produrre un'indicizzazione ove l'iword assegnata alle chiavi provenienti da un attributo non è progressiva ma si tratta della stessa assegnata all'elemento al quale l'attributo appartiene.
Per ulteriori indicazioni consultare arc.attribfreeorder
Veniamo ora al particolare comportamento del server e per farlo parliamo anche della chiave di istanza che può essere assegnata ad un elemento. La chiave di istanza consente di identificare, con un'apposita iword, dove abbia inizio ogni elemento. In tal modo è possibile separare e distinguere le iword delle chiavi identificate in un elemento da quelle di un altro elemento identico che lo segua.
Passiamo subito ad un chiaro esempio per meglio comprendere di cosa stiamo parlando.
Si prenda a campione questo frammento XML che rappresenta un documento identificato dall'elemento a.
<?xml version="1.0"?> <a> <b c="roberto tirabassi"/> <b c="massimo morara"/> <txt>Questo documento server a capire le adiacenze.</txt> </a>
Il documento è molto semplice ma chiarisce lo scenario.
Ricordiamo che le iword servono in particolare per la soluzione delle adiacenze quindi, nell'esempio del testo introdotto nell'elemento txt, la ricerca...
[/a/b/txt]=capire le adiacenze
...indica il desiderio di trovare i documenti in cui i termini capire, le, e adiacenze siano prossimi tra loro nello stesso campo. La distanza ed il rispetto dell'ordine sono fattori condizionanti della ricerca che però assumono un ruolo molto importante che vedremo man mano.
Nel documento generale sulla ricerca per adiacenza (Ricerca in adiacenza. Modalità di ricerca e comportamento del server eXtraWay) si parla anche di ricerca as is, e di come essa venga compiuta in ordine a distanza 1 tra i termini. A differenza di questa modalità, la più frequente forma di adiacenza prevede sì l'ordine dei termini, delle chiavi, ma distanze variabili tra 2 e 4 in questo modo la frase di ricerca...
[/a/b/txt]=capire adiacenze
...è ugualmente efficace.
Veniamo ora all'adiacenza tra termini di un attributo. Avendo qualificato l'attributo come multi valore, così come avviene normalmente per gli elementi, ci si aspetta di poter esprimere adiacenze anche sui contenuti di questi campi ma per ottenere risultati ragionevoli ci vuole un po' di attenzione e diversi sono gli scenari cui si può dover far fronte.
Andiamo per ordine.
In caso di indici semplici, le chiavi del nostro esempio assumono le seguenti iword:
Ne consegue che la ricerca...
[/a/b/@c]=tirabassi massimo
...eseguita in ordine anche semplicemente a distanza parole pari ad 1, seleziona questo documento ove, in realtà, non esiste un tirabassi massimo.
La distanza tra termini che appartengono agli attributi di elementi diversi corrisponde, e quindi può essere confusa, con quella di termini dello stesso attributo.
Considerando che la distanza è spesso pari a 2 o più chiavi la cosa si fa ancor più evidente.
Nello scenario descritto non è possibile garantire che la ricerca trovi documenti che presentino tutte le chiavi richieste nello stesso attributo in quanto attributi prossimi potrebbero ingannare la verifica di adiacenza.
Ecco quindi che diviene necessario definire i bacini di pescaggio...
Il concetto di bacino di pescaggio è stato già trattato nel documento che spiega le adiacenze (Ricerca in adiacenza. Modalità di ricerca e comportamento del server eXtraWay) ma in questo caso trova un'ulteriore caso di applicazione. Se è vero che cercando l'adiacenza tra valori appartenenti ad attributi diversi si vuol intendere che essi siano presenti in attributi appartenenti allo stesso elemento (alla stessa ripetizione di quell'elemento in tutto il documento), per farlo si usa appunto il bacino di pescaggio.
Il bacino di pescaggio, in questo caso, viene scelto autonomamente dal server in fase di ricerca. Altrettanto non avviene per la ricerca in adiacenza tra termini dello stesso attributo quindi l'operatore deve curarsi di qualche accorgimento in più.
In primo luogo l'elemento che ospita l'attributo sul quale si intende fare con correttezza questo tipo di selezione deve presentare la caratteristica di instance (non documentata in questa sede), ovvero appunto l'identificazione del bacino.
In questo modo le iword assegnate alle chiavi del nostro esempio cambiano come segue:
Ecco che la selezione...
[/a/b/@c]=tirabassi massimo
...non darebbe esito per distanza 1 ma continuerebbe a darlo per distanza 2 o superiore. Ne consegue che è opportuno esplicitare sempre il bacino di competenza con la forma seguente...
[/a/b/@c|(AdjBay:/a/b)]=tirabassi massimo
...in modo che la selezione trovi solo i documenti in cui i due termini sono presenti nella stessa istanza. Nel nostro caso il documento in esempio non verrebbe selezionato mai, indipendentemente dall'ordine e dalla distanza delle chiavi di selezione in quanto gli ID di bacino spezzano l'adiacenza e non la rendono più riconoscibile.
Questo comportamento diventa ancor più importante quando si fa uso dell'appiattimento delle iword degli attributi...
Oltre ai casi espressi sino ad ora c'è anche il caso dell'appiattimento delle iword degli attributi, appiattimento che ha scopi prestazionali ma anche logici. L'ordine degli attributi di un elemento, infatti, non è ne obbligato ne garantito e quindi non è corretto pensare che la numerazione progressiva delle iword assegnate possa risentire dell'ordine degli attributi.
Volendo quindi dare a tutti gli attributi di un elemento la stessa iword di partenza si incappa in alcune limitazioni che impongono che tutti i termini di un attributo con iword appiattite abbiano in realtà la stessa iword, ovvero lo stesso indice progressivo.
Sulla base di quanto appena detto abbiamo due ulteriori scenari: iword appiattite con o senza l'identificazione del bacino di pescaggio.
In assenza di identificazione di bacino di pescaggio le iword assegnate al nostro documento divengono:
Ignorando il termine Questo che appartiene ad un vocabolario distinto, tutte le altre chiavi hanno la stessa iword. In questo caso ogni tentativo di esprimere un'adiancenza con elementi in sequenza come in questo caso ricade nel caso dell'AND.
Se l'importanza dell'identificazione del bacino di pescaggio è stata chiarita precedentemente, in questo caso diviene semplicemente vitale.
Con l'impostazione dell'ID le cose cambiano lievemente:
Ecco che con quest'accorgimento la risoluzione della ricerca per adiacenza con espressione del bacino di pescaggio torna a dare risultati sensati.
Se è vero che in eXtraWay si è sempre voluta garantire la possibilità di effettuare selezioni in adiacenza tra i termini di un attributo multi valore, i casi come quelli esposti richiedono un po' di attenzione per poter garantire la selezione dei documenti realmente pertinenti.
Ad essi si somma la modalità di indicizzazione delle iword appiattite per gli attributi, recentemente introdotta, per l'uso della quale quest'aspetto diviene ancor più importante.
Torna a Indice delle voci