Archives par étiquette : Base de données

Mémento de requêtes SQL pour Omeka Classic

Omeka Classic, la plateforme de publication de collection numérisées, repose sur le logiciel de base de données relationnelle MySQL (ou sa version entièrement GPL, MariaDB). Aussi, des connaissances de base en SQL et des droits d’accès à cette base de données vous permettront d’obtenir des informations sur les documents déposées sur votre bibliothèque numérique que l’interface d’administration de Omeka ne pourra vous fournir. Par exemple, afficher le nombre de fichiers associés aux documents des collections ou trouver des documents en doublons.

Ce document constitue un mémento de requêtes SQL utilisées pour interroger la bibliothèque numérique du Centre de recherche bretonne et celtique dont vous pouvez vous inspirer pour interroger votre instance de Omeka. Il présuppose une connaissance des concepts de Omeka (fichiers, contenus ou items, collections) et des connaissances de base en SQL1.

Si vous êtes intéressé par la même démarche avec Omeka S, vous pouvez consulter l’article de Pierre Couchet : Quelques requêtes MySql avec Omeka S. Continuer la lecture

  1. Pour une introduction au SQL, voir Des fichiers Excel au SQL, introduction aux bases de données relationnelles et Administrez vos bases de données avec MySQL []

Sémantiser une base de données relationnelle (4e épisode) : Nettoyage d’été de la base de données des acteurs de la littérature en breton

La base de données prosopographique des acteurs de la littérature en langue bretonne (projet PRELIB) est renseignée depuis trois ans par des étudiants vacataires de la Faculté des lettres et sciences humaines de Brest. Après nous être attelés en début d’année à un travail de nettoyage des informations géographiques (villes, départements, pays) et d’alignement des lieux et des individus avec les référentiels Wikidata1 et IdRef2, le nettoyage des “professions” est le gros chantier en cours depuis le début de l’été. Ce nettoyage est l’occasion de revoir la structure de la base de données et de se poser des questions sur le sens des informations saisies.

Pour cette opération, nous ne passons pas en revue une à une toutes les fiches des individus mais nous avons exporté en bloc les données de table “profession” et les avons importées dans le logiciel de nettoyage de données OpenRefine3. C’est beaucoup plus simple pour avoir une vue d’ensemble des données.

Les informations sur les “professions” sont stockées dans une table dont la structure était la suivante :

Schéma de la table profession de la base de données PRELIB

Schéma simplifié de la table profession. Cette table est liée aux tables des personnes (seule table liée représentée ici), des villes, des départements, des pays et des aires géographiques. Seuls quelques champs de la table personne ont été représentés afin de ne pas alourdir le schéma.

La notion floue d’employeur

Je ne sais plus trop pourquoi nous n’avions pas choisi de saisir les “employeurs” dans une table séparée comme nous l’avions fait pour les villes ou les pays4. Et comme il fallait s’y attendre, les données saisies étaient très hétérogènes…

Le champ “employeur”, contenait des noms d’institutions5, des types d’institutions (clinique privée, collège privé), des noms d’individus (Charles Dullin, Alan Stivell, Louis Jouvet, Louis XIV). Certains étudiants avaient cru bon de saisir “église catholique”, “diocèse de Vannes”, comme employeur de certains prêtres ou “Ministère de l’éducation nationale” pour les enseignants alors que d’autres avaient précisé le nom de l’établissement (Lycée Chaptal, Petit séminaire de Ploërmel).

Outre le farfelu de certaines saisies (Louis XIV pour l’aumônier de la Dauphine, Napoléon III pour un consul), on se retrouvait dans de nombreux cas avec des employeurs différents pour le même type d’occupation. Un peu comme si les étudiants avaient cherché à remplir cette case avec ce qui leur avait semblé être l’employeur et non pas avec des informations trouvées dans les sources (Cela dit, je doute que Napoléon III rémunérait ses consuls sur ses propres deniers).

Cependant, si la notion d’employeur peut être sans ambiguïté pour des professions contemporaines (employé chez Air France ou au Commissariat à l’énergie atomique), il est en réalité plus difficile de savoir exactement qui verse le salaire de l’individu, quand bien même il en perçoit un. Ce champ a donc été ventilé dans d’autres champs dont le nouveau champ “collectif” lié à la table du même nom. Le collectif correspondant à l’entreprise, institution, association, congrégation religieuse, etc. dans laquelle s’est exercée la profession.

Après tout, le fait que l’institution en question ait versé ou non le salaire de l’individu n’a pas d’importance. L’essentiel étant pour nous de lier des individus entre eux.

Le siège de la banque ou l’agence locale ?

La base de données a été modifiée pour faire disparaître la notion d’employeur au profit de l’association avec la table “collectif”. Mais au cours du remplissage de cette table avec les employeurs, un nouveau questionnement est apparu.

Yvonne Martin avait été indiquée comme employée de la Société générale dans la ville de Morlaix. Il suffisait donc en apparence de créer une nouvelle entrée “Société générale” dans la table “collectif” et d’y associer l’identifiant Wikidata de la banque française6. Mais si l’on faisait alors une requête dans la base pour obtenir la liste de tous les individus ayant travaillé à Société générale (la banque française dont le siège est à Paris et dont les agences sont réparties sur tout le territoire français) et à Morlaix, on n’aurait pas eu pour autant la certitude que ces individus aient travaillé au même endroit, car même à l’époque (de 1941 à 1942), il y avait peut-être plusieurs agences de la Société générale à Morlaix. Faute de ne savoir pour l’instant s’il existait Nous avons donc rattaché cette activité au collectif “Société générale (agence de Morlaix)”, elle même rattachée au collectif “Société générale” (identifiant Wikidata Q270363).

De même pour Hervé Mazé qui est noté comme ayant exercé le métier d’ingénieur à Rouen pour Shell (non pas “Shell à Rouen” mais “Shell” pris au sens de la compagnie pétrolière multi-nationale dont le siège est à La Haye en Hollande) . Rouen étant une grande ville, cela ne nous permet pas d’affiner le lieu d’exercice d’Hervé Mazé qui est très probablement la raffinerie de Petit-Couronne exploitée par Shell jusqu’en 2008. Il vaudrait donc mieux lier cette activité au collectif “Raffinerie de Petit-Couronne”, lui même lié au collectif “Shell”.

Dans la mesure du possible, il vaut donc mieux privilégier l’association avec le collectif liant l’individu avec le groupe d’individus le plus restreint possible.

Églises et paroisses

Je ne sais également plus pourquoi nous avions aussi ajouté un champ “lieu”. Peut-être pour distinguer l’employeur (celui qui verse le salaire) de l’institution dans laquelle s’exerce l’activité. Toujours est-il que l’on s’est retrouvé comme pour les employeurs avec des informations très disparates : des noms d’institutions (collège de Dinan, Fédération régionaliste de Bretagne), des noms de lieux géographiques (Finistère, Morlaix, Nantes), des types d’institutions (collège, évêché, prison, port, cathédrale), des noms d’individus (“chez F. Guilmer”), des informations du type “étude de son père” ou “ferme familiale” ou “village minier au sud du Pays de Galles”.

La question du “lieu” a été particulièrement épineuse pour les prêtres. Pour certains, c’est le nom de l’église ou de la cathédrale qui était saisi (cathédrale Saint-Corentin de Quimper), pour d’autres l’évêché (évêché de Quimper et Léon) ou le nom de la paroisse ou du diocèse (diocèse de Quimper et Léon). Le tout avec des intitulés plus ou moins officiels. Pour éviter que la même information ne puisse être désignée de plusieurs manières, c’est le nom du diocèse ou de la paroisse qui a été préférée à l’église ou à l’évêché.

En effet, les églises sont plutôt à considérer comme des bâtiments et non pas des lieux géographiques (voir plus loin Un bâtiment n’est pas un lieu) et il n’y pas de sens à considérer l’activité d’un prêtre comme circonscrite à la surface terrestre sur laquelle repose son église. Cette activité s’étend plutôt à celle de sa paroisse que l’on a finalement considéré comme un territoire (une aire géographique) plutôt que comme l’ensemble des paroissiens (qui serait considéré dans la base comme un collectif).

J’avais d’ailleurs des notions assez floues sur les notions d’évêché et de diocèse. Notions éclaircies par Yvon Tranvouez, notre spécialiste de l’histoire du catholicisme au CRBC lors d’un échange de mails :

1) Diocèse et évêché peuvent être synonymes mais mieux vaut employer diocèse, parce que évêché peut signifier à la fois le diocèse (comme territoire) et le bâtiment qui abrite l’évêque et ses services.

2) La paroisse est l’unité de base de l’organisation territoriale de l’Église catholique. Un diocèse comprend un nombre X de paroisses (nombre qui varie avec le temps et les restructurations du dispositif : le diocèse de Quimper va passer l’an prochain [en 2017] de plus de 300 paroisses à une vingtaine !)

3) Un édifice religieux n’est pas forcément rattaché à une paroisse : les chapelles d’ordres religieux ou de congrégations, et aussi les chapelles privées (dans un château par exemple), échappent à la juridiction paroissiale. Exemple : l’abbaye de Landévennec ne dépend absolument pas de la paroisse de Landévennec, laquelle a son église paroissiale, au bourg et non dans le domaine monastique.

4) La cathédrale est un cas particulier : église de l’évêque, elle est aussi celle de la paroisse où elle est implantée. Saint-Corentin, à Quimper, a un curé, distinct de l’évêque, mais l’évêque a sa cathèdre épiscopale (ornée de ses armes) dans le chœur de la cathédrale.

Yann Celton, bibliothécaire diocésain à l’évêché de Quimper7, nous a également livré des informations intéressantes au sujet des paroisses du Finistère et de leur évolution :

Depuis 1801, le diocèse est le même, Quimper et Léon, qui correspond au Finistère ; ses frontières n’ont pas changé : c’est déjà bien. Avant, il faut parler de Cornouaille, de Léon ou de Trégor et il faut regarder sur une carte, nous n’avons pas de listes de ce genre. Ensuite, le curé est curé d’une paroisse (Saint-Mathieu de Morlaix, par exemple) et donne le culte dans son église, qui porte le même nom que la paroisse. A Brest, l’église Saint-Laurent est celle de la paroisse Saint-Laurent, qui correspond au civil à Lambézellec. […] La forme géographique des paroisses ne varie que très peu. Dans les villes en extension, (Brest) furent créées des paroisses nouvelles dans les années 50 (Le Bouguen…) mais c’est une exception. Je vous conseille de consulter les annuaires diocésains en cas de doute, numérisés jusqu’en 1980. Dans les années 1990, il fut procédé à des regroupements de paroisses ; ces ensembles paroissiaux prenant parfois des noms étranges. L’ensemble paroissial des “Rives de l’Aulne” regroupe les paroisses de Châteaulin, Dinéault, Port-Launay, Saint-Coulitz et Trégarvan. Mais en définitive, ce sont ces paroisses ancestrales qui comptent, et non le regroupement artificiel et ponctuel (qui correspondrait à un canton dans le civil). Vous pouvez à mon avis vous baser uniquement sur le nom des paroisses anciennes.

Nous avons donc suivi ses conseils pour le choix des noms de paroisses et nous nous sommes servis d’un référentiel de noms qu’utilise en interne la bibliothèque diocésaine de Quimper.

Pour les activités autres que la prêtrise, il a fallu ventiler à la main les saisies entre le nouveau champ “Collectif” et les champs relatifs à des informations géographiques (ville, pays, département, aire géographique).

Un bâtiment n’est ni un lieu ni un collectif

Pour les bâtiments saisis comme des lieux (des localisations géographiques) et qui ne sont ni des églises ni des cathédrales (remplacés par la paroisse), un champ supplémentaire “bâtiment” a été créé. Pour m’aider dans cette décision, je me suis aidé de l’ontologie CIDOC CRM8 où les bâtiments sont considérés comme des E22 Man-Made Object9 et non pas comme des E53 Place.

Étant donné que E22 Man-Made Object est une sous-classe de E18 Physical Thing qui peut être composée de plusieurs E18 Physical Thing10, j’ai également considéré que l’abbaye Saint-Guénolé de Landévennec était aussi un E22 Man-Made Object bien que l’abbaye soit composée de plusieurs bâtiments distincts.

On pourrait aussi être tenté de considérer l’abbaye comme un collectif mais il vaut mieux distinguer les bâtiments des éventuels groupes d’individus qui les occupent. En effet, un même lieu peut servir successivement de couvent, de salle de réunion, de prison, d’école publique, de site industriel, de supermarché pour finir comme musée, comme c’est le cas du couvent des Capucins à Landerneau.

Faut-il rattacher les informations géographiques et les bâtiments au collectif ou à la profession ?

Table profession

Table profession

Concernant les informations géographiques (ville, département, pays, aire géographique) et les bâtiments, vous remarquerez dans le schéma ci-dessus qu’ils ont été directement associés aux professions. Mais peut-on circonscrire l’exercice d’une profession à une zone géographique ou à l’occupation de bâtiments ? Cela peut sembler utile lorsque les sources indiquent “vicaire et enseignant dans le Tregor” ou “chargé de recueillir les chants et mystères de Basse-Bretagne”. Mais si l’on interroge la base de données pour savoir qui était présent en Basse-Bretagne en 1845 au même moment que François-Marie Luzel (1821-1895), cela ne nous apprendra pas grand-chose sur les probabilités de rencontre entre ces individus.

Dans la plupart des cas, les informations saisies concernent plutôt le lieu d’implantation du collectif lié à l’activité. La base de données permettant la saisie des lieux d’implantation des collectifs, cette information devrait suffire.

Histoire des individus, histoire des collectifs

La saisie des parcours de vie d’individus revient tout autant à s’intéresser à l’histoire des collectifs. En effet, ceux-ci peuvent changer de nom, de lieu ou de statut au cours du temps.

C’est le cas par exemple de l’École des frères à Brest devenue “La Croix-Rouge La Salle” après s’être appelée “École de Bonne-Nouvelle” d’après la page “Notre histoire” de l’établissement brestois. Ou de l’École du calvaire à Pontchâteau où Jean-Louis Rozec (1898-1946) a été professeur et qui s’avère être le Petit séminaire de Guérande, transféré à Pontchâteau de 1912 à 1922 d’après un répertoire d’archives diocésaines réalisé par Jean Bouteiller et Claire Gurvil.

Si l’on se contente de créer trois “collectifs” distincts pour tous ces intitulés sans faire des recherches approfondies pour savoir s’ils ne sont pas liés entre eux, on passe à côté de la mise en relation des individus ayant fréquenté le même collectif ou des collectifs ayant le même héritage. Mais la question n’est pas aisée. S’agit-il du même collectif qui aurait juste changé de nom au cours de l’histoire ou ce changement de nom ne s’accompagne-t-il pas également d’un changement de statuts ou de lieux qui en fait un nouveau collectif ?

Il faut donc prévoir dans la base de saisir des informations dépendant du temps pour les collectifs et trouver des sources dédiées à leur histoire n’est pas toujours chose aisée. Mais nous avons des pistes, puisque c’est en interrogeant des collègues sur ces problématiques que nous avons appris que certains d’entre eux participaient à un dictionnaire des établissements de l’enseignement catholique du second degré. Et Sébastien Carney, maître de conférences en histoire contemporaine va apporter sa contribution à PRELIB avec des données sur les militants bretons.

Désambiguïser les collectifs

La saisie des lieux géographiques étant rattachée à la profession et non pas au collectif, nous nous sommes retrouvés avec des collectifs tels que “Petit séminaire”. Or il a existé au moins un séminaire par département breton. Quand on consulte donc la table des collectifs en dehors du contexte des professions (la table collectifs est liée à d’autres tables que celle des professions), rien ne permet de savoir de quel petit séminaire il s’agit. Celui de Pont-Croix ? Tréguier ? Quimper ? La précision “Petit séminaire de Point-Croix” ou “Faculté des lettres de Poitiers” dans l’intitulé du collectif n’est donc pas superflue.

Afin de lever complètement les ambiguïtés, nous avons ajouté depuis le début de l’année la saisie des identifiant Wikidata et des identifiants IdRef (les PPN). Mais les collectifs n’étant pas tous présents dans ces référentiels, il faudra leur créer une notice si nécessaire.

Cas des activités directement liées à un autre individu

Ce nettoyage a aussi permis de mettre en évidence certaines limites. La base permet actuellement de lier une profession à un collectif mais pas à un autre individu. Le cas se pose par exemple pour saisir que Erwan Kervella a été le chauffeur d’Alan Stivell. On peut toujours contourner le problème en trouvant le nom de la structure qui rémunérait Erwan Kervella, par exemple, la maison de production d’Alan Stivell et déclarer conjointement qu’Alan Stivell était un artiste de cette maison de production. Mais cela ne permet pas de lier directement les deux individus (ce n’est pas parce que deux individus travaillent dans la même entreprise qu’ils travaillent l’un pour l’autre). La base permet de lier directement deux individus par la table “relationinterpersonnelle” mais on perd alors le contexte de la structure dans laquelle s’exerce cette relation. A revoir, donc.

Évolutions de la table “profession”

Le schéma de la table professions après le nettoyage de la base de données PRELIB

Le schéma de la table “professions” après le nettoyage de la base de données PRELIB

Suite au nettoyage des professions, la table éponyme a été modifiée selon le schéma ci-dessus. Le champ “lieu” a été remplacé par la référence à une nouvelle table “bâtiment” (non représentée ici). Le champ “employeur” a été remplacé par une référence à la table “collectif”. Soit dit en passant, il aurait été plus judicieux de lier non pas un seul mais plusieurs collectifs à la même profession. Il est toujours possible d’associer des informations géographiques à la profession au cas où elle s’exercerait en dehors de la collectivité (qui possède ses propres informations géographiques). Mais la pertinence de cette information est discutable.

En guise de conclusion

Nettoyer les données ou ne serait-ce qu’y jeter un œil de temps en temps, c’est comme la vaisselle ou faire le ménage chez soi, on considère ça comme une corvée que l’on a toujours envie de remettre à plus tard. Pourtant, c’est l’occasion de revenir sur des concepts qui nous avaient semblé évidents au départ et de les affiner.

Laisser des champs de saisie assez flous ou d’une acception assez large n’est pas forcément un problème. Cela permet aux opérateurs de saisie de ne pas devoir toujours “rentrer dans les cases” et de saisir des informations que l’on n’avait pas envisagées lors des premières versions de la base de données (les bâtiments, par exemple).

Une base de données n’est pas figée. Sa structure n’est pas gravée dans le marbre et peut évoluer avec le temps. Mais ce n’est pas une opération anodine car un changement de structure entraîne une redistribution des données selon le nouveau schéma de la base et un recodage de l’interface de consultation des données.

La base de données PRELIB couvre tellement de champs connexes (histoire des institutions scolaires et religieuses, histoire du militantisme breton, histoire de l’imprimerie en Bretagne, etc.) liés tant par la nature que par la structure des informations saisies que l’on peut se demander s’il ne vaudrait pas mieux rassembler toutes les données produites au sein d’un même laboratoire dans une seule et unique base de données, les informations saisies par les uns bénéficiant aux autres.

On peut s’aider d’ontologies pour penser ses données. Dans notre cas, nous nous aidons du CIDOC CRM. C’est notamment ce qui nous a permis de distinguer les lieux des bâtiments.

Merci à Florence Daniel, secrétaire d’édition de la Revue Natures Sciences Sociétés au Ladyss et à Philippe Jarnoux, directeur du CRBC, pour leurs remarques et corrections.

  1. Pour en savoir plus sur Wikidata : https://fr.wikipedia.org/wiki/Wikidata. Nous avons choisit Wikidata car cette base pourrait être le socle du web des données (Open data). []
  2. Pour en savoir plus sur IdRef : http://www.abes.fr/IdRef/IdRef-Referentiel-d-autorites. []
  3. Voir aussi : OpenRefine, mes données à la machine. []
  4. Les villes et les pays correspondant aux attributs ville_id et pays_id de la table “profession” qui contiennent non pas le nom de la ville ou du pays mais un nombre entier correspondant à l’identifiant de la ville ou du pays dans leurs tables respectives “ville” et “pays”. Par exemple, l’identifiant interne à PRELIB de Brest est le chiffre 40. Cet identifiant s’appelle une clé primaire en SQL. []
  5. Par institution, j’entends tout type de groupe d’individus : entreprises, associations, structures gouvernementales, établissement d’enseignement, congrégations religieuses, etc. []
  6. Nous saisissons l’identifiant Wikidata et le PPN de IdRef pour les collectifs, les individus et les lieux afin de désambiguïser les données saisies. L’utilisation de ces référentiels nous permettra également de récupérer des informations, telles que les coordonnées géospatiales des villes. []
  7. La bibliothèque diocésaine de Quimper met à disposition une partie des documents issus de son fonds dans une bibliothèque numérique. []
  8. CIDOC Conceptual Reference Model []
  9. La classe E22 Man-Made Object du CIDOC-CRM est une sous-classe de E24 Physical Man-Made Thing qui englobe tous les “objets physiques persistants” créés par l’activité humaine qui comprend le Tunnel sous la Manche ou le Canal de Suez (deux E25 Man-Made Feature) ou la collection des oeuvres du musée du Louvre (E78 Collection). Les exemples donnés de E22 Man-Made Object sont la locomotive à vapeur “Mallard” détentrice du record de vitesse des locomotives à vapeur, le vase Portland conservé au British Museum, le Colisée à Rome (donc un bâtiment). Un E22 Man-Made Object peut-être lié à une E53 Place par P53 has former or current location. []
  10. A travers la propriété P46 is composed of (forms part of). []

Sémantiser une base de données relationnelle (3ème épisode)

Ce billet est le troisième épisode d’une série de billets sur la sémantisation d’une base de données relationnelle des auteurs de langue bretonne issue du projet PRELIB.

Je posterai dorénavant la dernière version de la totalité des triplets RDF sur mon compte personnel sur le site de partage de code informatique GitHub Gist. Je commençai en effet à être un peu perdu avec mes petits bout de triplets dispersés d’un billet à l’autre. Pour l’instant, les triplets déclarés avec le vocabulaire BIO et le vocabulaire FRBRoo sont dans des fichiers prelib.ttl séparés, mais cela n’exclut pas par la suite l’utilisation combinée des deux vocabulaires.

Dans les fichiers prelib.ttl publiés sur GitHub Gist des codes de langue (language tags) ont été rajoutés sur tous les littéraux en se servant du formulaire de recherche de la page de l’ISO 639-6 sur geolang.org (champ de recherche Language Reference Name).

Saisie du décès de Théodore et de ses années collège avec BIO

Dans la version BIO de prelib.ttl, les triplets de la date et du lieu de décès de Théodore ont été rajoutés ainsi que ses études au collège des Jésuites de Keranna à Quimper entre 1825 et 1826.

BIO permet de déclarer des bio:Interval (les années d’études de Théodore au collège des Jésuites de Keranna correspondent à la ressource http://prelib.huma-num.fr/interval/1) bornées par des bio:Event (les ressources http://prelib.huma-num.fr/event/3 et http://prelib.huma-num.fr/event/4 correspondant à sont entrée en 1825 et à sa sortie en 1826 du collège). Les informations spatio-temporelles sont rattachées aux bio:Event.

Si une autre personne rentre au même moment au collège des jésuites de Keranna, faut-il créer une nouvelle ressource de type bio:Enrolment ou rattacher la personne au même événement ? Vous ne trouverez pas la réponse dans la documentation du vocabulaire BIO mais dans le schéma du vocabulaire1 où il est indiqué que la propriété bio:principal liant la personne à l’événement a une cardinalité de 1 pour les ressources de type bio:IndividualEvent (dont bio:Enrolment est une sous-classe). En d’autres termes, il ne peut y avoir qu’une seule personne liée par la propriété bio:principal à un événement de type bio:Enrolment. Il faut donc bien créer autant d’événements de type bio:Enrolment que de personnes qui seraient rentrées au collège des Jésuites de Quimperlé la même année que Théodore.

Le collège des Jésuites correspond à la ressource http://prelib.huma-num.fr/organization/1 de type foaf:Organization où le nom de l’établissement a été saisi avec dc:title et foaf:name. Mais cette saisie ne permet pas de tenir compte des éventuels changement de nom ni de statut de l’établissement ni de ses divers lieux d’enseignement. Comment modéliser par exemple l’histoire mouvementée des Écoles normales supérieures ? L’École normale supérieure de l’enseignement primaire de Fontenay-aux-Roses créée par Jules Ferry en 1880 et École normale supérieure de Fontenay-Saint-Cloud doivent-elle être représentées par la même ressource ou par des ressources différentes mais liées entre elles (de quelle manière) ?

Petite remarque en aparté : L’idée sous-jacente à la saisie des études est de savoir si des personnes ont fréquenté les mêmes lieux de sociabilité. Mais une proximité spatio-temporelle n’est pas suffisante pour attester d’une relation. Dans le cas d’études, des documents tels qu’une thèse ou des devoirs en groupe seraient des preuves plus tangibles d’une relation (de professeur à étudiant ou entre étudiants).

Les multiples implémentations de FRBR pour le web sémantique

Plus j’explore l’utilisation de FRBR pour la base de donnée, plus je m’aperçois qu’il en existe de multiples implémentations en RDFS ou dans les différentes versions de OWL2. Voici celles que j’ai trouvées jusqu’à présent :

Implémentations de FRBRER (entité-relation)

– La version de l’IFLA : http://iflastandards.info/ns/fr/frbr/frbrer/
– La version RDFS de Ian Davis (auteur également du vocabulaire BIO) : http://purl.org/vocab/frbr/core et http://purl.org/vocab/frbr/extended
– La version OWL 2 DL de Paolo Ciccarese et Silvio Peroni3 qui fait référence à la version de Ian Davis : http://purl.org/spar/frbr

Implémentations de FRBRoo (orienté objet, version dérivée de CIDOC-CRM)

– La version RDFS de la dernière version de FRBRoo (version 2.1 du modèle) édité par le groupe de travail du groupe de travail CRM-FRBR : voir en haut de la page http://www.cidoc-crm.org/frbr_drafts.html
– La version de l’IFLA : http://iflastandards.info/ns/fr/frbr/frbroo/
– La version OWL DL de l’Université d’Erlangen (version 1.0.2 du modèle) : http://erlangen-crm.org/efrbroo

Sur la page Vocabulaires du web sémantique sur le site de la BnF on trouve également un lien vers la page The FRBR Vocabularies de l’IFLA. Pas facile de s’y retrouver dans tout ça…

  1. Je mets en lien la version du schéma publié par Ian Davis sur GitHub pour faciliter sa lecture. []
  2. Pour tenter d’y voir clair dans les différentes versions de OWL, lire Difference between OWL Lite, DL, and Full. []
  3. Silvio Peroni a également développé le web service LODE permettant de créer une documentation web d’une ontologie OWL. []

Sémantiser une base de données relationnelle (2ème épisode)

Ce billet est le deuxième épisode d’une série de billets sur la sémantisation d’une base de données relationnelle des auteurs de langue bretonne issue du projet PRELIB.

Corrections et améliorations

Depuis le dernier billet, Patrick Le Boeuf de la BnF m’a apporté quelques précisions sur le modèle CIDOC-CRM et Gabriel Kepeklian d’Atos m’a aidé à connecter une copie locale de ma base de données à DataLift1. Je vous conseille à ce propos la lecture de How to import an SQL database? Si vous avez des difficultés pour utiliser DataLift ou si vous voulez signaler votre utilisation de l’outil, n’hésitez pas à le faire sur la liste de diffusion du projet DataLift. J’ai également réalisé en discutant avec mon collègue Fañch Postic qui connait très bien Théodore, que je n’avais pas très bien interprété l’écriture manuscrite de l’acte de naissance de ce dernier puisque le nom de famille de la mère de Théodore Hersart de la Villemarqué est Feydeau et non pas Kerjean, plus précisément Feydeau de Vaugien2.

Pour revenir aux exemples précédents de triplets en Turtle, j’ai un doute sur la validité des URI des classes et des propriétés du CIDOC CRM. J’avais supposé que l’URI de P96 by mother par exemple, était http://www.cidoc-crm.org/cidoc-crm/by_mother mais il s’avère que c’est plutôt http://www.cidoc-crm.org/cidoc-crm/P96_by_mother. Je modifie les triplets de l’accouchement http://prelib.huma-num.fr/event/1 en conséquence. J’en profite également pour corriger les URI préfixées. En effet, les URI prelib:event/1 ou prelib:person/1115 ne sont pas valides : Le / n’est pas reconnu après les préfixes. J’ai donc remplacé le préfixe prelib: par les préfixes event: et person:

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@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#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

event:1 a cidoc:E67_Birth ;
cidoc:P98_brought_into_life person:80 ;
cidoc:P96_by_mother person:1115 ;
cidoc:P97_from_father person:1114 ;
cidoc:P1_is_identified_by _:date1 .

_:date1 a cidoc:E50_Date ;
rdfs:label “1815-07-07″^^xsd:date .

J’ai rajouté un triplet concernant le père de Théodore, Pierre Hersart de la Villemarqué (person:1114) car j’avais mal interprété l’utilisation de P97 from father. Comme me l’a expliqué Patrick Le Boeuf, cette propriété sert à désigner le père biologique et peut être utilisée même si celui-ci n’a pas assisté à l’accouchement.

Saisie du lieu de naissance

Modélisation des informations sur une personne aec le modèle CIDOC CRM. Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/person_nationality.html.

Modélisation des informations sur une personne aec le modèle CIDOC CRM. Source : http://www.cidoc-crm.org/cidoc_graphical_representation_v_5_1/person_nationality.html.

Comment saisir le lieu de naissance, c’est à dire la ville de Quimperlé ? D’après le schéma publié sur le site du CIDOC CRM et reproduit ci-dessus, il faut créer une ressource E53 Place que l’on lie à l’accouchement par la propriété P7 took place at. On crée donc une nouvelle ressource http://prelib.huma-num.fr/place/1 et on déclare à cette URI les triplets suivants :

@prefix place: <http://prelib.huma-num.fr/place/> .
@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

place:1 a cidoc:E53_Place ;
rdfs:label “Quimperlé″ .

Cependant, le CIDOC-CRM incite à saisir les dénominations dans des classes dédiées afin de relater leur évolution dans le temps (par exemple, Lutèce qui devient Paris). E48 Place Name, sous-classe de E44 Place Appellation, semble la mieux indiquée dans notre cas3. Je pourrai créer une nouvelle ressource http://prelib.huma-num.fr/appellation/1 de type E48 Place Name mais je ne sais pas si celle-ci sera utilisée pour un autre usage que l’appellation de http://prelib.huma-num.fr/place/1, je me contente donc pour l’instant d’une ressource anonyme (ou blank node en anglais).

@prefix place: <http://prelib.huma-num.fr/place/> .
 @prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .
 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

place:1 a cidoc:E53_Place ;
cidoc:E87_is_identified_by _place_name .

_place_name a cidoc:E48_Place_Name ;
rdfs:label “Quimperlé″ .

On peut maintenant compléter les triplets de l’accouchement avec une référence à Quimperlé :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@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#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

event:1 a cidoc:E67_Birth ;
cidoc:P98_brought_into_life person:80 ;
cidoc:P96_by_mother person:1115 ;
cidoc:P97_from_father person:1114 ;
cidoc:P1_is_identified_by _:date1 ;
cidoc:P7_took_place_at place:1 .

_:date1 a cidoc:E50_Date ;
rdfs:label “1815-07-07″^^xsd:date .

Retour sur la date de l’accouchement

Je ne suis toujours pas convaincu de cette saisie de la date de l’accouchement. Or, on trouve l’information suivante dans le commentaire au début du fichier http://www.cidoc-crm.org/rdfs/cidoc_crm_v6.0-draft-2015January.rdfs :

8. CRM time extension 1.0 Encoded in RDFS
Since the Time Primitive of the CRM can not directly be implemented in RDF Triple Stores, we define in this extension of 4 properties replacing P81 and P82 adequately using xsd:dateTime.
Property P81 is dedicated for modeling the Time-Span’s maximum known temporal extent i.e. ongoing_throughout. Property P82 is for modeling the minimum outer bounds of events i.e. at_some_time_within. P81 has its time interval redefined by P81a and P81b. Similarly, we redefine P82 by P82a and P82b.

Visiblement, cette implémentation en RDFS par le FORTH-ICS4 a nécessité la création de quatre propriétés RDF P81a_end_of_the_begin, P81b_begin_of_the_end, P82a_begin_of_the_begin et P82b_end_of_the_end qui sont les seules propriétés permettant explicitement la saisie de dates au format ISO 6801 (elles ont toutes les quatre pour portée (range en anglais) http://www.w3.org/2001/XMLSchema#dateTime) .

A y regarder de prêt, il semblerait que toute information temporelle est de facto une durée dont il faut saisir la date de début et la date de fin. Cela vient du fait que les concepteurs du modèle considèrent que les données temporelles sont forcément floues (fuzzy en anglais)5 et qu’ils ont voulu introduire la possibilité d’utiliser l’algèbre des intervalles d’Allen pour déduire la chronologie d’événements6.

Cela dit, dire que Théodore est né le 7 juillet 1815 signifie qu’il est né entre le 7 juillet à 0 heure et le 7 juillet à minuit… Toute “date” est en soit une durée. Mais il faut tout de même avouer que cela complique un peu la saisie.

Expression des données avec le vocabulaire BIO

Comment les mêmes informations pourraient-elles être exprimées avec le vocabulaire BIO du développeur anglais Ian Davis suggéré par Gautier Poupeau ? A la fin de la documentation de BIO, Ian Davis a illustré le vocabulaire par des données biographiques sur le roi d’Angleterre Henry VIII exprimées en RDF dont voici un extrait :

@prefix bio: <http://purl.org/vocab/bio/0.1/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

_:henryviii
  a foaf:Person
  ; foaf:name "Henry VIII, King of England"
  ; bio:father _:henryvii
  ; bio:mother _:elizplantagenet
  ; bio:child _:child1, _:child2, _:child3, _:child4, _:child5, _:child6, _:child7, _:child8
  ; bio:birth _:birth
  ; bio:death _:death
  ; bio:event _:burial, _:accession, _:coronation, _:marriage1
            , _:marriage2, _:marriage3, _:marriage4, _:marriage5, _:marriage6
  .

_:henryvii
  a foaf:Person
  ; foaf:name "Henry VII Tudor, King of England"
  ; bio:child _:henryviii
  .

_:elizplantagenet
  a foaf:Person
  ; foaf:name "Elizabeth of York"
  ; bio:child _:henryviii
  .
  
_:birth
  a bio:Birth
  ; rdfs:label "The birth of Henry VIII to Henry VII and Elizabeth Plantagenet on 28 June 1491"
  ; bio:date "1491-06-28"
  ; bio:place <http://dbpedia.org/resource/Palace_of_Placentia>
  ; bio:parent _:henryvii, _:elizplantagenet
  ; bio:principal _:henryviii
  .

_:death
  a bio:Death
  ; rdfs:label "The death of Henry VIII on 28 January 1547"
  ; bio:date "1547-01-28"
  ; bio:place <http://dbpedia.org/resource/Palace_of_Whitehall>
  ; bio:principal _:henryviii
  .

Je me suis largement inspiré de cet exemple à la seule différence que j’ai évité l’utilisation de ressources anonymes.

Les triplets associés à Théodore pourraient devenir :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@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 bio: <http://purl.org/vocab/bio/0.1/> .

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 ;
bio:birth  event:1 .

Et les triplets de l’accouchement deviennent :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@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#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dbpedia: <http://dbpedia.org/resource/> .

event:1 a bio:Birth ;
rdfs:label "Naissance de Théodore-Claude-Henri Hersart de la Villemarqué le 7 juillet 1815 à Quimperlé"@fr ;
bio:date "1815-07-07"^^xsd:date ;
bio:place dbpedia:Quimperl%C3%A9 ; # Voir http://www.dbpedia.org/resource/Quimperl%C3%A9
bio:parent person:1115 , person:1114 ;
bio:principal person:1 .

On perd la distinction du père et de la mère du CIDOC CRM mais les informations sur la date et le lieu sont plus faciles à saisir. Notamment pour le lieu, il est possible de ne saisir non pas une valeur littérale mais l’URI d’une ressource qui permette de désambiguïser l’information et de récupérer des informations saisies par ailleurs7. Après, je ne dis pas que cela n’est pas possible avec le CIDOC CRM, je n’ai peut-être pas encore compris comment procéder. Toujours est-il que la propriété bio:place n’a pas de portée (range) et n’impose donc pas de valeur particulière à l’objet d’un triplet dans lequel la propriété est utilisée.

Pour signifier Quimperlé, j’ai suivit l’exemple de la biographie d’Henry VIII et j’ai utilisé DBpedia en anglais, mais j’aurais tout aussi bien pu utiliser DBpedia en français, voire un référentiel géographique (gazetteer en anglais) tel que Getty Thesaurus of Geographic Names et faire la déclaration suivante :

@prefix person: <http://prelib.huma-num.fr/person/> .
@prefix event: <http://prelib.huma-num.fr/event/> .
@prefix place: <http://prelib.huma-num.fr/place/> .
@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#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix tgn: <http://vocab.getty.edu/tgn/> .

event:1 a bio:Birth ;
rdfs:label "Naissance de Théodore-Claude-Henri Hersart de la Villemarqué le 7 juillet 1815 à Quimperlé"@fr ;
bio:date "1815-07-07"^^xsd:date ;
bio:place tgn:7009459 ; # Voir http://vocab.getty.edu/tgn/7009459
bio:parent person:1115 , person:1114 ;
bio:principal person:1 .

Bon, ce n’est pas tout de faire des tests de vocabulaires, mais il faudrait faire quelques premières requêtes en SPARQL pour les évaluer. Pour cela rien de tel qu’un triple store tel que Sesame RDF que vous pouvez installer en suivant les instructions de Thomas Francart. La suite au prochain épisode…

  1. Par copie locale, j’entends une copie de ma base de données installée sur mon ordinateur avec la plateforme de développement web EasyPHP. []
  2. Source : Ces Quimperlois(es) qui ont fait l’histoire (Jacques Gouriou, Alain Pennec, Fañch Postic), Amis de l’abbaye Sainte-Croix de Quimperlé / Société d’Histoire de Kemperle, décembre 2007. []
  3. Notez que la notion de sous-classe est indiquée dans le graphique ci-dessus par des doubles flèches. []
  4. Le FORTH Institute of Computer Science est un institut d’informatique grec où travaille Martin Doerr, un des co-rédacteurs du manuel de référence du CIDOC CRM []
  5. Voir à ce sujet la discussion Start/End vs Period of Existence sur le site officiel du CIDOC CRM. []
  6. Voir le chapitre 6 “Example” de Deducing Event Chronology in a Cultural Heritage Documentation System où l’on trouve un exemple de déduction de la date de construction d’une église à partir de la date à laquelle ont été approuvés les plans et la date d’un mariage célébré dans cette église. []
  7. L’intérêt de passer par des ressources externes sera plus évidente quand on fera des requêtes en SPARQL. []

Sémantiser une base de données relationnelle (1er épisode)

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 CIDOC1 CRM2 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 Vocabulary3).

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

Table "Personne" de la base de données relationnelle PRELIB

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

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

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é

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é6, 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 CRM7. 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 sujet8 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.

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…

  1. Comité International pour la DOCumentation du Conseil international des musées []
  2. Conceptual Reference Model []
  3. Linked Open Vocabularies est un projet hébergé par l’Open Knowledge Fundation qui propose le référencement d’ontologies pour le web des données. []
  4. Wiki qui n’est certes pas mis en avant. []
  5. Pour en savoir plus, vous pouvez consulter la page Wikipedia sur la négociation de contenu : http://fr.wikipedia.org/wiki/N%C3%A9gociation_de_contenu. []
  6. L’acte de naissance de Théodore Hersart de la Villemarqué peut-être consulté en ligne dans la version numérisée des actes de naissances de Quimperlé entre 1814 et 1822 sur le portail des Archives départementales du Finistère. []
  7. Si vous n’êtes pas familiers avec ce vocabulaire, lisez le RDF 1.1 Primer du W3C. C’est une bonne introduction au web sémantique []
  8. Pour le concept de triplets RDF composés d’un sujet, d’un prédicat et d’un objet, lire le RDF 1.1 Primer. []