# Lincs

[toc]

## Intro

Bonjour à toutes et tous,

Nous sommes très heureux·ses d’être parmi vous, aujourd’hui, pour vous présenter notre retour d'expérience sur LOD-export, un point de terminaison de l’API de notre base de données relationnelle locale. LOD-export propose une représentation intermédiaire de nos données afin de faciliter leur sémantisation par l’infrastructure LINCS. Ce travail s’inscrit dans le cadre d’un projet de recherche pilote financé par le Conseil des Arts du Canada (CAC), _Pour un commun numérique de l'art public_ (2023-2024). L’objectif de ce projet est d'améliorer la visibilité et l'influence des artistes historiquement marginalisé·es qui pratiquent l'art public. Pour répondre à ces objectifs, nous explorons les potentialités offertes par les technologies du web sémantique.

Ce projet pilote est porté par la Maison MONA, une organisation sans but non lucratif (OSBL) fondée en 2020, dédiée à la mise en valeur de l'art et de la culture dans les espaces publics au Québec. Notre principale initiative est le développement d'une application mobile gratuite, MONA. Elle vise à susciter la curiosité et l'appréciation de l'art public, des espaces culturels et des sites patrimoniaux au Québec. Pour ce faire, nous alignons des données culturelles provenant d’une vingtaine de jeux de données ouverts issus de portails gouvernementaux comme Données Québec afin de les rassembler en un seul jeu de données culturelles stockée dans notre base de données. C’est dans ce contexte, qu’afin de permettre leur sémantisation, que nous avons développé LOD-Export. LOD-Export rend disponible une version toujours actualisée de nos données à LINCS dans le but de faciliter leur agrégation dans leur triplestore. LODExport sert donc de "pierre de Rosette" entre nos données non-RDF et leur représentation CIDOC-CRM.

## Présentation de LOD-export

Pour commencer, LOD-Export, enpoint de notre API REST, retourne un Objet JSON. Celui-ci contient une représentation des données que nous voulons prioritairement sémantiser. Parmi elles, plusieurs ont fait l’objet d’une réconciliation.

Le *Response body* retourné par LOD-Export est structuré de la manière suivante. Nous avons un premier objet « data » qui contient six propriétés ~~(= clefs, valeurs)~~ et un second objet « meta » qui contient les métadonnées de la réponse de l’API. Dans le cadre de cette communication, nous nous focalisons sur le premier objet « data ». Celui-ci, comme nous venons de le mentionner, contient 6 propriétés :
artworks
artists
sources
categories
producers
owners

Ces six propriétés sont des arrays qui contiennent des objets correspondant à des rangées de nos tables dans notre base de données. Par exemple, pour « artworks », nous renseignons les propriétés suivantes: id, title_fr, title_en, produced_at […], artists, source, catégorie, producer et owner.

Pour « artists » : nous retrouvons les mêmes propriétés que dans notre base de données. Nous avons également ajouté une propriété « wikidata_id » pour l’identifiant de l’élement wikidata correspondant et le nombre d’occurences d’œuvres par artiste. ~~Le nombre d’occurrences est également ajouté pour les sources ; les catégories, les producers et les owners. ~~

Les proprietés : artists, producers et owners ont été réconciliées avec les éléments Wikidata correspondants lorsque ces derniers existent. Par exemple, Nadia Myre, une artiste algonquine et membre de la nation Kitigan Zibi Anishinaabe, identifiée dans le base de données par l'identifiant 676, possède un identifiant Wikidata Q19662177. ~~La propriété « catégorie », quant à elle, a été réconciliée avec le vocabulaire structuré *Art & Architecture Thesaurus (AAT)* du Getty. Nous l'utilisons comme source d’autorité. Ce vocabulaire est en effet plus précis car il a été développé spécifiquement pour la description et l’indexation des arts visuels et de l’architecture. Par exemple, la catégorie "murale"  ayant pour id MONA 1 correspondant à l’ID 300033644 du AAT. Ces URI réconciliés sont ensuite ajoutés en tant que propriété à la sortie de LOD-export. ~~

En somme, nous venons de vous présenter le résultat que nous « pensions » obtenir. Toutefois, à cette étape de l’implémentation, nous nous sommes confronté·es à **plusieurs problèmes de standardisation** de nos données que nous n’avions pas suffisamment anticipé.

## Défis de standardisation des données

Le premier problème que nous avons rencontré concerne des **données lacunaires**. Nous possédons des informations sur les œuvres et les artistes qui ne sont présentes dans les jeux de données ouverts. Par exemple, l'initiative Art Public Montréal renseigne un seul artiste pour l’œuvre _Memorial Installation dedicated to four Concordia professors_ (1996) identifiée 468 dans notre base de données, alors que celle-ci a été crée par trois personnes : Eduardo Aquino, Johanne Sloan et Kathryn Walter. Si la premier artiste possède une entrée dans notre base de données, ce n’est pas le cas pour les deux dernières.

Le deuxième problème auquel nous avons du faire face concerne **des données erronées**. Par exemple, les œuvres _Bar Glacé_ d’Axe Lalime (id_MONA, 1119) et _Murale interactive_ du collectif K6A (id_MONA, 1126) possèdent des dates inexactes. En effet, elles sont datées de 1905 alors que les artistes n’étaient pas nés…

Le troisième problème est l’absence totale de réconciliation avec des sources d’autorité telles que Wikidata et les vocabulaires structurés du Getty. C’est pourquoi, nous avons l’ambition d’ajouter cette donnée, comme nous l’avons mentionné précédemment, dans nos tables.

Le dernier problème auquel nous avons été confrontés est le conflit d’autorité entre les sources. Lorsque nous importons, par exemple, une donnée similaire issue de plusieurs sources ouvertes, mais non-identique, cela peut aboutir à la création de deux identifiants différents pour un même artiste. Par exemple, pour l’artiste québécois, Monk.E, qui a réalisé notamment plusieurs murales à Montréal, nous avons deux identifiants dans notre base de données : 248 et 523. La typographie de son nom diffère selon la source de données dont la donnée provient. La première, Art Public Montréal, orthographie son nom de la manière suivante : Monk-E, tandis que la seconde, le jeu de données des murales subventionnées de la Ville de Montréal l’écrit : Monk.E. Cette incohérence typographique s’est également manifestée, dans d’autres cas, comme avec l’artiste Aless MC dont le nom est écrit : « Aless MC » (id MONA 841) par Art Public Montreal, tandis qu’il est écrit « Aless McGovern » id MONA 555) au sein du jeu de données de l'association artistique MU.

En définitive, les défis liés à la standardisation sont relativement communs lorsque des données provenant de plusieurs entrepôts de données ouvertes sont "naivement" agrégées. Cependant, l’étape d’implémentation de nos données dans LOD-export, nous a permis, d'une part, d'améliorer la consistance de nos données, et d’autre part, de réfléchir à une stratégie de standardisation pérenne.

## Phase de normalisation : utilisation d'une base de données en mémoire ; la métaphore de l'égoût

Ainsi, notre stratégie repose sur la normalisation des données issues des portails de données ouverts **au moment de leur entrée dans notre serveur**. Appelée "pré-traitement", cette stratégie permet d'obvier les problèmes de standardisation, en créant un "pipeline" reproductible de données. Celui-ci prend source dans les portails de données ouvertes, passe par notre base de données, et se termine dans LOD-Export.

Ce pré-traitement s'incrit dans un processus consistant à la correction ciblée des erreurs de standardisation grâce à des requêtes SQL. Elles sont stockées dans les _stored procedures_ de notre base de données. Cette solution est pertinente car elle permet d'enregistrer des corrections manuelles en prévision des futurs imports de données. En outre, il est impossible de faire directement des requêtes sur les données des portails de données ouvertes, qui sont principalement en format CSV ou JSON. Pour y pallier, nous utilisons une seconde base de données relationnelle éphémère en mémoire vive, SQLite, qui stocke les données issues des portails. Les requêtes SQL sont alors exécutées dans SQLite, avant l'importation de son contenu dans notre base de données.

Pour illustrer nos cas d'étude, nous avons choisi de vous présenter plusieurs requêtes SQL qui viennent solutionner les problèmes de standardisation susmentionnés : les données lacunaires et erronées, l'absence de réconciliation et les conflits d'autorité entre les sources.

Les requêtes SQL pour remedier aux trois premiers problèmes sont simples.

Le premier exemple de requête concerne les données lacunaires.

### les données lacunaires

Dans l'exemple mentionné plus tôt de l’œuvre _Memorial Installation dedicated to four Concordia professors_ (1996) ayant un artiste renseigné alors que celle-ci a été créee par trois personnes dont un seul artiste, Eduardo Aquino, possède une entrée dans notre base de données. Nous pouvons utiliser une requête `INSERT INTO` pour expliciter l'ajout des entrées pour les deux autres artistes qui n'en ont pas au moment de l'importation des données.

INSERT INTO sqlite_mona_artists (label_fr, external_id) VALUES ("Johanne Sloan", "Q55722862");
INSERT INTO sqlite_mona_artists (label_fr) VALUES ("Kathryn Walter");

Finalement, la valeur originale du champ "artiste" attribuée à l'œuvre devient donc erronée car celle-ci ne fait pas référence à ces nouvelles entrées (création des entrées pour les deux artistes manquants) dans la base de donnée. Nous faisons, par la suite, une requête supplémentaire pour remplacer la donnée erronée par l'ajout des valeurs séparées pour les trois artistes.

Ensuite, le deuxiéme exemple de requête concerne un autre exemple de données erronées.

### données erronées

Pour corriger un cas où une ou plusieurs colonnes d'une entrée contient une valeur erronée comme l'exemple de l'œuvre _Bar Glacé_ (id_MONA, 1119) de l'artiste Axe Lalime avec une date inexacte qu'est 1905. Nous pouvons faire appel à une requête `UPDATE`. Cette requête substitue la valeur erronée par une valeur correcte enregistrée issue d'une correction manuelle.

UPDATE sqlite_artpubmtl SET produced_at = 2020-01-01 WHERE internal_id=1119;

Le troisieme exemple de requête concerne l'absence de réconciliation avec des sources d'autorité.

### absence de réconciliation

Pour remédier à l'absence de réconciliation, nous pouvons, une nouvelle fois, faire appel à une requête `UPDATE`. Cette fois-ci pour inscrire une valeur dans la colonne `external_id` qui est vide par défaut lors de l'ingestion des données des sources ouvertes dans SQLite.

UPDATE sqlite_mona_artists SET external_id = "Q109742798" WHERE id=32;

Le quatrieme et dernier exemple est plus complexe. Pour gérer les conflits d'autorités entre plusieurs sources de données ouvertes, il faut d'une part, définir l'intersection entre les différentes sources de données, et d'autre part, hiéarchiser leur ordre d'importation dans notre base de données.

### conflits d'autorité entre les sources

Contrairement aux exemples précédents de problèmes de standardisation, pour un conflit d'autorité entre les sources, comme c'est le cas des différentes typographies de l'artiste Monk.E selon les sources de données ouvertes, nous ne pouvons seulement recourir aux requêtes SQL.

En effet, plusieurs aspects sont à considérés:

Premièrement, pour régler ce conflit, nous attribuons le même identifiant à l'artiste identifié comme Monk.E issue de chaque source de données en lui renseignant une valeur pour le champ `artist_internal_id`. En définitif, cette étape nous permet d'expliciter que Monk.E, dont la typographie différe d'un jeu de données à l'autre est le même individu.

UPDATE sqlite_artpubmtl SET artist_internal_id = 523 WHERE id=32;
UPDATE sqlite_domontreal SET artist_internal_id = 523 WHERE id=105;

Une fois, cette étape terminée, nous copions ces données contenues dans SQLite dans notre base de données en établissant un ordre de préseance défini entre les sources de ces données. La source jugée la plus fiable, ici la Ville de Montréal, est importée en dernière, de sorte à écraser la valeur "Monk-E" issue d'Art Public Montréal au profit de "Monk.E". C'est à ce moment que le _merge_ des sources est faite.

## Conclusion

Pour conclure, cette courte communication visait à présenter notre retour d'expérience, ou autrement dit l'état actuel du développement de LOD-export, qui je le rappelle, vise à faciliter la sémantisation de nos données par l'infrastructure LINCS. Nous avons été confrontés à plusieurs problèmes de standardisation de nos données que nous n'avions pas suffisamment anticipé : données lacunaires et erronées, absence de réconciliation et conflits d'autorité entre les sources. De ce fait, nous avons entamé un travail rétrospectif sur la consistance de nos données qui nous a permis de réfléchir à une stratégie de standardisation pérenne de nos données portée par la mise en place dans notre workflow d'une banque de requêtes SQL et d'une instance SQLite dans laquelle elles seront executées. À terme, cette stratégie permettra le pré-traitement nécessaire de nos données avant leur implémentation dans LOD-Export et ainsi facilitera leur sémantisation a posteriori.

# The Challenges of Semantisation in a Dynamic Workflow

[toc]

## Intro (Simon) // [Slide 1]

Good morning everyone,

We are very happy to present our retrospective, reflecting on our experiences thus far on LOD-export. It's an endpoint of the API of our local relational database and it gives an intermediary representation of our data with the goal of facilitating their semantisation using LINCS' infrastructure.

[Slide 2]

This effort is a part of a pilot research project supported by the Canada Council for the Arts (CCA) called _Towards a digital commons of public art_ (2023-2024). The goal of this project is to shed light on historically marginalised artists creating public art. To achieve this goal, we're exploring the possibilities offered by semantic web technologies.

[Slide 3]

This pilot project is an undertaking by Maison MONA, a non-profit organization founded in 2020 dedicated to the highlighting of art and culture in Québec's public spaces. Our main initiative is the development and maintenance of a free mobile application, MONA, which aims to foster curiosity for and appreciation of public art, cultural spaces, and heritage sites in Quebec. To accomplish this, we align cultural data sourced from twenty open datasets from various governmental open data portals such as Données Québec into one cultural dataset stored in our own database.

[Slide 4]

It is with the goal of semantisation of our data, that we are developping LOD-export. LOD-export makes available an always-up-to-date version of our data in order for LINCS to ingest it into their triplestore. LOD-export can therefore be thought of as a "Rosetta stone" between our non-RDF yet normalised data, and their CIDOC-CRM representation.

[Slide 5]
## Presenting LOD-Export (Camille)

To begin with, LOD-Export, an endpoint of our REST API, returns a JSON object. This object contains the data we want to prioritise in our data's semantisation. Many data point contained within it have been reconciled using Open Refine.

The response body returned by LOD-Export is structured as follows. We have a first object, "data", which contains six properties and a second object containing metadata for the response. The metadata is outside of the scope of this talk, we will focus on the former, "data". As we have mentioned, this field contains 6 subfields:

- artworks
- artists
- sources
- categories
- producers
- owners [oooners]

These six properties are arrays containing objects corresponding to the rows of tables in our relational database.

[Slide 6]
For example, in "artworks", we present the following properties for each item: id, title underscore fr, title underscore en, produced underscore at [...], artists, source, categorie, producer, and owner.

[Slide 7]
For "artists", we see all of the same properties recorded [recordit] in our database. Of note is the "wikidata_id" property which identifies the wikidata entry corresponding to an artist in our database. The number of occurences in the artworks is also appended [apandete] to the artists, sources, categories, producers, and owners when displayed in LOD-Export so we can prioritize the most common entries in our [awer] database when reconciliating our data.

[Slide 8]

As mentioned [menchenite] we store the wikidata entries corresponding to the artists in our database when they exist, and we also do the same for the producers and the owners. For example, Nadia Myre, an algonquin artist, member of the Kitigan Zibi Anishinaabe nation, identified in our database by the ID 676 (six seven six), has a wikidata URI, Q19662177. (like this one)

(Simon)

In short, we've presented what we expect LOD-Export's response to look like following the completion of its development. At this stage however, we are confronted with many standardisation problems regarding our data which we had not sufficiently anticipated.

[Slide 9]

## Challenges of data standardization (Camille)

The first problem we have confronted concerns **incomplete data**. We possess information on the artworks and artists which aren't present or misrepresented in the open portal datasets. For example, *Art Public Montréal* provides us with a single artist for the artwork _Memorial Installation dedicated to four Concordia professors_ (1996) (ID 468 in our database) despite the artwork having been created by 3 people : Eduardo Aquino, Johanne Sloan, and Kathryn Walter. The first artist has an entry in our database but the other two do not.

[Slide 10]

The second problem we have faced concerns **erroneous data**. For example, the artworks _Bar Glacé_ by Axe Lalime (id_MONA 1119) and _Murale interactive_ by the K6A collective (id_MONA 1126) are recorded with inaccurate dates. In fact, both artworks are dated to 1905 (nineteen 0 five) when the artists hadn't been born yet.

[Slide 11]

The third problem is the total **absence of reconciliation** with authorities such as Wikidata and Getty's structured vocabularies. This is why we wish to completely add this data to our databaseS tables. [taibleS]

[Slide 12]

The final problem to which we have been confronted is the **conflict of authority** between open data sources. When we import similar data points provided by multiple open data sources, this can result in the creation of multiple differing internal IDs for what should be a single data point.

For example, for the Québécois artist Monk.E, who produced [producet] multiple murals in Montreal, we have two IDs in our database : 248 (two, four, eight) and 523 (five, two, three). The typography of his name differs in the two open data sources. We obtain his artworks' data from. Art Public Montréal writes his name "Monk-E", with a hyphen, while the Montreal municipal government's dataset of financed [finenancet] murals writes his name with a period: "Monk.E".

(Simon)

Ultimately, these challenges of data standardisation are relatively common when dealing with data provided by multiple open data stores that have been naively agregated. Meanwhile, implementing LOD-Export has allowed us, on the one hand, to improve the consistence of our data, and on the other, do conceive of a sustainable, robust standardisation strategy.

[Slide 13]

## Normalization stage. Using an in-memory database; the wastewater treatment metaphor (Simon)

Our strategy is founded on the idea of normalizing the data incoming from the open data portals **before they enter our database**. This pre-treatment strategy allows us to obviate the problem of managing multiple correction strategies when presenting data aggregated naively. It can be thought of as an "assembly line" of reproducible corrections to our data that begins at the open data portals and ends at LOD-Export.

[Slide 14]

The pre-treatment consists of a bank of targetted SQL queries acting as a sort of "patch" to the ingested open data. These SQL queries are stored in our main database's _stored procedures_. This solution is relevant as it allows us to store the corrections we must do manually in prevision for future imports of our data.

Furthermore, it isn't possible to directly apply these patches to the data as it is received from open data portals in CSV or JSON format. To compensate for this incoherence, we use an in-memory, ephemereal, auxiliary relational database, SQLite, which temporarily stores the open data for the pre-treatment, and which allows the execution of SQL queries on this data. Once this pre-treatment is done, the corrected contents of SQLite are copied to our main database.

(Camille)

To illustrate our case studies, we have chosen to present a variety of simple SQL queries which solve the mentioned challenges: incomplete and erroneous data, absence of reconciliation, and authority conflicts between sources.

(Simon)
The first example concerned incomplete data.

### incomplete data - [Slide 15]

In the previously mentioned example where the _Memorial Installation dedicated to four Concordia professors_ (1996) had a single artist when in reality the artwork has three creators of which only one, Eduardo Aquino, is in our database, we can use an `INSERT INTO` SQL query to explicitly add the missing information. We can therefore create new artist entries for the two other artists which don't get entries during our old naive importation strategy.

INSERT INTO sqlite_mona_artists (label_fr, external_id) VALUES ("Johanne Sloan", "Q55722862");
INSERT INTO sqlite_mona_artists (label_fr) VALUES ("Kathryn Walter");

The original "artist" field for the artwork therefore becomes erroneous as it doesn't reference the newly created artist entries. For this example, we'll need an additional query to update the erroneous field so that it includes all three artists.

Next, the second SQL query concerns another erroneous data example.

### erroneous data [Slide 16]

To correct the case where one or more columns for a row contain erroneous data, such as in the example of _Bar Glacé_ (id_MONA 1119) by Axe Lalime with the inaccurate date of creation, 1905, we can call an `UPDATE` query. This query simply substitutes the erroneous values with correct ones initially recorded manually.

UPDATE sqlite_artpubmtl SET produced_at = 2020-01-01 WHERE internal_id=1119;

The third query example concerns the absence of reconciliation with authority sources.

### absence of reconciliation [Slide 17]

To remedy the absence of reconciliation, we can once again use an `UPDATE` query. This time we use it to inscribe a value in the `external_id` column which exists only within our databases and which defaults to empty during importing of open data into SQLite. This column stores, in our database, the external URIs with which we would like to reconcile our data.

UPDATE sqlite_mona_artists SET external_id = "Q19662177" WHERE id=32;

The fourth and final example is more intricate, as it necessitates an understanding of our data import process to elucidate it. We need to, on the one hand, define the intersection of our open data sources, and on the other, order the sources in terms of priority.

### authority conflicts between sources [Slide 18]

Unlike the previous examples of standardisation challenges, for an authority conflict between sources, as is the case with the aformentioned Monk.E typography issue, we cannot only rely on a simple SQL query.

In fact, a couple of aspects are to be considered:

Firstly, we must define what the intersection is between the data sources. This is done by attributing the same target internal identifier to both instances of Monk.E by affecting the same value for a column called `artist_internal_id` in the tables corresponding to both sources. This step allows us to explicitly state that Monk.E and Monk-E are the same individual.

UPDATE sqlite_artpubmtl SET artist_internal_id = 523 WHERE id=32;
UPDATE sqlite_domontreal SET artist_internal_id = 523 WHERE id=105;

Secondly, once this step is done, we can copy the data from the tables in SQLite corresponding to the different sources one table at a time, following an established order of precedence. The source considered to be most trustworthy, in this case the municipal government of Montreal, is copied over last, overriding the previous "Monk-E" value with the desired "Monk.E". It is at this step that a _merge_ of the values is done.

## Conclusion (Camille)

In conclusion, this short communication aims to present our retrospective working on LOD-Export so far, or in other words, the current state of LOD-Export. As a reminder, LOD-Export serves to ultimately facilitate the semantisation of our data using LINCS' infrastructure. We were confronted to a number of standardisation challenges that we had not sufficiently anticipated: incomplete and erroneous data, absence of reconciliation, and conflicts between our sources. From this, we have established the basis of a durable standardisation strategy leveraging "patches" based on stored SQL queries and an SQLite instance on which we can execute them. In the long term, this strategy will cement a necessary pre-treatment of our data before they can be shared using LOD-Export and therefore facilitate their semantisation *a posteriori*.