Dans un billet précédent, j’avais commencé à envisager l’évolution de la base de données relationnelle des auteurs de langue bretonne du projet PRELIB afin de mieux gérer la saisie des données temporelles. Mais au delà de ce problème, ce pose la question du stockage dans une base de donnée relationnelle et le passage au web sémantique.
Je m’intéresse depuis 2012 au web sémantique mais j’avais du mal à passer à la pratique faute d’avoir trouvé un outil de publication en RDF bien documenté et des vocabulaires ou des ontologies permettant d’exprimer nos données biographiques en RDF.
Concernant les outils, j’avais découvert en 2013 le logiciel Open source Callimachus en lisant le livre Linked Data co-écrit par David Wood (livre dont je vous recommande la lecture que je trouve plus digeste que celle du livre en français Le web sémantique), mais la documentation de Callimachus n’était pas assez aboutie à l’époque et je n’ai pas su comment l’utiliser pour mes besoins. J’avais aussi repéré CubicWeb un outil en Python sur lequel repose data.bnf.fr. Mais son installation s’est avérée trop compliquée sous Windows et je n’ai pas pu le tester. Sans compter là encore sur une documentation peu aboutie.
D’un autre côté, la plateforme DataLift, que j’ai rapidement testée la semaine dernière, permettrait dans un premier temps de transformer les données relationnelles en RDF. Je conserverai le stockage des données dans la base de données relationnelle mySQL, mais elles seraient “libérées” de la base sous la forme d’un export en RDF (et interrogeables à travers un SPARQL Endpoint ou REST + RESTdesc ? A voir).
Pour découvrir DataLift, je vous conseille de visionner la vidéo de démonstration de Gabriel Kepeklian où il se sert de DataLift pour sémantiser en quelques clics un fichier CSV des emplacements des kiosques à journaux mis à disposition sur ParisData. C’est plutôt convaincant.
Du côté des vocabulaires, j’avais identifié FRBR pour la saisie des œuvres littéraires mais j’avais du mal à en trouver une pour exprimer les données biographiques jusqu’à ce que j’entende parler fin 2014 de CIDOC CRM grâce au projet Biblissima.
Une lecture récente de documents sur le CIDOC CRM m’a également permit de comprendre que FRBRoo (FRBR object oriented) était une extension du modèle du CIDOC et que je devais plutôt m’intéresser à FRBRoo qu’à FRBR pour exprimer en RDF les données de ma base concernant la production littéraire.
L’objectif, au printemps 2015 est donc d’essayer de voir comment exprimer les données avec le CIDOC CRM et FRBRoo puis de convertir les données de la base de données relationnelles avec DataLift afin de comparer les requêtes SPARQL avec des requêtes SQL, de faire des essais d’analyse de réseau à partir de ces données RDF et de vérifier si le web sémantique permet réellement d’inférer de nouvelles connaissances (peut-être l’aspect le plus intéressant du web sémantique) en mettant en pratique l’article Bringing reasoning to the Web de Ruben Verborgh.
Vous pouvez télécharger le PDF du Schéma conceptuel de la base de données PRELIB au 23 octobre 2014. Ce n’est certainement pas un modèle à suivre pour la conception d’une base de données relationnelle mais il me servira de référence pour RDFiser la base de données par étapes successives.
Pour commencer, où peut-on trouver des informations sur le CIDOC CRM ?
Le site officiel du CIDOC CRM (version du 17 avril 2015) est la source de référence mais est un peu fouillis. L’information est dispersée dans de multiples sous-rubriques où l’on a un peu de mal à se retrouver. Mais j’ai découvert un peu par hasard qu’une nouvelle version du site est en chantier à cette adresse http://139.91.183.82:8888/drupal/ où l’excellent CIDOC-CRM Tutorial et la version HTML du manuel de référence de la version 6.0 du CRM (sortie en février 2015) sont mieux mis en avant.
SI vous êtes intéressés par la version PDF du manuel de référence (200 pages) de la version 6.0, il est disponible depuis la page Official Release of the CIDOC CRM où vous trouverez également un lien vers l’expression en RDF Schema du modèle (à consulter aussi sur LOV, Linked Open Vocabulary).
Le manuel faisant 200 pages, vous aurez une meilleure introduction au CRM en lisant le document d’introduction (les anglophones appellent ce type de document des “primer”) ou si vous avez du temps devant vous, en visionnant les vidéos du CIDOC-CRM Tutorial.
Pour vous y retrouver dans les multiples entités et propriétés du modèle, vous pouvez aussi consulter des représentations graphiques de la version 5.0.4 du modèle : La version complète et la version réduite.
Toutes ces ressources sont en anglais. Le seul document de référence en français sur le CIDOC CRM est la traduction de la norme ISO 21127 (la normalisation ISO du CIDOC CRM) dont la lecture vous coutera 198 francs suisses sur le site de l’ISO ou 157 euros sur la boutique en ligne de l’Afnor.
Il faut noter au passage que le CIDOC CRM est un modèle et qu’il n’impose pas de langage pour exprimer les données. Je pourrai donc tout aussi bien adapter ma base de données relationnelle pour qu’elle repose sur le modèle, rien ne m’oblige à utiliser le RDF sinon mon intérêt pour ce format et le web sémantique. Il est néanmoins dommage que l’on ne trouve pas d’exemples de données exprimées en RDF sur le site officiel du CIDOC CRM alors que le Dublin Core Metadata Initiative l’a fait pour le Dublin Core dans deux guides utilisateurs publiés sur son wiki.
Table “Personne” de la base de données relationnelle PRELIB
Essayons d’appliquer le modèle CIDOC CRM à la base de données en commençant par la table “Personne” qui stocke des informations sur des individus. L’entité qui correspond le mieux à cette table est E21 Person. Dans le futur site du projet, chaque individu va devenir une ressource RDF de type E21 Person accessible à partir d’une URI construite à partir de la clé primaire de la table “Personne”. Par exemple, les informations sur Théodore Hersart de la Villemarqué, qui a pour clé primaire id_personne = 80 dans la table “Personne” pourra être accessible à l’URI http://prelib.huma-num.fr/person/80. Notez que vous pourrez récupérer depuis cette URI, soit du contenu en HTML sur Théodore si vous la consultez avec votre navigateur web, soit du RDF si vous vous connectez avec une application telle ARQ pour faire des requêtes SPARQL.
Une première lecture de la référence à E21 Person dans le manuel de référence peut donner l’impression que l’entité n’a qu’une seule propriété P152 has parent. Ne peut-on que donner des informations sur les parents d’un individu avec CIDOC-CRM ?
Que neni.
En effet, en consultant la représentation graphique des entités et des modules disponibles pour signifier l’existence d’un objet ou d’une personne (reproduite ci-dessous), on se rend compte qu’il existe une propriété P98 brought into life qui permet de lier la personne à une ressource de type E67 Birth. Notez au passage que le sens de la flèche entre E67 Birth et E21 Person indique que P98 brought into life est une propriété de E67 Birth et non pas de E21 Person.
Source :http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/existence.html
Le diagramme indique aussi les cardinalités. Ces couples (0,n) ou (1,n) ou (0,1) qui indiquent le nombre d’entités minimales et maximales impliquées dans la relation. Notamment le (0,n) indiqué du côté de E67 Birth pour la propriété P98 brought into life indique qu’un accouchement (il s’agit plus d’un accouchement que d’une naissance si je ne m’abuse) peut donner naissance à zéro (!?) ou plusieurs enfants (dans le cas de jumeaux, triplés, etc.). Le (1,1) du côté de E21 Person précise comme on pourrait s’y attendre qu’une personne ne peut naitre qu’une seule fois lors du même accouchement et qu’un individu est forcément né une fois (donc Dieu ne peut être une E21 Person si on considère qu’il a toujours existé). On voit que E67 Birth nous permet aussi de déclarer le père et la mère des enfants et il y a fort à parier que l’on puisse aussi déclarer le lieu de la naissance.
A creuser : Les cardinalités fonctionnent-elles pour toutes les instances de l’entité ou pour une seule ? Autrement dit, dès qu’un individu est impliqué dans un accouchement comme nouveau-né, est ce que cela suffit pour qu’il ne puisse pas être impliqué dans un autre accouchement ?
Au passage, rien ne nous empêche d’enfreindre les règles de cardinalité. Il nous faudra nous même mettre en place des mécanismes pour vérifier si les règles sont respectées.
Concernant les parents, le manuel indique pour E67 Birth que dans ce modèle, le père biologique n’est pas vu comme un participant nécessaire de l’événement. Ce qui conforte l’idée que l’entité E67 Birth permet de décrire un accouchement (un événement impliquant la mère et les nouveaux-nés, ayant lieu à une date, une durée et à un endroit donnés) et non pas des liens de parentés. Puisque comme chacun sait, les pères n’assistent pas systématiquement à la naissance de leurs enfants.
In this model, the biological father is not seen as a necessary participant in the E67 Birth event.
Le manuel précise également que P96 by mother et P97 from father concernent uniquement les parents biologiques. Le modèle n’écarte pas pour autant les parents non-biologiques puisqu’ils peuvent être déclarés avec la fameuse propriété P152 has parent évoquée précédemment :
This property associates an instance of E21 Person with another instance of E21 Person who plays the role of the first instance’s parent, regardless of whether the relationship is biological parenthood, assumed or pretended biological parenthood or an equivalent legal status of rights and obligations obtained by a social or legal act.
Extrait de l’acte de naissance de Théodore Hersart de la Villemarqué. Source : Archives départementales du Finistère (http://mnesys-portail.archives-finistere.fr).
D’après l’acte de naissance de Théodore Hersart de la Villemarqué, l’auteur du Barzaz-Breiz est né le 7 juillet 1815 à Quimperlé et il est le fils de Pierre Michel François Marie Toussaint Hersart de la Villemarqué et de Marie Ursule Claude Henriette Kerjean Feydeau.
Pour exprimer cette information en RDF, il nous faut une URI (si possible une URL permanente ou PURL) où un processeur SPARQL comme ARQ pourra trouver une version RDF Shema ou OWL du CIDOC CRM. En tapant “CIDOC” sur LOV (Linked Open Vocabularies), on trouve que l’espace de nom du CIDOC est http://www.cidoc-crm.org/cidoc-crm/.
L’URI http://prelib.huma-num.fr/person/80 pourrait donc renvoyer le RDF suivant (exprimé ici avec Turtle) :
@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
prelib:person/80 a cidoc:Person, foaf:Person ;
dc:title "Théodore-Claude-Henri Hersart de la Villemarqué (1815-1895)"@fr ;
foaf:name "Théodore-Claude-Henri Hersart de la Villemarqué"@fr ;
foaf:givenName "Théodore Claude Henri" ;
foaf:familyName "Hersart de la Villemarqué" ;
foaf:nickname "Barz Nizon", "Kervarker";
foaf:gender "male"@en, "homme"@fr.
Le CIDOC CRM permet de nommer les ressources mais je vais me contenter pour l’instant d’exprimer le nom et les pseudonymes de Théodore avec le Dublin Core et FOAF (Friend of a Friend) comme le fait la BnF sur data.bnf.fr.
Les informations concernant la naissance de Théodore devront être exprimées depuis une autre URI par une autre ressource de type E67 Birth. En effet, je ne peux exprimer à l’adresse http://prelib.huma-num.fr/person/80 que des triplets qui ont pour sujet la ressource elle-même (Enfin, je suppose que c’est comme cela qu’il faut procéder).
Je pourrai mettre à disposition la ressource à l’URI http://prelib.huma-num.fr/birth/1 (où le chiffre 1 indique le numéro de la ressource de type E67 Birth) mais pour éviter d’utiliser des chemins dédiés à chaque classe du CIDOC CRM, je vais utiliser le nom de la classe générique E5 Event dans le chemin de l’URI.
Supposons donc qu’à l’URI http://prelib.huma-num.fr/event/1 on va pouvoir récupérer le RDF suivant (en supposant que l’URI correspondant à Marie Kerjean Feydeau, la mère de Théodore soit http://prelib.huma-num.fr/person/1115) :
@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
prelib:event/1 a cidoc:Event ;
prelib:event/1 a cidoc:Birth ;
cidoc:brought_into_life prelib:person/80 ;
cidoc:by_mother prelib:person/1115.
Comme rien ne prouve que le père de Théodore n’ai assisté à l’accouchement, on ne le rajoute pas à l’événement avec la propriété P97 from father. Par contre, comment signaler la date et le lieu de l’heureux événement ? C’est là que ça se complique.
En parcourant les représentations graphiques sur le site officiel du modèle, j’ai trouvé la modélisation des informations sur la nationalité d’une personne où l’on constate que l’on peut déclarer qu’un accouchement E67 Birth s’est produit durant une E4 Period et à une E53 Place.
Modélisation des informations sur une personne avec le modèle CIDOC CRM. Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/person_nationality.html.
Cependant, P10 falls within sert à lier entre elles des E4_Period et servirait plutôt à déclarer que la naissance de Théodore a eu lieu durant la Restauration. Comme E67 Birth est une sous-classe de E2 Temporal Entity (une sous-sous-sous-classe) il doit bien y avoir moyen de déclarer la date du 7 juillet 1815 avec une propriété quelconque de Temporal Entity ou de ses sous-classes ?
En cherchant sur le web, j’ai trouvé la présentation du modèle CIDOC CRM par Patrick Le Boeuf le 9 décembre 2010 (reproduite ci-dessus) où l’on constate à la diapositive n°37 que la valeur littérale de la date de l’accouchement pourrait être saisie grâce à une ressource de type E50 Date elle même reliée à notre accouchement par P4 has time-span.
Pour l’instant, j’utilise une ressource anonyme ou blank node en anglais pour exprimer la ressource de type E50 Date et je saisi la valeur littérale avec une propriété rdfs:label et en lui donnant un type xsd:date conforme au format ISO 8601.
@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
prelib:event/1 a cidoc:Event ;
prelib:event/1 a cidoc:Birth ;
cidoc:brought_into_life prelib:person/80 ;
cidoc:by_mother prelib:person/1115.
cidoc:is_identified_by _:date1
_:date1 a cidoc:Date ;
rdfs:label "1815-07-07"^^xsd:date
Pourquoi utiliser rdfs:label ? Et bien parce que c’est le seul moyen que j’ai trouvé l’instant pour saisir cette fameuse valeur. Si vous exprimez ces données avec RDF/XML, vous pouvez toujours mettre la valeur à l’intérieur d’une balise, comme dans l’exemple de la saisie de la période entre -500 à 500 tiré du wiki du projet Claros.
<crm:E52_Time-Span>
<crm:P82_at_some_time_within>
<claros:Period>
<claros:period_begin rdf:datatype="&xsd;gYear">-550</claros:period_begin>
<claros:period_end rdf:datatype="&xsd;gYear">-500</claros:period_end>
</claros:Period>
</crm:P82_at_some_time_within>
</crm:E52_Time-Span>
Sauf qu’avec Turtle ou Notation3 (N3), la valeur (l’objet du triplet RDF) passe forcément par l’utilisation d’un prédicat. C’est pourquoi GND Ontology l’ontologie de la Deutsche Nationalbibliothek met à disposition la propriété (en non pas la classe) Date of birth qui permet la déclaration suivante :
@prefix prelib: <http://prelib.huma-num.fr/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dc: <http://purl.org/dc/terms/> .
@prefix gnd: <http://d-nb.info/standards/elementset/gnd#> .
prelib:person/80 a cidoc:Person, foaf:Person , gnd:DifferentiatedPerson ;
dc:title "Théodore-Claude-Henri Hersart de la Villemarqué (1815-1895)"@fr ;
foaf:name "Théodore-Claude-Henri Hersart de la Villemarqué"@fr ;
gnd:dateOfBirth "1815/07/07"^^xsd:date .
Bon, ce billet est assez long comme ça. La suite au prochain épisode…
