Mettre nos données en réseau – un démonstrateur. [1] Introduction.

Ce démonstrateur est un plaidoyer en faveur d’une approche “web sémantique” de l’interopérabilité des données de l’IST. Mais, cette fois, il s’agit de montrer et non d’argumenter. Il s’agit de défendre, en illustrant cette approche par des études de cas. Alors, si vous fuyez les plaidoyers, si vous exigez du concret, de la donnée (RDF), de la requête (SPARQL), passez cette introduction et lisez l’un des billets suivants :

  1. Introduction (ce billet)
  2. Inventaire des données
  3. Suivez le guide ! Le modèle de données
  4. Études de cas

SPARQL endpoint : https://lod.abes.fr/sparql
Interface de recherche full text et de navigation : https://lod.abes.fr/fct

Pourquoi ce démonstrateur

Mettre nos données en réseau, c’est structurer et publier nos données conformément aux principes et aux bonnes pratiques du web sémantique.
Nos données, ce sont à la fois les données produites par les réseaux ABES (Sudoc, Sudoc PS, Thèses, Calames) mais également  toutes ces données voisines, complémentaires produites par les éditeurs, l’administration, les institutions culturelles, les institutions dédiées à l’information scientifique et technique (IST).
Ce périmètre est par définition extensible : par exemple, si nos données, ce sont d’abord les métadonnées de thèse électronique produites ou importées dans STAR, ce sont également les informations sur l’équipe de recherche (RNSR, HAL, IdRef), l’école doctorale (Ministère, IdRef), l’entreprise qui finance le contrat CIFRE (ANRT), les articles du doctorant (HAL et autres archives, éditeurs), la production du directeur de thèse (HAL, éditeurs), les vocabulaires contrôlés qui décrivent le contenu (RAMEAU, MeSH, tel vocabulaire spécialisé, etc.), les bibliothèques qui possèdent telle thèse, etc.
Second exemple : nos données, ce sont d’abord les métadonnées des articles acquis dans le cadre d’ISTEX (ISSN, Sudoc), mais ce sont également les métadonnées des revues, des fascicules et des volumes, les métadonnées des auteurs (IdRef, ISNI, VIAF, ORCID, HAL, Persée, Wikipedia, etc.), les affiliations, les vocabulaires contrôlés, les métadonnées sur le package commercial correspondant à l’acquisition (BACON, GoKB), la licence, les bibliothèques couvertes par la licence, etc.

lodcloud
Troisième et dernier exemple : pour savoir que tel auteur est affilié à l’université Paris 4, on a besoin de remonter le courant : de telle notice Sudoc à tel auteur IdRef, puis à tel auteur HAL, puis à tel document HAL, puis à telle équipe de recherche du référentiel HAL, puis à cette même équipe dans le référentiel RNSR, équipe rattachée à Paris 4. Il existe un chemin plus court, mais dans tous les cas, il faut être agile, rebondir d’une base à l’autre, d’un organisme à l’autre.
ist_organismes

L’information est par définition extensible. On ne peut définir a priori le périmètre des données qui correspond à nos besoins. La gestion de l’information doit être aussi extensible que l’information elle-même.
Et précisément, les technologies du web sémantique sont faites pour ça : établir des liens effectifs entre données complémentaires, sans fixer à l’avance ni le périmètre des données, ni la nature de ces liens.

Une base RDF + des requêtes SPARQL

Ce démonstrateur n’est rien d’autre que l’agrégation de données RDF brutes au sein d’une seule base de données. Si ce n’est préparer et documenter ces données, nous n’avons rien fait d’autre : ni construction d’index pour interroger les données, ni développement d’un web service de recherche, ni réalisation d’une interface graphique. Nous nous sommes contentés de charger ces données brutes dans une base RDF supportant le langage de requête SPARQL : ipso facto, nos données sont devenues interrogeables, consultables, navigables.

Pour interroger nos données, il suffit de se rendre à cette adresse : https://lod.abes.fr/sparql et de lancer une requête SPARQL. SPARQL est un langage très puissant, qui demande un apprentissage progressif. Mais tous les billets de cette série proposent des exemples de requête. Ce sont de bons points de départ. Si vous vous prenez au jeu, forgez vos propres requêtes et les jugez intéressantes, merci de les partager en commentaires.
SPARQL est un langage mais également un protocole web , c’est-à-dire un web service : https://lod.abes.fr/sparql n’est donc pas seulement une page web pour fans des données, mais également l’URL principale d’un web service de recherche qui permet à n’importe quel programme d’interroger une base RDF et d’en exploiter les résultats sous différents formats (HTML, XML, CSV, JSON, etc.). Grâce  à SPARQL, nous pourrons offrir une API standard pour interroger de manière sophistiquée les corpus ISTEX, par exemple, en complément de l’API de recherche développée par l’INIST. On a besoin des deux : une base de données ouverte et un moteur de recherche ouvert.
Si vous n’êtes ni un geek ni un programme, vous avez la possibilité de vous promener dans les données de notre base via cette interface, livrée avec le logiciel qui gère notre base de données : https://lod.abes.fr/fct. Chaque page de cette interface correspond à une entité de notre base (un article, une personne, un concept, etc.). Ainsi, la page https://lod.abes.fr/describe/?url=http://hub.abes.fr/springerB/ebook/3540183000/w décrit l’ebook identifié par : http://hub.abes.fr/springerB/ebook/3540183000/w. (Si vous activez cette URL, conformément aux principes des linked data (par TBL, il y a dix ans), vous serez redirigé vers une page qui décrit ce document : ne pas confondre la chose et sa description).
Cet ebook est caractérisé par des attributs (son titre, sa langue) et par des relations : relations vers les concepts dont parlent ce livre, relations vers l’éditeur, relations vers les auteurs (via le concept de contribution), etc. Ce sont ces relations qui permettent de naviguer d’entité en entité, comme on parcourt une encyclopédie. On croit naviguer d’une page à l’autre, mais en fait on navigue aussi d’une chose à l’autre : d’un laboratoire vers une personne, d’une personne vers un document, d’un document vers un concept, etc. De proche en proche, l’ensemble de ces relations constitue un réseau de données, un web de données.

Stratégie du coucou ? Pourquoi mettre tous ces données dans le même panier ?

Il sera naturel de soulever l’objection suivante : vous n’allez pas prétendre enfermer le web de données dans le monde clos de votre base ? Par définition, le web est décentralisé et il doit en être de même pour le web de données.
Cette objection est tout à fait légitime : il y a quelque chose d’artificiel à vouloir démontrer l’efficacité du web sémantique comme solution d’interopérabilité en rassemblant au sein d’une même base tous les jeux de données qu’on veut interconnecter et faire interagir. Nous justifions ainsi notre choix :
La plupart des données que nous voulions entrelacer n’existent pas (encore) sous forme RDF. On s’y est collé, à des fins pédagogiques.
Les solutions pour interroger un web de données décentralisé ne sont pas encore tout à fait mûres. SPARQL prévoit bien la recherche fédérée mais, quel que soit le type de technologies, ce type de recherche achoppe toujours sur les mêmes difficultés (disponibilités des bases à interroger, performances).
Il va de soi que ce n’est pas à l’ABES de produire, maintenir et publier en RDF les données du RNSR, de HAL, de Paris 4 ou d’ORCID, voire de Nature ou Springer (d’ailleurs, la plupart de ces initiatives sont précisément en train de construire leur offre de service RDF – disons, à notre connaissance, 4 sur 6 – nous vous laissons deviner). Ce qu’on espère c’est précisément un monde où les uns et les autres, sans concertation, sans négociation, sans plan quinquennal, font le pari du web sémantique et, comme par miracle, contribuent à construire un espace public de données, souvent complémentaires, parfois redondantes, parfois dissonantes.
Il ne s’agit pas de s’accorder entre nous (même si ça aide et fait plaisir), mais de s’accorder sur les mêmes bonnes pratiques internationales, sur l’état de l’art.

Affirmons à nouveau que chaque producteur est responsable de publier ses données et que le consommateur a le choix des moyens pour les exploiter : requête SPARQL fédérée, navigation à travers des browsers sémantiques, récupération de données en local (ne serait-ce que pour leur faire jouer le rôle d’un cache). Chaque solution a ses avantages et ses contextes d’utilisation privilégiés.

Caveat emptor

  • Ce démonstrateur est un démonstrateur.
  • Ce démonstrateur est vivant et donc périssable. Nous nous réservons le droit d’y ajouter des données, d’en retirer et même de le passer par pertes et profits.
  • Les URLs de ressources commençant par http://hub.abes.fr n’ont pas de durée de vie garantie. Encore moins les URLS pour les ressources de BACON,  HAL, de Persée ou du RNSR.
  • Certains jeux de données de la base sont complets (ORCID, Nature), d’autres ne sont que des échantillons (Annuaire Paris 4, Sudoc, IdRef, Oxford UP).
  • L’approche web sémantique n’est pas l’alpha et l’oméga de l’interopérabilité. A côté de la puissance de SPARQL, coûteuse et pas toujours performante, il y a de la place pour des API hyperspécialisées et hyperoptimisées, comme les micro web services du Sudoc ou d’IdRef.

Mettre nos données en réseau – un démonstrateur. [4h] La fédération a de l’avenir

[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

Une des forces de SPARQL est d’être non seulement un langage de requêtes, comme SQL, mais aussi un protocole, s’appuyant sur des requêtes http. Un sparql endpoint fonctionne donc comme un web service. Mais il y a mieux : comme il est standard, il permet à un endpoint d’en interroger n’importe quel autre, distant. A condition, bien entendu, que chacun d’eux ait été configuré pour cela. Cet appel distant est introduit par une sous requête SERVICE {…}

Ainsi que la requête suivante interrogera la BNF : http://data.bnf.fr/sparql, qui nous renverra les métadonnées du document identifié par l’ISBN 978-3-540-38409-0

PREFIX bnf-onto: <http://data.bnf.fr/ontology/bnf-onto/>
SELECT DISTINCT *
WHERE {
  SERVICE <http://data.bnf.fr/sparql> {?bookbnf bnf-onto:isbn "978-3-540-38409-0" ; ?p ?o}
}

Évidemment, jusqu’ici cela ne présente qu’un intérêt limité : mieux vaut interroger directement data.bnf.fr.

Ce qui est plus intéressant, c’est de croiser des données locales et distantes :

PREFIX rdaw: <http://rdaregistry.info/Elements/w/>
PREFIX rdarelationships: <http://rdvocab.info/RDARelationshipsWEMI/>
PREFIX bnf-onto: <http://data.bnf.fr/ontology/bnf-onto/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>

SELECT *
FROM <http://hub.abes.fr/springer/ebooksLN2011/SPR_EBOOK_ALL_25DEC>
FROM <http://hub.abes.fr/rameau_avril2015/ppns>
WHERE {
?bookspringer bibo:isbn ?isbn.
SERVICE <http://data.bnf.fr/sparql> {?bookbnf bnf-onto:isbn ?isbn ; dcterms:subject ?rameau}
?rameau owl:sameAs ?idref.
}
limit 5

Cette fois, on cherche les documents (plus précisément les manifestations) ayant le même ISBN que tel e-book du corpus Springer, et on récupère des identifiants Rameau, avec lesquels on rebondit sur IdRef via les alignements contenus dans le graphe <http://www.hub.abes.fr/rameau_avril2015/ppns > ayant le même ISBN que tel livre du corpus Springer. Magique, non ?
Voilà comment on peut obtenir une partie des triplets du graphe <http://www.hub.abes.fr/springer/ebooksLN2011/SPR_EBOOK_ALL_25DEC/rameauppn > :

SELECT * 
FROM <http://hub.abes.fr/springer/ebooksLN2011/SPR_EBOOK_ALL_25DEC/rameauppn>
WHERE {?s ?p ?o}
LIMIT 50

(En réalité on a procédé autrement pour descendre au niveau des chapitres)

… Attention, la requête prend du temps.

Voyons à présent un cas plus sophistiqué. Soit une base de données rencontrée au fil de nos errances sur le web de données : bio2rdf.org

Cette base agrège un grand nombre de thésaurus et bases de connaissances biomédicales anglophones, reliés entre eux dans un capharnaüm plus ou moins organisé. Après avoir dressé une cartographie sommaire des lieux, on découvre qu’elle contient notamment la quasi totalité des descripteurs Mesh, déjà mentionnés dans une précédente étude de cas. Et que certains d’entre eux (apparemment plutôt ceux décrivant des pathologies) ont été alignés avec d’autres vocabulaires, qui eux-mêmes sont associés à des références d’articles dans Pubmed, également sommairement chargé dans cette base.

Muni de ces informations, et de la présence, chez nous, de nos notices FMESH francophones, il est possible d’obtenir, à partir d’une notice IdRef ou de son libellé, une liste de références dans Pubmed.

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT  ?label ?citation ?uriPubmed
  {
    SELECT * where
    { <http://www.idref.fr/040671224/id> skos:prefLabel ?label ; owl:sameAs ?mesh.
      BIND (URI(REPLACE(str(?mesh), 'http://id.nlm.nih.gov/mesh/', 'http://bio2rdf.org/mesh:')) AS ?mesh2).
      SERVICE <http://pubmed.bio2rdf.org/sparql> 
      { ?concept <http://bio2rdf.org/ctd_vocabulary:disease> ?mesh2 ; <http://bio2rdf.org/ctd_vocabulary:article> [ <http://bio2rdf.org/clinicaltrials_vocabulary:citation> ?citation ; <http://bio2rdf.org/bio2rdf_vocabulary:x-identifiers.org> ?uriPubmed].
       }
     }  LIMIT 1000
}
GROUP BY ?label ?citation ?uriPubmed

Le résultat donne une idée du potentiel des requêtes fédérées, tout en pointant leurs limites actuelles : c’est long ! Et la fiabilité n’est pas absolue : on n’est pas à l’abri du « time out » ou d’une absence de résultat. En l’occurrence, ici, on rencontre une difficulté pour obtenir la liste des articles, les plus nombreux, pour lesquels on n’a que le lien et pas de citation bibliographique (?uripubmed sans ?citation). Voilà pourquoi, en attendant des lendemains qui chantent sur le web de données, on préfère généralement charger une copie (un « dump ») des données distantes, pour les manipuler à loisir dans sa propre cuisine.

Mettre nos données en réseau – un démonstrateur. [4g] Le Bouquet des ebooks dalloz

[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

Avec Bacon, le bestiaire ABES s’enrichit d’une nouvelle espèce : le bouquet. Un bouquet (package) n’est pas une collection de titres de périodique, mais une collection de TIPP : “Title Instance, Package, and Platform”. En effet, ce qu’on achète ou loue à travers un bouquet, en général, ce n’est pas une revue dans l’absolu, mais telle revue sur telle plateforme selon les conditions de telle offre commerciale. Ainsi, quand on achète les droits d’accès aux archives d’une revue, les dates de la revue ne coïncident pas avec les dates du TIPP correspondant : la revue peut être encore vivante alors que le TIPP s’arrête en 2014.

Pour modéliser KBART en RDF, il ne suffit donc pas d’exprimer en RDF la relation entre un bouquet et un titre. Il est nécessaire d’introduire la notion de TIPP. Le consortium GoKB est actuellement en train de concevoir un vocabulaire RDF pour modéliser le KBART (et les collègues allemands également, dans le cadre de http://www.dswarm.org/en/). Nous nous sommes contentés de reprendre a minima l’esquisse de vocabulaire RDF de GoKB pour dire des choses aussi simples que :


# ce tipp a telle url (sur cette plateforme)
<http://hub.abes.fr/bndalloz/ebook/9782247041091/m/web/tipp>    <http://www.loc.gov/standards/mods/modsrdf/v1/#locationUrl>    "http://dallozbndpro-pvgpsla5.dalloz-bibliotheque.fr/fr/pvpage2.asp?puc=4236&nu=36&selfsize=1" .

# ce tipp correspond à tel titre (tel ebook, en l’occurrence)
<http://hub.abes.fr/bndalloz/ebook/9782247041091/m/web/tipp>    <http://gokb.org/tipp/#hasTitle>    <http://www.sudoc.fr/191183768/id> .

# ce tipp appartient à tel bouquet
<http://hub.abes.fr/bndalloz/ebook/9782247041091/m/web/tipp>    <http://gokb.org/tipp/#belongsToPkg>    <https://bacon.abes.fr/package2kbart/dalloz_global_bnd> .

Pour un bouquet de revues, il aurait été intéressant de préciser les dates : les dates du TIPP et les dates de la revue.

Mais c’est sur un autre point que nous voulons insister : comment “exemplariser” les titres de ce bouquet ? comment exprimer le fait que telle bibliothèque est abonnée à cette collection d’ebooks et donc à chacun des ebooks ?

Traditionnellement, dans le Sudoc comme dans d’autres catalogues, on ajoute un exemplaire sous chaque (notice d’) ebook.
En posant de manière explicite la notion de bouquet, c’est ce dernier qu’on exemplarise, et non plus l’ebook. Il suffit d’établir une relation entre la bibliothèque et le bouquet :

# la bibliothèque (identifiée par on UAI) est une organisation
<http://data.enseignementsup-recherche.gouv.fr/uai/0383075L>    <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>    <http://schema.org/Organization> .

# la bibliothèque a acquis ce bouquet
<http://data.enseignementsup-recherche.gouv.fr/uai/0383075L>    <http://schema.org/owns>    <https://bacon.abes.fr/package2kbart/dalloz_global_bnd> .

La gestion des changements devient plus facile :

  • Si la bibliothèque se désabonne, il suffit de supprimer le lien entre la bibliothèque et le bouquet : inutile de supprimer un exemplaire par ebook.
  • Si un ebook est ajouté au bouquet, il suffit de créer un lien entre le bouquet et le TIPP de cet ebook : inutile de lister toutes les bibliothèques qui sont abonnés à cet book.

Cette organisation plus souple des données aurait pu être implémentée dans une base de données rationnelle classique. Pas besoin de RDF pour ça. Mais comme toutes les données de ce démonstrateur sont gérées dans une base RDF, il était naturel de faire de même pour ces données de gestion, moins polymorphes que les données bibliographiques.

Il faut noter, par ailleurs, que les liens entre les bibliothèques et les bouquets nous ont été fournis par Couperin, sous la forme d’un fichier Excel que nous avons très simplement modélisé et converti en RDF. Ces données Couperin proviennent de l’application ERE (http://ere.couperin.org) qui fait l’inventaire des ressources électroniques des bibliothèques. Hélas, les équipes ABES et Couperin ont constaté que la notion de produit dans ERE et la notion de bouquet dans BACON ne coïncidaient pas souvent. Dans le cas contraire, via BACON, ERE aurait constitué pour le Sudoc une source d’exemplarisation en masse majeure.

Pour finir ce post, quelques requêtes très simple :

La liste des ebooks Dalloz possédés par Grenoble 2 :


PREFIX schema: <http://schema.org/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>

select ?idsudoc ?titresudoc

where
{

<http://data.enseignementsup-recherche.gouv.fr/uai/0383075L> schema:owns ?bouquetdalloz.

?tipp    <http://gokb.org/tipp/#belongsToPkg>    ?bouquetdalloz.

?tipp    <http://gokb.org/tipp/#hasTitle>    ?idsudoc .

?idsudoc dc:title ?titresudoc

}

La liste des bibliothèques abonnées au bouquet Dalloz :

PREFIX schema: <http://schema.org/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>

select ?bib

where
{

?bib schema:owns ?bouquetdalloz.

}

Comme l’identifiant des bibliothèques a été construit à partir de l’UAI de l’établissement d’appartenance, on devine qu’on pourrait croiser ces “données d’exemplaire” avec des données administratives (ou autres) se rattachant à l’établissement (budget, spécialités, nombre d’étudiants, UMR et leurs abonnements, etc.).

Mettre nos données en réseau – un démonstrateur. [4f] Matrice des fascicules pour conservation partagée

[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

Dans le cadre d’ISTEX, les éditeurs nous livrent des données plutôt riches : un fichier par article, comprenant, outre le full text, des informations sur l’article mais également le fascicule, le volume et la revue. Or, ces différents niveaux reflètent le mode de publication imprimée. Il est donc tentant de vouloir extraire de ces métadonnées ISTEX des informations utiles à la conservation des revues papier correspondantes.

Ainsi, la requête suivante permet de générer une grille qui liste tous les fascicules d’une revue (Oxford economic papers), répartis par année :

PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX rdaw: <http://rdaregistry.info/Elements/w/>
PREFIX bibo: <http://purl.org/ontology/bibo/>
PREFIX isbd: <http://iflastandards.info/ns/isbd/elements/>

SELECT ?year (group_concat(?sici, ' ---- ') as ?sici)

FROM <http://hub.abes.fr/oup/journals/oxecon>

WHERE {

?issue  dcterms:isPartOf ?vol ; rdaw:P10072 [isbd:P1003 <http://iflastandards.info/ns/isbd/terms/mediatype/T1010> ; dcterms:issued ?issuedate] ; bibo:issue ?numero.
?vol dcterms:isPartOf <http://hub.abes.fr/oup/periodical/oep/w> ; bibo:volume ?volume.
<http://hub.abes.fr/oup/periodical/oep/w> <http://rdaregistry.info/Elements/w/P10072> [bibo:issn ?pissn ; isbd:P1003	<http://iflastandards.info/ns/isbd/terms/mediatype/T1010>] .
BIND (year(?issuedate) AS ?year).    
BIND (replace(xsd:string(?issuedate), '-', '') AS ?date).
BIND (concat(?pissn, ' (', ?date, ') ', ?volume, ':', ?numero) as ?sici)

}
GROUP BY ?year 
ORDER BY ?year

Si vous avez copié puis collé la requête à cette adresse https://lod.abes.fr/sparql, vous voyez ça :
sici
Chaque fascicule est identifié par un identifiant SICI, qui contient l’ISSN, la date, le numéro de volume et le numéro de fascicule. (Oui, c’est pas faux, ce serait encore mieux si les fascicules de chaque année étaient dans l’ordre de parution … mais cela rendrait la requête encore plus compliquée…)

Une telle grille pourrait aider les gestionnaires de collections de périodiques imprimés à déclarer leurs états de collection et surtout les lacunes. Au lieu de partir d’une page blanche, ils interviendraient sur une grille qui, par défaut, pourrait être vide (« j’ai peu de lacunes ») ou pleine (« j’ai quelques années isolées »).

Encore faut-il que les données numérisées puis livrées par l’éditeur soient complètes et correctes ! Et précisément, on voit que les années 2006 et 2007 ont des … lacunes :
sici_lacunes
Quelques fascicules sont absents de notre base (et du moteur ISTEX) car les fichiers XML correspondants, livrés par l’éditeur, étaient mal formés… (soupir)

Mettre nos données en réseau – un démonstrateur. [4d] Le même auteur dans IdRef, VIAF, HAL, Persée, etc.

[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

La production d’un chercheur est dispersée entre différentes bases de publication ou de référencement. Les alignements entre les différents identifiants du même auteur permettent de rassembler toute cette production, d’en faire la liste comme si toutes les références étaient dans la même base.

C’est le cas de ce chercheur de Paris 4 : Mounir Arbach. Il est présent dans l’annuaire de Paris 4, dans HAL et dans Persée. Nos alignements ont permis de faire converger toutes ces mentions vers le même identifiant IdRef – et du coup, vers le même identifiant VIAF ou ISNI. Voici ce que sait notre base RDF :

<http://hub.abes.fr/paris4/person/qe_paris4_28>  owl:sameAs    <http://www.idref.fr/060160470/id> .  owl:sameAs    <http://www.idref.fr/060160470/id> .

<https://hal.archives-ouvertes.fr/resource/author/152982>     owl:sameAs    <http://www.idref.fr/060160470/id> .

<http://data.persee.fr/person/141820#Person>  owl:sameAs    <http://www.idref.fr/060160470/id> .

<http://viaf.org/viaf/7406574>  owl:sameAs    <http://isni.org/isni/0000000066589445> .
<http://viaf.org/viaf/74065742>  owl:sameAs    <http://www.idref.fr/060160470/id> .
<http://viaf.org/viaf/74065742>  owl:sameAs    <http://id.loc.gov/authorities/names/nr2002026561> .

On peut noter que deux identifiants HAL sont alignés vers le même identifiant IdRef. C’est donc qu’on a un doublon dans HAL (sans doute deux formes-auteurs différentes pour le même auteur).
Il faudrait ajouter que chacun des deux identifiants HAL est lié à plusieurs autres identifiants “locaux” HAL, qui sont eux directement liés à des documents HAL :

<https://hal.archives-ouvertes.fr/resource/document/halshs-00581439/person/1>     owl:sameAs    <https://hal.archives-ouvertes.fr/resource/author/152982> .
<https://hal.archives-ouvertes.fr/resource/document/halshs-00670393/person/1>     owl:sameAs    <https://hal.archives-ouvertes.fr/resource/author/152982> .
etc.

Il est donc désormais possible d’interroger les données HAL avec un identifiant IdRef. La requête suivante demande les documents HAL dont http://www.idref.fr/060160470/id est l’auteur :

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX dcterms: <http://purl.org/dc/terms/>

select ?titre

where {

?formeauteurhal owl:sameAs <http://www.idref.fr/060160470/id>.

?idauteurhal owl:sameAs ?formeauteurhal.

?authorship    <http://vivoweb.org/ontology/core#relates>    ?idauteurhal .

?dochal    <http://vivoweb.org/ontology/core#relatedBy> ?authorship .

?dochal dcterms:title ?titre

}

On peut faire plus court :

DEFINE input:same-as "yes"

PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX dcterms: <http://purl.org/dc/terms/>

select ?titre

where {

?authorship    <http://vivoweb.org/ontology/core#relates>    <http://www.idref.fr/060160470/id> .

?dochal    <http://vivoweb.org/ontology/core#relatedBy> ?authorship .

?dochal dcterms:title ?titre

}

En effet, en ajoutant DEFINE input:same-as « yes » en tête de la requête, on demande à notre base RDF de raisonner, en l’occurrence de tirer toutes les conséquences logiques des alignements au moyen de owl:sameAs. C’est simple : si la base sait que X=Y et que Y est l’auteur du doc D, alors la base peut en déduire ce fait : X est l’auteur de D. C’est simple, mais c’est surtout logique. Dans notre exemple, la base va tester notre requête en substituant à http://www.idref.fr/060160470/id tous les autres identifiants qui sont alignés avec lui, y compris les identifiants HAL

D’une manière générale, il est possible d’écrire une requête qui, pour chaque identifiant IdRef, liste le ou les formes-auteurs HAL correspondantes :

select ?idref group_concat(?auteurccsd , ', ')

from <http://hub.abes.fr/ccsd/docs/paris4/align/idref>

where {

?auteurccsd owl:sameAs ?idref.

}

GROUP BY ?idref

Enfin, la requête suivante liste les auteurs de l’annuaire de Paris 4 et mentionne, s’il existe, l’identifiant correspondant dans IdRef, HAL ou Persée :

select *
where {

Graph <http://hub.abes.fr/paris4/labos/auteurs> {
?auteurp4 a foaf:Person
}

optional {
Graph <http://hub.abes.fr/paris4/labos/auteurs/align/idref> {
?auteurp4 owl:sameAs ?idref.

optional {
Graph <http://hub.abes.fr/ccsd/docs/paris4/align/idref> {
?auteurccsd owl:sameAs ?idref.
}
}

optional {
Graph <http://hub.abes.fr/persee/auteurs/align/idref> {
?auteurpersee owl:sameAs ?idref.
}
}
}
}
} LIMIT 1000

Mettre nos données en réseau – un démonstrateur. [4e] Mapping entre structures de recherche de Paris 4 : IdRef/RNSR/HAL

[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

Comme les personnes physiques, les organismes de recherche sont identifiés dans différents référentiels. En principe, pour la France, le RNSR a vocation à devenir le référentiel pivot, si ce n’est unique.

D’après nos alignements manuels, cette équipe RNSR http://data.enseignementsup-recherche.gouv.fr/rnsr/structure/200412806G est identique à une équipe IdRef et trois équipes HAL :

Paradoxalement, pour lister tous les documents HAL de cette équipe de recheche, il faut donc passer par son identifiant dans le RNSR :

select ?doc ?structureCCSD

from <http://hub.abes.fr/ccsd/structures/paris4>
from <http://hub.abes.fr/alignements/structures/rnsr/idref/ccsd>
from <http://hub.abes.fr/rnsr/structures/paris4>
from <http://hub.abes.fr/ccsd/docs/paris4>

where
{
?structureCCSD owl:sameAs <http://data.enseignementsup-recherche.gouv.fr/rnsr/structure/200412806G> .

?authorship hub:hasAuthorshipAffiliation ?structureCCSD .

?doc vivo:relatedBy ?authorship.
}

Résultat : tous les documents, avec la structure HAL associée

(...)

<https://hal.archives-ouvertes.fr/resource/document/halshs-00398956/w>     <https://hal.archives-ouvertes.fr/resource/structure/2092>
<https://hal.archives-ouvertes.fr/resource/document/halshs-00487825/w>     <https://hal.archives-ouvertes.fr/resource/structure/2092>
<https://hal.archives-ouvertes.fr/resource/document/halshs-01059723/w>     <https://hal.archives-ouvertes.fr/resource/structure/150960>
<https://hal.archives-ouvertes.fr/resource/document/halshs-01059731/w>     <https://hal.archives-ouvertes.fr/resource/structure/150960>

(...)

Encore mieux, en activant l’inférence logique sur owl:sameAs :

DEFINE input:same-as "yes"

select ?doc

from <http://hub.abes.fr/ccsd/structures/paris4>
from <http://hub.abes.fr/alignements/structures/rnsr/idref/ccsd>
from <http://hub.abes.fr/rnsr/structures/paris4>
from <http://hub.abes.fr/ccsd/docs/paris4>

where
{
?authorship hub:hasAuthorshipAffiliation <http://data.enseignementsup-recherche.gouv.fr/rnsr/structure/200412806G> .

?doc vivo:relatedBy ?authorship.
}

Grâce à l’inférence logique sur owl:sameAs, on peut faire comme si la structure RNSR était directement rattachée aux documents HAL. On ne mentionne plus les structures HAL.

Cela simplifie la requête.

Enfin, voici une requête générale pour trouver tous les doublons de structures HAL : on cherche les structures HAL qui pointent vers la même structure RNSR :


select ?rnsr ?ccsd1 ?ccsd2

from <http://hub.abes.fr/ccsd/structures/paris4>
from <http://hub.abes.fr/alignements/structures/rnsr/idref/ccsd>
from <http://hub.abes.fr/rnsr/structures/paris4>
from <http://hub.abes.fr/ccsd/docs/paris4>

where
{
?ccsd1 owl:sameAs ?rnsr ; a <http://schema.org/Organization>.
?ccsd2 owl:sameAs ?rnsr ; a <http://schema.org/Organization>.
filter(?ccsd1 != ?ccsd2)
}
order by ?rnsr

Mettre nos données en réseau – un démonstrateur. [4c] Les ebooks Springer, IdRef, RAMEAU, Dewey

[ Lire le billet qui introduit cette série « Mettre nos données en réseau – un démonstrateur » ]

A force d’en goûter, nous avons développé un certain nez pour les métadonnées d’éditeur. Verdict : Springer, c’est une bonne maison, fiable, facile à boire mais avec du corps. Nous en avons donc pris soin, en ajoutant aux métadonnées initiales toutes sortes d’enrichissements, certes franco-français (auteurs IdRef et RAMEAU), mais qui servent de passerelles vers les référentiels étrangers ou internationaux (LCSH, VIAF, ISNI, etc.).

Notre travail d’enrichissement a fait feu de tout bois. Voici quelques stratégies :

Tel ebook Springer est décrit par telle notice Sudoc …

  • qui est liée à tel auteur IdRef
    • qui est lié à tel auteur VIAF, BnF, etc.
  • qui est liée à telle concept RAMEAU
    • qui est proche de tel concept LCSH, etc.

Tel ebook Springer est décrit par telle notice Worldcat …

  • qui est liée à tel auteur VIAF (ou LC)
    • qui est lié à tel auteur IdRef, BnF, etc.
  • qui est liée à telle concept LCSH
    • qui est proche de tel RAMEAU

Tel ebook Springer possède tel ISBN …

  • qui est associé à tel indice Dewey selon le web service Classify de OCLC

Tel ebook Springer a pour sujet tel concept du thesaurus Springer …

  • que nous avons alignés avec tel concept LC
    • qui est proche de tel concept RAMEAU

Tel auteur Springer est associé à telle adresse email …

  • qui est également associée à tel autre auteur Springer avec un nom proche

Tel ebook Springer a pour auteur …

  • tel auteur IdRef selon les calculs de Qualinca
    • et cet auteur IdRef est lié à tel auteur VIAF, BnF, etc.

 

Les enrichissements automatiques effectués, l’équipe du hub a passé le relais à l’équipe de Lyon 1, dans le cadre d’un chantier CERCLES d’amélioration des notices.