INTEROPERABILITE ET SERVICES WEB STANDARDISES : DU «HUMAN TO HUMAN» AU «MACHINE TO MACHINE»

Transcription

1 INTEROPERABILITE ET SERVICES WEB STANDARDISES : DU «HUMAN TO HUMAN» AU «MACHINE TO MACHINE» MISE EN CONTEXTE Le partage de l information géographique est aujourd hui une nécessité reconnue par tous et divers dispositifs mis à disposition des acteurs d un même territoire la permettent : observatoires territoriaux et infrastructures de données spatiales mises en œuvre au niveau d agglomérations, de départements, de régions ou au niveau national. Ces dispositifs s appuient techniquement sur divers standards d interopérabilité mis au point par l OGC («Web Services» géographiques et de métadonnées notamment) pour assurer à la fois l interopérabilité de chaque plate-forme avec les dispositifs de ses adhérents / partenaires et l interopérabilité des plates-formes entre elles. Ils permettent notamment : De moissonner des métadonnées, soit par transfert périodique automatisé, soit par accès distant via des requêtes à un géorépertoire (interface CS-W) D accéder uniformément à des données distribuées, exposées par des Services Web, pouvant comporter également des fonctions de traitement, et donc sans jamais requérir de transférer ou télécharger les fichiers natifs (interfaces WMS, WFS, WCS, WPS) On rappelle la définition publiée sur son site par le Forum OGC France (FOF). «L interopérabilité est la capacité des systèmes à communiquer, à échanger des données, à "travailler" ensemble, sans que l utilisateur ait besoin de connaître les caractéristiques spécifiques à chaque système. L interopérabilité est basée sur l utilisation de standards définissant les interfaces des composants des systèmes. Une application connaissant les interfaces standards est capable d utiliser n importe quel composant respectant ces standards.» 3 composants techniques sont donc concernés par cette problématique d interopérabilité : Les données, car la plupart des besoins d interopérabilité concernent la capacité d accéder à des données distantes et/ou stockées dans des systèmes divers, et leur mise à disposition dans un schéma applicatif (ou modèle de données) unifié: elles doivent donc si possible être accessibles à travers des interfaces de service et des encodages standardisée (GML, SensorML, WaterML, O&M ). Les services d accès aux données (en encodage natif et/ou standard) et les services offrant des traitements sur ces données Enfin, les métadonnées, qui permettent dans un premier temps d identifier des données et des services, dans un second temps de les sélectionner, dans un troisième temps d intégrer les accès ou traitements à des processus informatisés Il semble important de rappeler que ces standards sont conçus pour plusieurs types d usages, impliquant comme émetteurs ou récepteurs des humains («Human») et des systèmes informatiques («Machine»). Aujourd hui, pour de nombreux géomaticiens, avant d être reconnues comme un moyen de gérer leur patrimoine informationnel, les métadonnées sont

2 surtout un moyen pour un acteur (personne ou structure organisationnelle) de faire connaître à d autres acteurs l existence de données et de services et ils sont tentés de se focaliser sur les interactions entre humains. Dans ce registre, les métadonnées et les outils d exploitation associés posent un certain nombre de problèmes (ergonomie, compréhension et complexité sémantique, etc). On verra plus loin que les métadonnées doivent également être conçues comme un moyen pour les systèmes informatiques de dialoguer et d échanger. Il s agit ici véritablement d interopérabilité et celle-ci pose des problèmes d un autre ordre qui doivent également être abordés. Les deux tableaux suivants examinent les divers cas possibles dans le contexte des métadonnées et des «Web Services». Contexte Human to Human Human Computer Interaction (HCI) Machine to Machine (M2M) Interaction via les métadonnées Une personne après avoir identifié des métadonnées, téléphone à leur gestionnaire pour obtenir plus d informations sur ces données et pouvoir y accéder. Une personne exécute une requête de recherche de métadonnées dans un logiciel Le logiciel présente les métadonnées, triées à l aide de certains algorithmes, à l utilisateur La personne active les liens permettant d ouvrir les fichiers de données Ces interactions sont de plus en plus gérées par des applications Web (technologies du WWW), et sont souvent présentées comme des «Services» (sur le Web). Il va sans dire que ce terme apporte une confusion dans la bonne compréhension de ce que sont et font par ailleurs les «Web Services» 1 Un logiciel envoie des requêtes de recherche ou de moissonnage de métadonnées à d autres logiciels et indexe les résultats Contexte Interaction via les «Web Services» Human to Human Les «Web Services» sont par définition des interfaces programmatiques Human Computer Interaction (HCI) Machine 2 Machine (M2M) Une personne configure les paramètres d accès à un «Web Service» WMS pour l utiliser dans son SIG bureautique habituel. Le logiciel présente à un utilisateur une carte affichant le résultat de l appel du «Web Service» Un logiciel orchestre un chaînage de «Web Service» pour réaliser une fonction à valeur ajoutée PROBLEMES IDENTIFIES Il faut en premier lieu signaler que le gestionnaire des données en reste souvent dans la pratique au renseignement de métadonnées de découverte, alors que les métadonnées d usage (exploration et exploitation), qui seraient pourtant très utiles, sont pour le moment pauvres et peu utilisables : par exemple «qualité», précision, complétude Divers problèmes ont par ailleurs déjà été identifiés. Ils concernent l identification des données et des services, leur qualification et leur sélection, puis enfin leur utilisation. Ces problèmes ont une expression «Human» et une expression «Machine». Ainsi le problème de la sélection des métadonnées pertinentes se pose dans les deux cas, mais de façon probablement différente. Le 1 Web Service : Human Computer Interaction : Machine to machine : Groupe OGC AFIGEO / FOF du H2H au M2M - AFIGEO_OGC_M2M_V5.doc 04/05/ Page 2

3 fait que certains processus s exécutent sans intervention humaine et de façon automatisée recouvre des problématiques particulières. Identification Identifier les catalogues de métadonnées pertinents Comment savoir où aller chercher des métadonnées? HUMAN : la première difficulté que rencontre la personne qui cherche des données ou des services est d identifier les sites mettant des métadonnées en ligne pertinentes dans le domaine ou le territoire recherché. Elle pose la question de méta-annuaires ou de la centralisation des métadonnées. Il est certain qu après avoir identifié des catalogues, la personne va en priorité effectuer ses recherches sur ceux qui semblent concerner plus spécifiquement le territoire et/ou la thématique recherchée. MACHINE. Aujourd hui, un système informatique ne peut aller chercher des métadonnées que dans des catalogues dont on lui a fourni les références, donc prédéfinis. Il ne dispose pas de moyens lui permettant d effectuer une présélection géographique ou thématique, cette sélection ne pouvant se faire qu au niveau des métadonnées, par les mots clés et les emprises ( bounding boxes ). Ne récupérer que des métadonnées pertinentes Comment faire en sorte qu une requête renvoie le plus de données pertinentes possible et si possible, ne renvoie que des données pertinentes? En principe, les mots clés permettent cette sélection, mais l expérience montre d une part, que la profusion de mots clés dans les métadonnées conduit à la sélection de métadonnées non pertinentes, d autre part, à l inverse, que des métadonnées pertinentes ne sont pas sélectionnées car les mots clés ne sont pas suffisamment standardisés ou sont incomplets. Une différence entre le mode humain et le mode informatisé provient du fait que le premier tolère et est capable d exploiter une certaine ambiguïté des concepts ou est capable d établir des correspondances tout seul (si PLU ne donne rien, il tentera urbanisme ou zone de construction), alors que le second ne peut que combiner des concepts qui ont été préalablement associés et n a pas la capacité de passer d un niveau à l autre dans l exécution d une indexation. De fait, la préoccupation de disposer de mots clés pertinents semble aboutir à deux logiques inverses, suivant qu on est dans le mode humain ou le mode informatisé. Le premier étant susceptible de rechercher des métadonnées à partir de vocabulaires très différents dans leur richesse sémantique et étant capable d effectuer des tris et sélection à partir de processus cognitifs très complexes, peut tirer profit de mots clés peu standardisés et peut aboutir à une sélection plus restreinte et plus pertinente, pourvu que les mots clés aient été correctement renseignés. Le second, ne peut tirer profit que de mots clés standardisés dans des nomenclatures, thésaurus ou ontologies et n a pas la capacité d analyse et de sélection du premier. Les mots clés et descriptions textuelles sont donc peu précis et difficiles à utiliser : comment traiter les problèmes sémantiques tels que : une recherche sur PLU dans le géocatalogue ramène des métadonnées de zonages de PLU, des métadonnées sur les communes qui disposent de PLU et des métadonnées dans lesquels on trouve la syllabe «plu» (exemple : des réserves naturelles Groupe OGC AFIGEO / FOF du H2H au M2M - AFIGEO_OGC_M2M_V5.doc 04/05/ Page 3

4 dont la délimitation doit être reportée au PLU, des zonages de SCOT, un guide méthodologique concernant l évaluation des PLU, etc). La situation est donc un peu paradoxale : plus les mots clés sont spécifiques et diversifiés, plus l utilisateur humain pourra spécifier ses requêtes et récupérer des listes pertinentes, mais moins le système informatique trouvera de réponses à ces requêtes. A l inverse, plus les mots clés seront génériques, plus ils seront accessibles au système informatique, mais plus l utilisateur humain risque d avoir de réponses non pertinentes à ses requêtes. La réponse à cette difficulté réside-t-elle seulement dans le fait de disposer de thésaurus et ontologie riches et d en imposer l utilisation aux acteurs qui renseignent des métadonnées? D interdire le renseignement de mots clés spécifiques hors thésaurus? Un autre problème concerne également la définition des emprises ( bounding boxes ), pas toujours correctement renseignés ou le fait que les rectangles englobant conduisent à récupérer des données sur d autres territoires. L utilisateur humain a rapidement la capacité d éliminer un résultat de requête non pertinent sur d autres critères. Dans sa recherche de PLU sur la Saône et Loire, il éliminera rapidement les métadonnées concernant les PLU de la Nièvre ou de l Ain sur le seul titre des métadonnées, ce que le système informatique n est pas en mesure de faire facilement. Problème des recherches multilingues. Comment gérer le problème des mots clés dans un contexte multilingue? L utilisateur ou le système informatique peuvent-ils espérer dans une même requête accéder à des données disponibles dans plusieurs langues et/ou provenant de plusieurs pays? Certains moyens d identification sont précis : thésaurus standardisés communs à plusieurs pays, catégories INSPIRE, nomenclature ISO (souvent inadaptée aux contextes), mots clés géographiques quand il s agit de zonages renseignés à partir de thésaurus (en France : régions, départements et communes). Ils peuvent cependant poser un problème lié à l exécution de requêtes multilingues. Il faut, soit, que les catégories INSPIRE ou ISO (par exemple) soient encodées de façon à ce que le requêteur effectue des recherches sur le code plutôt que sur le nom, soit que l on dispose de nomenclatures multilingues, disposant de différentes traductions, soit que l on dispose d outils de traduction de nomenclatures et index. Mais dans ce cas, il ne s agit que de problème de traduction, les concepts étant supposés communs aux différentes langues de renseignement des métadonnées. Les thésaurus standardisés spécifiques à un pays facilitent la requête dans leur pays d origine, mais sont vus dans le cas d une requête multilingue ou multi-pays comme les mots clés et descriptions textuelles que nous abordons ensuite. Ils offrent des moyens d identification standardisés dans leur langue, mais doivent être traduits pour qu un utilisateur d une autre langue puisse les utiliser, et il n y a pas forcément correspondance entre les concepts qu ils décrivent dans le pays concerné et les concepts similaires dans les autres pays. Les mots clés et descriptions textuelles sont encore moins précis et encore plus difficiles à utiliser dans le cas de recherches multilingues : il faudrait en effet que l utilisateur humain d un pays connaisse les terminologies des divers pays concernés par sa requête : il est aussi démuni Groupe OGC AFIGEO / FOF du H2H au M2M - AFIGEO_OGC_M2M_V5.doc 04/05/ Page 4

5 que le système informatique et se voit obligé de focaliser ses critères sur des éléments de catégorisation multilingues. Qualification de la sélection Comment comparer les données et/ou les services? Pour l utilisateur «HUMAN», l examen des diverses métadonnées collectées peut être long et fastidieux 2 mais il dispose de moyens cognitifs pour distinguer les données et choisir celles qui lui conviennent. L utilisateur «MACHINE» est rarement en capacité de comparer les services et de choisir automatiquement le plus pertinent. Il ne peut choisir que sur des critères précis : emprise ou nom de territoire, mots clés issus de thésaurus, éventuellement, critères qualités s ils sont renseignés de façon homogène (ce qui n est aujourd hui jamais le cas). La pertinence du résultat d une requête automatisée dépend de la précision de renseignement des métadonnéesil serait intéressant de ce point de vue d obtenir plus d information sur les opérations réalisées au préalable sur les données et les métadonnées géologiques (OneGeology) ou sur les PLU (Plan4All) pour que le moissonnage permette de récolter des fiches de métadonnées pertinentes et pour que les données soient comparables. Présélection des données, effort de renseignement de mots clés particuliers prédéfinis permettant de s assurer que les données sont comparables, effort de standardisation et d adoption d un thésaurus particulier? Une grosse différence entre les usages «MACHINE» et les usages «HUMAN» concerne par exemple la qualification des données. Un utilisateur interprète la mention «données exhaustives en Saône-et-Loire et dans la Nièvre, mais pas en Côte d Or ni dans l Yonne», mais pour qu une machine puisse exploiter cette information, il faut séparer la fiche de métadonnées valable pour la Bourgogne en 4 fiches, une par département et renseigner un taux d exhaustivité sous forme de pourcentage (ayant la même définition) pour chaque département. Ceci permettra à un logiciel de sélectionner les PLU de Saône et Loire et de la Nièvre, mais pas ceux des deux autres départements. Ceci suppose d ailleurs que tous les organismes renseignent le taux d exhaustivité de la même façon : il est tout à fait licite de renseigner un taux d exhaustivité (99 %) ou un taux de carences (1 %) : le logiciel ne sera pas capable de distinguer l un de l autre dans la situation actuelle (c est un élément textuel qui dit comment interpréter le taux. Comment savoir si divers lots de données ou services provenant de divers territoires sont homogènes et peuvent être assemblés? Ceci ne peut être fait que dans la mesure où des métadonnées très complètes ont été renseignées, incluant les catalogues d attributs et les valeurs d attributs. Il faut en effet que ceux-ci soient «compatibles», «comparables» et n est donc possible que si les données sont standardisées. Les modèles de données standardisés liés aux annexes INSPIRE en cours d approbation vont dans ce sens, mais dans combien de temps seront-ils généralisés? 2 le 3 décembre 2010, il y avait 24 fiches de métadonnées répondant au critère PLU dans le géocatalogue, combien y en aura-t-il le 3 décembre 2011? Dans ces 24 fiches, peu concernaient réellement des zonages de PLU, de nombreuses fiches concernant des inventaires de PLU dressés par les DDT (listes des communes de leur département qui ont un PLU) ou des données faisant référence au PLU. Groupe OGC AFIGEO / FOF du H2H au M2M - AFIGEO_OGC_M2M_V5.doc 04/05/ Page 5

6 Utilisation Comment assembler divers services et/ou lots de données? Ici encore, différence importante entre «HUMAN», qui peut définir une configuration à la carte, service par service et homogénéiser jusqu à un certain point la présentation des données et «MACHINE» qui n est pas en mesure de résoudre ce problème sans intervention humaine, sauf si des critères de présentation ont été associés aux services (SLD), et si les données sont homogènes. Il semble que OneGeology ait fait la preuve de la possibilité d appliquer un même service de présentation à des données partiellement hétérogènes (noms d attributs thématisés différents par exemple). Commentaires Dans tout ce qui précède, apparaissent des problèmes d interopérabilité à divers niveaux : problèmes d interopérabilité technique :, compatibilité ascendante des versions d interfaces, maturité des outils de validation des protocoles d interopérabilité (cf. les efforts de l OGC CITE conformance testing ), coûts d évolution des systèmes (par exemple la question de la migration d un parc de navigateurs Web cf. Javascript, HTML 3/4/5, ) problèmes d interopérabilité d ordre sémantique : d une part, différents utilisateurs décrivent les mêmes données sur des territoires différents avec des mots clés hétérogènes, d autre part, les mots clés et descripteurs renseignés dans les métadonnées ne sont pas compris de la même façon par les utilisateurs qui consultent. Bien entendu, ceci peut arriver avec des mots clés spécifiques, mais aussi avec des thésaurus. Les mots clés spécifiques sont utilisables par des utilisateurs humains, plus difficilement par des systèmes informatiques, mais les mots clés standardisés par des nomenclature devraient pouvoir être utilisés par les deux catégories d utilisateurs. problèmes d ordre linguistique : la confrontation des mêmes concepts exprimés dans plusieurs langues peut poser des problèmes (à un concept dans une langue peuvent correspondre pour partie plusieurs concepts voisins dans une autre langue) et l exploitation combinée de ces concepts pose des problèmes au requêteur (lancer des requêtes multilingues) problèmes d ordre organisationnel? Ce sont là les enjeux majeurs en matière d interopérabilité, notamment sémantique. Les organisations humaines en charge de ces problématiques, comme l OGC ou INSPIRE, n existent que par leurs contributeurs, qui doivent réaliser des investissements initiaux conséquents pour tirer parti sur le long terme des gains de l interopérabilité. Mais ils doivent aussi se structurer en interne pour induire ces efforts dans leurs processus métier. Un bon exemple concerne la définition de profils applicatifs sur la base de standards existants (cf. INSPIRE et les standards OGC). Ces profils, pour être pérennes, doivent être portés par l organisation au sein du processus de standardisation (et non pas rester confidentiels au sein de la communauté). Groupe OGC AFIGEO / FOF du H2H au M2M - AFIGEO_OGC_M2M_V5.doc 04/05/ Page 6

7 Les problèmes évoqués semblent montrer que l objectif de faciliter la mutualisation entre les acteurs peut être atteint, même avec une faible standardisation des données, services et métadonnées, mais que l objectif d interopérabilité entre les systèmes est beaucoup plus difficile à atteindre sans un niveau supplémentaire de standardisation, en cours de spécification dans le cadre d INSPIRE, mais qui ne produira probablement pas d effets avant une dizaine d années.. Les questions de licences et d autorisation d accès ne sont pas un problème marginal, et peuvent en particulier bloquer les actions de type MACHINE (ce n est en général pas le système informatique qui clique dans la case acceptant les conditions ). La problématique est de deux types : autoriser l accès à des services ou données (approche basée sur le rôle) ou éviter la diffusion incontrôlée des données (approche basé sur les licences). L OGC a globalement tardé à prendre en considération les questions de sécurité et d accès. Sur le thème de l accès, qui est crucial pour permettre l interopérabilité des services, l OGC propose à travers un Best Pratice document l adoption du Standard Internationnal WS-Security publié par l organisme OASIS. Sur le thème des licences, les initiatives OGC sur GeoDRM semblent enlisées pour l instant. A noter toutefois que la majeure partie des données concernées par INSPIRE pourront être exonérées de cette procédure. PISTES DE REFLEXIONS ET SOLUTIONS A ETUDIER Des solutions améliorant la définitions d'ontologies ou l'amélioration des services de recherche sont en grande partie déjà arrêtées dans le cadre du dispositif INSPIRE, que ce soit par les spécifications déjà adoptées ou en cours de discussions, ou les obligations portées par le règlement Téléchargement avec l'enchaînement des opérations : décrire une série de données géographiques + accéder à un objet géographique + décrire un type d'objet géographique. Toutefois, ces solutions ne seront dans notre environnement quotidien que d'ici dix ans. Les avis sont partagés sur la capacité de ces solutions à résoudre les problèmes évoqués. Pour certains, la question est surtout : que pouvons-nous faire pour accélérer leur mise en place? D autres se demandent s il sera suffisant d imposer une ou plusieurs ontologies, de mettre au point des services de recherche plus élaborés, et de standardiser le nommage des métadonnées et les mots clés, même si ces dispositions peuvent apporter des améliorations significatives. Faut-il étudier d autres moyens techniques utilisés dans des contextes «machine to machine» : outils de tri de l intelligence économique, autres (futurs) standards de WEB Services Ce point reste à développer. POUR PLUS D INFORMATION Le projet GIGAS (GEOSS, INSPIRE and GMES an Action on Support) GIGAS est un projet Européen qui a étudié pendant prés de deux ans, l ensemble des opportunités et problématiques de l interopérabilité entre les initiatives GEOSS, INSPIRE et les projets GMES. L ensemble des Technology Watch Reports sont disponibles sous : Contributeurs : Arnaud CAUCHY, François ROBIDA, François SALGE, Henri PORNON (contributeur initial), Hervé CAUMONT, Marc LEOBET, Nicolas KLEIN Groupe OGC AFIGEO / FOF du H2H au M2M - AFIGEO_OGC_M2M_V5.doc 04/05/ Page 7