Identifier les auteurs de HAL avec IdRef

logo-idref   C’est une histoire déjà ancienne à l’Abes que celle de l’identification automatique des Personnes impliquées dans des ressources documentaires. Du moins, est-ce un sujet qui, depuis plusieurs années, aiguillonne des études et aboutit progressivement à des réalisations intéressantes. En voici une illustration avec des corpus extraits de HAL.

Corpus SHS – 2011

Entre octobre 2010 et novembre 2011, dans le cadre du projet SudocAd, un premier prototype a été développé avec pour objectif l’enrichissement des métadonnées du moteur de recherche ISIDORE par l’ajout de lien aux autorités Sudoc (IdRef). Le prototype exploita un échantillon de 13 444 notices d’articles issues du portail Persée – domaine «Économie » – en identifiant, quand elle existait, l’autorité IdRef correspondant à chacun des auteurs. Une fois traitées, les notices furent livrées à ADONIS et à l’équipe Persée. Côté performance, le prototype SudocAD atteignait un très bon niveau : sur un échantillon vérifié de 150 notices Persée, 80% étaient estimées comme de « bonnes décisions » (liage ou non liage), et surtout, le taux d’erreur (création de liens erronés) était inférieur à 2%.

Corpus SHS – septembre 2015

Depuis, le projet Qualinca a repris le flambeau, avec une approche plus globale. En septembre 2015, une nouvelle expérimentation d’identification automatique est menée sur un corpus de HAL : 1 900 documents du domaine SHS sont puisés dans l’entrepôt OAI-PMH. Après traitement, 3 200 formes-auteurs sont extraites et passées à la moulinette du prototype. Lors du développement de l’outil, seuls 2 critères de matching -appelés également dans ce cadre « heuristiques »- sont utilisés (« co-auteur » et « unica »). Sur la base de ces critères,  1 100 entités – soit 34% des formes-auteurs – seront matchées, puis rattachées à une notice d’autorité dûment identifiée.

Corpus Astrophysique – avril 2016

Les disciplines ayant des pratiques de publication fort diverses, le choix s’est porté sur le traitement de 300 articles issus du domaine « Astrophysique » et leurs 1 242 formes-auteurs.  L’astrophysique étant un domaine dans lequel les publications sont hautement internationalisées, la proportion d’auteurs étrangers y est importante. De plus, l’interdisciplinarité y étant élevée, on trouvera parmi les auteurs des chercheurs physiciens, biologistes, ingénieurs, océanographes, chimistes, mathématiciens…

La qualité de l’identification finale dépendant largement de la qualité des données de départ, on notera que les données en entrée sont majoritairement de qualité basse, un aspect amplifié par l’absence de normalisation dans l’écriture des appellations. Quelle sera l’incidence de ces variantes orthographiques sur la couverture du corpus par IdRef ?

Le corpus comportait : 406 appellations d’auteur avec nom + prénom (soit 33%) et 836 appellations d’auteur avec nom + initiale du prénom (soit 66%). Les 1 242 formes-auteurs ont d’abord été ramenées à 1 156, suite à la suppression de 43 doublons évidents (avec accent vs. sans accent ; initiale du Prénom vs. Prénom développé).

Premier  constat : le prototype a appris à gérer de façon très satisfaisante ce paramètre de variabilité des graphies. Ainsi, 467 appellations (soit 37,6%) ont été identifiées avec les heuristiques «co-auteur», «titre» et «unica» – pour ce dernier critère, les appellations « Nom, P. » furent mises de côté. Second constat : sur les 775 appellations restantes, 57 -soit 4,6%- correspondaient à des auteurs dont des homonymes ont été correctement écartés par la machine. Afin de tester la couverture d’IdRef, une deuxième passe a ensuite été effectuée, sous forme d’une recherche manuelle rapide, qui a permis d’identifier 95 auteurs supplémentaires.
En valeur absolue,  autant d’auteurs avec « Nom, Prénom » qu’avec « Nom, P. » ont été identifiés. En valeur relative, le résultat est évidemment en faveur des auteurs avec « Nom, Prénom » – 66 % – contre 33% pour les auteurs avec « Nom, P. »  Dans ce cas également, le fait de disposer de notices d’autorité est très intéressant puisque dans la majorité des cas d’appellations avec « Nom, P. »,  le prénom développé a été retrouvé. Ces éléments permettent d’estimer le potentiel de clusterisation apportée par une notice d’autorité grâce aux variantes de formes.

Au final, ce sont 561 auteurs qui ont été identifiés, soit 45% d’identification des auteurs du corpus Astrophysique de HAL. A titre de comparaison, on remarquera que les requêtes lancées sur AuréHAL  sur les formes-auteurs présentes, en demandant pour chacune si elle correspondait à une forme présente dans un idHal, a donné un résultat de seulement 3,5 % des appellations du corpus « Astrophysique ».

Corpus idHal – janvier 2017

Le corpus idHal – identifiants uniques gérés dans HAL- en progression continue, constitue un nouvel enjeu majeur en termes d’alignement d’identifiants – notamment sur fond de projet Conditor. L’exploitation de ce service de HAL est importante à plusieurs égards : outre la sensibilisation auprès des chercheurs quant à la question de l’identification pérenne et unique, idHal permet de tirer parti du travail de validation d’attribution de publication réalisés par les chercheurs eux-mêmes.
Récemment,  un alignement vers IdRef des auteurs – publiant dans HAL et disposant d’un idHAL- a été tenté. En 5 étapes, cela a donné :
1)    identifier tous les auteurs HAL ayant un idHal
2)    récupérer les documents liés à ces idHal
3)    les convertir et les charger dans la base RDF de l’Abes
4)    lancer les heuristiques d’alignements
5)    extraire les premiers résultats : 11 000 auteurs à lier pour 6 400 alignés ( soit 58,2 %)

Ainsi, grâce aux puissants algorithmes d’alignement élaborés en interne, une bonne partie du chemin semble parcourue. Mais aller plus loin – beaucoup plus loin !-  est envisageable. En effet, il est désormais tout à fait possible de lancer les heuristiques sur l’intégralité de HAL.

De belles perspectives

Depuis 2010 à l’Abes, les avancées de la réflexion et des outils en matière de données d’autorité ont construit une approche intellectuellement et technologiquement performante, ce qui permet  de promouvoir, désormais preuves à l’appui, l’offre de service d’IdRef auprès des opérateurs de l’IST en France.
En effet, si le taux de couverture des auteurs de publications de recherche est proche de 50%, il est de l’ordre de 90% pour les auteurs français – ce qui confirme la portée réelle d’IdRef en termes de référentiel des auteurs de l’Enseignement Supérieur et de la Recherche.
Dans les mois à venir, le programme de travail ira en ce sens. La consolidation des process constitue l’axe prioritaire : il s’agira tout d’abord de les automatiser intégralement afin de moissonner de très gros volumes de données. La redistribution de ces alignements constitue le second axe.

Sur le même concept que le web service de récupération des alignements – idref2id,  le stock d’alignements disponibles va s’accroitre  pour mettre en vitrine tout ce que nous avons déjà en « arrière-boutique ». De belles perspectives donc.

François Mistral, responsable IdRef

STAR : les statistiques 2016

starDepuis l’ouverture en 2006 de l’application nationale STAR, développée suite à l’arrêté du 7 août 2006  relatif aux modalités de dépôt, de signalement, de reproduction, de diffusion et de conservation des thèses électroniques, outre la garantie d’un signalement et d’un archivage numérique fiable,  c’est bien également in fine la valorisation et la diffusion des thèses françaises que le dispositif mis en œuvre par l’Abes soutient. Un dispositif qui devrait se renforcer suite à la parution de l’arrêté du 25 mai 2016  rendant obligatoire le dépôt de la thèse dans sa version électronique  pour tous les établissements à partir du 1er septembre 2016. 

Outre un éclairage original sur la richesse de la production et sur la dynamique de diffusion des « documents Thèses », la publication des statistiques 2016 se veut un indicateur d’activité au service des établissements membres du réseau Star.

Volumétrie de la base de données STAR

Au 1er janvier 2017,  56 287 thèses déposées et archivées  sont recensées dans la base de données STAR/CINES. On constate que, depuis 3 ans, le volume de thèses traitées annuellement tend à se stabiliser autour de 10 000 thèses par an – 11 258 en 2016 pour être précis. Il est prévisible que cette moyenne augmente sensiblement en fonction du nouvel arrêté rendant le dépôt électronique des thèses obligatoire.

depot-annuel

Indicateurs d’activité dans STAR

Calculée en fonction du nombre de thèses traitées, l’activité dans l’application STAR se caractérise par un relatif lissage tout au long de l’année. Cependant, tout comme en 2015, on constate un léger pic d’activité lors du premier trimestre de l’année civile.

Le délai de traitement moyen d’une thèse dans STAR, donnée statistique présente dans l’application de pilotage Webstats, est calculé en fonction de l’écart entre  la date de soutenance et la date de validation finale.  Alors qu’en 2015 ce délai de traitement était en moyenne de 293 jours,  il est de 317  jours en 2016.

ration-mensuel

delai-traitement

Diffusion des thèses : l’accès libre largement privilégié

Illustration d’une belle dynamique d’ouverture et de libre accès,  le pourcentage de thèses déposées dans STAR diffusées sur Internet, stable depuis 2013, est évalué à 75%. On note qu’est privilégiée la diffusion des thèses sur plusieurs plateformes en simultané, cette diffusion s’appuyant sur la plateforme Thèses-en-Ligne (TEL) du CCSD, la plateforme des établissements de soutenance et la plateforme ABES.

Signe que les automatisations introduites entre les différents systèmes -et notamment entre STAR et TEL –  favorisent la politique de dépôt en open access ?  Quoiqu’il en soit, comme l’indiquent les statistiques publiées récemment par le CCSD, en 2016, on peut se réjouir que 72% des thèses déposées dans TEL – soit 5 731 thèses – l’aient été à partir de l’application STAR.  En 2014,  cela ne représentait que 39% des cas…

Type de diffusion

diffusion

plate-forme

Olivier CIAN, responsable fonctionnel de l’application STAR

 

Calames : les statistiques 2016

calamesTout en inaugurant la prise de relais entre le blog Calames, qui cesse ses publications en ce début d’année, et  Punktokomo, blog technique de l’ABES, ce billet vise prioritairement à fournir aux établissements membres du réseau Calames des éléments complémentaires aux statistiques générales accessibles via l’application Webstats.

Les statistiques présentées ici  fournissent des tendances et des indicateurs, mais ne prétendent pas donner d’information sur la qualité, la précision, la pertinence des encodages adoptés, ni sur la part de travail récurrent ou rétrospectif touchant des niveaux descriptifs pré-existants. En effet, le caractère hybride de l’instrument de recherche EAD – partagé entre la volonté de mettre en forme des documents et la tendance à l’usage de référentiels et autres données destinés aux traitements informatiques –  explique en partie cette difficulté à prendre tout le recul souhaitable sur ces ensembles de fichiers : bien souvent, seul un regard humain est à même de juger complètement de la qualité des encodages. Ces diagrammes sectoriels sont néanmoins des témoins sûrs de l’implication des établissements dans le signalement de leurs archives et manuscrits, de leur importance dans le paysage patrimonial de l’ESR en général et dans la vie du réseau Calames en particulier.

État de la base publique Calames au 31 décembre 2016

Répartition du 3/4 de million de composants publiés dans Calames par établissements

repartition-c-publies-fin-2016-par-rcr

Répartition des composants publiés dans Calames par origine (rétroconversions nationales originelles ou production/ attribution d’ID par l’outil)

originedonneescalames2016

Répartition  des composants publiés dans Calames par cercles de déploiement (1er cercle déployé en 2008, 7e et 8e cercles en 2014)

repartition-c-publies-fin-2016-par-cercles

Nouvelles données publiées dans Calames en 2016

La quantité de données nouvellement publiées est restée notablement élevée en 2016, bien que le surcroît soit moins spectaculaire qu’en 2015 et qu’il soit beaucoup plus également réparti entre une bonne dizaine de sources de signalement. origine-surcroit-c-publies-courant-2016

Neuf ans après son lancement, Calames dépasse ainsi les trois quarts de million de niveaux descriptifs publiés :

evolution-c-publies-2007-2016

Travaux de catalogage dans l’outil Calames Prod en 2016

La quantité de <c> nouvellement identifiés par l’outil Calames est très proche du niveau de l’année précédente : environ 126.000 composants ont été créés courant 2016 par le réseau Calames.

On constate que très peu d’établissements dérogent à la recommandation de cataloguer en-dehors de la base de production (env. 4000 <c> répondent à ce cas de figure après analyse), et le cas n’échoit que pour de bonnes raisons (emplois d’exports spécifiques ou volonté de faire des publications tests notamment).
Les 5 établissements ayant créé la plus grande quantité de niveaux descriptifs dans Calames depuis son origine sont ceux-là mêmes qui représentent à eux seuls plus de 60% des données actuellement publiées : Muséum National d’Histoire Naturelle (158067 <c> créés dans l’outil depuis 2008), BDIC (110203), Institut de France (86941), Bibliothèque Littéraire Jacques Doucet (65668) et Académie de Médecine (60648).

catalogage-dans-calames-2016

Depuis l’an dernier, nous disposons d’une statistique certes un peu complexe, mais complémentaire à la précédente, qui nous renseigne sur la fréquence du recours à l’outil de catalogage Calames Prod (au-delà du seul nombre de nouveaux <c> créés). Le graphique ci-dessous doit être ainsi lu : en 2016, la BLJD a effectué 839 interventions quotidiennes sur fichiers EAD unitaires (ou 839 « jours-fichiers »).

L’existence pour un même établissement d’un grand nombre de fichiers EAD favorise certes l’élévation des chiffres, quelques établissements ayant à gérer des dizaines d’instances distinctes. Le graphique témoigne aussi, en comparaison de 2015, d’un recours à la fois plus intense et fréquent à l’outil Calames Prod (plus de 1100 jours-fichiers supplémentaires pour une quantité de composants créés équivalente) ainsi que d’une part non négligeable de travaux rétrospectifs (retours sur des instances dont l’architecture au moins avait été créée les années précédentes).

temps-frequence-catalogage-calames-2016

Ventilation de 9  années de catalogage -aussi bien en production qu’en publication/indexation- dans Calames

production-c-2008-2016

Le décalage entre ces deux représentations des composants créés via l’outil Calames (<c> publiés / <c> créés) est une donnée structurelle depuis plusieurs années : de l’ordre de 100.000 composants présents mais n’ayant jamais connu de première publication. Les <c> créés en base de formation ont été « purgés » au maximum des rebuts, données de tests, et doublons de fait (ID différents mais données identiques à des niveaux descriptifs publiés en base de production). A noter aussi, une forte tendance à l’accélération des publications d’inventaires, puisque seuls 1/4 des <c> créés en 2016 n’ont pas connu de première indexation à la fin de leur année de naissance.

Statistiques de consultation 

Comme en 2015, la hausse continue de la quantité de données exposées, ainsi que plusieurs épisodes de popularité liés aux recherches ponctuelles de certains mots-clés sur les moteurs de recherche généralistes, se sont soldés par un nombre de visites sur le catalogue public en sensible accroissement.

Ainsi, la moyenne annuelle est de l’ordre de 16 000 visites/mois (soit 5.000 de plus qu’en 2013-2014) ; un phénomène corollaire est la recrudescence du « zapping » des internautes (durées moyennes de visites raccourcies), mais en restant bien loin des niveaux liés au sur-référencement que la nouvelle interface Calames avait connu dans ses premiers mois d’existence.

Jean-Marie Feurtet, responsable Calames

Webservice AlgoLiens : remédier à l’absence de liens dans les données du Sudoc

imagealogoliens

Expo Asterix BNF / Manuel F. Picaud / CC BY-NC-SA 2.0, via Flickr

L’ABES vient de mettre en production un nouveau web service, baptisé AlgoLiens. Ce dernier détecte les notices du Sudoc dans lesquelles une zone de liens aux autorités n’est pas liée. En mettant à la disposition de leurs créateurs les notices présentant une telle anomalie afin de les amener à la corriger, l’objectif est d’atteindre à un signalement documentaire total.

A l’origine d’AlgoLiens, nouvel outil à la disposition des catalogueurs du réseau Sudoc, se trouve une question que plus d’une fois nous nous sommes collectivement posée : comment améliorer les données du Sudoc ? Cette question à peine énoncée, le doute s’instille. Finalement, est-ce tout simplement possible ? Ecrasante, la recherche de la réponse est repoussée à un horizon de pieuse espérance habité par de dociles machines… Pourtant, insistons car le jeu, en vaut la chandelle et répond à quatre enjeux MAJEURS :

  • l’exhaustivité du signalement catalographique,
  • la valorisation scientifique de l’IST,
  • la valorisation patrimoniale des BU,
  • la contribution des données Sudoc au Web de données liées.

Commençons par rendre la question moins effrayante : comment approcher la notion de qualité du catalogue Sudoc et prendre à bras le corps les anomalies qu’immanquablement les données contiennent ? Avec le webservice Algoliens, la porte d’entrée retenue concerne les zones de liens aux notices d’autorité. En effet, les notices d’autorité ont pour fonction de normaliser les points d’accès autorisés des notices – bibliographiques et d’autorités. De plus, elles recensent les variantes de formes. Enfin, elles ont vocation, dans les notices bibliographiques comme dans les notices d’autorité, à être liées à tous les points d’accès.

Conçu sous forme d’un web service, AlgoLiens détecte les notices dans lesquelles une zone de lien n’est pas liée. Ce servicepermet de générer à la demande un « rapport d’absence de liens dans les zones de lien du Sudoc » qui se présente sous forme d’un fichier .csv contenant les résultats des tests de l’algorithme.

L’algorithme porte, en premier lieu, sur la présence d’un lien situé dans les zones de lien des notices. Mais il fait bien plus en permettant de croiser de nombreux critères. Il est ainsi possible de filtrer les résultats souhaités par établissement, depuis une date fixée, pour un type de document précis, pour les unicas uniquement.

Voici par exemple la requête qui permet de remonter les notices des documents imprimés créées et modifiées par l’ILN 100 depuis le 10 mars 2015 dans lesquels des zones d’indexation ne sont pas liées :

http://www.idref.fr/AlgoLiens?typdoc=Aa&iln=100&code=B60X&date=20150310

Pour chaque PPN en anomalie, le catalogueur est invité à corriger la notice dans WinIBW ou IdRef. Le rapport dynamique lui suggère d’intervenir à tel ou tel endroit de la notice :

Aujourd’hui, des dizaines de milliers d’anomalies sont détectées. Face à l’ampleur de la tâche, il est nécessaire d’organiser le travail de correction. En utilisant des paramètres dans l’url de génération du rapport dynamique, il est possible de définir des lots personnalisés.

La documentation de ce webservice est disponible à cette adresse. Le J-e.cours de présentation de ce service qui a eu lieu le 1er décembre 2016 est accessible sur notre plateforme de formation.

Nous espérons que ce webservice sera l’occasion pour les établissements de mettre en place des chantiers de corrections ciblés, à l’instar de la démarche CERCLES. Et si vous ne savez pas par où commencer, songez à vos corpus préférés, vos petits trésors documentaires ou vos unicas… et testez des requêtes !!!

De son côté, l’ABES utilisera AlgoLiens pour suivre l’avancement des corrections de manière globale. De même, elle s’en servira pour déterminer des corpus pertinents sur lesquels l’apport d’algorithmes correctifs s’avérerait pertinent.

Enfin, un jour – que nous espérons le plus proche possible, ce webservice deviendra inutile car l’algorithme ne détectera plus aucune anomalie. Ce jour, nous pourrons être encore plus fiers du travail collectif accompli.

François Mistral, responsable du référentiel IdRef

Récit d’une immersion. Traiter les ebooks Dalloz avec les données Sudoc, les données de l’éditeur et les outils du hub

Ce billet relate à la première personne l’immersion effectuée par Catherine Storne (Université de Strasbourg) au sein de l’équipe hub de l’ABES, entre le 1er et le 5 février 2016. Catherine a eu l’occasion de partager cette expérience aux dernières journées ABES. Merci pour tout, Catherine !

Placée en face de la nouvelle « Metadaten Weltanschauung » au travers de la réflexion locale sur l’abonnement à un outil de découverte (discovery tool) ou sur les réalisations de la plateforme ISTEX sur les licences nationales, je ressentais le besoin de monter en compétences sur la manipulation des métadonnées. J’ai donc souhaité faire une immersion à l’ABES pour mieux comprendre les projets de l’établissement tournant autour des métadonnées dont les noms parvenaient aux confins de nos bibliothèques : BACON, hub de métadonnées, CERCLES, ainsi que les liens entre eux. Mon objectif étant de travailler au rapprochement, au sein du SCD de Strasbourg, des équipes de la documentation électronique et du catalogage, la participation à un projet concret, au travers d’un chantier CERCLES me semblait de nature à y contribuer.

Après discussion avec quelques collègues, il est apparu que le corpus d’e-books de la bibliothèque numérique Dalloz était mal-traité, i.e mal catalogué au SCD, qu’un catalogage de qualité de ce corpus dans le Sudoc était attendu et profiterait à l’ensemble des bibliothèques du réseau.

Pour l’ABES, l’immersion devait permettre d’avancer dans la réflexion sur le rôle que certains établissements pourraient jouer dans la chaîne de traitement des métadonnées fournies par les éditeurs, avant même leur traitement par le hub de métadonnées.

Avec un peu (beaucoup) d’appréhension à l’idée de me retrouver dans l’antre de « Winnie » [WinIBW] sans savoir réellement cataloguer et sans avoir retenu de mes lectures sur RDF tout ce que j’aurais dû, je quittais mon grand Est natal pour rejoindre le temps d’une semaine Montpellier, la surdouée.

1.  Les données sur la bibliothèque numérique Dalloz

La plateforme de Dalloz http://www.dalloz-bibliotheque.fr/ , permet une recherche sur les e-books de cet éditeur par titre, auteur, domaines ou collections. La liste complète des titres sous la forme d’un tableau est quant à elle disponible à  http://www.dalloz-bibliotheque.fr/listing.php (appelée par la suite « Tableau-Dalloz »).

Par ailleurs, Dalloz met à disposition un entrepôt OAI : http://logistic.book-vision.com/services/oai/act68.php?verb=ListRecords&metadataPrefix=onix_dc (appelé par la suite « OAI-Dalloz ».)

1.1  Premier constat

Les deux sources ne comportent pas un nombre identique de titres (1939 pour Tableau-Dalloz, 1626 pour OAI-Dalloz) ni les mêmes données.

Tableau-Dalloz contient l’ISBN électronique, l’ISBN papier correspondant, le titre, le n° de l’édition, la collection. Pas même l’URL de consultation. Les données d’OAI-Dalloz sont plus riches ; parmi elles : titre, auteur, sujet, résumé, éditeur, date d’édition, ISBN électroniques, les informations pour la reconstitution d’une URL de consultation, etc.

1.2  Deuxième constat, dû à l’œil expert des collègues de l’ABES

Tous les titres, ou presque, sont catalogués dans le Sudoc, pour la version papier du livre. Le web service isbn2ppn de l’ABES permet, à partir des ISBN-papier du tableau-Dalloz d’obtenir la liste des ppn (de la version papier) correspondants ; une extraction du Sudoc de ces titres à partir de la liste des ppn (de la version papier) constitue la troisième source de données (appelée Sudoc-Dalloz),

1.3  Directions de travail

A partir de ces deux constats, s’esquissent quelques lignes de travail :

  • vérifier la qualité des notices du Sudoc, pour s’assurer que les liens sont présents (6XX et 7XX, collection)
  • comparer les 3 sources entre elles.

Pour les notices Sudoc :

  • tous les 7XX ont un lien vers un ppn autorités
  • tous les 410 ont un lien vers le ppn de la collection

Sur les 1939 du Tableau-Dalloz :

  • 38 titres ne sont pas catalogués dans le Sudoc dans leur version papier
  • 38 autres titres sont déjà catalogués dans le Sudoc dans leur version électronique
  • 1 titre du Tableau-Dalloz contient une erreur d’ISBN électronique
  • 31 ppn sont écartés car il faut vérifier s’ils sont des doublons

Au final, il reste 1832 titres qui ne posent aucun problème.

En règle générale, le hub de métadonnées part des données des éditeurs pour créer les notices d’e-books. Dans le cas du corpus Dalloz, la réflexion est différente car la pré-existence dans le Sudoc des notices des documents papier, complètes, constitue une base de départ fiable.Il est donc décidé de créer les notices des e-books dans le Sudoc à partir des notices correspondantes des livres-papier puis d’utiliser les données venues des sources Dalloz pour enrichir ou corriger les notices créées dans le Sudoc en utilisant pour cela des outils développés dans le cadre du Hub de métadonnées.

2.  Création par copie de notices d’e-books dans le Sudoc

Pour chaque ppn indiqué, le script de création de notices a dupliqué la notice du livre imprimé en y apportant les modifications du tableau ci-dessous :

Notice papier Notice d’e-book correspondante
001 Non repris
002 Non repris
003 Non repris
008 Par défaut :

$aOax3

010 Non repris
020 Non repris
021 Non repris
033 Non repris
034 Non repris
035 Remplacé par défaut par :

##$aBNDalloz

073 Non repris
106 Non repris
135 Ajout par défaut :

##$av$br$cm$e#$gm$ia$ja

181 Ajout par défaut :

##$P01$ctxt

182 Ajout par défaut :

##$P01$cc

215 Non repris
225 Non repris
230 Ajout par défaut :

##$aDonnées textuelles

337 Ajout par défaut :

##$aNécessite un logiciel capable de lire un fichier au(x) format(s)Widelook ou Widelook Flash

410 Non repris
452 Ajout par défaut :

##$0″ + ancienPpn

801 Non repris
802 Non repris
830 Non repris

 

3.  Les enrichissements du hub de métadonnées (ABES)

Les notices d’e-books ont été enrichies par le hub de métadonnées.

Pour ce faire, le fichier « Tableau-Dalloz » a été complété via l’outil Openrefine (téléchargeable à openrefine.org/), des données suivantes :

  • ppn papier (obtenu grâce au web service isbn2ppn)
  • ppn électronique (équivalence p-ppn/e-ppn obtenue par le compte-rendu du script de création)

Il a ensuite été transformé en RDF.

Par ailleurs, les données « OAI-Dalloz » ont été converties en RDF/XML et chargées dans la base XML Oracle de l’ABES. Plusieurs notices étant en doublon dans le moissonnage OAI, le nombre final d’e-books distincts est de 1566.

3.1  RDF

3.1.1  En trois mots

RDF est le langage du web sémantique.

« RDF (Resource Description Framework) est un modèle de représentation de données élaboré sous l’égide du W3C (World Wide Web Consortium). Il attribue à des ressources, identifiées par des URI, des propriétés et des classes (ou catégories), permettant de les définir, les décrire, ou d’établir des relations entre elles. […]

Les données sont découpées en entités élémentaires pour former des triplets : <sujet> <prédicat> <objet>

  • le sujet est l’identifiant de la ressource ;
  • le prédicat est une propriété ou une relation, elle-même identifiée par une URI (le plus souvent représentée par un préfixe) ;
  • l’objet est l’identifiant d’une autre ressource en relation avec la première, une valeur ou un littéral. »

Définition trouvée dans : http://documentation.abes.fr/sudoc/manuels/pdf/sudoc-rdf.pdf (consulté 06/03/2016)

3.1.2  Choix de construction des URI

Pour que les sujets, prédicats, éventuellement objets puissent être identifiés de manière unique, il faut leur attribuer des identifiants, construits sous forme d’URI.

Voici les choix qui ont été faits dans le cas de la bibliothèque numérique Dalloz pour construire un modèle de création des URI pour les œuvres et les manifestations.

  • Pour l’œuvre :
  • Pour la manifestation :
    • Manifestation électronique :
      • champs attribués à la manifestation électronique : issn (électronique), ppn (électronique), numéros permettant de reconstituer l’url de consultation (n° puc, n° nu), date de publication
      • identifiant choisi : ISBN électronique
    • Exemple : http://www.hub.abes.fr/bndalloz/ebook/9782247103713/m/web (/m pour préciser qu’il s’agit d’une manifestation ; /web pour préciser qu’elle est électronique)
    • Manifestation imprimée (papier) :
      • champs attribués à la manifestation électronique : issn (papier), ppn (papier), date de publication
      • identifiant choisi : ISBN électronique
    • Exemple : http://www.hub.abes.fr/bndalloz/ebook/9782247103713/m/print (/m pour préciser qu’il s’agit d’une manifestation ; /print pour préciser qu’elle est imprimée)

3.1.3  Exemples de triplets

<http://www.hub.abes.fr/bndalloz/ebook/9782247103713/w> dcterms:title "50 droits contre l'exclusion " ;

<http://rdaregistry.info/Elements/w/P10072> <http://www.hub.abes.fr/bndalloz/ebook/9782247103713/m/web>, <http://www.hub.abes.fr/bndalloz/ebook/9782247103713/m/print> .

Signifie : L’oeuvre dont l’identifiant (l’ISBN électronique) est 9782247103713 a pour titre « 50 droits contre l’exclusion » ; elle a deux propriétés dont on retrouve la définition dans rdaregistry : P10072 correspond à « has manifestation of work ; donc, l’oeuvre a deux manifestations : l’une  électronique, l’autre imprimée.

<http://www.hub.abes.fr/bndalloz/ebook/9782247103713/m/web> <http://purl.org/ontology/bibo/isbn> "9782247103713" ;

<http://www.hub.abes.fr/namespaces/ppn> "191163120" ;

dcterms:isPartOf <http://www.hub.abes.fr/bndalloz/collection/asavoir> ;

<http://purl.org/ontology/bibo/edition> "1" .

Signifie : la manifestation électronique a pour ISBN électronique 9782247103713 et  pour ppn (défini dans le vocabulaire du hub) 191163120 ; elle appartient à la collection « asavoir » (A savoir) et en est à la première édition

<http://www.hub.abes.fr/bndalloz/ebook/9782247103713/m/print> <http://purl.org/ontology/bibo/isbn> "9782247070602" ;
<http://www.hub.abes.fr/namespaces/ppn> "134600878"

Signifie : la manifestation papier a pour ISBN papier 97822470706020 et pour ppn 134600878.

RDF, par les déclarations  et les triplets, décrit des relations. Ces relations peuvent être décrites sous forme de représentations graphiques, composées d’ovales, flèches, rectangles.

dalloz_graphe

 

3.1.4  Les graphes

On obtient deux sous-ensembles séparés dans la base RDF (ce qu’on appelle des « graphes ») :

  • celui des données du « Tableau-Dalloz » enrichi :

<http://www.hub.abes.fr/dalloz/DALLOZ_4FEV2016/tableaudalloz>

  • celui des données « OAI-Dalloz :

<http://www.hub.abes.fr/dalloz/DALLOZ_4FEV2016/>

Les URI des documents étant dans chacun d’eux construits sur l’ISBN électronique, les données peuvent être fusionnées facilement.

3.2  Le programme MARCEDMOD

L’ABES a récemment développé un programme expérimental de modification de notices du Sudoc, répondant au doux nom de MARCEDMOD [pour Marc-édition-modification ? eux, comme ils veulent toujours créer du lien, l’appellent plutôt Marc et Maud ! Il faudra quand même leur demander la source de leur inspiration !].

Ce programme interroge les données auparavant converties en RDF, avec des requêtes SPARQL (SPARQL n’est rien d’autre que le langage de requête des données en RDF). Ces requêtes permettent de sélectionner les triplets correspondant aux critères choisis. Ensuite, pour chaque type de modification à faire dans le Sudoc, un script va chercher les notices correspondantes dans le Sudoc et opérer la transformation souhaitée en remplaçant la donnée présente dans le Sudoc par celle issue de RDF.

Par exemple, pour ajouter la Dewey issue de OAI-Dalloz sur les notices du Sudoc qui n’en ont pas, MARCEDMOD fait ce qui suit :

select distinct ?eppn

# Je sélectionne tous les ppn électroniques

from <http://www.hub.abes.fr/dalloz/DALLOZ_4FEV2016/tableaudalloz>
from <http://www.hub.abes.fr/dalloz/DALLOZ_4FEV2016>

# à la fois dans les données Tableau-Dalloz et OAI-Dalloz désormais présentes en RDF dans la base du hub

where {

?work <http://rdaregistry.info/Elements/w/P10072> ?manif.

?manif <http://iflastandards.info/ns/isbd/elements/P1003> <http://iflastandards.info/ns/isbd/terms/mediatype/T1002>.

?manif <http://www.hub.abes.fr/namespaces/ppn> ?eppn.

# pour lesquels une œuvre a une manifestation, manifestation qui est de type électronique et qui a dans le hub un ppn électronique

} LIMIT 1000

Script :

J’injecte cette liste de ppn électroniques dans le Sudoc :

Node zone=Notice.find("676");

Je recherche toutes les zones « 676 »

if (zone == null)
{
Notice.Insert("676","#","#","a","340");

S’il n’y a pas de Dewey présente, j’insère 676##a340

}
else
{
Notice.alert("la zone existe dejà");
}

Sinon, je ne fais rien et je dis que « la zone existe déjà »

3.3  Enrichissements faits par le hub

  • Résumé : prévu, sera bientôt fait
  • ISBN électronique (tirés du tableau-Dalloz)
  • Dates d’édition : dates du tableau-Dalloz ajoutées en 100$a et 210$d (par écrasement de celles éventuellement présentes)
  • Edition : pour les titres du tableau-dalloz ayant un numéro d’édition autre que 1, ce numéro d’édition a remplacé celui présent dans le Sudoc
  • Dewey : pour les notices sans 676, ajout d’un 676 avec le code dewey 340 tiré d’OAI-Dalloz
  • URL : le champ 859 a été créé pour les seules les notices de OAI-Dalloz ont pu être traitées car les numéros permettant de reconstituer l’URL ne sont pas présents ailleurs.
  • Editeur : seules les notices de OAI-Dalloz ont pu être traitées

4.  Le programme de travail du chantier CERCLES

Récapitulatif des travaux catalographiques (vérifications ou corrections) à faire dans le Sudoc par le SCD de Strasbourg :

  • Catalogage des notices qui n’ont de ppn papier : 38 titres
  • Vérification et enrichissement des notices d’e-book qui existaient déjà dans le Sudoc : 35 titres
  • Vérification d’1 titre du Tableau-Dalloz qui contient une erreur d’ISBN électronique
  • Catalogage des 31 ppn écartés car il faut vérifier s’ils sont des doublons
  • Vérification des notices pour lesquelles la date d’édition entre le Sudoc et le tableau-Dalloz sont différentes : 59 titre
  • Enrichissement manuel des notices ne figurant pas dans OAI-Dalloz : 382 titres
    • ajout de l’url
    • modifier l’année
    • modifier l’éditeur
    • ajouter le code Dewey “340” si aucun Dewey n’est présent dans la notice
  • Titres présents dans OAI-Dalloz mais absents de tableau-Dalloz : 29 titres à traiter dans un second temps
  • Travail sur les notices d’e-books créées par l’ABES :
    • collections numériques : récupération du ppn ou demande de création
    • Envoi à l’ABES des ppn des collections numériques, en regard des URI fournis par l’ABES
    • Vérifier nécessité de créer et comment les champs 303,304,305,307,339
    • Vérifier les 13 notices signalées par l’ABES pour lesquelles plusieurs urls de consultations sont associées (liste fournie par l’ABES)

Conclusion

La durée de l’immersion n’a pas encore permis de répondre aux questionnements de l’ABES sur une implication d’établissements volontaires dépassant le cadre du catalogage et s’attachant  à des manipulations préparatoires sur les données soit pour participer à la mise à jour régulière des corpus  soit pour alimenter aussi BACON . Cette réflexion est encore en cours et fera l’objet vraisemblablement d’un autre billet.
Il nous faudra également revenir sur le chantier CERCLES en cours et et sur la question du fichier KBART, qui dépend de l’action de l’éditeur lui-même.

 

Catherine STORNE,

Responsable du département du système d’information documentaire,

SCD de l’université de Strasbourg

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.