Voici l’épisode 2/3 de l’article « Human to Human » au « Machine to Machine » :

Problèmes identifiés

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 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.

COMPUTER. Aujourd’hui, un système informatique ne peut aller chercher des métadonnées que dans des catalogues dont on lui a fournit 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 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 19115 (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 19115 (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 que le système informatique et se voit obligé de focaliser ses critères sur des éléments de catégorisation multilingues.

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 mais il dispose de moyens cognitifs pour distinguer les données et choisir celles qui lui conviennent. L’utilisateur « COMPUTER » 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).  Il 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 métadonnées géologiques (OneGeology) ou sur les PLU (Plan4All) 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 « COMPUTER » 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. C’est lancé, mais cela ne sera probablement pas le cas pour une part significative d’entre elles avant une dizaine d’années.

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 « COMPUTER » 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.

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 égalementdes 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 (‘Humana’) et des systèmes informatiques (‘Machine’). Aujourd’hui, pour de nombreux géomaticiens, les métadonnées sont 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, 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 4 cas possibles dans le contexte des métadonnées et des ‘Web Services’ :

Contributeurs : Arnaud CAUCHY, François ROBIDA, François SALGE, Henri PORNON (contributeur initial), Hervé CAUMONT, Marc LEOBET, Nicolas KLEIN

Consulter la suite de l’article concernant les problèmes identifiés…