@prefix cw: . @prefix dcterms: . @prefix xsd: . cw:tags . cw:wf_info_for . cw:wf_info_for . cw:tags , . cw:tags , . cw:wf_info_for . cw:tags . cw:tags . cw:tags . cw:tags , , . a cw:BlogEntry, ; cw:content """Ce week end, samedi 19 et dimanche 20 novembre, aura lieu le [Capitole du libre](capitoledulibre.org/) à Toulouse. Cet évènement est toujours important dans notre calendrier car Logilab porte depuis sa création les valeurs du Logiciel Libre et dispose de locaux à Paris et à Toulouse. Nous serons donc, cette année encore, sponsor de cette conférence et prévoyons d'assister à de nombreuses présentations.\r \r Nous présenterons, le samedi 19 novembre à 17h en salle A202, les dernières avancées de nos travaux de recherche, à savoir ["CubicWeb-as-a-Service: Publier des données ouvertes ‘as a service’"](https://cfp.capitoledulibre.org/cdl-2022/talk/3T9FD7/).\r \r Nous serons enchantés de faire de nouvelles rencontres à l'occasion de Capitole du Libre. Contactez-nous par les réseaux sociaux si vous voulez convenir d'un moment pour discuter. Au plaisir de vous croiser cette fin de semaine à Toulouse !""" ; cw:content_format "text/markdown" ; cw:creation_date "2022-11-17T16:02:41.397907+00:00"^^xsd:dateTime ; cw:cw_source ; cw:entry_of ; cw:has_creator ; cw:heading "Comme chaque année, Logilab sponsorise et participe au Capitole du libre. Nous présenterons nos avancés sur le projet CubicWeb as a Service à 17h en salle A202." ; cw:in_state ; cw:modification_date "2022-11-17T16:25:37.331724+00:00"^^xsd:dateTime ; cw:title "Logilab sera au Capitole du libre 2022" ; dcterms:title "Logilab sera au Capitole du libre 2022" ; """Ce week end, samedi 19 et dimanche 20 novembre, aura lieu le [Capitole du libre](capitoledulibre.org/) à Toulouse. Cet évènement est toujours important dans notre calendrier car Logilab porte depuis sa création les valeurs du Logiciel Libre et dispose de locaux à Paris et à Toulouse. Nous serons donc, cette année encore, sponsor de cette conférence et prévoyons d'assister à de nombreuses présentations.\r \r Nous présenterons, le samedi 19 novembre à 17h en salle A202, les dernières avancées de nos travaux de recherche, à savoir ["CubicWeb-as-a-Service: Publier des données ouvertes ‘as a service’"](https://cfp.capitoledulibre.org/cdl-2022/talk/3T9FD7/).\r \r Nous serons enchantés de faire de nouvelles rencontres à l'occasion de Capitole du Libre. Contactez-nous par les réseaux sociaux si vous voulez convenir d'un moment pour discuter. Au plaisir de vous croiser cette fin de semaine à Toulouse !""" . a cw:BlogEntry, ; cw:content """*Temps de lecture 2 min (325 mots)*\r \r Nous sommes allés à la [Plateforme Française en Intelligence Artificielle 2022](https://ci.mines-stetienne.fr/pfia2022/) à Saint-Étienne cette année. Cet ensemble de conférences rassemble chaque année les acteurs de l'intelligence artificielle francophone. Nous étions très heureux et heureuses de pouvoir y participer cette année encore.\r \r ![](https://www.logilab.fr/file/21317747/raw/2db172b5e850787b30543be0e.jpg)\r \r Nous avons suivi la conférence d'[Ingénierie des Connaissances](https://ci.mines-stetienne.fr/pfia2022/conferences/ic/), qui est la plus proche de notre domaine d'expertise. Nous y avons présenté nos travaux actuels sur OWL2YAMS et avons eu des retours positifs avec plusieurs perspectives dont nous vous ferons part dans de futurs articles.\r \r Même si toutes les présentations étaient enrichissantes (nous avons appris beaucoup de choses !), nous avons choisi d'en mettre trois en lumière.\r \r **DAGOBAH** est un outil permettant de générer un graphe RDF à partir d'un fichier CSV, en alignant au passage les données avec Wikidata et DBPedia. Cet outil est arrivé premier à [SemTab 2021](https://www.cs.ox.ac.uk/isg/challenges/sem-tab/2021/index.html), un challenge de sémantisation de données tabulaires. Cet outil, que nous avions déjà vu lors de [SemWeb.Pro 2021](https://www.semweb.pro/15014450) pourrait nous servir de base de départ pour les projets de sémantisation de données CSV, mais ses conditions d'utilisation (libre ou non ?), restent à préciser.\r \r Un [état de l'art](https://ci.mines-stetienne.fr/cntf/home) sur **la négociation de contenu** a été présenté. Il catégorise les approches existantes et ouvre des perspectives en proposant de la négociation de contenu par vocabulaire ou par forme SHACL sur les données RDF disponibles. Nous allons voir comment utiliser ces résultats dans nos travaux sur la négociation de contenu dans [CubicWeb](https://www.cubicweb.org). Les dernières propositions, si elles sont standardisées, pourraient être utiles dans notre [navigateur pour le web de données](https://hal.archives-ouvertes.fr/hal-02283368v1).\r \r Le projet **ATLANTIS** a pour but de sémantiser des instructions nautiques, jusque là conservées dans un document textuel, afin de simplifier la recherche en leur sein. Ce projet est une application très concrète des technologies du Web sémantique, qui montre comment elles peuvent aider les utilisateurs et utilisatrices. Nous essayons, à Logilab, de promouvoir les mêmes idées à travers de projets comme [data.bnf.fr](https://www.logilab.fr/blogentry/1888), ou encore [FranceArchives](https://www.logilab.fr/blogentry/4716152).""" ; cw:content_format "text/markdown" ; cw:creation_date "2022-08-17T07:25:03.751868+00:00"^^xsd:dateTime ; cw:cw_source ; cw:entry_of ; cw:has_creator ; cw:heading "Logilab était présent à #PFIA2022 cette année ! Nous avons présenté les dernières évolutions de #CubicWeb avec #OWL2YAMS et nous avons assisté à quantité de présentations intéressantes. Nous en citons trois qui sont proches de nos propres travaux." ; cw:in_state ; cw:modification_date "2022-08-17T12:43:47.730154+00:00"^^xsd:dateTime ; cw:title "Logilab était à PFIA 2022 à Saint-Etienne" ; dcterms:title "Logilab était à PFIA 2022 à Saint-Etienne" ; """*Temps de lecture 2 min (325 mots)*\r \r Nous sommes allés à la [Plateforme Française en Intelligence Artificielle 2022](https://ci.mines-stetienne.fr/pfia2022/) à Saint-Étienne cette année. Cet ensemble de conférences rassemble chaque année les acteurs de l'intelligence artificielle francophone. Nous étions très heureux et heureuses de pouvoir y participer cette année encore.\r \r ![](https://www.logilab.fr/file/21317747/raw/2db172b5e850787b30543be0e.jpg)\r \r Nous avons suivi la conférence d'[Ingénierie des Connaissances](https://ci.mines-stetienne.fr/pfia2022/conferences/ic/), qui est la plus proche de notre domaine d'expertise. Nous y avons présenté nos travaux actuels sur OWL2YAMS et avons eu des retours positifs avec plusieurs perspectives dont nous vous ferons part dans de futurs articles.\r \r Même si toutes les présentations étaient enrichissantes (nous avons appris beaucoup de choses !), nous avons choisi d'en mettre trois en lumière.\r \r **DAGOBAH** est un outil permettant de générer un graphe RDF à partir d'un fichier CSV, en alignant au passage les données avec Wikidata et DBPedia. Cet outil est arrivé premier à [SemTab 2021](https://www.cs.ox.ac.uk/isg/challenges/sem-tab/2021/index.html), un challenge de sémantisation de données tabulaires. Cet outil, que nous avions déjà vu lors de [SemWeb.Pro 2021](https://www.semweb.pro/15014450) pourrait nous servir de base de départ pour les projets de sémantisation de données CSV, mais ses conditions d'utilisation (libre ou non ?), restent à préciser.\r \r Un [état de l'art](https://ci.mines-stetienne.fr/cntf/home) sur **la négociation de contenu** a été présenté. Il catégorise les approches existantes et ouvre des perspectives en proposant de la négociation de contenu par vocabulaire ou par forme SHACL sur les données RDF disponibles. Nous allons voir comment utiliser ces résultats dans nos travaux sur la négociation de contenu dans [CubicWeb](https://www.cubicweb.org). Les dernières propositions, si elles sont standardisées, pourraient être utiles dans notre [navigateur pour le web de données](https://hal.archives-ouvertes.fr/hal-02283368v1).\r \r Le projet **ATLANTIS** a pour but de sémantiser des instructions nautiques, jusque là conservées dans un document textuel, afin de simplifier la recherche en leur sein. Ce projet est une application très concrète des technologies du Web sémantique, qui montre comment elles peuvent aider les utilisateurs et utilisatrices. Nous essayons, à Logilab, de promouvoir les mêmes idées à travers de projets comme [data.bnf.fr](https://www.logilab.fr/blogentry/1888), ou encore [FranceArchives](https://www.logilab.fr/blogentry/4716152).""" . a cw:BlogEntry, ; cw:content """1500 mots: ~7min\r \r \r \r Du 1er au 3 juin 2023 a eu lieu le colloque "Des archives aux données" au cours duquel deux jours de hackathon ont permis de s'interroger sur l'interopérabilité des données entre différentes institutions culturelles.\r \r Les données présentées concernaient les représentations théâtrales de la Comédie Française ([Base RCF](https://www.cfregisters.org/)), de la Comédie Italienne, du théâtre d'Amsterdam ([Base On Stage](https://lod.uba.uva.nl/CREATE/ONSTAGE/)) et du théâtre français des XVIIe et XVIIIe siècles ([Base CESAR](https://cesar.huma-num.fr/cesar2/)).\r \r Ce fut l'occasion d'éprouver dans un contexte concret les avantages des technologies du Web Sémantique. Les requêtes fédérées ont en effet permis d'assembler et de manipuler des données publiées sans concertation préalable par les différents participants.\r \r ## Tempête de cerveaux sur les besoins en interopérabilité\r \r Lors de la première journée nous avons commencé par faire émerger des idées de traitements qui nécessitent une interopérabilité des données. Cette session a été très riche et il nous a fallu quelques efforts pour résumér les diverses idées et choisir vers quoi nous diriger.\r \r Nos sources de données divergent principalement sur le périmètre étudié: les registres de la Comédie Française concernent une unique troupe, la base "ON_Stage" se focalise sur le théâtre d'Amsterdam et la base CESAR se limite à une période de temps.\r \r La date des représentation théâtrales a été clairement identifiée comme centrale puisqu'elle permet de les aligner de manière non ambigüe. Chaque source de données décrit différemment les représentations, mais toutes ont renseigné la date.\r \r Les lieux des représentations constituent un autre point de contact, pour autant que les périodes temporelles soient les mêmes.\r \r Partant de ces deux constats, nous nous sommes demandé s'il serait possible d'afficher un graphique qui rendrait compte de l'évolution géographique d'une pièce dans une période de temps donnée.\r \r ## Maquette d'une potentielle application\r \r Dans la maquette ci-dessous, nous pouvons observer l'évolution dans le temps d'une pièce donnée. Au centre on voit l'enchaînement des villes où la pièce a été jouée. Une ville peut apparaître plusieurs fois si la pièce y a été rejouée après avoir tourné ailleurs. En bas figure la ligne de temps, qui est sous-divisée par année. A droite, on trouve un cadre avec des boutons qui permettent de choisir le mode de représentation.\r \r Dans la première figure, la taille des cercles qui représentent les villes est liée au nombre de représentations.\r \r ![](https://www.logilab.fr/file/27573054/raw/rcf_hackathon_1.png)\r \r Dans la deuxième figure, la taille des cercles qui représentent les villes est liée au revenu généré.\r \r ![](https://www.logilab.fr/file/27573055/raw/rcf_hackathon_2.png)\r \r Dans la troisième figure, les données sont affichées sur une carte plutôt qu'avec un graphe.\r \r ![](https://www.logilab.fr/file/27573056/raw/rcf_hackathon_3.png)\r \r \r ## Analyse des sources de données\r \r Nous avons choisi de nous focaliser sur les sources déjà publiées dans des entrepôts SPARQL pour deux raisons. D'une part le hackathon était court, donc il fallait éviter de onsacrer du temps à des questions de lecture de formats de fichiers qui ne produiraient aucun résultat visible. D'autre part les gens autour de la table connaissaient déjà bien ces jeux de données. \r \r Nous avons donc privilégié l'utilisation de ces trois sources de données: \r * Les registres de la Comédie Française / [accès sparql](https://rcf-sparql.demo.logilab.fr/)\r * La base CESAR / [accès sparql](https://cesar2.huma-num.fr/)\r * La base ON-STAGE / [accès sparql](https://lod.uba.uva.nl/CREATE/ONSTAGE/sparql/ONSTAGE#)\r \r Nous avons tout d'abord écrit des [requêtes SPARQL fédérées](https://www.w3.org/TR/2013/REC-sparql11-federated-query-20130321/) afin de pouvoir joindre avec une seule requête des données de plusieurs bases.\r \r Ce faisant, nous avons rencontré un premier problème technique, à savoir que l'entrepôt qui héberge les données de la Comédie Française n'était pas configuré pour accepter les requêtes fédérées. Nous avons donc essayé l'inverse, à savoir interroger l'entrepôt de la base CESAR, mais ce dernier repose sur Ontop, qui ne permet pas non plus les requêtes fédérées. Nous avons finalement utilisé l'entrepôt de la base ONSTAGE, déployé avec TriplyDB, pour exécuter une requête fédérée assemblant des données de RCF et CESAR... mais aucune de ONSTAGE. Ceci nous a rappelé que la fédération de requêtes, séduisante sur le papier, est parfois plus compliquée qu'il n'y paraît.\r \r ## Alignement des modèles\r \r Nous avons ensuite cherché quel modèle utiliser pour assembler les données obtenues avec ces requêtes.\r \r La base CESAR décrit des "Séances", qui peuvent être définies comme des ensembles de représentations contigües. Cette notion peut être rapprochée de celle de "Journée" dans le modèle RCF, mais cet alignement n'est pas tout à fait exact puisqu'il est possible qu'il y ait plusieurs "Séances" à la même date, donc plusieurs "Séances" dans une "Journée". Les registres de la Comédie Française ne détiennent pas cette information de "Séance" spécifique et se contentent de considérer uniquement la "Journée".\r \r Ces différences de modélisation sont monnaie courante et nous avons dû, sans surprise, définir un modèle intermédiaire adapté à notre objectif et des opérations de transformation des données pour les convertir de leur modèle d'origine vers ce modèle afin de les fusionner. \r \r Nous avons retenu les notions de Pièce, de Représentation, de Séance et de Lieu.\r \r ![](https://www.logilab.fr/file/27573057/raw/rcf_hackathon_4.png)\r \r ## Alignement des données\r \r L'objectif de notre maquette étant de rendre visible les évolutions des pièces qui apparaissent quand on fusionne les données complémentaires issues des différentes sources, nous avons ensuite aligné les pièces.\r \r Pour cela, nous avons utilisé la date de représentation pour restreindre les candidats à l'alignement, puis le nom de la pièce. Par exemple, nous savons que le 30 septembre 1681 on a joué d'après la base CESAR une pièce 123303 intitulée "Phèdre et Hippolyte" et une pièce 23287 intitulée "Les Fragments de Molière". A la même date, d'après la base RCF, on a joué une pièce 5772 intitulée "Phèdre et Hippolyte ou Phèdre" et une pièce 5396 intitulée "Fragments de Molière (Les)". Avec une simple [distance de Levenshtein](https://fr.wikipedia.org/wiki/Distance_de_Levenshtein) entre chaînes de caractères, nous pouvons aligner les pièces et affimer que 123303 chez CESAR correspond à 5396 chez RCF.\r \r En appliquant ce traitement sur l'ensemble des dates, nous avons obtenu un alignement entre les 49 pièces de CESAR et RCF.\r \r ![](https://www.logilab.fr/file/27573058/raw/rcf_hackathon_5.png)\r \r Vu le temps imparti, nous nous sommes limité aux pièces, mais on pourrait pousser plus loin et par exemple inclure dans le modèle les personnes, puis les aligner en utilisant des critères appropriés.\r \r ## Exploitation des données\r \r Une fois les données importées depuis les différentes sources, converties dans le même modèle et alignées automatiquement entre CESAR et RCR ou une par une pour quelques pièces de ONSTAGE, il devient possible de les exploiter.\r \r Les bases RCF et ONSTAGE ne contenant pas de lieux, nous avons supposé que toutes les représentations RCF étaient à Paris et toutes celles d'ONSTAGE à Amsterdam. C'est probablement faux, donc pour améliorer la qualité du résultat il faudrait trouver des sources complémentaires à partir desquelles importer les lieux exacts des représentations.\r \r Dans le calepin Jupyter qui nous a servi pour consigner nos expérimentations de manière reproductible, nous avons finalement produit le graphique ci-dessous:\r \r ![](https://www.logilab.fr/file/27573059/raw/rcf_hackathon_6.png)\r \r Le menu déroulant en haut à gauche permet de choisir une pièce.\r \r Nous voyons au centre un nuage de points, avec l'année en abscisse et la ville en ordonnée. La couleur des points reflète la source de données et leur taille dépend du nombre de représentations.\r \r L'histogramme au-dessus du graphique est l'aggrégation des données par an pour toutes les villes. L'histogramme de droite est l'agrégation par ville pour toutes les années.\r \r Ce graphique démontre que nous avons produit les données souhaitées, mais il aurait fallu plus de temps pour les représenter comme imaginé en début de hackathon lorsque nous avons dessiné les maquettes graphiques.\r \r ## Conditions de l'interopérabilité et gouvernance\r \r Ce hackathon a mis en lumière pour tous les participants des questions bien connues de ceux qui ont l'habitude de ce genre d'exercice:\r \r 1. un modèle commun est nécessaire pour communiquer entre les bases et celles et ceux qui administrent ces bases\r 2. la qualité des données d'entrée détermine l'efficacité du traitement, c'est à dire le rapport entre la qualité du résultat et l'effort nécessaire pour le produire\r 3. l'alignement est une étape cruciale de la fusion des données issues de plusieurs sources\r 4. les standards du Web Sémantique, et particulièrement le RDF et le SPARQL sont des atouts indéniables pour faire interopérer plusieurs sources de données\r \r Ces constats ont fait émerger, au sein de la communauté présente à ce colloque, la question du partage des bonnes pratiques de publication de données. Effectivement, maintenir un modèle commun d'échange, rédiger une guide de bonnes pratiques pour la publication, accompagner les institutions dans leur parcours d'apprentissage, tout cela est un travail long, mais primordial pour supprimer les obstacles à l'interopérabilité.\r \r Il a été discuté de créer un consortium Huma-Num consacré à la gestion des données du spectacle vivant et à l'expression de ces bonnes pratiques, pour orienter la suite des travaux vers des solutions communes et faciliter les interactions entre les données de différentes institutions.\r \r A Logilab, nous apprécions le travail que nous réalisons depuis plusieurs années pour le projet des Registres de la Comédie François et nous avons été honorés d'être invités à ce colloque. Ce hackathon nous a permis de relier les données de RCF, que nous connaissons bien, à d'autres jeux de données, que nous avons découverts, mais aussi de prendre part aux débats sur leur gouvernance future. Nous espérons pouvoir continuer à apporter nos compétences techniques à ces projets, pour faciliter le travail de recherche sur le théâtre et son histoire.""" ; cw:content_format "text/markdown" ; cw:creation_date "2023-06-26T12:11:52.347386+00:00"^^xsd:dateTime ; cw:cw_source ; cw:entry_of , ; cw:has_creator ; cw:heading "Logilab a participé au hackathon \"Des archives aux données\" organisé par la Comédie Française autour des questions de l'interopérabilité des données du spectacle vivant. Cet article regroupe les réflexions et conclusions autour de cet hackathon." ; cw:in_state ; cw:modification_date "2023-06-26T12:12:04.107000+00:00"^^xsd:dateTime ; cw:title "Hackathon \"Des archives aux données\" 2023" ; dcterms:title "Hackathon \"Des archives aux données\" 2023" ; """1500 mots: ~7min\r \r \r \r Du 1er au 3 juin 2023 a eu lieu le colloque "Des archives aux données" au cours duquel deux jours de hackathon ont permis de s'interroger sur l'interopérabilité des données entre différentes institutions culturelles.\r \r Les données présentées concernaient les représentations théâtrales de la Comédie Française ([Base RCF](https://www.cfregisters.org/)), de la Comédie Italienne, du théâtre d'Amsterdam ([Base On Stage](https://lod.uba.uva.nl/CREATE/ONSTAGE/)) et du théâtre français des XVIIe et XVIIIe siècles ([Base CESAR](https://cesar.huma-num.fr/cesar2/)).\r \r Ce fut l'occasion d'éprouver dans un contexte concret les avantages des technologies du Web Sémantique. Les requêtes fédérées ont en effet permis d'assembler et de manipuler des données publiées sans concertation préalable par les différents participants.\r \r ## Tempête de cerveaux sur les besoins en interopérabilité\r \r Lors de la première journée nous avons commencé par faire émerger des idées de traitements qui nécessitent une interopérabilité des données. Cette session a été très riche et il nous a fallu quelques efforts pour résumér les diverses idées et choisir vers quoi nous diriger.\r \r Nos sources de données divergent principalement sur le périmètre étudié: les registres de la Comédie Française concernent une unique troupe, la base "ON_Stage" se focalise sur le théâtre d'Amsterdam et la base CESAR se limite à une période de temps.\r \r La date des représentation théâtrales a été clairement identifiée comme centrale puisqu'elle permet de les aligner de manière non ambigüe. Chaque source de données décrit différemment les représentations, mais toutes ont renseigné la date.\r \r Les lieux des représentations constituent un autre point de contact, pour autant que les périodes temporelles soient les mêmes.\r \r Partant de ces deux constats, nous nous sommes demandé s'il serait possible d'afficher un graphique qui rendrait compte de l'évolution géographique d'une pièce dans une période de temps donnée.\r \r ## Maquette d'une potentielle application\r \r Dans la maquette ci-dessous, nous pouvons observer l'évolution dans le temps d'une pièce donnée. Au centre on voit l'enchaînement des villes où la pièce a été jouée. Une ville peut apparaître plusieurs fois si la pièce y a été rejouée après avoir tourné ailleurs. En bas figure la ligne de temps, qui est sous-divisée par année. A droite, on trouve un cadre avec des boutons qui permettent de choisir le mode de représentation.\r \r Dans la première figure, la taille des cercles qui représentent les villes est liée au nombre de représentations.\r \r ![](https://www.logilab.fr/file/27573054/raw/rcf_hackathon_1.png)\r \r Dans la deuxième figure, la taille des cercles qui représentent les villes est liée au revenu généré.\r \r ![](https://www.logilab.fr/file/27573055/raw/rcf_hackathon_2.png)\r \r Dans la troisième figure, les données sont affichées sur une carte plutôt qu'avec un graphe.\r \r ![](https://www.logilab.fr/file/27573056/raw/rcf_hackathon_3.png)\r \r \r ## Analyse des sources de données\r \r Nous avons choisi de nous focaliser sur les sources déjà publiées dans des entrepôts SPARQL pour deux raisons. D'une part le hackathon était court, donc il fallait éviter de onsacrer du temps à des questions de lecture de formats de fichiers qui ne produiraient aucun résultat visible. D'autre part les gens autour de la table connaissaient déjà bien ces jeux de données. \r \r Nous avons donc privilégié l'utilisation de ces trois sources de données: \r * Les registres de la Comédie Française / [accès sparql](https://rcf-sparql.demo.logilab.fr/)\r * La base CESAR / [accès sparql](https://cesar2.huma-num.fr/)\r * La base ON-STAGE / [accès sparql](https://lod.uba.uva.nl/CREATE/ONSTAGE/sparql/ONSTAGE#)\r \r Nous avons tout d'abord écrit des [requêtes SPARQL fédérées](https://www.w3.org/TR/2013/REC-sparql11-federated-query-20130321/) afin de pouvoir joindre avec une seule requête des données de plusieurs bases.\r \r Ce faisant, nous avons rencontré un premier problème technique, à savoir que l'entrepôt qui héberge les données de la Comédie Française n'était pas configuré pour accepter les requêtes fédérées. Nous avons donc essayé l'inverse, à savoir interroger l'entrepôt de la base CESAR, mais ce dernier repose sur Ontop, qui ne permet pas non plus les requêtes fédérées. Nous avons finalement utilisé l'entrepôt de la base ONSTAGE, déployé avec TriplyDB, pour exécuter une requête fédérée assemblant des données de RCF et CESAR... mais aucune de ONSTAGE. Ceci nous a rappelé que la fédération de requêtes, séduisante sur le papier, est parfois plus compliquée qu'il n'y paraît.\r \r ## Alignement des modèles\r \r Nous avons ensuite cherché quel modèle utiliser pour assembler les données obtenues avec ces requêtes.\r \r La base CESAR décrit des "Séances", qui peuvent être définies comme des ensembles de représentations contigües. Cette notion peut être rapprochée de celle de "Journée" dans le modèle RCF, mais cet alignement n'est pas tout à fait exact puisqu'il est possible qu'il y ait plusieurs "Séances" à la même date, donc plusieurs "Séances" dans une "Journée". Les registres de la Comédie Française ne détiennent pas cette information de "Séance" spécifique et se contentent de considérer uniquement la "Journée".\r \r Ces différences de modélisation sont monnaie courante et nous avons dû, sans surprise, définir un modèle intermédiaire adapté à notre objectif et des opérations de transformation des données pour les convertir de leur modèle d'origine vers ce modèle afin de les fusionner. \r \r Nous avons retenu les notions de Pièce, de Représentation, de Séance et de Lieu.\r \r ![](https://www.logilab.fr/file/27573057/raw/rcf_hackathon_4.png)\r \r ## Alignement des données\r \r L'objectif de notre maquette étant de rendre visible les évolutions des pièces qui apparaissent quand on fusionne les données complémentaires issues des différentes sources, nous avons ensuite aligné les pièces.\r \r Pour cela, nous avons utilisé la date de représentation pour restreindre les candidats à l'alignement, puis le nom de la pièce. Par exemple, nous savons que le 30 septembre 1681 on a joué d'après la base CESAR une pièce 123303 intitulée "Phèdre et Hippolyte" et une pièce 23287 intitulée "Les Fragments de Molière". A la même date, d'après la base RCF, on a joué une pièce 5772 intitulée "Phèdre et Hippolyte ou Phèdre" et une pièce 5396 intitulée "Fragments de Molière (Les)". Avec une simple [distance de Levenshtein](https://fr.wikipedia.org/wiki/Distance_de_Levenshtein) entre chaînes de caractères, nous pouvons aligner les pièces et affimer que 123303 chez CESAR correspond à 5396 chez RCF.\r \r En appliquant ce traitement sur l'ensemble des dates, nous avons obtenu un alignement entre les 49 pièces de CESAR et RCF.\r \r ![](https://www.logilab.fr/file/27573058/raw/rcf_hackathon_5.png)\r \r Vu le temps imparti, nous nous sommes limité aux pièces, mais on pourrait pousser plus loin et par exemple inclure dans le modèle les personnes, puis les aligner en utilisant des critères appropriés.\r \r ## Exploitation des données\r \r Une fois les données importées depuis les différentes sources, converties dans le même modèle et alignées automatiquement entre CESAR et RCR ou une par une pour quelques pièces de ONSTAGE, il devient possible de les exploiter.\r \r Les bases RCF et ONSTAGE ne contenant pas de lieux, nous avons supposé que toutes les représentations RCF étaient à Paris et toutes celles d'ONSTAGE à Amsterdam. C'est probablement faux, donc pour améliorer la qualité du résultat il faudrait trouver des sources complémentaires à partir desquelles importer les lieux exacts des représentations.\r \r Dans le calepin Jupyter qui nous a servi pour consigner nos expérimentations de manière reproductible, nous avons finalement produit le graphique ci-dessous:\r \r ![](https://www.logilab.fr/file/27573059/raw/rcf_hackathon_6.png)\r \r Le menu déroulant en haut à gauche permet de choisir une pièce.\r \r Nous voyons au centre un nuage de points, avec l'année en abscisse et la ville en ordonnée. La couleur des points reflète la source de données et leur taille dépend du nombre de représentations.\r \r L'histogramme au-dessus du graphique est l'aggrégation des données par an pour toutes les villes. L'histogramme de droite est l'agrégation par ville pour toutes les années.\r \r Ce graphique démontre que nous avons produit les données souhaitées, mais il aurait fallu plus de temps pour les représenter comme imaginé en début de hackathon lorsque nous avons dessiné les maquettes graphiques.\r \r ## Conditions de l'interopérabilité et gouvernance\r \r Ce hackathon a mis en lumière pour tous les participants des questions bien connues de ceux qui ont l'habitude de ce genre d'exercice:\r \r 1. un modèle commun est nécessaire pour communiquer entre les bases et celles et ceux qui administrent ces bases\r 2. la qualité des données d'entrée détermine l'efficacité du traitement, c'est à dire le rapport entre la qualité du résultat et l'effort nécessaire pour le produire\r 3. l'alignement est une étape cruciale de la fusion des données issues de plusieurs sources\r 4. les standards du Web Sémantique, et particulièrement le RDF et le SPARQL sont des atouts indéniables pour faire interopérer plusieurs sources de données\r \r Ces constats ont fait émerger, au sein de la communauté présente à ce colloque, la question du partage des bonnes pratiques de publication de données. Effectivement, maintenir un modèle commun d'échange, rédiger une guide de bonnes pratiques pour la publication, accompagner les institutions dans leur parcours d'apprentissage, tout cela est un travail long, mais primordial pour supprimer les obstacles à l'interopérabilité.\r \r Il a été discuté de créer un consortium Huma-Num consacré à la gestion des données du spectacle vivant et à l'expression de ces bonnes pratiques, pour orienter la suite des travaux vers des solutions communes et faciliter les interactions entre les données de différentes institutions.\r \r A Logilab, nous apprécions le travail que nous réalisons depuis plusieurs années pour le projet des Registres de la Comédie François et nous avons été honorés d'être invités à ce colloque. Ce hackathon nous a permis de relier les données de RCF, que nous connaissons bien, à d'autres jeux de données, que nous avons découverts, mais aussi de prendre part aux débats sur leur gouvernance future. Nous espérons pouvoir continuer à apporter nos compétences techniques à ces projets, pour faciliter le travail de recherche sur le théâtre et son histoire.""" .