Le web des données est-il vraiment ouvert ?

2018-05-31

Principe

Le web des données, aussi connu sous le dénominatif plus parlant Linked Open Data, doit permettre la réutilisation d’information distante, évitant ainsi les redondances. Autrement dit, on n’est pas obligé de stocker localement (par exemple, dans une instance de LODEX, mettons placename-entity) des informations qu’on peut retrouver ailleurs simplement en référençant ces informations (via une URI, ou clé étrangère dans le langage des bases de données relationnelles). Une URI est un identifiant universel (Uniform Resource Identifier), qui sert justement à lier des concepts, distants ou non.

Le projet ISTEX-LOD a entrepris de décrire des jeux de données extraits d’ISTEX, notamment en alignant ces données avec d’autres référentiels. Dans un premier temps, nous avons choisi de représenter des entités géographiques administratives. L’avantage est de profiter des données de GeoNames, décrites en RDF.

Pour afficher des données distantes liées par une URI, nous avons mis en place un format LODEX appelé SPARQL Texte. Ce format permet d’afficher dans une instance de LODEX les données ramenées d’un triple store distant, via une requête SPARQL adressée à son SPARQL EndPoint (son API).

Écueils

SPARQL EndPoint inexistant

Malheureusement, GeoNames n’a pas de SPARQL EndPoint.

Deux solutions possibles :

  1. charger un dump de GeoNames (l’intégralité des données GeoNames au format RDF) dans notre triple store, le rendant disponible via notre SPARQL Endpoint, mais dans ce cas ce ne sont plus des données distantes, c’est à nous de nous assurer de la fraîcheur des données,
  2. trouver un SPARQL EndPoint non affilié à GeoNames contenant les données nous intéressant.

ISTEX-LOD a choisi la deuxième solution, recensant quelques SPARQL EndPoints pertinents :

  • la BNF (mais les données GeoNames semble n’y concerner que la France)
  • DBPedia (mais les informations ne sont pas toujours exactes)
  • Wikidata
  • Factforge
  • GeoSPARQL
  • etc.

Pour autant que nous avons pu en juger, quand un organisme choisit d’intégrer des données GeoNames, il sélectionne seulement une partie de ces informations, ou bien il ne les met pas à jour régulièrement.

Protocoles HTTP/HTTPS incompatibles

Lors de nos premiers essais, tout s’est bien passé, nous utilisions notre propre SPARQL EndPoint : https://data.istex.fr/sparql/. De même lorsque nous avons attaqué celui de l’ABES : https://lod.abes.fr/sparql.

C’est quand nous avons essayé ceux de la BNF (http://data.bnf.fr/sparql) ou de Wikipédia (http://dbpedia.org/sparql, http://fr.dbpedia.org/sparql) que nous avons été confrontés à un comportement inattendu du navigateur.

Quand un navigateur web sert une page via le protocole https, il bloque les requêtes que fait cette page à des serveurs exposant leurs données en utilisant un protocole moins sûr (http, en l’occurrence).

Les sites data.istex.fr sont servis avec le protocole https, point normalement positif : cela expose à moins de risques, mais limite sérieusement les appels à des serveurs en http.

Nous allons mettre en œuvre un contournement permis par le fait que data.istex.fr est aussi servi en http (même s’il n’est pas le protocole par défaut) : dans ces cas, on peut recharger la page en http, et le navigateur arrête de bloquer les réponses.

Authorization gênante

Pour faire n’importe quelle requête à une API (et donc SPARQL aussi), LODEX envoie un entête HTTP d’Authorization. Mais cet entête superflu est gênant pour les SPARQL EndPoints qui peuvent accepter des utilisateurs authentifiés (qui ont alors plus de droits). Dans certains cas, les SPARQL EndPoints refusent de répondre à une requête dont ils ne reconnaissent pas l’utilisateur.

C’est là un problème au niveau de LODEX, que nous allons corriger.

CORS – Cross-origin resource sharing

Les requêtes venant d’un nom de domaine (placename-entity.data.istex.fr) et allant vers un autre nom de domaine (factforge.net) sont, pour des raisons de sécurité, bloquées quand elles ne respectent pas le standard CORS (voir la documentation de Mozilla à ce sujet).

Là encore, nous devons nous atteler à mieux respecter ce standard dans LODEX.

Unsupported Media Type

La plupart des SPARQL EndPoints interrogés retournent des résultats exprimés en JSON. C’est d’ailleurs le format demandé par les requêtes (header HTTP Content-Type: application/json).

L’API de GeoSPARQL réclame une autre sorte de format (header HTTP Accept: application/sparql-results+json) et renvoie donc une erreur HTTP 415 Unsupported Media Type : application/json.

Synthèse

Le tableau suivant synthétise les erreurs que nous avons rencontrées (ce qui signifie qu’une cellule blanche dans ce tableau représente un cas où aucun problème n’a été relevé).

Requête

SELECT *
WHERE {
 ?s ?v ?c
}
LIMIT 1
La requête SPARQL utilisée est la plus simple qui renvoie un triplet, pour être certain que c'est possible

Environnements

  • Formulaire ad hoc : ce sont les formulaires d’interrogation SPARQL proposés par les SPARQL EndPoints eux-mêmes (en général à la même URL). On s’attend à ce que ce soit le cas qui marche le mieux (on notera un léger problème pour sparql.org, sans doute dû au graphe nommé par défaut, car dès qu’on tente une requête adaptée à son contenu, il fonctionne).
  • http://yasgui.org : le démonstrateur de YASGUI (un client web universel pour SPARQL), où un proxy pour contrer les problèmes de CORS est utilisé (voir le dépôt GitHub).
  • YASGUI http : l’interface YASGUI installée sur le nom de domaine data.istex.fr, utilisant le protocole HTTP http://data.istex.fr/triplestore/sparql
  • YASGUI https : l’interface YASGUI sur le nom de domaine data.istex.fr, utilisant le protocole HTTPS https://data.istex.fr/triplestore/sparql
  • LODEX http : une instance de LODEX locale, avec le protocole HTTP
  • LODEX https : une instance de LODEX utilisant le protocole HTTPS

Légende des erreurs

  • AUTH : authorization gênante (ex: Request header field Authorization is not allowed by Access-Control-Allow-Headers in preflight response.)
  • CORS : Cross Origin Resource Sharing (ex: Failed to load https://babelnet.org/sparql/: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘https://data.istex.fr’ is therefore not allowed access.)
  • HTTPS : protocoles incompatibles (ex: Mixed Content: The page at ‘https://data.istex.fr/triplestore/sparql/’ was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint ‘http://dbpedia.org/sparql’. This request has been blocked; the content must be served over HTTPS.)
  • Media : mauvais MIME-Type (ex: Error 415: Unsupported: application/json)
Erreurs rencontrées
Environnement
SPARQL EndPoint
Formulaire ad hoc http://yasgui.org YASGUI http YASGUI https LODEX http LODEX https
BNF HTTPS HTTPS
DBPedia HTTPS AUTH HTTPS
DBPedia.fr HTTPS HTTPS
FactForge CORS HTTPS CORS HTTPS
WikiData AUTH AUTH
BabelNet CORS CORS CORS CORS CORS
GeoSPARQL HTTPS Media HTTPS
sparql.org ~ CORS HTTPS CORS HTTPS
Persée HTTPS HTTPS
ISIDORE CORS CORS HTTPS CORS HTTPS
HAL CORS CORS HTTPS CORS HTTPS
ABES

L’équipe de développement de LODEX va s’attacher à corriger dans l’ordre :

  1. HTTPS (par contournement)
  2. CORS (en collant mieux au standard, et peut-être en mettant en place un serveur proxy)
  3. AUTH (en n’envoyant plus les headers Authorization)
  4. Media (en adaptant les headers).

D’une manière générale, nous avons l’impression que les organismes qui mettent en ligne des données liées ouvertes se sont préoccupés principalement de diffuser les informations. Souvent ils l’ont fait en important des dumps dans leur triple store, et rarement ils ont vérifié les liens de leurs données avec des données non locales, en interrogeant des SPARQL EndPoints distants.