Re: [sdx-users] affichage alphabétique d'un e liste de terme sur un champ

[Frédéric Glorieux]

> Mmmh... je suis en train de me bagarrer là-dessus avec les développeurs 
> d'eXist :-)) Ma religion est faite : pourquoi faire porter à du code qui 
> se veut générique une politique d'indexation qui ne sert pas les 
> objectifs de la politique de requête ?

Je ne sais pas si je suis avec ou contre toi, pour moi, un index doit 
contenir "Architecture -- Bâtiment cultuel -- Église", c'est au code à 
rendre (ou ne pas rendre) le terme à ceux qui cherchent "église".

Cela signifie aussi que "architecture -- bâtiment cultuel -- église" 
(sans majuscules) constitue un autre terme (qui en l'occurence pourrait 
faire doublon).


> > Attention, je ne sais pas ce que cela donne avec de l'arabe ou autres 
> > langues pour laquelle toLowerCase() n'est pas précisément implémenté.
>
>
> C'est implémenté ne serait-ce que parce que que c'est du Java standard. 
> Mais en arabe... c'est kif-kif :-)

Merci JAVA

> > des numéros commencent par ~, parce que ma copie de travail est 
> > modifiée pour prendre en charge des choses comme
> > w* x* y* z* (les quatre dernières lettres d'un coup),
> > tout aussi bien que
> > "terme avec espace" terme
> >
> > Autrement dit faire que l'espace soit un "ou" implicite, comme dans le 
> > langage de requête Lucene.

> De plus, ne pas oublier que, pour les champs non
> tokenisés, l'espace *peut* être significative :
> "cul de sac" peut
> représenter un seul token...

C'est le problème que peuvent rencontrer des applications en 
fonctionnement. J'ai implémenté l'usage des guillemets, mais cela casse 
les applis qui par exemple fonctionnait sur des choses comme

Architecture*
Architecture -- Bâtiment cultuel*

(pour par exemple présenter des thesauri hiérarchiques).

Il faudrait alors ajouter des guillemets quand il y a des espaces

Architecture*
"Architecture -- Bâtiment cultuel*"

Premier cas d'incompatibilité ascendante.

> C'est une idée, mais, d'une façon plus générale, il faudrait offrir les 
> mêmes possibilités que l'on a pour les requêtes (et, ou, sauf à partir 
> d'une "baseQuery"). 

A faible coût, on peut probablement implémenter
le "et" et le "non" de cette manière

+Architecture* -"*bâtiment cultuel*" +*roman*

Devrait donner tous les descripteurs qui parlent d'architecture romane, 
en excluant les églises et les chapelles (si le vocabulaire est bien 
fait). Par contre, ma science du patrimoine est trop limitée pour savoir 
s'il y a beaucoup de désignations potentielles qui répondraient à ce filtre.

Attention tout de même de ne pas implémenter trop de choses, on se 
tromperait a confondre liste de termes et base de documents. En général, 
 les listes sont utilisées pour des regroupements (genre type de 
document), ou des nom propres (personnes, lieux...), rarement structurés 
pour que cette syntaxe apporte beaucoup à un utilisateur. Cet exemple 
<http://noticesrameau.bnf.fr/> me semble le cas limite, sachant que 
l'objet d'une navigation dans une liste de sujets dans SDX a ensuite 
pour objet d'amener la liste de documents qui s'y rapportent.



--
Frédéric Glorieux ("AJLSM", <http://ajlsm.com>)