Les choix d’impl´ementation effectu´es au chapitre 4 nous permettent de construire une base de m´etadonn´ees “documentaire” et une base de connaissances. Il nous faut `a pr´esent permettre l’acc`es et l’exploitation de ces bases.
Apr`es avoir pr´esent´e l’architecture g´en´erale de notre application d’acc`es aux m´etadonn´ees section 5.1, nous en d´ecrivons plus particuli`erement les aspects “SI” et “SBC” sections 5.2 et 5.3. Nous montrons ensuite section 5.4 comment nous mettons en œuvre quelques-uns des exemples de raisonnement ER vus au chapitre 3. Section 5.4, nous tentons de cerner quelques-unes des limites de l’application construite.
5.1 Architecture de l’application
Nous d´eveloppons une application Web accessible depuis l’intranet de l’IGN. Nous adoptons une architecture Web classique “n-tiers” :
L’utilisateur dispose d’un ordinateur ´equip´e d’un navigateur Web standard et connect´e au r´eseau intranet de l’IGN. Via le protocole HTTP, l’utilisateur acc`ede aux pages HTML de l’application, soumet de requˆetes et transmet des donn´ees au serveur Web.
Le serveur Web re¸coit les requˆetes de l’utilisateur. Il les reformule et les transmet au serveur d’application. Le serveur d’application renvoie la r´eponse au format XML. Le serveur Web effectue la mise en forme en transformant le XML en HTML qui est alors envoy´e `a l’utilisateur. Le rˆole du serveur Web se limite `a g´en´erer du HTML `a partir des r´eponses XML fournies par le serveur d’application.
Le serveur d’application effectue toutes les op´erations sur les m´etadonn´ees autres que leur mise en forme : ex´ecution des requˆetes, adaptation des modes d’emploi, v´erification de la conformit´e de la base de m´etadonn´ees au mod`ele, pont entre les formalismes SI et SBC. Le serveur d’application peut ˆetre d´ecoupl´e en plusieurs serveurs d’application distincts, ´eventuellement r´epartis sur des machines distantes.
Les serveurs de donn´ees stockent les bases de m´etadonn´ees “SI” et “SBC”. Par choix de simplicit´e, nous n’avons en fait pas r´eellement mis en place de serveur, du moins pas qui utilise un protocole du Web. L’acc`es aux bases de m´etadonn´ees s’effectue en effet par simple chargement de fichiers. Cette solution pr´eserve la philosophie de l’architecture souhait´ee, `a savoir que la base de donn´ees soit dissoci´ee de l’application. Une nouvelle application doit-elle
acc´eder aux m´etadonn´ees ? Elle le peut, ind´ependamment des applications existantes.
La figure 5.1 illustre l’architecture que nous avons mise en place. Les fl`eches entre les parties du syst`eme signifient “interagit avec”. L’application Consul apparaˆıt en gris´e car nous ne l’avons pas d´evelopp´ee. Elle ne faisait pas partie de nos objectifs, mais nous devions prendre en compte son existence future. Il est en effet pr´evu que notre serveur de m´etadonn´ees des traitements soit int´egr´e `a une plateforme plus large d´edi´ee ´egalement aux m´etadonn´ees sur les donn´ees g´eographiques et au calcul de tˆaches (projet de l’action de recherche Consul dans laquelle s’inscrit notre travail). Ceci, entre autres, explique pourquoi serveur d’application et serveur Web sont s´epar´es : les m´etadonn´ees des traitements ne doivent pas seulement ˆetre fournies au format HTML mais aussi au format XML. Cette s´eparation rend ainsi ais´ee, par exemple, la construction d’un service Web SOAP dont les r´eponses encapsuleraient nos m´etadonn´ees au format XML.
Fig. 5.1 – Architecture de l’application d’acc`es aux m´etadonn´ees
Aucune partie de notre application n’est li´ee `a un syst`eme d’exploitation particulier. Les parties “SI” et “SBC” du serveur d’application reposent sur diff´erentes API Java ; la machine virtuelle Java JRE 1.5.0 (alias Java 2 version 5.0) est utilis´ee. Les servlets Java d´evelopp´es fonctionnent avec Tomcat 5.5. Les pages Web statiques de l’application sont fournies par un serveur de pages Web Apache 1.3.27.
5.2 L’application d’acc`es aux m´etadonn´ees – aspect “SI”
Apr`es avoir succinctement indiqu´e nos principaux choix techniques concernant l’aspect SI de notre application, nous pr´esentons cette derni`ere en suivant le point de vue de l’utilisateur.
5.2.1 Choix d’impl´ementation – aspect “SI”
Pour manipuler les diff´erents formats de donn´ees nous faisons appel `a diverses API Java. En particulier, pour manipuler les documents XML nous utilisons l’API standard Jaxp (Java API for XML Processing). Cette API nous permet d’utiliser XSLT et XPath.
XSLT (eXtensible Stylesheet Language Transformation) est le langage standard de transfor-mation de documents XML. XPath est le langage qui permet d’adresser les ´el´ements du
docu-ment XML `a transformer. XSLT et XPath sont des recommandations W3C dont les premi`eres versions ont ´et´e rendues publiques en 1999 [W3C99b][W3C99c].
Nous nous servons d’XPath comme d’un langage de requˆetes, de la mˆeme fa¸con que nous pourrions utiliser SQL si nos m´etadonn´ees ´etaient stock´ees dans une base de donn´ees relation-nelle.
XSLT est un langage fonctionnel. Il est bien adapt´e `a l’impl´ementation d’algorithmes r´ecursifs. Nous en mettons en œuvre dans de nombreux endroits de l’application, pour g´en´erer des fichiers d’index invers´es1, des fichiers retrouvant les types parents ou sous-types des ressources (cf. l’exemple des modes d’emplois code A.4 p. 234), des pages HTML repr´esentant des arbres XML dont on ne connaˆıt pas `a l’avance la profondeur (cf. fig. 5.6, 5.12 et 6.8 p. 186, 199 et 220). D’une fa¸con g´en´erale, les structures arborescentes se prˆetent bien `a la r´ecursion. Pour d´evelopper nos servlets nous utilisons le package javax.servlet. De fa¸con annexe, nous nous assurons de la validit´e de notre base de m´etadonn´ees vis-`a-vis du sch´ema XML avec XML Spy 2005, outil qui impl´emente toutes les sp´ecifications W3C relatives aux ´el´ements du langage que nous utilisons. Nous effectuons ´egalement des contrˆoles suppl´ementaires. N´eanmoins, en th´eorie, la saisie via l’application ne permet pas d’enregistrer de description invalide.
5.2.2 Navigation et recherche dans la base de m´etadonn´ees
Notre application de consultation des m´etadonn´ees se pr´esente `a l’utilisateur sous la forme d’un site Web. L’utilisateur y acc`ede avec un navigateur Web standard, via l’Intranet de l’IGN. La figure 5.2 est une copie d’´ecran de la page d’accueil. La barre de navigation, situ´ee `a gauche, offre plusieurs fonctionnalit´es :
– Le lien “Navigation dans les index” m`ene au diagramme de la page d’accueil (dont les ´el´ements sont cliquables).
– Le lien “Soumettre une requˆete” m`ene au formulaire montr´e fig. 5.9 p. 193. L’utilisateur ne fait que remplir ce dernier, il n’utilise aucun langage de requˆete (i.e. il ne saisit pas d’expression de langages comme SQL ou XPath).
– Le lien “Statistiques” m`ene `a la page montr´ee fig. 5.4.
– Le lien “Index de toutes les ressources” m`ene `a la liste alphab´etique de toutes les ressources index´ees dans la base de m´etadonn´ees.
– Le champ “Rechercher” permet d’effectuer une recherche plein-texte dans la base de m´etadonn´ees.
La partie “Acquisition” sera discut´ee au chapitre 6.
La figure 5.3 montre le r´esultat de la s´election de “Ensemble de traitements” puis de “Logi-ciel/SIG” : la liste de ces derniers est affich´ee. La liste peut ˆetre tri´ee en prenant comme crit`ere les propri´et´es affich´ees (les tˆetes de colonnes “nom”, “(domaine de) fonctionnalit´es”, etc. sont “cliquables”) ou celles propos´ees dans la liste d´eroulante en haut de l’´ecran. Remarquons que les fl`eches situ´ees `a gauche des noms de ressources permettent d’en visualiser une courte description. Les RessourcesTraitements mises `a part, la plupart des ressources de notre base de m´etadonn´ees sont reli´ees entre elles par des relations de sp´ecialisation. Lors de la navigation dans les index, il est possible de visualiser les taxinomies constitu´ees sous forme arborescente. La figure 6.1 p. 214 montre un ´ecran affichant la liste des fonctionnalit´es sous cette forme. Ce
1Le principe est simple : ´etant donn´e un ensemble d’index d´ecrivant les relations entre ressources, on construit de nouveaux index d´ecrivant les relations inverses. Typiquement, partant de pages Web contenant des listes de mots, on construit les index inverses qui d´ecrivent pour chaque mot les pages Web qui les contiennent.
Fig. 5.2 –Page d’accueil de l’application
Fig. 5.4 – Affichage de statistiques – G´en´eration dynamique de camemberts JChart
type d’´ecran est g´en´er´e dynamiquement avec des feuilles XSL dont les templates parcourent r´ecursivement la hi´erarchie des ressources (chaque ressource n’indiquant que son parent direct). L’utilisateur peut naviguer dans les index ; il peut aussi soumettre des requˆetes. Celles qui s’effectuent via le formulaire propos´e sont trait´ees par la partie SBC de l’application. Celles qui reposent sur la soumission de mots-cl´es sont plus simples, elles reposent sur la simple recherche plein-texte. Le r´esultat est la liste de toutes les ressources dont n’importe lequel des ´el´ements de description contient la chaˆıne de caract`ere soumise par l’utilisateur. Un des obstacles de ce type de recherche r´eside dans les probl`emes de synonymies ou de multilinguisme. Notre application permet de le surmonter en partie. Voici un proc´ed´e s’appliquant de fa¸con g´en´erique. L’utilisateur pensant avoir un probl`eme de vocabulaire pour utiliser les bons termes de recherche peut consulter la description des concepts d´ecrits dans la base de m´etadonn´ees. Par exemple, l’utilisateur recherche un programme de d´etection de talwegs. S’il soumet le mot-cl´e “talweg” le r´esultat de la recherche ne comportera aucun traitement, mais comportera en revanche le concept “relief”. L’utilisateur demande alors de visualiser la description de ce concept. La liste de toutes les ressources li´ees s’affiche. Parmi elles figure le programme “caract´erisation des MNT”, qui r´epond au besoin de l’utilisateur.
Dans notre contexte, la question du tri des r´esultats en fonction de la popularit´e des res-sources est un aspect secondaire. Nous n’avons pas cherch´e `a le traiter. N´eanmoins, si les utili-sateurs le souhaitaient, il n’y aurait aucune difficult´e `a proposer un tri des r´esultats en fonction du nombre de ressources dont la description “pointe” vers les ressources recherch´ees (“popula-rit´e d’apr`es les m´etadonn´ees”), ou un tri en fonction du nombre de “clics” effectu´es depuis une p´eriode donn´ee par les utilisateurs, indice ´eventuellement pond´er´e par l’anciennet´e de l’acc`es ou le profil des utilisateurs2 (“popularit´e d’apr`es les utilisateurs”).
2L’identit´e des utilisateurs est connue. Les servlets de notre application gardent une trace de leurs actions dans des fichiers log. ´Etant dans un contexte Intranet, nous avons stock´e la table de correspondances entre les noms des
5.2.3 Visualisation des descriptions de traitements
`
A partir des listes de ressources obtenues par un des modes de recherche ´evoqu´es, l’utilisateur acc`ede `a la description d’une ressource particuli`ere. La description du programme Accord´eon v.2 telle qu’elle apparaˆıt `a l’utilisateur est montr´ee figure 5.5.
Les pages de descriptions de RessourceTraitement sont organis´ees selon les cinq facettes qui structurent notre mod`ele conceptuel. Chaque facette est signal´ee par une barre horizontale bleue. Les descriptions comportent une sixi`eme barre nomm´ee “Ressources li´ees”, repr´esentant la partie o`u sont list´ees toutes les ressources qui font r´ef´erence `a la ressource courante. Par exemple, `a la fin d’une description d’une librairie se trouvent indiqu´ees toutes les RessourceTraitement qui l’utilisent. Ce type d’information est simple mais pr´ecieux.
Pour plus de la moiti´e des ´el´ements de description, les valeurs sont des r´ef´erences `a des ressources. De fa¸con syst´ematique, ces valeurs apparaissent sous forme de lien hyper-texte (en bleu, ou en violet pour les liens d´ej`a visit´es)3. Les autres valeurs, de type simple (texte, nombres entiers et r´eels, date, bool´eens) apparaissent sous forme de texte simple (en noir). Les illustrations sont un cas particulier. Certaines ne sont que des images raster non index´ees en tant que ressources. C’est le cas de l’image, figure 5.5, o`u les routes sont symbolis´ees en rouge. D’autres illustrations, au contraire, sont des ressources de type Echantillon. Certains ´echantillons sont de simples images raster (au format bitmap, GIF, Jpeg ou PNG). Les autres ´echantillons – il est important de le souligner – sont des jeux de donn´ees r´eels au format shape. C’est le cas des deux ´echantillons qui illustrent la description du programme Accord´eon 5.5. Le jeu de donn´ees avant traitement est issu de la version d’octobre 2002 de la BD Carto et repr´esente des routes de la r´egion de Nice. Il a ´et´e g´en´eralis´e avec le module AGENT du SIG Lamps2 en f´evrier 2006 ; Accord´eon est un des programmes qui a ´et´e appliqu´e. Les jeux de donn´ees sont stock´es dans la base de m´etadonn´ees. Ils sont visualis´es dans les pages HTML de notre application grˆace `a des applets4 Java Geotools inclues dans des frames HTML.
utilisateurs et le nom ou l’IP fixe de leur machine, ces derniers ´etant r´ecup´er´es par les servlets avec la m´ethode getRemoteHost() de l’objet HttpServletRequest cr´e´e `a chaque acc`es `a une page de l’application (pour les pages statiques comme la page d’accueil, l’utilisateur est au pr´ealable redirig´e automatiquement vers un servlet d´edi´e au log grˆace `a une instruction Javascript location.replace(page )).
3Les propri´et´es des donn´ees sont des ´el´ements de descriptions, mais ce sont aussi des ressources. Elles sont donc repr´esent´ees par des liens hypertextes menant `a leur description.
4appl ication widget, un widget ´etant un ´el´ement graphique d’interface (contraction de windows gadget, mais n´eanmoins utile ici).