L’OGC, fondé en 1994, a pu apparaître initialement comme un cercle réservé à quelques experts et spécialistes anglophones concevant, rédigeant et testant au sein de groupes techniques (Standards Working Groups ) des spécifications permettant de développer l’interopérabilité géospatiale.

Ces dernières années, de nombreux groupes thématiques (Domain Working Group) ont été créés et permettent d’adresser des besoins spécifiques aux thématiques considérées en s’appuyant et si besoin étendant sous forme de profils les spécifications élaborées au sein des groupes techniques.

La forte croissance de l’OGC tant en nombre de membres qu’en centres d’intérêts et spécifications rédigées a conduit à la création de plusieurs comités (Committees) visant à renforcer la gouvernance et la cohérence de l’OGC, par exemple l’OGC Architecture Board (OAB) ou le Strategic Member Advisory Committee (SMAC).

Le dernier-né de ces comités est le Business Value Committee (BVC) présidé par Marge Cole, US National Aeronautics and Space Administration (NASA).

Continue reading »

Tagged with:
 

L’activité de beaucoup d’entre nous est aujourd’hui mobilisée par la mise en œuvre de la Directive Inspire, et l’obligation que les acteurs publics ont de respecter la lettre de la loi. Les difficultés de lecture, d’interprétation et de mise en œuvre opérationnelle du texte de la Directive ne doivent cependant pas nous faire oublier le but du jeu !

Car de quoi est-il question avec INSPIRE ? Pour avoir participé depuis 2003 au groupe d’experts de la Commission Européenne chargé de préfigurer INSPIRE, j’avoue que j’ai parfois du mal à retrouver l’esprit derrière la lettre.

Continue reading »

Tagged with:
 

Utiliser des données 3D dans un objectif de les visualiser amène à travailler sur la notion de représentation de la donnée. Une même donnée peut en effet, dans le cadre des SIG, avoir différentes représentations (le mot « portrayal » est souvent employé). Si nous prenons l’exemple d’un arbre, il est possible de lui affecter plusieurs niveaux de détails permettant d’aller d’une représentation 3D simplifiée à une représentation très réaliste. Il est aussi possible d’utiliser une symbolique de représentation comme en cartographie ; l’arbre serait alors représenté par un icône ou un point dont la couleur pourrait par exemple dépendre de  son essence. Le client devra donc demander un objet en spécifiant le type de représentation voulu ; le serveur devra analyser cette requête et renvoyer les objets liés.

Continue reading »

Tagged with:
 

Voici la suite et fin de l’article « Human to Human » au « Machine to Machine » (voir plus bas l’épisode 1 « mise en contexte » et 2 « problèmes rencontrés »).

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 migrations 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é).

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.

Les questions de licences et autorisation d’accès ne sont pas un problème marginal, et peuvent en particulier bloquer les actions de type COMPUTER (ce n’est en général pas lui 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 licenses). 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 réflexions et solutions à étudier

Faut-il imposer une ou plusieurs ontologies ? Mettre au point des services de recherche plus élaborés ? Standardiser le nommage des métadonnées et les mots clés ?

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, 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 :

  1. Décrire une série de données géographiques
  2. Accéder à un objet géographique
  3. Décrire un type d’objet géographique.

Toutefois, ces solutions ne seront dans notre environnement quotidien que d’ici dix ans.

La question est donc : que pouvons-nous faire pour accélérer leur mise en place ?

Étudier les moyens techniques utilisés dans des contextes « computer to computer » : ontologies, outils de tri de l’intelligence économique, autres (futurs) standards de WEB Services… Ce point reste à développer.

Pour plus d’informations

Le projet GIGAS (GEOSS, INSPIRE and GMES an Action on Support)

http://www.thegigasforum.eu/project/project.html

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 :

http://www.thegigasforum.eu/project/material/deliverables.html

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

Tagged with:
 

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.

Vérifier comment on peut 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). Cf. OneGeology

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

Consulter la suite concernant les pistes de réflexions…

Tagged with:
 

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

Tagged with: