[toc]

# Plan d'attaque

D’ici vendredi, j’écris un premier draft de l’intro

Vendredi 19 avril :
- Reprise des notes
- Presentation // Résultat de LOD-export + exemple de table reconciliée (catégories i guess ?)
- Problèmes liés à la standardisation ; exemples de données

D’ici lundi, je reprends les notes de la reunion de vendredi pour écrire un premier draft
Simon :
- Draft schéma de la chaine de travail entre le portail de données ouvertes et LOD-export
- présenter sqlite temporaire
- Exemples de requêtes sql pour les corrections

Lundi 22 avril :
- Reprise des notes
- Pre-traitement : entre l'importation du portail de données ouvert et la BD MONA

Mercredi 24 avril :
- séance d’écriture de la dernière partie
- Reprise globale
- Draft conclusion

Semaine du 29 :
- Version finale de notre présentation
- Traduction
- Support visuel
- Entraînement à l’oral

https://www.culture.gouv.fr/Thematiques/Innovation-numerique/Faciliter-l-acces-aux-donnees-et-aux-contenus-culturels/Web-semantique-outils-pratiques

# Presentation // Résultat de LOD-export + exemple de table reconciliée (catégories i guess ?)

## Structure LOD_export vs notre BD

- endpoint API REST accessible par Http, donc accessible publiquement sur le web. endpoint retourne un fichier json.
- base de données contient x tables ==> une transformation ; nouvelle présentation (ajout nb Occurences)
- Ce fichier contient plusieurs fields (artworks, artistes, sources, categories, producers et owners) qui correspondent aux tables de notre bd relationnelle qui contiennent les données que nous voulons sémantiser. Dans LOD-export, on identifie les URI issues d'autorite issues d'une reconcilisation (wikidata et Getty) ==> un artiste avec wikidata et categorie avec le AAT du Getty

*OpenRefine*

Dans ce que nous venons de présenter, pour que ça fonctionne y'a un hidden assumption (qqch d'implicite) que nous n'avons pas mentionné, c'est qu'il faut que nos données soient "propres".

A cette etape de l'implementaiton, nous nous sommes rendus compte que ce n'etait pas le cas

## Defis de standardisation : Monk-e ?

pas d'informations que nous avons car les données des portails ouverts sont importes dans la BD MONA

Conflits d'autorité entre les sources (ID)
- ArtPublic Montréal vs Données Québec vs Données Ouvertes de la ville de Mtl. @to do Monk-e (deux ids à l'interne)

Problemes de différentes typographies

toujours avec l'exemple de Monk-e

incohérences des données
- source plus précise que l'autre
- informations genre de location pas différences

pas de reconciliation avec les autorités de Wikidata et du Getty

- il faut affecter un id pour chaque entree dans notre BD qui vienne d'une autorité (qui soit deja existant ou que nous le creons )
+ correction au besoin : données lacunaires : nous avons des informations sur des oeuvres ou des artistes que les jeux de donnees ouvertes ne nous donne pas // données lacunaires : le cas de Johanne Sloan et Kathryn Walter, existent pas dans notre base de données
- données erronées
- un artiste qui en fait sont 3 = pas ids MONA pour deux d'entre eux
- artworks 1119 et 1126 (dates erronées)

==> (defis de standardisation qui sont assez communs quand on importe de n'importe quel portail de donnees ouvertes // mais ce qui est interessant dans ce processus de travail retroactif (on regarde nos données), grâce a LOD-export, nous nous sommes rendus comptes de ces "erreurs" // "qualité" de nos données // cohérences // agglomerations des sources differentes

- vue ensemble globale de nos données, ca passe quasiment inapercu
- depends de l'utilisation

----
# Notes, draft de plan
16 et 17 avril 2024

Introduction @cam

- contexte :
- projet Towards a digital commons of public art financé par le CAC. @cam
- but du projet @cam

- on travaille à la "semantisation" de la base de données MONA par l'infrastructure Lincs qui offre....

presenter d'ou viennent nos données
- agrégation de nombreuses sources de données ouvertes dans notre bd (les citer)
- objectif de les rendre disponibles à Lincs pour les "semantiser"
- pierre de rosette : LOD-Export
- but de LOD-export, endpoint de notre API qui permet à Lincs d'avoir toujours une selection de nos donnèes qui soient actualisées quand les jeux de donnèes issus des portails de données ouvertes le sont aussi.

Presentation // Resultat de LOD-export @cam et simon
- une représentation "intermédiaire" de nos données
- "pierre de rosette" de nos données
- structure // fichier Json

Nous pensions que nos données étaient cleans, mais au moment du developpement de LOD-export, nous nous sommes rendus compte que non.

nous avons rencontré plusieurs défis liés à la standardisation : @cam et @simon
- conflits d'autorités entre les sources
- données erronnées
- données lacunaires
- problemes de différentes typographies
- pas de reconciliation avec les autorités de Wikidata et du Getty

==> (defis de standardisation qui sont assez communs quand on importe de n'importe quel portail de donnees ouvertes // mais ce qui est interessant dans ce processus de travail retroactif (on regarde nos données), grâce a LOD-export, nous nous sommes rendus comptes de ces "erreurs" // "qualité" de nos données // cohérences

---

Comment nous résolvons ces pbs ? @cam et simon

Décrire le processus à partir d'un exemple et comment nous l'avons corrigé
- Deux options possibles :
- post-traitement : entre BD MONA et LOD-Export
- pre-traitement : entre l'importation du portail de données ouvert et la BD MONA

- On a commencé par choisir la premiere option mais on s'est vite rendu des nombreux desavantages
- en gros ce qu'on vous a montré avant

- Finalement, on s'est tourné vers la seconde option
- normalisation en amont au moment de l'importation des données
On utilise Laravel, serveur de MONA (framework), on peut definir des commandes a executer ==> cad l'importation des jeux de donnees ouverts vers notre base de données :
Laravel nous permet d'avoir des connexions a plusieurs points d'acces, on peut aussi generer une base de donnees ephemere et temporaire aka sqlite (en mémoire vive)
interet de pv creer un sqlite, faire des traitements aux donnees des sources ouvertes grâce a des requetes sql, avant l'importation de notre base de donnees principale
car les requetes sql que nous voulons faire sont focalisées sur des petites corrections sur les données "ouvertes"
corrections pour regler les problemes susmentionnés

- sqlite temporaire @simon
- nos corrections sont des requetes sql @simon

Conclusion
- un gros travail de plusieurs mois
- presentement : on peut vous donner ça:
- a terme, au dela de ce projet là

- idée de ne pas faire peur à Lincs, gros travail mais nous devons quand même leur fournir quelque chose, donc c'est leur dire nous sommes capables de vous donner ça pour le moment, mais finalement cette démarche de recherche-action nous amene à reconsidérer "l'ensemble de notre chaine de travail" + parler de ça pour Cultiver ?

- démarche de recherche-action
- idée de workflow dynamique
- travailler avec une timeline
- fluidité // "mécanisation" de la chaine de travail

## Phase de normalisation. Le cas d'utilisation d'une base de données en mémoire

Post traitement?

Nous avons choisi de normaliser les données issues des sources de données ouvertes au moment de leur entrée dans notre serveur. Nous appelons, pré-traitement, cette approche. Nous avons choisi cette stratégie, afin d'obvier les problèmes de standardisation susmentionnées liées à "un post-traitement".

Ce pré-traitement consiste à la correction ciblée des erreurs de standardisation susmentionnées avec des requêtes SQL. Ces requêtes sont stockées dans les _stored procedures_ de notre base de données.

Sous forme de csv ou de JSON, il n'est pas possible de faire directement des requêtes sur les données des portails de données ouverts. Pour y pallier, nous utilisons une seconde base de données relationnelle éphémère en mémoire vive, SQLite. Celle-ci permet de corriger les données venant des PO avant leur entrée dans notre base de données principale.

Phrase de transition : exemple de requêtes SQL
# Exemple SQL

## Problème d'autorité

Supposons deux oeuvres provenant de deux sources différentes sont la même.

Plusieurs choses à considérer:

1. Nous importons les données une source à la fois, avec les sources ayant plus d'influence en dernier pour qu'elles viennent remplacer les valeurs moins bonnes. On décide de l'ordre d'importation.

2. On peut préserver la valeur d'une source moins prioritaire en supprimant la modification qui serait porter par la plus récente. Il faut donc s'assurer que si une valeur est NULL, qu'elle ne se fera pas copiée à la base de données MONA. La base de données est vidée à l'importation de toute façon. (Est ce que ça peut causer problème si l'importation dure trop longtemps?)(on peut pt cache toutes les appels d'API et à l'importation ou suite à une modification dans l'interface admin, flush le cache)

`UPDATE sqlite_artpubmtl SET titre_en = NULL WHERE id=32;`

3. On peut aussi forcer un identifiant MONA spécifique pour une oeuvre importée en lui donnant une valeur pour `internal_id`. Si cette colonne contient une valeur pour une entrée, celle-ci sera ajouté à la bonne oeuvre dans la base de données interne.

`UPDATE sqlite_artpubmtl SET internal_id = 789 WHERE id=32;`

### Problème de typographie

Il suffit de faire un appel à update tout simplement:

`UPDATE sqlite_artpubmtl SET produced_at = 1932-04-22 WHERE id=32;`

### Problème d'incohérence

Ce problème sera régler par l'ordre d'importation.

## Ajout de données propres de MONA (données lacunaires)

Cette fois-ci par la construction d'une requête INSERT
`INSERT INTO sqlite_artpubmtl (internal_id, label_fr, external_id) VALUES (32, "SbuOne", "Q109742798");

## Ajout d'un identifiant wikidata/getty

Encore une fois, il suffit de peupler la colonne `external_id` avec la command UPDATE:
`UPDATE sqlite_artpubmtl SET external_id = "Q109742798" WHERE id=32;`

---

# Abstract : The challenges of semantisation in a dynamic workflow
The Forward Linking conference

[Maison MONA](https://monamontreal.org), a non-profit organization founded in 2020, is dedicated to highlighting art and culture in public spaces in Québec. Our main initiative is the development of a free mobile app, MONA: it aims to spark in the public curiosity for, and appreciation of, public art, cultural spaces and heritage sites. To do so, we align cultural data originating from multiple governmental open data portals to generate a rich, diverse and complex panorama as a sort of “meta” cultural collection stored in our local relational database.

In the context of a research project funded by the Canada Council for the Arts (CAC), [_Towards a digital commons of public art_](https://monamontreal.org/projets/recherche.html), our goal is to improve visibility and influence of historically marginalized artists practicing public art. We seek to achieve this using semantic web technologies in collaboration with [Linked Infrastructure for Networked Cultural Scholarship](https://lincsproject.ca) (LINCS). We are putting in place an API endpoint, LODExport, which presents our data in an intermediary representation to facilitate its aggregation in LINCS' infrastructure, all the while remaining responsive for future additions. LODExport serves as a 'Rosetta Stone' between our non-RDF data and its CIDOC-CRM representation at LINCS. LODExport's development has brought to light numerous challenges including semantic reconciliation, that we would like to share in this paper

# Biographie

**Simon Janssen** is a MA student in computer science at the University of Montreal's *Département d'Informatique et Recherche Opérationnelle*. His research focuses on static analysis of concurrent programming languages. Additionally, he has a particular interest in semantic web technologies. He has worked with MONA since 2021 as a developper and maintainer of MONA’s backend infrastructure. He is currently collaborating with Maison MONA in the context of a MITACS research partnership.

**Camille Delattre** is a PhD candidate in art history specializing in museum studies and student in the Certificate in Digital Humanities program at the University of Montreal. Her research aims to develop a digital documentary model based on the CIDOC-CRM ontology, specified on performance art, to address the challenges posed by its conservation.
Since 2022, she has been coordinator of Axis 4 "la collection partagée" with the research partnership [*Des nouveaux usages de colletions dans les musées d'art*](https://cieco.co/fr/projets/partenariat). In the same year, she also joined Maison MONA as Director of Operations, and more recently as Data Structuring Coordinator for the [_Towards a digital commons of public art_](https://monamontreal.org/projets/recherche.html) project funded by the Canada Council for the Arts.