L’APIfication des musées et Linked Data à l’ère du Web 3.0
Les collections des musées en tant que patrimoines culturels et historiques d’une société occupent une place particulière dans la mémoire culturelle et sociale de chaque pays. Elles sont aussi importantes que les autres formes d’informations consignées comme la littérature, surtout et en particulier à l’ère numérique. Les caractéristiques spécifiques des contenus numériques en tant que documents soulèvent beaucoup de complexités qui sont reliées à la nature spéciale de ses supports ainsi que les problèmes technologiques et logistiques dans les processus de traitement. Ils impliquent des missions spécifiques pour les institutions publiques dépositaires de ce patrimoine, à l’instar de la Cinémathèque québécoise qui affirme dans son rapport annuel 2016–2017 :
De ce point de vue, les institutions publiques devraient engager une grande politique de numérisation, de diffusion et de mise en valeur de leurs archives, et permettre aussi aux différentes institutions privées qui disposent de fonds d’archives significatifs de les mettre en valeur.
Les professionnels du secteur de l’information et de la muséologie ont commencé de mettre en valeur leurs collections dès l’avènement du World Wide Web, il y a presque 30 ans. La mise en ligne de leurs catalogues a permis un accès plus libre et plus ouvert des collections. De telles initiatives ont souvent portées par le concept d’Open Data et l’interopérabilité offerte par les technologies du web sémantique. Si le Web 1.0 était un Web en lecture seule (« read-only ») conçu pour les humains, son descendant le Web social ou Web 2.0 a offert la possibilité de développer les contenus produits par les utilisateurs, le Web 3.0, également appelé « Web sémantique » quant à lui cible la lisibilité des informations par machine. Selon le consortium du World Wide Web (2015), « Semantic web technologies enable people to create data stores on the web, build vocabularies, and write rules for handling data. Linked data are empowered by technologies such as RDF, SPARQL, OWL, and SKOS .» Avec le développement du Web sémantique et le web de données liées, les professionnels du domaine disposent désormais d’outils technologiques et d’un cadre de travail pour permettre aux utilisateurs d’accéder à des objets associés à travers l’ensemble des collections en ligne. Comme le souligne Vidal, « Les acteurs du patrimoine culturel sont amenés à repenser leurs pratiques, tant pour s’approprier les technologies du Web sémantique (Web 3.0) propres à leur culture professionnelle, que pour proposer des innovations face à une situation socio-économique leurrant les tentatives d’alternative informationnelle, à partir desquelles les publics sont susceptibles d’agir dans le cadre d’usages dits horizontaux, en modérant l’apport des utilisateurs » (Vidal, 2009).
Le Linked Data et les bases de données dans le contexte des musées
Les œuvres conservées dans les collections muséales, sont de plus en plus souvent mises à disposition en ligne sous la forme de données ouvertes et liées. Elles deviennent dès lors accessibles au monde entier par l’intermédiaire d’Internet. Dès lors que ces données sont lisibles par les machines, elles deviennent éminemment partageables : « Technically, Linked data refers to data published on the web in such a way that it is machine-readable, its meaning is explicitly defined, it is linked to other external data sets, and can in turn be linked from external data sets » (Berners-Lee, 2009). Ce qui rend les technologies du web sémantique et les principes des données liées particulièrement précieux c’est notamment leur capacité d’application à toute sortes de domaines et la possibilité de rassembler des collections éparses dans le contexte du numérique :
With an organizational culture that emphasizes open access, a major component of the DPLA model is an application programming interface (API) that provides direct access to aggregated metadata in the form of JavaScript Object Notation for Linked Data (JSON-LD), a linked data format (Mitchell, 2013). As a result, individual LAMs contributing to the growing network of linked open data on the web, even if they are not actively encoding their metadata in a linked data format within their institution. (Angel et Fuchs, 2018)
À cet égard, dans les modèles de Linked Open Data (LOD) la construction des métadonnées partageable est essentielle pour augmenter l’accès, l’interopérabilité et l’échange de l’information. De plus, la gestion de métadonnées est un autre aspect très important dans le traitement des catalogues des musées (Figure 1). Comme le souligne Catherine Lupovici, pour être capable de préserver l’information, et donc de s’assurer de son intégrité et de sa lisibilité, nous devons documenter, à l’aide de métadonnées, plusieurs contraintes techniques relatives au traitement du contenu par la machine. Il y a cinq composantes dans le processus de la préservation d’une ressource numérique : la couche physique, la couche binaire, la couche structure, la couche objet et finalement, la couche application. D’abord, en ce qui concerne la couche physique, on doit collecter les métadonnées permettant l’identification du document et informant sur l’historique de celui-ci (auteur, organisme et unité, titre, signataire, langue, date, etc.) et éventuellement, les métadonnées sur les matériels périphériques. Dans la composante suivante, la couche binaire, les métadonnées du système d’exploitation (nom et version) doivent être conservées. Ensuite, les informations sur le logiciel compatible (la version) qui est en mesure d’interpréter le document préservé doivent être considérées dans les métadonnées. Les informations sur l’interpréteur et le compilateur sont également nécessaires pour s’assurer de pouvoir réutiliser le logiciel. Dans la couche objet seront conservées les informations relatives au format des objets (système de codage). Finalement, les métadonnées qui sont collectées et enregistrées servent à présenter les objets à l’utilisateur à l’aide de certains programmes qui sont conformes aux formats de ceux-ci.
Les objets associés peuvent être liés entre eux dans le contexte du Web sémantique, à leurs éléments de données partagés dans l’environnement en ligne. Le format JSON-LD offre une approche très structurée et efficace pour connecter, non seulement des objets numériques, mais aussi des représentations numériques des objets physiques (Figure 2).
Les API : comment ça fonctionne?
Une API définit le « langage » par lequel un système d’informatique communique. Comme un langage, il a son propre vocabulaire avec des termes qui ont des significations spéciales (par exemple, les noms de propriétés et les étiquettes), la grammaire (comment ces noms de propriétés et les étiquettes sont arrangés — collectivement, son schéma) et la syntaxe (c’est-à-dire comment l’information elle-même est organisée). Nous pouvons donc l’utiliser pour poser des questions et obtenir des réponses. Avec un peu de pratique, elle peut être un outil de communication puissant et extensible.
Une API est donc un ensemble de commandes que les programmeurs informatiques exposent au monde pour permettre à d’autres programmeurs d’effectuer une action sur leurs systèmes (souvent pour récupérer des données). Les développeurs utilisent des API pour prendre des ensembles de données dispersés et les combiner pour créer de nouvelles connaissances. L’API permet d’accéder les données à partir des systèmes externes, afin de les réutiliser de plusieurs façons. Le but de tout cela est de fournir aux utilisateurs du musée de nouvelles applications Web plus intelligentes et utilisables qui peuvent également être utilisés par d’autres applications Web via des interfaces de programmation d’application (API) bien définie.
Semantic linked data is published not only as passive datasets, but as operational services than can be utilized by legacy and other CH applications via open and generic Application Programming Interfaces (API). By utilizing shared ready-made services, application programmers can re-use work done by others, and save their own programming effort and resources. This idea can be paralleled with Google and Yahoo! Maps that provide map services on a global basis to applications via easy to-use APIs for mash-up development. (Handler et Ding, 2012)
Les musées rendent parfois disponibles leurs données par l’intermédiaire de la plateforme de partage de code informatique GitHub dans différents formats comme JSON, CVS et XML. À des fins d’interopérabilité certains catalogues adoptent des modèles de métadonnées basés sur des standards comme par exemple The New York Public Library Digital Collections API qui utilise MODS XML (figure 3) pour la description des objets de sa collection.
Le MoMA utilise quant à lui NetX Web Services API pour gérer l’interface full-web de son API. Celle-ci donne accès à toutes les données et les images haute-résolution des œuvres du musée dans le domaine public en accès ouvert. Selon le documentation de l’interface, les APIs sont disponibles par l’intermédiaire des points d’accès suivants (Figure 4) :
- Objets: une liste de tous les ID d’objet valides disponibles pour l’accès.
- Objet: un enregistrement pour un objet, contenant toutes les données en libre accès sur cet objet, y compris son image (si l’image est disponible sous Open Access)
- Départements: une liste de tous les départements valides, avec leur ID de département et le nom complet du département
- Recherche: liste de tous les ID d’objets pour les objets contenant la requête de recherche dans les données de l’objet
Le défi ici était de trouver un moyen pour faire communiquer la base de données existante TMS avec l’API. Comme il est indiqué dans le site du fournisseur (Figure 5) :
With an existing art database (TMS) full of 130,000 art object records, and a NetX DAM equipped with a Web Services API, the challenge for MoMA was to make these two systems “talk to each other”. More specifically, the systems needed to access and share information on both the metadata associated with each object record (artist, date, medium, title, etc.), and the media for each record (images of front, back, both sides, black and white, color, on display, etc.).
Pour résoudre ce problème, l’API a été configurée par les développeurs pour connecter les deux systèmes afin d’échanger des informations entre eux sur la base du lien commun.
De son côté, l’API de Harvard Art Museums prend la forme d’un service REST (Representational state transfer) conçu pour les développeurs qui souhaitent explorer et intégrer les collections des musées dans leurs projets. L’API fournit un accès direct aux enregistrements détaillés au format JSON-LD (Figure 6) pour plus de 220 000 objets d’art, personnes, expositions, publications, etc. La documentation peut être trouvée sur Github de l’API. Le musée donne également accès à plus de 230 000 manifestes de présentation IIIF pour des objets, des expositions et des galeries via un service séparé. La documentation spécifique à IIIF peut également être trouvée sur Github.
La DPLA (Digital Public Library of America) utilise quant à elle API Codex, une interface qui est constituée d’un ensemble de méthodes définies qu’on peut utiliser pour communiquer avec un système logiciel (souvent complexe) et obtenir des réponses d’une manière qu’un ordinateur, et, avec un peu de pratique, un humain, peut comprendre :
A request is a URL sent to the web server over HTTP with the expectation of getting resource items back in the form of human-readable text or data. The URL supplies the web server with everything it needs to create and return a correct response. This is called a RESTful approach to API design and is employed by the DPLA API (Api Codex).
Le DPLA a mis en place un réseau croissant de « Content Hubs » et de « Service Hubs » (Figure 7)
Dans ce modèle, les hubs de contenu sont des institutions qui fournissent une grande quantité de contenu numérique directement au DPLA. En revanche, les centres de services sont des « state, regional, or other collaborations that host, aggregate, or otherwise bring together digital objects » (DPLA 2016, « Hubs ») produits par ces professionnels pour livraison à DPLA.
Pour les musées, il existe différents facteurs à considérer lors de la sélection et l’implémentation d’un API, comme architecture du système, profils disponibles, interface utilisateur, sécurité, soutien, développement, tarification et gestion de contenu. Nous pouvons partager les données avec un actif numérique externe de systèmes de gestion contenu Web à l’aide de différentes extensions comme Office Connect. Dans certains cas, il est possible d’utiliser un CMS (Content Management System) pour diffuser une collection et un catalogue. Ces logiciels de gestion de contenu permettent de créer et gérer les pages web très facilement en séparant la création du contenu des volets techniques pour l’afficher sur le Web. Dans un logiciel comme Joomla, le contenu est stocké dans une base de données et l’apparence du site est créée par un modelé à la place des codes HTML par exemple. Joomla regroupe le modelé et notre contenu pour créer des pages web. En fait, c’est une façon de gérer un site web à l’aide de modèles pour éviter les inconvénients liés à la gestion et l’édition d’un site web statique page par page et sans la nécessite des connaissances en HTML et CSS. Ces types de CMS libre et open source sont souvent basés sur le langage PHP et associée à la base de données MySQL. Ce qui est très intéressant dans ce contexte est la possibilité d’utiliser les applications comme XAMPP qui offrent un serveur local sur l’ordinateur personnel et qui sont à la fois un serveur web Apache, un serveur de base de données MySQL et un moteur de script PHP ». Les développeurs ont la possibilité de construire et de tester les sites avant la diffusion finale des pages Web.
Les défis
L’adoption des musées au web sémantique est également sujet de plusieurs débats. Comme l’explique Parry :
The dilemma faced by museums, however, hinges on the significant gap between the vision and the reality of the Semantic Web — a gap which critically undermines the ability of the sector to move forward in a clear and constructive way” (Parry, 2008).
Certaines API demandent un code d’accès afin de permettre les utilisateurs ou les professionnels d’utiliser l’interface. Aussi, dans certains cas l’expertise technique est nécessaire pour utiliser l’API. Par exemple l’API de Flickr (figure 8) dispose de fonctions sophistiquées pour téléverser des images avec des métadonnées descriptives.
Il est donc essentiel pour les professionnels du domaine d’enrichir leurs compétences informatiques pour être en mesure de créer, manipuler et faire communiquer les données diverses entre les différentes institutions pour les fins d’interopérabilité et d’accessibilité de données liées. Également, il est nécessaire pour les musées d’avoir les moyens adéquats pour implémenter et utiliser les avantages offerts par le Web sémantique :
La décision d’exposer les données du British Museum dans le format du CRM trouve son origine dans le constat qu’un grand nombre de réalisations dans le Web de données (Linked Data) ne fourniront pas les moyens adéquats pour la prochaine génération de projets collaboratifs dans les humanités numériques. Ces systèmes ne proposeront pas aux institutions les outils nécessaires au passage d’un contrôle restreint des données qu’elles gèrent à un contrôle plus large et mieux localisé en ce qui concerne l’analyse, la modélisation et la découverte de relations entre des connaissances qui leur appartiennent. (Juanals et Minel, 2016).
Finalement, il faut que les musées se dotent de moyens de communication efficaces entre eux afin d’éviter les redondances et les ambiguïtés lors de la création et l’échange de données liées ainsi que régler les enjeux reliés à droit d’auteur et droit d’accès plus facilement. Les musées ont également besoin d’une politique de standardisation de données sur lequel ils peuvent se baser pour une coordination plus efficace et plus claire non seulement entre eux, mais aussi avec les entreprises qui conçoivent et fournissent les données :
En effet, la prolifération de différents modèles, créés sans coordination, peut engendrer un environnement confus et complexe en ce qui concerne l’alignement entre les entrepôts de données et de ce fait limiter la puissance de la technologie du Web de données et ainsi produire des résultats qui ne soient pas supérieurs, en matière d’exposition des données, à ceux qui sont fournis par les systèmes existants. (Ibid.)
Bibliographie
- Angel, Christine M., and Caroline Fuchs. 2018. Organization, representation and description through the digital age: information in libraries, archives and museums. https://doi.org/10.1515/9783110337419.
- Berners-Lee, Tim. 2006. « Linked Data — Design Issues. » W3C , no. 09/20.
- Bizer, Christian, Tom Health, and Tim Burners-Lee. 2009. « Linked Data — The Story so far ». International Journal on Sementic Web and Information Systems 5(3):1–22. Doi:10.4018/jswis.2009081901.
- Hyvönen, E. 2012. Cultural heritage on the Semantic Web. In Publishing and using cultural heritage linked data on the Semantic Web (pp. 1–12). Palo Alto,CA: Morgan & Claypool.
- Juanals, Brigitte, et Jean-Luc Minel. 2016. « La construction d’un espace patrimonial partagé dans le Web de données ouvert. Entre interopérabilité et stratégies institutionnelles ». Communication. Information médias théories pratiques, no vol. 34/1 (17 août 2016). https://doi.org/10.4000/communication.6650.
- Lupovici, Catherine. 2001. Les besoins et les données techniques de préservation. 67th IFLA Council and General.
- Mitchell, Lorna Jane. 2013. PHP Web Services: [APIs for the Modern Web]. First edition. Beijing: O’Reilly Media.
- Oldman, Dominic, Joshan Mhmud et Vladimir Alexief. 2013. « The conceptual reference model revealed », Technical Report, Londres, British Museum.
- Parry, R., et al. 2008. Semantic Dissonance: Do We Need (And Do We Understand) The Semantic Web?, in J. Trant and D. Bearman (eds.). Museums and the Web 2008: Proceedings, Toronto: Archives & Museum Informatics. Consulted December 20, 2020. http://www.archimuse.com/mw2008/papers/ parry/parry.html
- Vidal, G. (2009). Pour en finir avec le Web 2.0 : vers le Web 3.0 dans les musées. Documentation et bibliothèques, 55 (4), 201–207. https://doi.org/10.7202/1029184ar
- Harvard Art Museums API. s.d. Consulté 19 décembre 2020. https://harvardartmuseums.org/collections/api.
- The New York Public Library Digital Collections API. s.d. Consulté 19 décembre 2020. http://api.repo.nypl.org/.
- The App Garden. Repéré à .s.d. Consulté 19 décembre 2020. https://www.flickr.com/services/api/.
