Skip to content

blockchain, intelligence artificielle et fonds spéculatifs

13/07/2017

Je ne vous ai finalement pas beaucoup parlé de la blockchain, et je n’ai pas suivi les innovations autour de cette technologie autant que je l’aurais souhaité (de manière générale, j’avoue que je blogue moins et je veille moins depuis quelques mois). Pour ceux qui débutent et en voudraient une vision claire, je vous recommande vivement cet article Minimum viable block chain, que j’ai renoncé à traduire en français, mais ce n’est pas bien car il en vaut la peine : il reprend l’explication des mécanismes traditionnels d’un échange marchand, et comment le dispositif de blockchain, avec ses clés publiques et privées, vient se substituer au rôle de l’Etat (ou plutôt vient rendre inutile le rôle d’un Etat) comme garant de la pérennité de la valeur d’une monnaie fiduciaire. Éclairant !

Parmi les sujets que cet article aborde, il y a les smart contracts : les contrats intelligents. Le principe est le suivant : vous développez un programme, et le publiez dans une blockchain, de manière à ce qu’il soit in-modifiable (et tout le monde peut le vérifier). Ce programme prévoit que si une personne, correspondant à certains critères (ce peut être une personne identifiée, une société prestataire, ou n’importe qui — ça va dépendre de qui accède aux conditions du contrat) réalise une action que le programme peut constater, celui-ci active une récompense (ou tout autre type de conséquence).

Un récent article donne l’exemple de smarts contracts inscrits dans une blockchain appliqués au monde de la prévision des cours en bourse : si quelqu’un prévoit une évolution, mise de l’argent pour la société qui a développé ce contrat, et que la société y gagne des sous, elle rémunère le « quelqu’un ». S’il s’est planté, il perd ses jetons.

C’est un peu plus subtil que ça, évidemment, mais le mieux est de lire l’article.

Ce que cet article nous apprend par ailleurs du monde de la finance et de la spéculation, je ne gloserai pas là-dessus : je n’ai aucune des compétences nécessaires pour avoir une opinion légitime, donc la mienne ne vaut pas plus que celle que vous entendriez au café du coin, et vaut certainement moins que la vôtre.

En revanche je trouve que ce genre d’exemple permet de se projeter davantage dans un univers de travail collaboratif, où on pourrait récompenser les participants : inciter à tagger des ressources, à reprendre un OCR, etc.

On en est encore très loin, mais je trouve la perspective intéressante. Deux grandes marges de progression :

  • envisager sur quels genre de services, et avec quels genres de « récompenses », cela pourrait être envisagé
  • s’approprier les outils permettant de créer un smart contract
Publicités

« Vers de nouveaux catalogues » : quelles questions, quelles réponses ?

02/05/2017

J’ai fini récemment Vers de nouveaux catalogues, paru aux Editions du Cercle de la Librairie sous la coordination d’Emmanuelle Bermès (l’introduction est en ligne sur Figoblog).

J’avoue avoir eu un peu de mal à me le procurer : il y avait une file d’attente pour le lire au service de documentation professionnelle interne de la BnF !

L’ouvrage veut rendre compte, à travers l’ensemble de ses contributions (table des matières), de ce que sera l’avenir des catalogues. Le procédé est le suivant : chaque contributeur essaie de rendre compte, à travers un retour d’expérience précis illustrant le propos (la plateforme data.bnf.fr, la FRBRisation des données, le projet SGBm du réseau Sudoc, le futur data lake de l’INA, etc.), de lignes de fond qui permettent d’anticiper ce que seront les catalogues demain.

A un ou deux articles près, l’équilibre, assez complexe à tenir, entre retour pratique et propos plus théorique, est très bien tenu par leurs auteurs. Les exemples donnés sont concrets, mais le propos ne s’en tient pas à dérouler simplement l’histoire : il en tire des conclusions, dégage des grandes logiques.

Parmi celles-ci : les catalogues seront (de plus en plus) alimentés par des flux, les informations seront enrichies, les notices ne seront qu’une manière de visualiser l’information (article de Raphaëlle Lapôtre sur la datavisualisation, et de Gautier Poupeau sur l’éclatement des notices en données), leur gestion sera de plus en plus collaborative — la description stricte des documents ne sera finalement qu’un type de contenu parmi d’autres, de ce que les bibliothèques diffuseront à leurs internautes, après avoir agrégé et produit des informations sur leurs ressources. L’ouvrage est l’occasion d’avoir aussi une bonne synthèse sur l’état d’avancement de la transition bibliographique : c’est le bon moment, car de plus en plus de bibliothèques se demandent comment, concrètement, y participer1.

Participer à cette évolution, c’est précisément à quoi ce livre prépare : en rendant compte des enjeux pour les prochaines années, à partir d’observations les plus récentes.

Il serait formidable dès que possible y adjoindre un tome 2 ! En effet, en dépit de tout l’intérêt que j’ai porté à chacun des articles, j’en suis sorti frustré par l’absence de contribution qui rendrait compte des nouveaux usages chez nos publics. En effet, si nos catalogues évoluent, c’est aussi pour s’adapter à l’évolution des pratiques et des attentes des lecteurs, chercheurs, réutilisateurs de nos données : l’utilisation quotidienne de Google crée un horizon d’attente, de même que la politique de l’open data (chapitre de Romain Wenz).
Les bibliothèques s’efforcent de suivre pour faire évoluer à la fois leurs données et leurs interfaces — mais concrètement, aujourd’hui, quelles tendances observe-t-on ? Quand c’est pour consulter les documents, quelles stratégies les internautes utilisent-ils ? Quand ils en font un autre usage (lequel ?), comment s’en servent-ils ? Quelle porosité dans les pratiques de navigation entre Amazon, un catalogue de bibliothèque, une plateforme illégale de téléchargement de fichiers ePub ?
Je serais bien incapable d’en dire quoi que ce soit — mais justement, je crains que si beaucoup d’entre nous ont des intuitions là-dessus, il serait utile d’en avoir connaissance d’une manière plus objective, plus statistique, plus méthodique.
D’autant plus lors d’une phase de transition, pour s’assurer que les projections envisagées il y a quelques années sont toujours en phase avec les pratiques constatées aujourd’hui.

Une autre interrogation implicite qu’induit la lecture de l’ouvrage : comment favoriser l’acculturation et l’appropriation de ces problématiques par la profession ? Le livre y répond ainsi : « Lis-moi ! » Le conseil est bon.

———————————————————

1. J’y reviendrai sans doute plusieurs fois cette année

Le modèle de données de data.bnf.fr évolue

24/04/2017

Pour des raisons de tambouille interne, data.bnf.fr — que ce soient les données ou l’interface — a peu évolué ces derniers mois.

Mais voici que pointe une mise à jour du modèle de données qui n’est pas tout à fait anodine si vous voulez extraire des infos en partant d’éditions (par exemple un ISBN) pour remonter à leur auteur (par exemple) — ou l’inverse.

La mise à jour corrige notamment un bug ou l’expression était redoublée sans aucune raison.

Avant

 

Maintenant

(ça ressemble beaucoup. Les différences sont dans le quart inférieur gauche)

Il n’y a plus qu’une seule expression — en revanche l’auteur se retrouve avec 3 URI :

  • l’ARK « pur », préfixé http://data.bnf.fr/, désigne le concept : forme retenue, formes rejetées ; et gère les métadonnées de la notice : date de création et de modification
  • l’ARK avec suffixe #foaf:Person, qui désigne la personne elle-même, et porte encore la plupart des propriétés de cette personne (date de naissance, etc.)
  • l’ARK avec suffixe #about, qui pour l’instant ne supporte que la mention d’auteur de l’expression — mais à terme remplacera le #foaf:Person

Cette modification est en effet première étape vers un modèle cible où tous les objets (distincts des concepts dont ils partagent l’ARK, mais avec une URI propre à eux)  seront désignés avec une URI dont le suffixe sera #about (au lieu de #frbr:Work, #foaf:Person, #foaf:Organization, etc. comme c’est le cas actuellement)

Attention

J’en profite pour redire une chose importante que j’ai déjà eu l’occasion de signaler ici :

  • Il y a dans data.bnf.fr 8.911.627 manifestations
    Seules 9%
    d’entre elles sont liées à des oeuvres (772.468 aujourd’hui)
  • Si on ne regarde que les textes (en excluant la musique, les films, etc.) :
    seules 6% des manifestations sont liées à des oeuvres (418.673 sur 7.029.163 manifestations)
    En revanche 45% sur les 598957 expressions de type Sound sont liées à des entités « oeuvres » (les règles de catalogage sont un peu différentes, la conséquence en est qu’il y a une plus grande proportion de notices d’oeuvres musicales)

La plupart du temps, le modèle (actualisé) est donc plutôt celui-ci :

Par conséquent, si vous voulez obtenir la liste des ouvrages d’un auteur, ne passez pas forcément par les œuvres.

En effet n’existent comme notices d’œuvres dans data.bnf.fr que celles qui ont un jour été créées dans le catalogue pour des besoins d’indexation (la première étude paraît sur le Da Vinci Code -> on crée une notice d’oeuvre Da Vinci Code, qui se retrouve du coup dans data.bnf.fr).

Par conséquent les œuvres qui n’ont pas fait l’objet d’études de la part d’autres œuvres n’existent pas sous forme de pages dans data.bnf.fr : vous n’y retrouverez que les éditions successives.

Ça devrait changer dans les mois à venir, avec le projet de création automatique d’œuvres, mais ce sera nécessairement très progressif, et pendant longtemps très partiel.

Assurer la pérennité des requêtes SPARQL

Si vous avez peiné pour produire une requête SPARQL qui marche — enfin, qui marchait bien dans l’ancien modèle de données : pas de panique.

Il vous suffit de rajouter en première ligne de la requête :

DEFINE:input same-as "yes"

Ainsi la base de triplets commencera à reporter les propriétés d’une ressource sur toutes les autres ressources qui sont en relation owl:sameAs avec elle.

De la sorte, la ressource « Auteur » en #about récupèrera aussi les propriétés « Nom », « Date de naissance », etc. de la ressource #foaf:Person.

La requête SPARQL décrivant un graphe suivant le chemin de la manifestation à l’auteur, en passant par l’expression, sera ainsi toujours valide.

Pour plus de détails sur le modèle de données

La documentation est beaucoup plus fournie et détaillée sur la page de data.bnf.fr présentant le modèle de données

Ce qui ne va pas dans data.bnf.fr

08/12/2016

Résumé : ne sont versées dans data.bnf.fr que les notices d’autorité identifiées dans le catalogue comme « validées », et leurs notices bibliographiques associées. Cela induit-il un biais sur la constitution du corpus que constitue data.bnf.fr, comme représentatif ou non du catalogue de la BnF ?


Autant le dire tout de suite : le titre est un mauvais jeu de mots pour être le plus accrocheur possible. Son sens est très certainement autre que ce que vous pensiez en cliquant dessus1.

En fait, data.bnf.fr est constitué, pour 99% de son contenu, par des données issues du catalogue général de la BnF.

Pourtant, il n’y a que ~80% du contenu du catalogue qui arrive dans data.bnf.fr. Qu’est-ce qui fait que certaines choses n’y sont pas ?

Il me semble utile quel mécanisme génère cela (quel est le système de « sélection »), et prendre surtout ensuite le temps d’insister sur les conséquences quand on manipule les données de data.bnf.fr.

Le principe des biais

De manière plus générale, je vais essayer de publier une série de billets sur les biais dans data.bnf.fr : j’ai tendance à vouloir utiliser cette base comme un reflet suffisamment complet de la production éditoriale, au point que quand on veut avoir une approche statistique, les résultats sont représentatifs.

Je veux dire par là que même s’il manque un cinquième du catalogue, les informations qu’on pourrait tirer de data.bnf.fr (comme « les livres sur le sujet ‘laïcité’ progressent dans les années 2000 de x% ») resteraient vrais si on observait la totalité du catalogue, parce que la manière dont le « tri » technique s’effectue n’a rien à voir avec l’indexation sujet, donc la proportion d’ouvrages sur la laïcité par année devrait être la même dans le catalogue et dans data.bnf.fr.

Logiquement oui. Pourtant c’est à nuancer. Mais commençons par le commencement : qu’est-ce qui ne va pas dans data.bnf.fr ?

Le transfert des données, du catalogue à data.bnf.fr

Le catalogue est — sans étonner personne — constitué de deux grosses bases :

  • les notices bibliographiques
    ce qui inclut les notices de monographies et de périodiques, bien sûr, mais aussi les notices de spectacles, de collections, et d’ensembles éditoriaux (comme ce dernier concept n’est pas forcément familier à tous, voici un exemple : cet ensemble regroupe la série de enquêtes de Harry Bosch par Michaël Connelly, chez Calmann-Lévy à partir de 2012)
  • les notices d’autorité
    notices d’auteurs et de collectivités, notices Rameau et Dewey, notices d’œuvres (créées pour les besoins d’indexation, lorsqu’elles servent d’entrée sujet à d’autres ouvrages), etc.

Il existe évidemment de nombreux liens entre notices d’autorité et notices bibliographiques.

nnb_nna

Or la longue, complexe (et douloureuse ?) histoire du catalogue à la BnF explique qu’il y a naturellement eu des périodes de catalogage à la chaîne, pour rétroconvertir sur ordinateur des millions de fiches bibliographiques, en créant à la volée des notices d’autorité. Sans forcément s’assurer d’abord que l’auteur n’existait pas déjà. Ou sans disposer d’éléments biographiques (autre que « Nom, Prénom », mentionnés dans la notice bibliographique).

Donc face à un livre d’un certain Jean Martin :

  • dans certains cas, dans le doute, on rattachait l’ouvrage à une notice d’autorité déjà existante
  • dans d’autres cas, dans le doute, on créait une nouvelle notice d’autorité, sans beaucoup d’informations

Donc on se retrouve aujourd’hui avec des notices d’autorité qui sont déclarées comme auteurs d’ouvrages écrits en réalité par plusieurs homonymes ; et des notices d’autorité qui doublonnent inutilement avec d’autres.

Mais rassurez-vous : la BnF consacre beaucoup de temps et d’ETP à corriger le problème (on s’est même doté d’un tout nouvel outil, qui s’appuie sur les algorithmes déjà utilisés dans data.bnf.fr, pour conduire des chantiers de manière automatisée ou semi-automatisée). Mais comme il y a 5 millions de notices d’autorité…

Actuellement, il y a :

Or dans data.bnf.fr, on ne veut exposer que les informations « validées ». Donc on prend toutes les notices d’autorité validées, toutes les notices bibliographiques qui leurs sont associées, et on envoie tout ça dans data.bnf.fr.

C’est ainsi qu’on a dans data.bnf.fr 50% des notices d’autorité, et 80% des notices du catalogue.

Est-ce que c’est grave ?

La question que je me pose n’est pas tant : est-ce le bon choix de laisser le côté des notices d’autorité élémentaires avec toutes leurs notices bibliographiques (qui, elles, sont potentiellement correctes) ? Celle-là, j’y reviendrai peut-être un autre jour mais pour l’instant je la laisse de côté.

Non, la question pour aujourd’hui, c’est : est-ce que ça empêche de faire comme si data.bnf.fr était représentatif (statistiquement parlant) du contenu du catalogue, donc du dépôt légal, donc grosso modo de la production éditoriale française (je laisse de côté, faute de compétences, la question de l’écart entre dépôt légal et production réelle) ? Est-ce que ça empêche d’exploiter data.bnf.fr comme source bibliographique pour une analyse historique et statistique de la société française ?

A vue de nez, il me semble que c’est relativement neutre.

  • Sauf que, par exemple, en l’état, ça surreprésente les grands auteurs par rapport à ceux qui n’ont écrit qu’un seul livre : parce que les grands auteurs sont les premiers qu’on aura pris la peine de corriger et d’en faire des notices d’autorité « validées ».
  • De même, ça surreprésente les auteurs récents, parce que de combler les vides biographiques d’auteurs du XIXe siècle dont on ignore tout (sauf qu’ils ont écrit le livre qu’on a entre les mains), c’est plus compliqué

Pour le vérifier de manière un peu plus satisfaisante, on pourrait tenter une approche comparative sujet : par exemple en comparant l’évolution du sujet « laïcité » dans le catalogue et dans data.bnf.fr, au fil des années. Mais l’approche sujet est tributaire de la politique d’indexation, et Rameau n’apparaît que dans les années 1980.

Comparaison concrète : titre contient « science »

Voici tout de même une évolution comparée de la présence du terme « science » dans les titres dans le catalogue et dans data.bnf.fr.

Requête dans le SRU du catalogue, en Python(non accessible hors BnF pour le moment)

# -*- coding: utf-8 -*-
from lxml import etree

ns = {"srw":"http://www.loc.gov/zing/srw/", "m":"http://catalogue.bnf.fr/namespaces/InterXMarc","mn":"http://catalogue.bnf.fr/namespaces/motsnotices"}
url = "http://xxx.bnf.fr/SRU?version=1.2&operation=searchRetrieve&query=Title%20any%20%22science%20sciences%22&recordSchema=InterXMarc_Complet"
resultats = open("D:/resultatsSciencecatalogue.txt","w")
url = (url+"&").replace("&&","&")
firstPage = etree.parse(url)
nbResultats = int(firstPage.find("//srw:numberOfRecords",namespaces=ns).text)
nbPagesResultats = round(nbResultats/20)
i = 1
while (i < nbResultats):
    urlPage = url + "startRecord=" + str(i)
    page = etree.parse(urlPage)
    for record in page.xpath("//m:record",namespaces=ns):
        nnb = record.get("Numero")
        date = ""
        if (record.find("m:controlfield[@tag='008']",namespaces=ns) is not None):
            date = record.find("m:controlfield[@tag='008']",namespaces=ns).text[8:12]
        resultats.write(nnb + "\t" + date + "\n")
    i = i+20

Requête SPARQL pour « titre contient science »

PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX bnf-onto: <http://data.bnf.fr/ontology/bnf-onto/>
select ?decennie (count(?manif) as ?nbManif) where {
  ?manif a <http://rdvocab.info/uri/schema/FRBRentitiesRDA/Manifestation>.
  ?manif dcterms:title ?titre.
  ?manif bnf-onto:firstYear ?date.
  BIND (concat(substr(str(?date),1,3), "0") as ?decennie)
  FILTER (regex(?titre, "science")).
  FILTER (?date > 1599)
}
ORDER BY ?decennie

Arrondi à la décennie près, voici la proportion de notices bibliographiques du catalogue versées dans data.bnf.fr comme manifestations :

part_du_cg_dans_databnf

J’ai fourni le code des requêtes pour que ceux qui s’en sentent le courage puissent m’indiquer les éventuelles erreurs de méthode que j’aurais pu faire : car je ne trouve pas d’explication à ce graphique. Notamment le fait que pour les années 2000-2015, il n’y aurait que 30% du catalogue dans data.bnf.fr.

Il est clair que les 2 requêtes ne sont pas équivalentes :

  • dans le catalogue, on cherche les titres contenant les mots « science » ou « sciences »
  • dans data, on filtre sur les manifestations dont le titre contient la chaîne de caractère « science »

Mais même dans l’hypothèse où une requête différemment formulée permettrait de retrouver une plus grande partie du catalogue dans data.bnf.fr, l’évolution chaotique de cette courbe me laisse très perplexe.

Au passage, il me semble que l’interprétation d’un pourcentage ne sera pas la même si « 100% » correspond à 100, ou  à 100.000 notices. Du coup voici le même graphique, enrichi de 2 courbes secondaires permettant de voir de quelle volumétrie on parle, à chaque décennie :

sciences-dans-catalogue-et-data

L’info principale reste la courbe bleue, qui se cale sur l’axe vertical gauche (en pourcentages). Mais pour qu’on sache de quelle volumétrie il est question, j’ai ajouté les 2 courbes correspondant à la volumétrie stricte des notices concernées (en rouge pour le catalogue, en vert pour data.bnf.fr) ; et ces 2 courbes fines sont tracées en fonction de l’axe de droite.

Comparaison concrète : Strasbourg

Voici un tout autre angle d’approche : la mention éditoriale qui contient le mot « Strasbourg » (pour les textes imprimés uniquement, en évacuant les objets signalés dans le catalogue pour les besoins de Gallica, mais pas dans data.bnf.fr pour le moment) dans le catalogue et dans data.bnf.fr.

 

strasbourg_cg_data

Le graphique me semble plus facile à expliquer : les notices récentes, de meilleure qualité, sont plus souvent présentes dans data.bnf.fr.

Nombre de notices, par année

Et pour comparer le tout, voici le nombre de notices (ou, dans data.bnf.fr, de « manifestations ») par décennie : % des notices du catalogue dans data.bnf.fr, nombre total de notices dans le catalogue, nombre total de notices dans data.bnf.fr

pourcentagecataloguedansdata

Quelle question on se pose, déjà ?

Ma question de départ, c’est : pour avoir une approche globale, statistique, puis-je considérer que data.bnf.fr réagit (en proportions) comme le catalogue, et que je peux donc interpréter les grandes masses que je trouve dans data.bnf.fr comme s’il s’agissait du catalogue ?

J’avoue avoir du mal à interpréter les 3 courbes ci-dessus (mais sans doute n’ai-je pas posé les bonnes questions), mais selon que je cherche un lieu d’édition, ou la présence d’un mot (assez générique) dans un titre, la proportion des notices trouvées, par année, n’a pas la même allure que la proportion globale des notices.

Le dernier graphique m’indique que pour la période 1400-1950, environ 50% du catalogue est dans data.bnf.fr. Et ensuite on passe à 80%.

Mais les 2 graphiques précédents n’ont pas vraiment les mêmes caractéristiques. Donc « l’échantillon » que je peux exploiter dans data.bnf.fr, comme export du catalogue, ne peut pas être considérer comme uniformément représentatif du corpus global.

Je vous laisse réagir et me suggérer quelles questions poser, ou quelles réponses apporter à mes égarements ?

——————
↑↑ 1. je suis lucide : espérer être raccoleur en parlant de data.bnf.fr est voué à l’échec]

Si c’est un lieu #hackathonBnF

20/11/2016

J’ai participé avec beaucoup de plaisir au premier hackathon organisé par la BnF ce week-end du 19-20 novembre. J’y étais pour apporter en cas de besoin une aide sur des questions de format, ce qui veut dire notamment que je n’ai eu aucune responsabilité à assurer sur les questions logistiques. J’étais donc concentré sur le fond, et ce fut une expérience vraiment sympa, sans stress (je le précise car d’autres ont dû être davantage happés par les aspects organisationnels, et ont dû en ressortir plus fatigués).

J’en profite pour saluer le travail des collègues de la BnF qui ont bossé dur pour que ça se déroule bien (il me semble que ce fut le cas), et féliciter l’équipe qui a été déclarée gagnante : @Gallicarte (site web / extension Chrome1).

Leur projet : proposer une navigation cartographique dans les résultats de Gallica, pour les documents qui possèdent une information de lieu. Question : comment, dans les données disponibles, un document est-il associé à un lieu dans Gallica.

Leur premier point d’entrée : voir si le document contient une indexation sujet de type Lieu.

(d’autres modalités ont été évoquées : lieux du déroulement de l’histoire que contient le document numérisés, si ces lieux sont listés dans Wikidata – exemple avec Le Comte de Monte Cristo, propriété Narrative location ; extraction de cette info dans les tables des matières)

Et donc c’est une occasion pour moi de parler un peu de data.bnf.fr. En effet quand vous avez une indexation Sujet, comment savoir (automatiquement) que ce sujet désigne un lieu ?

Le problème

Imaginions que vous tombiez sur ce document (parmi d’autres)

Fontaine du Pot de fer St Marcel (1671) - Rue Mouffetard : [photographie] / [Atget] -- Licence Etalab

Fontaine du Pot de fer St Marcel (1671) – Rue Mouffetard : [photographie] / [Atget] — Licence Etalab

Dans les métadonnées, accessibles à partir de l’identifiant ARK du document (et exposées via le protocole OAI, en Dublin Core) vous trouverez les infos suivantes :

Fontaines -- France -- Paris (France) -- 17e siècle
Paris (France) -- Rue Mouffetard
Paris (France) -- Rue du Pot-de-Fer
Paris (France) -- Fontaine du Pot-de-Fer

Comment distinguer ce qui est « sujet » de ce qui est « lieu » ?

La solution

Logiquement :

  1. les documents numérisés dans Gallica sont indexés en Rameau.
    Sauf exception : indexation avec le vocabulaire des noms de lieu du Département des Cartes et Plans (exemple)
  2. Rameau est dans data.bnf.fr
  3. Rameau est découpé en 8 sous-ensembles
  4. Chaque concept est rattaché à l’un de ces sous-ensembles par la propriété dcterms:isPartOf
  5. La famille des Lieux a pour URI : http://data.bnf.fr/vocabulary/scheme/r167

On peut exporter la liste des familles de concepts à travers une requête comme celle-ci :
(à noter que pour certaines de ces familles, le label n’est pas fourni dans le Sparql Endpoint, mais c’est un bug destiné à disparaître)

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select distinct ?sousensembleRameau ?label where {
 ?ressource a skos:Concept.
 ?ressource dcterms:isPartOf ?sousensembleRameau.
 OPTIONAL {
    ?sousensembleRameau rdfs:label ?label.
  }
}
ORDER BY ?sousensembleRameau

Ce qui signifie que pour chaque indexation Sujet entrée dans un document de Gallica, on peut vérifier si dans data.bnf.fr elle est liée à la famille r167.

Donc si on dispose d’une indexation, il « suffit » de récupérer l’URI du concept à partir de son label, et de voir si cette URI est rattachée au groupe r167. Par exemple pour la première entrée , la requête suivante renvoie 0 résultat

PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX dcterms: <http://purl.org/dc/terms/>
select ?concept where {
  ?concept skos:prefLabel "Fontaines -- France -- Paris (France) -- 17e siècle"@fr.
  ?concept dcterms:isPartOf <http://data.bnf.fr/vocabulary/scheme/r167/>.
}

Alors que pour la seconde indexation « Paris (France) — Rue Mouffetard », la même requête renvoie bien l’URI

La récupération ou non de l’URI est une manière de faire test « lieu : oui/non ». Et donc ensuite de choisir d’afficher le document sur une carte.

Recherche Auteur = Atget sur Gallicarte

Recherche Auteur = Atget sur Gallicarte

Addendum : si on tombe sur une indexation géographique « Cartes et plans », on les identifie dans data.bnf.fr comme étant de type wgs84_pos:SpatialThing (exemple)

Une URI, deux URI, tralalalalère

13/11/2016

Cherchez pas à comprendre le titre, je l’ai pris comme une évidence sous le coup de l’inspiration

Interpellé de bon matin par Gautier Poupeau sur Twitter, un week-end de pont (faut-y être sadique ! ou obsessionnel !) sur nos URI et nos alignements dans data.bnf.fr, je trouve que l’occasion est excellent pour faire un petit récapitulatif de la situation.

Bien sûr, pour ceux qui ont déjà été confrontés à de la modélisation RDF, je n’apprendrai rien. Mais je suppose qu’il en reste quelques-uns qui ne sont pas encore passés par là : donc voici le problème.

Au commencement était le Verbe

Cas d’école : vous voulez exposer en RDF un lot de notices de personnes (que ce soient les auteurs dans votre catalogue, ou les chercheurs dans votre annuaire universitaire). Vous allez attribuer à chacun d’entre eux une URI (généralement construite à partir de l’identifiant interne dans votre base de données) et affecter un certain nombre de propriétés à cette ressource.

Par exemple si votre base de données contient l’info :

vian_boris

Vous allez pouvoir exposer les triplets suivants, adossés aux ontologies FOAF + BIO qui vous fournissent les propriétés nécessaires :

<http://mon.univ.fr/123456> rdf:type foaf:Person
<http://mon.univ.fr/123456> foaf:familyName"Vian"
<http://mon.univ.fr/123456> foaf:givenName "Boris"
<http://mon.univ.fr/123456> bio:birth "1920-03-10"

La première ligne est essentielle : pour toute ressource exposée, on prend la peine de préciser de quoi on parle (ce qui est logique dans une base de données interne, n’a rien d’évident une fois exposé sur le web, récupéré, décontextualisé, etc.)

Maintenant, vous avez aussi une table des pseudonymes, et vous voulez exposer la liste des pseudonymes de Boris Vian.

sullivan

Pour lister des « formes alternatives » (ou « autres dénominations ») l’ontologie SKOS est très pratique : elle vous permet de définir des skos:altLabel en plus du (non répétable) skos:prefLabel.

Le plus simple et tentant serait donc d’écrire :

<http://mon.univ.fr/123456> skos:altLabel "Sullivan, Vernon"

Ben oui mais non : la propriété skos:altLabel ne peut avoir pour sujet qu’un skos:Concept. Or la ressource identifiée par l’URI <http://mon.univ.fr/123456&gt; n’est pas de type skos:Concept mais de type foaf:Person.

Une personne a une date de naissance. Un concept a, au mieux, une date de création (c’est-à-dire généralement la date de création de la notice). Ce sont donc deux choses bien distinctes.

Bref, si vous voulez utiliser à la fois les propriétés de FOAF et celles de SKOS, il va vous falloir deux ressources distinctes (le concept et la personne), donc deux URI distinctes, chacune avec ses propriétés, et un lien entre les deux.

Ce lien s’exprimera sous la forme : http://uri_du_concept foaf:focus http://uri_de_la_personne1

Dans data.bnf.fr, c’est propre…

Il y a plein de choses à revoir dans le modèle de data.bnf.fr, très certainement. Mais pour cette question-là, la distinction est bien faite : Boris Vian a

Et on a bien les triplets

<http://data.bnf.fr/ark:/12148/cb13091689x> rdf:type skos:Concept
<http://data.bnf.fr/ark:/12148/cb13091689x#foaf:Person> rdf:type foaf:Person

Chacune de ses URI a les propriétés adaptées qui lui sont associées : la date de naissance est attribuée à la personne, les formes alternatives (pseudonymes) sont attribuées au concept.

… ou presque

Les 5 étoiles du linked data

Les 5 étoiles du linked data

Mais on a un effet de bord, dû à la philosophie même de ce qu’est le web de données liées.

On s’efforce de lier autant que possible des ressources BnF à d’autres référentiels, de construire les équivalences.

Cela permet au réutilisateur des données de les enrichir facilement, en allant récupérer par exemple ailleurs la photo de Boris Vian si data.bnf.fr.

Par exemple, DBpedia (qui reste au centre du graphique Linked open data cloud dans sa version la plus récente — août 2014, avant la montée en puissance de Wikidata) fournit une propriété foaf:depiction avec photo.

Les données de data.bnf.fr sont donc alignées avec DBpedia. En soi, c’est une bonne idée. C’est même un minimum.

Malheureusement DBpedia n’a pas fait le même effort de modélisation. Et au lieu de distinguer 2 URI pour chaque ressource (faut reconnaître que ça peut compliquer la modélisation pour les modélisateurs, et la réutilisation pour les réutilisateurs), chaque ressource est tout simplement déclarée comme étant à la fois le concept et la personne.

personne_et_concept

Donc dans data.bnf.fr, devons-nous lier à DBpedia notre URI concept ou notre URI personne ?

Devons-nous exposer le triplet

<http://data.bnf.fr/ark:/12148/cb13091689x#foaf:Person&gt; owl:sameAs <http://fr.dbpedia.org/resource/Boris_Vian&gt;

ou le triplet

<http://data.bnf.fr/ark:/12148/cb13091689x&gt; skos:Concept <http://fr.dbpedia.org/resource/Boris_Vian&gt;

En fait, les deux alignements ont été déclarés dans data.bnf.fr. Cela nous conduit à une erreur dans notre propres données, puisque par déduction (on dit inférence) ça signifie que nos deux ressources, le concept et la personne, sont une seule et même chose.

Comment faire ?

On aurait pu imaginer de ne conserver qu’un de ces deux triplets. Par exemple, retenir que l’URI de DBpedia désigne la personne Boris Vian (avec date de naissance, etc.) et ne garder que l’équivalence :

<http://data.bnf.fr/ark:/12148/cb13091689x#foaf:Person&gt; owl:sameAs <http://fr.dbpedia.org/resource/Boris_Vian&gt;

Mais le résultat n’est pas tellement plus heureux : en effet l’URI DBpedia a comme propriété (entre autres)  rdf:type skos:Concept

Par inférence, cela revient à dire que notre foaf:Person est donc de type skos:Concept

Le problème est identique si l’on décide de lier notre URI concept à l’URI DBpedia : par inférence, notre concept serait donc aussi une personne.

Enfin bref, dès lors qu’on se lie à une ressource DBpedia de ce type-là (il y a beaucoup de types de ressources dans DBpedia, bien plus que dans data.bnf.fr, donc j’ignore si le problème se pose systématiquement), on créer une incohérence sur notre propres données.

En voulant enrichir nos données, sans même importer d’information de DBpedia, on en vient à les polluer. La seule conclusion logique serait donc de s’interdire de se lier à DBpedia.

En tout cas c’est la seule que j’envisage. Et je ne la trouve pas plus satisfaisante.

——————————————–
1. Je trouve d’ailleurs curieux que ce soit l’ontologie FOAF, et non l’ontologie SKOS, qui fournisse une propriété permettant de relier la chose (ici la personne) à son concept. En effet dans plein de cas on aura autre chose que des personnes (des objets, des événements, des documents), toutes sortes de choses du monde réel (même si skos:Concept est lui aussi une sous-classe de owl:Thing, puisque tout est chose et que les concepts, comme Internet, font partie du « vrai » monde) pour lesquelles on aura besoin de les associé à leur fiche SKOS — sans pouvoir utiliser foaf:focus, dont le sous-domaine (l’objet) est nécessairement un foaf:Agent (personne ou organisation).

SemWeb.Pro 2016 : c’est dans moins de 15 jours !

09/11/2016

SemWeb.Pro, c’est une journée de conférences et de rencontres autour de réalisations dans le web de données.

L’événement essaie de regrouper plusieurs domaines d’activités qui ne se rencontrent pas nécessairement dans la vraie vie : culture, industrie, services, etc.

Cette année, ce sera le lundi 21 novembre, dans le 14e arrondissement de Paris.

Et le programme vaut le coup de venir y faire un tour ! [Conflict of interest disclosure : j’ai participé à son élaboration]

Côté culture, il y aura notamment Isidore & Nakala, Persée, ISTEX, Biblissima. C’est donc l’occasion de se mettre à jour sur lces acteurs nationaux

Mais il me semble que, quand on vient des bibliothèques, un des enjeux de ce genre de journées est plutôt de se confronter à d’autres univers que nous connaissons moins, et dont les objets ne sont pas bibliothéconomiques : parce que c’est justement en découvrant les démarches issues d’autres milieux qu’on peut apprendre d’autres façons de penser, repartir avec des idées différentes.

Bref, une occasion à ne pas manquer.

Dernier intérêt de cette journée : sa date. SemWeb.Pro arrive juste au bon moment s’il vous reste quelques dizaines d’euros dans votre budget annuel, que vous ne savez pas trop comment dépenser. En l’occurrence, ce sera d’ailleurs plus un investissement qu’une dépense.