Documentation

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language - page fr wikipedia) est langage de requêtes. Il permet d’interroger, supprimer, modifier des données qui se trouve au format RDF (Resource Description Framework - page fr wikipedia). Il est apparu en 2008 et est un standard recommandé par le W3C. Comme le RDF, il repose sur l'utilisation des triplets. C'est-à-dire qu'une donnée est composée de trois informations: un sujet, un prédicat et un objet. À l'instar d'une phrase composée d'un sujet, d'un verbe et d'un complément, ici une donnée est répartie entre :

un sujet, la ressource à décrire

un prédicat, le type de propriété pour laquelle est applicable la ressource

un objet, une autre ressource ou donnée; la valeur de la propriété

exemple:

<http://dbpedia.org/resource/Yuri_Maltsev> dpb:birthDate <“1950-12-31”>

Il est possible de “traduire” ce triplet de la façon suivante: Yuri Maltsev (sujet) est né (prédicat) le 31 décembre 1950 (objet).

“dpb:” est un espace de nom qui dans lequel sont regroupés tous les types de ressources de dbpedia. Cela permet de faire en sorte que tout le monde utilise le même vocabulaire pour décrire des choses semblables.

vocabulaire de base à utiliser pour le langage de requête SPARQL:

PREFIX # définit des espaces de noms
SELECT # permet de choisir les variables du résultat, parmi les résultats de la clause WHERE
SELECT distinct # enleve les doublons parmi les couples
SELECT * # conserver toutes les variables de la requête
WHERE # contient des triplets qui définissent le pattern recherché
--------------------------------------------------------
FILTER # permet de mettre des conditions
GROUP BY # partitionner la solution en plusieurs groupes, sur lesquels on peut appliquer une fonction d’agrégat.
HAVING # Indique les valeurs lorsque les conditions sont respectés avec des agrégats de valeurs
BIND # sert à définir de nouvelles variables et à leur affecter une valeur.
LIMIT # permet de mettre une limite sur le nombre de résultats affichés
OFFSET # signifie qu’on ”passe” les n premières solutions.
OPTIONAL # on peut mettre des parties optionnelles, même lorsque qu'il ne pas de valeurs dans l'objet
SERVICE # permet d'agréger des points d'accès SPARQL
--------------------------------------------------------
ASK # retourne un booléen indiquant l’existence d’une solution qui satisfait le motif
CONSTRUCT # pour construire un graphe RDF solution, à partir des valuations des variables
DESCRIBE # retourne un graphe RDF décrivant les ressources trouvées. Le résultat dépend du service qui publie la donnée
INSERT # permet d'ajouter des données à un graph

Ce vocabulaire réalisé à partir du document de Caron Anne-Cécile, «sparql, Langage d’interrogation du web sémantique» dans le cadre du Master image parcours ipi-nt, 2016-2017.

Cette «anti-sèche» permet aussi de retrouver l'ensemble de la syntaxe du langage SPARQL.

Un document qui permet d'avoir toutes les clés en main pour comprendre le language SPARQL: Du Charme Bob, Learning SPARQL: querying and updating with SPARQL 1.1, Beijing, Chine, Pays multiples, 2011. Il est aussi possible de consulté le site de l'auteur, ainsi que son blog (ici l'ancienne version avec les articles avant Février 2019).

Exemple de requête SPARQL:

PREFIX foaf: <http://xmlns.com/foaf/0.1/> # exemple d'espace de nom (foaf pour Friend of a friend; vocabulaire qui permet de décrire les personnes)
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbp: <http://dbpedia.org/property/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT DISTINCT ?s ?name (year(xsd:dateTime(?Birth_Date)) AS ?year) #ce sont les variables que l'on veut afficher
# year permet de convertir une date (Année/Mois/Jour) en une année
WHERE
{?s a dbo:Person .
?s foaf:name ?name .
?s dbp:birthDate ?Birth_Date .
?s dbo:abstract ?abstract .
FILTER regex(?abstract, "lawyer") # la clause regex permet d'aller chercher dans les résumés ceux qui ont comme motif "lawyer"
FILTER (xsd:date (?Birth_Date) > "1800-01-01"^^xsd:date) # permet de ne garder que ceux qui sont nés après 1800.
}
ORDER BY (?year) #Cela ordonne les données par année de façon croissante
LIMIT 50 # c'est important quand on ne sait pas le nombre de résultat à afficher et qu'il peut être important

Ici, le but est d'afficher les juristes qui sont nés après 1800 avec leur nom. Il est possible de l’exécuter sur un point d'accès SPARQL.

Les points d'accès permettent d'accéder à des jeux de données.

Dans ce projet nous exécutons nos requêtes directement avec le language python. Pour cela, nous utilisons la bibliothèque SPARQLWrapper (il faut l'installer préalablement avec conda ou pip en ligne de commande sur un terminal).

Bien qu'il n'est pas possible d'associer différents jeux de données (provenant de sites différents) sur un même point SPARQL (pour des raisons de sécurité), il est possible de les fédérer via un système tiers (documentation W3C) sur le sujet. Nous avons fait le choix d'utiliser la version gratuite de GraphDB (documentation et lien de téléchargement), qui a une interface graphique permettant d'avoir un serveur local permettant notamment de faire des requêtes SPARQL fédérées. Pour les réaliser, il faut indiquer dans la requête les points d'accès que l'on veut utiliser en se servant de la clause SERVICE (voir le lien sur les requêtes fédérées pour l'utiliser correctement).

Il est là encore possible de faire les requêtes directement dans un carnet python. Pour cela, il faut utiliser l'API de GraphDB (documentation, plus précisement dans le serveur local, cela ce situe dans REST API -lui-même dans help- puis il faut choisir SPARQL puis expend operations- soit on choisie GET pour interroger les données ou POST pour les modifier. Il suffit ensuite de reporter le chemin -localhost:7200/webapi/repositories/{repositoryID} par exemple- dans le wrapper sur python).

Afin de vérifier si la syntaxe d'une requête est bien faite, il existe des outils:

query-validator

update-validator

ils vérifient uniquement si la requête est bien formulée mais cela ne permet pas de juger de la pertinence de la requête ou de sa réussite.

DBpedia

DBpedia est une projet participatif d'extraction de données structurées à partir de différents projets Wikimedia (c'est avant tout pour extraire les données de Wikipedia), débuté en 2007 par l'université libre de Berlin et l'université de Leipzig. Ce projet s'inscrit dans la démarche du linked data imaginé par Tim Berners-Lee. Le but étant de permettre que les données soient visibles aussi bien par des êtres humains que par des machines. Les données sont encodées au format RDF. Cette base de données peut ensuite être interrogée au moyen d'un langage SQL tel que SPARQL.

Au prémisse du projet, l'objectif de DBpedia était de récupérer toutes les données qui sont contenues dans les infoboxes (c'est une table de données résumant les informations essentiels dans une fiche Wikipedia) de Wikipedia. Ensuite, ils ont aussi récupérer diverses données comme le résumé ou bien tous les liens présents sur la pages. Ils ont pu aussi rajouter d'autres liens vers des fiches d'autres sites ou bases de données. Cette extraction (via l'extracteur MARVIN) se faisait au début du projet tous les ans, mais aujourd'hui ils arrivent à extraire l'ensemble des données de Wikipedia chaque mois. De plus actuellement, à chaque étape de l'extraction jusqu'à la publication, il y a une validation sur la plateforme Databus afin de corriger la syntaxe RDF, etc.

Voici le schéma complet du cycle de mis à jour de DBpedia:

schéma du cycle de mis à jour de DBpedia Source: Hofer M., Hellmann S., Dojchinovski M., Frey J., The New DBpedia Release Cycle: Increasing Agility and Efficiency in Knowledge Extraction Workflows, dans: Blomqvist E. et al. (eds) Semantic Systems. In the Era of Knowledge Graphs. SEMANTICS 2020. Lecture Notes in Computer Science, Springer, Cham, 27 octobre 2020. (DOI:10.1007/978-3-030-59833-4_1)

Il faut ajouter à cela que DBpedia a en plus une version par langue, appelées chapitres afin d'internationaliser au mieux DBpedia. C'est le cas du français.

De plus, il y a une version qui est mise à jour à chaque modification sur Wikipedia. Cette dernière ne se base que sur le Wikipedia anglais.

Parallèlement à ça, ils ont créé une ontologie afin de structurer hiérarchiquement l'ensemble des données. Cette ontologie se fait suite à l'extraction des données à partir de cette dernière, mais ils gardent accessible l'extraction initiale des ressources. L'ontologie s'appuie aussi ce que qui a été fait par schema.org (vocabulaire pour lier les données du web, créés par Google, Microsoft, Yahoo et Yandex) pour améliorer leur ontologie. DBpedia s'est aussi très récemment associé à Diffbot qui permet d'extraire des données structurées à partir de données non-structurées (TAL - Traitement automatique des langues) (lien vers la source).

Il est possible de voir la structure de l'ontologie, ainsi que les instancesici avec des graphs dynamiques.

Nous avons donc dans DBpedia des classes (exemple) et des propriétés (exemple). Mais aussi, nous avons des ressources simples (exemple) qui peuvent jouer le rôle d'instance.

Pour aller plus loin dans la compréhension de DBpedia, il est possible de lire de lire cette article sur la dernière mise à jour parue: Hofer M., Hellmann S., Dojchinovski M., Frey J., The New DBpedia Release Cycle: Increasing Agility and Efficiency in Knowledge Extraction Workflows, dans: Blomqvist E. et al. (eds) Semantic Systems. In the Era of Knowledge Graphs. SEMANTICS 2020. Lecture Notes in Computer Science, Springer, Cham, 27 octobre 2020. (DOI:10.1007/978-3-030-59833-4_1)

Vous retrouver ici la liste des espaces de noms (wikipedia fr) utilisés par DBpedia.

L'accès direct au point d'accès SPARQL de DBpedia, ainsi que de la version live et la version française.

BnF Data

BnF Data est une base de données permettant de rendre accessible les données de la Bibliothèque nationale de France, issues de Gallica (portail des numérisations de la BnF), du catalogue général de la bibliothèque, ainsi que d'Archives et manuscrits (catalogue dédié aux archives et au manuscrits des différents fonds de la BnF). Le projet a pour but de fournir des données structurés interprétables par des machines mais aussi lisibles par des humains, afin là aussi d'être dans les principes du linked open data. Les données sont encodées dans le format standard RDF. Cela implique qu'à chaque ressource un URI lui est associé, c'est le mécanisme ARK.

De plus, une partie des données est alignée sur d'autres référentiels et jeux de données comme DBpedia (à noter que c'est le DBpedia français et non le DBpedia global) et VIAF.

Modèle utilisé par BnF Data

BnF Data utilise aussi une modèle pour son fonctionnement. Ce modèle s'intitule FRBR (Functional Requirements for Bibliographic Records). Il a été développé par l'IFLA en 1998 afin de répondre aux besoins de bibliothèques en matière de modélisation mais il a évolué ensuite en deux modèles distincts le FRBRer et le FRBRoo. le FRBRer est le FRBR initial mais dont le nom a été modifié par commodité afin de la distinguer du FRBRoo. Il intègre aussi par le suite le FRANAR (Functional Requirements and Numbering of Authority Records) en 1999 et le FRSAD (Functional Requirements for Subject Authority Data model) en 2005 permettant d'intégrer des autorités. Le FRBRoo, quand a lui est issu d'un groupe de travail entre l'IFLA et le Cidoc CRM.

Les distinctions entre les deux modèles sont les suivantes:

Tout d'abord, le FRBRer est qualifié d'Entité Relation tandis que le FRBRoo est qualifié d'Orienté Objet afin de le placer dans le cadre du Cidoc CRM.

Ensuite dans le FRBRoo les entités deviennent des classes, les attributs et les attributs deviennent des propriétés. De plus, chaque classe ou propriété a un URI.

Enfin on ne parle d'ontologie que pour le FRBRoo.

Ce billet de blog d'Etienne Cavalié résume très bien la distinction qui est faite entre les deux modèles (l'échange de commentaires entre Etienne Cavalié et Patrick Le Boeuf en fin de blog est aussi intéressant).

Vous pouvez avoir ici les différentes version du FRBRoo.

Il faut ajouter à cela un autre modèle, le IFLA LRM (Library Reference Model), initié en 2017 qui a pour but de corriger certaines incohérences du FRBRer en créant un modèle commun au FRBRer, FRANAR et FRSAD. La présentation du modèle est disponible sur cette page. L’intégralité du modèle est disponible ici.

Le FRBR (dans ses deux modèles) a pour but de modéliser les données bibliographiques. Pour cela, il y a quatre niveaux pour délimiter les œuvres:

L'œuvre : C'est le niveau de la création, ex: Le seigneur des anneaux de Tolkien.

L'expression: Cela rassemble les différentes versions du même œuvre, un abrégé, une traduction. ex: la traduction française du seigneur des anneaux.

La manifestation: C'est la matérialisation d'une expression, comme une édition. ex: le Le Hobbit « Édition Deluxe illustrée par J.R.R. Tolkien, Christian Bourgois Édition».

L'item: C'est l'exemplaire. ex: Le seigneur des anneaux de Tolkien dans la bibliothèque de ma grand-mère ou bien le manuscrit Français 1158 conservé à la BnF au Département des Manuscrits.

Ces différents niveaux sont mis en relation à des personnes ou des collectivités. Auxquels, on peut ajouter des lieux, des événements, des concepts et des objets.

Schéma du modèle FRBR utilisé par la BnF:

Schéma FRBR

Source : Bénézet Joly, http://slideplayer.fr/slide/3213771/.

Liens utiles

Vous pourrez retrouver sur cette page l'ensemble du fonctionnement de BnF Data, c'est à dire le modèle employé, les alignements réalisés, ainsi que les espaces de noms utilisés.

La mission de BnF Data est résumée sur cette page.

L'accès au terminal SPARQL de BnF Data.

VIAF

VIAF (Virtual International Authority File) est un fichier des autorités internationales qui a pour but d'identifier les personnes ou les organisations qui se trouve dans d'autres fiches d'autorités. Cela permet aussi de les mettre en relation par un identifiant URI VIAF. Il est au cœur de la démarche du web sémantique et du linked open data. Pour ce faire, les fiches réalisés en RDF.

Le VIAF a été initié en avril 1998 par la Library of Congres, la Deutsche Nationalbibliothek et le OCLC. La Bibliothèque nationale de France a rejoins le contortium en 2007. Ces dernières sont les principales décisionnaire du projet. Le projet est aujourd'hui porté par de nombreuses institutions (61 en 2017) mais il est mis en œuvre et hébergé par le OCLC (Online Computer Library Center).

Cette page donne accès à de la documentation sur VIAF.

La page wikipedia (fr) du VIAF notamment pour connaître les bibliothèques partenaires.

VIAF Guidelines permet de connaître les points importants dans les missions et le fonctionnement de VIAF (il est aussi intéressant car ils donnent aussi les problèmes qui peuvent être rencontré).

VIAF utilise plusieurs espaces de noms pour fonctionner:

VIAF

OWL

SKOS

FOAF

FRBR

DC terms

Schema.org

UMBEL (ce dernier a été retiré en 2019 et son domaine vendu)

Le VIAF est utile dans notre projet, Les URI qu'ils utilisent sont employées à la fois par DBpedia et par BnF data. Donc il est utile pour faire le lien entre les deux.

Cette page donne accès à l'API de VIAF.

En 2014, différents changements dans le vocabulaire et des ajouts. Ils ont notamment changer certains espaces de noms pour prendre ceux de schema.org.

En 2016, des changements ont été opérés dans l'API de VIAF.

Ex: Notice au format json de John Maynard Keynes

Cette page explique comment le VIAF fonctionne ( Attention: Elle n'a pas été mise à jour depuis 2010).

Ils semblent qu'ils aient réalisé une ontologie mais qu'elle est, à ce jour plus exploitée, ou bien qu'elle ne soit publique (mais depuis 2011, il y a aucune documentation sur elle). Vous trouverez l'ontologie comme elle a été imaginée.

Github

Les différents carnets créés durant ce projet sont disponibles sur ce dépôt Github. Ils permettent de prendre connaissances de la façon dont nous avons procéder pour extraire des informations sur les économistes et les juristes et comment nous les avons traités ensuite.

Github nous permet de pouvoir faire des mis à jour sans impacter le travail des autres et pour voir une trace de toutes nos modifications (et d'éventuellement revenir à une version antérieure). Il fonctionne avec le langage Git.

Nous avons eu aussi recours à Github desktop (le site n'indique que les versions Windows et Mac mais il est aussi disponible sur Linux) afin de transmettre les carnets de nos machines vers Github.

Nous utilisons aussi une extension de Jupyterlab pour avoir Git, de même que nous utilisons une extension pour avoir Github.

Le recours à une clef SSH est aussi utile pour se connecter de façon sécuriser depuis une machine local vers Github.

Cette clef est en deux parties:

Une clef publique disponible par tous

Une clef privée est secrète

Il faut pour cela créer une clef privée sur une machine locale puis ensuite reporter la clef publique sur Github. Cela fonctionne à la fois sur Windows, Mac et Linux.