Lancement du projet Data&Musée

Nous démarrons pour deux ans le projet Data&Musée avec une dizaine de partenaires. Ce projet porte sur les données produites et utilisées par les musées et institutions culturelles: billetterie, traces de visite du site web, livre d’or, parcours…

Evidemment, nous allons exploiter les techniques du Web Sémantiques et nous aurons l’occasion de reparler de ce projet ici dans les prochains mois.

Il va y avoir des embauches.

Il y a des partenaires particulièrement intéressants pour ce qui est de la sémantique: Kernix, ITEN.

Pour plus d’informations voir: https://blogrecherche.wp.imt.fr/2017/10/12/datamusee-data-institutions-culturelles/

Publié dans Cultural data, Marquage sémantique | Laisser un commentaire

Identifiants IdRef de chercheurs

Dans le post Premier contact avec les outils de l’Agence Bibliographique de l’Enseignement Supérieur, j’avais identifié IDREF comme source possible d’identifiants pour le projet SemBib.

J’ai obtenu une liste de 195 personnels de Télécom ParisTech impliqués dans la recherche. J’ai utilisé la requête indiquée dans le précédent post avec comme critères de recherche le nom et le prénom de chaque personne.

J’ai obtenu 195 réponses:

  • 130 proposaient un seul identifiant,
  • 17 n’en proposaient aucun,
  • 48 en proposaient plusieurs

Une vérification visuelle dur les notices associées à ces identifiants a permis de constater que lorsqu’un seul identifiant est proposé, c’est généralement le bon:

  • 124 sont exacts: ils correspondent bien à la personne souhaitée
  • 6 sont erronés ou incertains (dans ce cas, la notice n’a pas permis de s’assurer qu’il s’agissait de la bonne personne)

Sur les 17 pour lesquels on ne trouve pas d’identifiants, pour au moins 8 d’entre eux, c’est normal: ce sont des personnes qui ne publient pas, par exemple parce qu’ils sont ingénieurs de recherche et que leur activité ne les conduit pas à publier. Les 9 autres devraient avoir un identifiant IDREF.

Pour les 48 où la recherche simple donne plusieurs possibilités, j’ai cherché dans les données de la notice des indices permettant de choisir un des ID proposés. En pratique, je cherche si dans les textes qui composent la notice je trouve soit le nom d’un des autres chercheurs de Télécom ParisTech, soit un des labels associés à Télécom ParisTech: ENST, Télécom Paris…

Cela a permis de trouver 23 identifiants exacts supplémentaires.

Au final, si l’on considère la classe des chercheurs qui doivent avoir un identifiant, on a avec la méthode actuelle:

  • 147 identifiants exacts trouvés (124+23)
  • 178 identifiants trouvés (130+48)
  • 187 identifiants qui auraient dus être trouvés (130+48+9)

Ce qui donne

rappel = 147/187 = 79,46 %

précision = 147/178 = 82,58 %

Dans l’immédiat, je ne vais pas chercher à améliorer la méthode et me limiter à utiliser les identifiants qui ont pu être vérifiés. L’idée est d’affiner une méthode pour choisir parmi les identifiants multiples et donc de ne garder que ces identifiants uniques. En effet, sur les identifiants uniques, nous avons:

rappel = 124/187 = 67,02 %

précision = 124/130 = 95,38 %

Dans un second temps, donc, je vais tenter d’améliorer la précision d’une part en ne proposant que des ID quasi certains au prix d’une légère augmentation des éléments considérés comme ‘non trouvés’ lorsque aucun moyen n’aura permis de sélectionner un ID parmi les choix multiples. L’idée est d’utiliser avec confiance tous les ID trouvés.

Les pistes d’amélioration de la méthode sont:

  • utilisation de données externes où l’IDREF est présent (par exemple du côté de VIAF)
  • affiner l’utilisation des notices: ajouter des éléments à chercher, exploiter les titres de documents qui y figurent pour les chercher dans d’autres référentiels de publications scientifiques

Il va principalement s’agir de trouver une méthode qui permet une sélection parmi les choix multiples sans dégrader les résultats sur les autres résultats.

Publié dans Données publiques, Marquage sémantique, SemBib | Laisser un commentaire

Où Telecom ParisTech publie régulièrement: un peu de technique

Dans l’article Où Telecom ParisTech publie régulièrement, j’ai montré un exemple d’utilisation de la représentation sémantique de notre bibliographie: un graphique qui permet de voir les séries de conférences principalement utilisées par les chercheurs de Télécom ParisTech pour publier des résultats scientifiques.

Je vais donner ici quelques éléments techniques qui ont permis d’obtenir ce résultat. Pour alléger les notations, des préfixes sont utilisés; ils sont explicités à la fin de cet article.

Pour commencer, une URI a été attribuée à chaque publication. Elles sont de la forme:

où NNNNN est un numéro unique attribué à unepublication dans la base bibliographique de Télécom ParisTech. Par exemple:

Chaque article de conférence est associé à une conférence par le prédicat <http://givingsense.eu/sembib/inConf> que nous avons défini pour nos propres besoins.

Par exemple, l’article précédent est associé à une conférence par le triplet:

Chaque conférence est associée à une série de conférences à l’aide du prédicat

<http://lod.springer.com/data/ontology/property/hasSeries>

défini par l’éditeur Springer pour son point d’accès à son graphe de données (voir http://lod.springer.com/sparql-form/index.html)(chaque fois que possible les prédicats sont choisis parmi des prédicats utiles déjà utilisés par d’autres ensembles de données).

Ainsi la requête suivante nous permet de trouver le nombre de publications par série de conférences, classés par valeur croissante:

En envoyant la requête avec une demande de réponse au format TSV, on peut directement intégrer la réponse en entrée d’un graphique défini avec la librairie graphique javascript D3.js. Le code utilisé par notre représentation graphique est une variante très simple de l’exemple présenté ici.

Note complémentaire: préfixes utilisés ci-dessus

 

Publié dans Marquage sémantique, SemBib, SPARQL, Visualisation | Laisser un commentaire

Où Telecom ParisTech publie régulièrement?

(cliquer pour voir en grand)

Notre base bibliographique ne permet pas de faire ressortir aisément les conférences et journaux où nous publions souvent. L’approche sémantique que nous avons entamé avec le projet SemBib apporte des réponses.

Dans le cadre du projet SemBib, un travail -semi-automatique- a été effectué pour identifier les entités significatives de ce point de vue. Il s’est agit en particulier de lister les conférences scientifiques où nous publions. Dans un futur billet nous présenterons la méthode de déduplication et mise en cohérence des références.

Illustrons le problème: la conférence ICASSP est présente dans la base avec 30 intitulés différents pour plus de 80 publications.

Nous avons publié 2190 articles dans 1340 conférences de novembre 2010 à novembre 2015. Ci-dessus, un graphique des séries de conférences où nous avons le plus publié.

 

 

Publié dans Marquage sémantique, SemBib, Visualisation | Un commentaire

Analyser les publications de Telecom ParisTech: les données disponibles

Cet article fait suite à https://onsem.wp.imt.fr/2016/04/20/co-auteurs-des-publications-dune-institution-scientifique-telecom-paristech/.

Dans cet article, nous visualisions les liens entre chercheurs matérialisés  par des publications scientifiques communes.

J’utilise les données obtenues de la base bibliographique de Telecom ParisTech.

Mon idée est de tirer des informations utiles -j’espère- de cet ensemble de données. Dans ce billet, je fais le point sur les données de base disponibles.

Sur 5 ans, les données extraites montrent que:

  • 3796 publications sont recencées dans la base, 3161 en anglais, 632 en français, 1 en italien et 2 en espagnol
  • 1313 sont associées à une url d’accès en ligne au document
  • 1067 ont des mots-clés associés, dont 885 en anglais et 182 en français
  • 608 ont un DOI associé, avec des formes très variées (avec ou sans préfixe doi, url,…)

Ces urls associées sont de diverses natures:

  • 419 pointent directement sur un document téléchargeable sans difficulté, presque tous au format pdf (418/419)
  • 52 pointent vers une page du site d’archivage arxiv; le document est accessible par un lien contenu dans cette page, mais arxiv bloque les robots et la récupération de l’article ne peut donc pas être aisément automatisée
  • 5 pointent vers ACM Digital Library, archive payante de l’ACM
  • 52 pointent vers IEEE XPlore, archive payante de l’IEEE

On voit qu’une analyse des mots-clés disponibles ne porterait que sur 1/4 des publications, ce qui constituerait un biais majeur, en particulier si renseigner les mots-clés rélève de façon répétitive des mêmes auteurs. Cette analyse constitue malgré tout une connaissance. Nous allons mettre en place les outils pour automatiser sa réalisation afin de la refaire périodiquement.

En conclusion, nous pouvons observer que la base bibliographique de Télécom ParisTech est une référence pour connaitre nos publications, mais qu’elle est insuffisante pour une analyse approfondie du contenu de ces publications.

Publié dans Marquage sémantique, Outils, SemBib | Laisser un commentaire

Essais avec l’API Mendeley

Mendeley est un outil d’aide aux chercheurs pour organiser les références qu’ils consultent. Mendeley dispose d’une API. Ce billet rend compte des premiers essais effectués avec cette API. Je vais accéder à quelques données depuis un programme Python.

Il est nécessaire d’avoir un compte sur Mendeley; c’est possible sans payer.

Ensuite, depuis ce compte, il faut déclarer une application; ça se passe ici.

Mendeley utilise OAuth pour authentifier les utilisateurs de son API.

Après avoir déclaré l’application, il faut obtenir un ‘token’ ici. Il s’agit d’une longue chaîne de caractères qui va être utilisée dans les appels à l’API; sa durée de validité est de une heure (au moment de l’écriture de ce billet).

Ici, j’illustre l’accès aux informations concernant un document désigné par son numéro DOI.

Ce qui me donne le résultat suivant:

Si on remplace la valeur de la variable urlquery par

On va trouver les ‘profils’ définis dans Mendeley et qui on un lien avec ‘Jean-Claude Moissinac’. La requête fournit de nombreuses informations: affiliation, quelques domaines d’intérêt, photos, localisation…

Un ensemble de données intéressantes pour compléter l’information sur les chercheurs dans le projet SemBib!

Publié dans Outils, SemBib | Laisser un commentaire

Identifiants LOD pour Télécom ParisTech

Télécom ParisTech est une des principales écoles d’ingénieur du numérique en France; c’est aussi une grande institution de recherche. Le slogan affiché est assez représentatif de ses objectifs « Innover et entreprendre dans un monde numérique ».

La dénomination de Télécom ParisTech a évolué au fil du temps. La multiplication des noms rend difficile les rapprochements entre différentes sources de données. Les principes du Linked Open Data vont nous aider.

Voici quelques noms officiels ou noms d’usage qui ont été utilisés:

Telecom ParisTech

Télécom Paris

Ecole Nationale Supérieure des Télécommunications

École Nationale Supérieure des Télécommunications de Paris

ENST ou E.N.S.T.

Sup Télécom

et précédemment:

ainsi que diverses variantes autour des ces intitulés.

Il est alors difficile aux catalogues et systèmes d’indexation de bien rattacher nos chercheurs et publications à une seule et même institution (par exemple, pour compter les publications pour un classement des universités…).

Les principes du LOD peuvent nous aider à utilisant un identifiant unique dans les données que nous allons produire dans le cadre du projet SemBib.

Quel identifiant utiliser?

VIAF est un fichier d’autorité, recensant de nombreux auteurs à travers le monde et leur attribuant un identifiant unique. Depuis quelques temps VIAF recense aussi les organismes et les conférences en s’aidant notamment de Wikidata (voir Corporate VIAF).

Une recherche simple sur leur site nous donne

http://viaf.org/viaf/130089636/

D’où, on peut déduire l’accès à une version RDF, sans faire de la négociation de contenu:

http://viaf.org/viaf/130089636.rdf

Les données associées sont cependant partiellement erronées, en particulier sur les propriétés schema:alternateName et skos:altLabel, où Télécom Bretagne est considérée comme un nom alternatif pour Télécom Bretagne.

Worldcat, le catalogue international de publication, initiative de l’OCLC, recense aussi des organisations et assure des liens avec VIAF. Avec l’URL suivante

http://www.worldcat.org/identities/viaf-130089636/

directement dérivée du numéro VIAF de Télécom ParisTech, on trouve l’enregistrement de Télécom ParisTech dans Worldcat. On constate des erreurs analogues à celles de VIAF. On trouve aussi dans cette page un lien vers un ensemble de publications associées à Télécom ParisTech. Par contre, la page obtenue à cette adresse contient du marquage RDFa, qu’on peut voir, par exemple, avec le RDFa Distiller du W3C:

https://www.w3.org/2012/pyRdfa/extract?uri=http%3A%2F%2Fwww.worldcat.org%2Fidentities%2Fviaf-130089636%2F&format=turtle&rdfagraph=output&vocab_expansion=false&rdfa_lite=false&embedded_rdf=true&space_preserve=true&vocab_cache=true&vocab_cache_report=false&vocab_cache_refresh=false

On y voit notamment les triplets suivants:

<http://www.worldcat.org/identities/viaf-130089636> ns1:sameAs <http://en.wikipedia.org/wiki/Special:Search?search=T%C3%A9l%C3%A9com_ParisTech>,
<http://id.loc.gov/authorities/names/n81054244>,
<http://viaf.org/viaf/130089636>,
<https://www.wikidata.org/wiki/Q2311820>

La dernière URI, celle de Wikidata, parait intéressante. Les informations liées sont assez peu nombreuses, mais toutes exactes. L’URI Wikidata semble être un bon candidat. De plus, le processus de production des données de Wikidata parait nous permettre, assez aisément, des mises à jour, des compléments et des corrections afin de garantir une description aussi correcte que possible associée à l’URI.

Sur la page Wikidata, on trouve aussi les identifiants suivants:

GRID – Global Research Identifier Database):

https://www.grid.ac/institutes/grid.463717.0

ISNI – International Standard Name Identifier (ISO 27729):

http://www.isni.org/0000000121082779

L’ISNI est une bonne référence internationale. Les informations liées semblent correctes.

Dans la page de l’ISNI, on trouve un lien vers un identifiant LC (Library of Congress):

http://id.loc.gov/authorities/names/n81054244

et enfin un identifiant SUDOC/IDREF -déjà abordé dans le billet Premier contact avec les outils de l’Agence Bibliographique de l’Enseignement Supérieur

http://www.idref.fr/026375273

On trouve au niveau de la page descriptive de cet URI une référence à l’ISNI http://www.isni.org/isni/0000000121096951 qui contient les mêmes confusions avec Telecom Bretagne qu’évoquées précédemment.

Dans cette page, on trouve un nouvel identifiant, l’identifiant ARK utilisé par la BNF (qui correspond au numéro de notice BNF FRBNF118634931):

http://catalogue.bnf.fr/ark:/12148/cb11863493k

Pour mémoire, citons aussi l’identifiant qu’on peut trouver au niveau du projet Semantic Web Doc Food, qui a évolué vers le projet Scholarlydata, et s’applique à la récolte de données sur les publications scientifiques:

http://data.semanticweb.org/organization/telecom-paristech

qui a évolué vers

https://w3id.org/scholarlydata/organisation/telecom-paristech

Conclusion

Pour les raisons évoquées ci-dessus, nous allons utiliser l’identifiant Wikidata:

https://www.wikidata.org/wiki/Q2311820

Par ailleurs, nous allons créer un graphe pour récolter les équivalences entre identifiants d’organisations et de chercheurs -voir Identificateurs uniques de chercheurs versus Uniques identificateurs de chercheurs– en exploitant notamment la propriété owl:sameAs.

 

 

 

Publié dans DBPedia, Données publiques, Marquage sémantique, SemBib | Laisser un commentaire

Expérimentation en Python pour accéder à ISTEX

ISTEX a pour ambition de « construire le socle de la bibliothèque scientifique numérique nationale. » Il s’agit d’une initiative dans le cadre des « Investissements d’Avenir » soutenus par l’Etat français.

ISTEX acquiert et structure de grandes quantités de documents scientifiques pour les rendre accessibles.

Nous nous intéressons ici à l’accès aux ressources d’ISTEX via une API.

API ISTEX

Les informations concernant l’API ISTEX se trouvent à l’adresse https://api.istex.fr/documentation/. Certaines ressources sont en accès libre, d’autres nécessitent une authentification.

L’API propose plusieurs modes d’authentification. Nous allons utiliser l’authentification par clé (token d’identification). La méthode décrite (https://api.istex.fr/documentation/access/) est en deux étapes: création du token, accès à l’API à l’aide du token.

La création du token nécessite de s’identifier à l’adresse https://api.istex.fr/token/ soit par son établissement d’enseignement/recherche en le sélectionnant dans une liste, soit en utilisant un CRU -Compte Réseau Universel- que l’on peut créer en ligne. Une fois cette authentification réalisée, un accès à la même adresse renvoie une structure JSON telle que:

Le champ « _accessToken » de la structure JSON obtenue est le token qui pourra être utilisé lors des accès suivants à l’API. J’ai sauvé la structure JSON dans un fichier tokenIstex.json.

Exemple de requête à ISTEX

Un code minimal pour interroger ISTEX est alors par exemple

Vous devez renseigner votre token.

La requête proprement dite est la valeur du paramètre q. Ici, j’indique que je veux chercher suivant le critère author.name qui doit avoir la valeur Moissinac.

La réponse est une structure JSON sur le modèle fictif suivant:

On y trouve le nombre total de réponse, par défaut les 10 premières réponses dans le champ hits, les urls de la page suivante, de la première et de la dernière page de réponses. Pour chaque réponse, on a le titre, un identifiant de ressource ISTEX -que nous utiliserons dans d’autres requêtes- et un score -qui évalue une pertinence de la réponse?.

La composition des requêtes est décrite ici:

https://api.istex.fr/documentation/search/

La requête suivante

donnera les documents contenant le mot semantic dans un des champs indexés.

et la requête

donnera le document dont l’identifiant ISTEX est 982F365ECC48B450E090EC595C09C8472DE784CF.

Pour avoir plus d’informations sur ce document, il suffit d’utiliser cet identfiant pour la requête

qui renvoie une structure JSON avec notamment le titre, les auteurs et leur affiliation….

Précautions

De façon classique lorsqu’on utilise une API, il faut éviter de surcharger le serveur en envoyant des salves de requêtes générées par un logiciel.

Vous devez utiliser une des méthodes permettant d’appeler une fonction chaque N secondes. La méthode appelée consomme à chaque fois une requête placée dans une liste de requêtes. J’ai ainsi sollicité ISTEX par une requête toutes les 5 secondes.

Résultats

Sur cette base, j’ai cherché les publications de Telecom ParisTech.

La requête

donne 479 références. Tandis que la requête

donne 225 références.

 

Publié dans Données publiques, SemBib, Uncategorized | Laisser un commentaire

Identificateurs uniques de chercheurs versus Uniques identificateurs de chercheurs

Comme mentionné dans l’article « Premier contact avec les outils de l’ABES » , pour le projet SemBib, j’ai commencé par utiliser mes propres identifiants pour les chercheurs. Ensuite, j’ai voulu utiliser des identifiants provenant de sources de références, à commencer par les identifiants IDREF de l’ABES.

J’ai mis le doigt dans un engrenage.

Devant les difficultés rencontrées pour récupérer les identifiants IDREF de tous les chercheurs de Telecom ParisTech, et ayant vu que l’ABES a des accords avec VIAF, j’ai cherché ce que je pouvais faire du côté de VIAF. VIAF est un ‘fichier d’autorité international virtuel’ créé par un ensemble de bibliothèques nationales. Il gère notamment un ensemble d’identifiants uniques de personnes. Nous avons vu dans le billet ci-dessus comment j’ai récupéré depuis VIAF des informations sur les chercheurs de Telecom ParisTech.

En analysant un peu les données obtenues, j’ai pu voir que les données VIAF provenaient de diverses sources; de proche en proche, à partir de ces sources, j’ai ainsi trouvé des identifiants de personnes provenant de:

  • BNF: la Bibliothèque Nationale de France attribue des identifiants à des auteurs et notamment des auteurs de publications scientifiques,
  • ARK: un système d’identification aussi utilisé par la BNF,
  • SUDOC: c’est un catalogue produit par l’ABES, qui gère notamment les identifiants IDREF,
  • ISNI: pour « International Standard Name Identifier », défini par une norme ISO, utilisé aussi, entre autres, par la BNF (voir ISNI et la BNF)
  • DBPedia:
  • ResearcherID:
  • ORCID: ces identifiants concernent des auteurs et contributeurs des domaines de l’enseignement supérieur et de la recherche; il y a des liens imparfaits entre l’ISNI et l’ORCID (voir Relations entre ORCID et ISNI);
  • DNB: les identifiants utilisés pat la DEUTSCHEN NATIONALBIBLIOTHEK;
  • RERO: semble définit par le Réseau des Bibliothéques de Suisse Occidentale;
  • LC: identifiants utilisés par la Library of Congress;
  • KRNLK: le point d’accès Linked Open Data de la National Library of Korea, qui comporte un accès SPARQL (http://lod.nl.go.kr/home/sparql/se.jsp)
  • ICCU: utilisé par l’Institut Central pour un Catalogue Unifié des Bibliothèques Italiennes (ICCU)
  • LNB: identifiants dans la Bibliothèque Nationale de Lettonie
  • NKC: identifiants de la Bibliothèque nationale tchèque
  • NLI: identifiants de la Bibliothèque nationale d’Israël
  • NLP: identifiants de la Bibliothèque nationale de Pologne
  • NSK: identifiants de la bibliothèque universitaire de Zagreb;
  • NUKAT: provient du Centre NUKAT de l’Université de Varsovie
  • SELIBR: utilisé par LIBRIS, un service de recherche qui fournit des informations sur les titres détenus par les universités suédoises et les bibliothèques de recherche (exemple: http://libris.kb.se/auth/264078);
  • WKD: concerne les identifiants utilisés par WikiData;
  • BLSA: provient probablement de la British Library
  • NTA: identifiants de la Bibliothèque royale des Pays-Bas

J’en ai surement oublié…

Ces identifiants désignent tous un chercheur de façon unique dans un système d’identification. Mais, comme nous venons de le voir, il peut y avoir de nombreux identifiants pour un même chercheur; tous les chercheurs n’ont pas tous les identifiants, mais ils en ont souvent plusieurs.

Par exemple, Antonio Casilli est identifié au moins par:

BNF, ARK,  ISNI, VIAF, LC, SUDOC, ORCID, DNB|1012066622, NUKAT|n 2016165182

Les chercheurs ont ainsi plusieurs identifiants plus ou moins équivalents qu’il peut être utile de connaître dans une approche Linked Open Data: si l’on veut être capable de lier les données sur un chercheur, il faut déjà pouvoir lier leurs identifiants uniques! Je reviendrais dans un prochain billet sur la solution décentralisée que je propose.

Note: cela me fait penser à la blague sur les normes vidéos « il y a N normes différentes, c’est trop; pour en finir, je vais faire un format unique qui réunira le meilleur de chaque norme »; après un tel travail, on n’a pas 1 norme, mais N+1 normes…

Publié dans Marquage sémantique, Outils, SemBib | Un commentaire

Premier contact avec les outils de l’Agence Bibliographique de l’Enseignement Supérieur

Dans le cadre du projet SemBib, j’ai été amené à choisir un identifiant unique pour chaque auteur. Suivant ma stratégie habituelle, j’ai commencé par utiliser des identifiants définis dans notre espace de nommage, avec notre préfixe. Ainsi, il a été possible de produire rapidement des résultats et d’inciter d’autres personnes à participer au projet.

J’applique cette méthode pour les éléments dont j’ai immédiatement besoin, ici les auteurs; je cherche à minimiser les identifiants et le vocabulaire que je définis de façon ad-hoc et à utiliser le plus de vocabulaire connus et courants, mais, dans un esprit d’approche agile, je ne veux pas bloquer de premiers résultats applicatifs par une recherche laborieuse de tous les vocabulaires pré-existants avec lesquels se lier.

Dans un deuxième temps, je cherche si un vocabulaire ou des identifiants existent afin  de créer des liens avec d’autres ensembles de données. Le principe de base est de créer de nouvelles versions de mes données -avec une compatibilité ascendante, si les données ont été publiées- notamment avec l’utilisation de owl:sameAs. Je compte consolider cette stratégie dans les prochains mois et je suis preneur d’avis à ce sujet.

Par hasard, j’ai trouvé que je suis identifié par IdRef avec le lien permanent http://www.idref.fr/157248550. Je suis donc allé voir de plus prêt de quoi il s’agit. La page à l’adresse http://www.idref.fr donne peu d’informations. Le sous-titre de IdRef est ‘Le référentiel des autorités Sudoc’, ce qui n’est pas très parlant -sauf si on sait que SuDoc est ‘Le catalogue du Système Universitaire de Documentation’. Le bas de la page contient un bandeau ‘ABES – Agence Bibliographique de l’Enseignement Supérieur’, ce qui suggère déjà un lien plus direct avec le projet SemBib et m’a incité à approfondir.

En fait, la documentation en ligne m’a appris que mon identifiant idref est http://www.idref.fr/157248550/id. Je peux obtenir une représentation XML du contenu de ma notice bibliographique enregistrée par l’ABES à l’adresse http://www.idref.fr/157248550.xml (noter qu’elle est très incomplète). Et pour la notice en JSON: http://www.idref.fr/services/biblio/157248550.json.

En principe, la requête http://www.idref.fr/services/idref2viaf/157248550 devrait trouver mon identifiant VIAF (http://viaf.org/viaf/291343068), mais ne le trouve pas.

Trouver l’identifiant d’un chercheur

Je me suis demandé si j’allais ainsi pouvoir associer un identifiant idref à tous les chercheurs de Telecom ParisTech. Comme il y a environ 200 chercheurs et autant de doctorants à Telecom ParisTech, je voudrais automatiser cela.

Par malchance, le jour où j’ai commencé mes tests les exemples de la section 2.3 ne fonctionnaient pas (le 16/1/2017). J’ai donc posté un message à l’adresse email figurant dans la documentation. Très vite j’ai eu une réponse, avec plusieurs propositions (merci F.M. dont la réponse est largement reprise ci-dessous). Je me borne ici à décrire les solutions publiquement accessibles.

Première méthode

La première consiste à interroger le moteur de recherche Solr d’IdRef avec un Nom/ Prénom de personne (service documenté ici http://documentation.abes.fr/aideidrefdeveloppeur/ch02s01.html).  Exemple de requête : http://www.idref.fr/Sru/Solr?q=persname_t:(Moissinac AND Jean-Claude)&fl=ppn_z, affcourt_z&wt=xml

Le paramètre q contient la recherche qui va être effectuée par Solr. Ici, on fait une recherche de type ‘contient les mots’ -indiqué par le suffixe _t- sur le champs persname (nom de personne), suivi de : pour indiquer ses paramètres, ici une liste de chaîne de caractères qui vont être cherchées. Si les mots cherchés sont trouvés -c’est le cas dans l’exemple ci-dessus-, on obtient une réponse telle que:

En remplaçant la fin de la requête wt=xml par wt=json, on obtient une réponse mise en forma en JSON (au 27/1/2017: pas avec le bon MIME type).

La méthode présente un risque de ne rien obtenir si la base IDREF ne contient pas exactement les chaînes cherchées ou la possibilité de récupérer trop de choses si on ouvre trop la recherche. Par exemple, une recherche limitée au mot Moissinac donne 9 réponses qu’il va falloir discriminer. Par exemple, en allant chercher les notices bibliographiques -cf.ci-dessus- et en éliminant les notices inappropriées. Dans les 9 réponses pour ‘Moissinac’, la première est l’id 056874022 associé à la notice http://www.idref.fr/services/biblio/056874022.json où on peut, par exemple, constater que le champ « name » a la valeur « Moissinac, Bernard ». On peut, par exemple, tester les différents champs « name » par rapport à la chaîne de référence « Moissinac, Jean-Claude » avec le distance de Levenshtein. Cela devrait suffire à discriminer correctement la plupart des cas. On peut aussi avoir un contrôle spécifique sur tous les noms pour lesquels on obtient 0 ou plusieurs réponses (en supposant que lorsqu’on a une seule réponse, c’est la bonne). Nous envisagerons plus tard de faire des tests automatisés sur les autres champs de la notice.

Deuxième méthode

La seconde méthode consiste à interroger le moteur Solr de theses.fr avec un nom/prénom et une contrainte supplémentaire de lien de cette personne avec Telecom Paristech (=Paris, ENST) ou son identifiant idref 026375273 :
http://www.theses.fr/?q=personneRAs:jean-claude+moissinac%20AND%20etabSoutenances:Paris%2C+ENST&type=avancee&lng=&lng=&format=xml&fl=directeurTheseNP,directeurThesePpn

On peut obtenir une sortie xml ou json.

Les personnes recherchées doivent avoir été impliquées dans une thèse et pas forcément associées à « Paris, ENST ». La contrainte est forte. De plus, theses.fr ne semble pas connaitre nos différents noms: Telecom Paris, Télécom Paris, Télécom ParisTech… ou, en tout cas, ne pas identifier qu’il s’agit de diverses dénominations d’un même organisme. L’idéal serait de trouver une fois pour toutes l’identifiant idref de notre institution et de l’utiliser dans les critères de recherche. Nous ne traiterons pas cette question aujourd’hui.

S’appuyer sur VIAF

Le billet http://corist-shs.cnrs.fr/IDChercheurs_2016 contient des pistes: au lieu d’utiliser IDREF, s’appuyer sur ORCID ou VIAF avec lesquels IDREF a des accords d’échange.

Un tour sur les API d’ORCID et notamment l’API VIAF (https://platform.worldcat.org/api-explorer/apis/VIAF) me donne le lien suivant:

http://www.viaf.org/viaf/search?query=cql.any+=+%22Jean-Claude%20Moissinac%22&maximumRecords=5&httpAccept=application/json

me permet de trouver mon identifiant VIAF et bien d’autres (SUDOC/IDREF notamment).

Je n’ai plus qu’à décliner cette requête sur l’ensemble des noms de chercheur de Telecom ParisTech en espérant qu’il n’y aura pas trop d’ambiguïtés -qui se traduit avec un champ numberOfRecords supérieur à 1- ou d’absents -qui se traduit avec un champ numberOfRecords supérieur à 0.

 

Suite: Accès Sparql

Dans un prochain billet, nous explorerons l’accès SPARQL de l’ABES:  https://lod.abes.fr/sparql.

 

 

Publié dans Données publiques, SemBib | 2 commentaires

Premiers contacts avec l’accès SPARQL de l’éditeur Springer

Dans le cadre du projet SemBib, je vais découvrir avec vous l’accès SPARQL public de l’éditeur scientifique Springer à l’adresse http://lod.springer.com/sparql-form/index.html. Pour un premier contact, il faut faire connaissance et quelques requêtes classiques vont nous y aider.

D’abord, découvrir les propriétés utilisées:

qui met environ 23 secondes (j’ai un peu triché: je l’ai exécutée une première fois pour voir les URI utilisées et en déduire des préfixes à définir et avoir le résultat plus compact ci-dessous, grâce aux préfixes).

Elle donne :

D’une part cela nous montre que les performances ne sont pas exceptionnelles. D’autre part, on voit que pour l’essentiel Springer a défini sa propre ontologie: des données sont accessibles, mais pas vraiment reliées au reste du monde par des concepts partagés. Les données sont définies avec 47 prédicats (propriétés).

La requête suivante -sans répéter les préfixes ci-dessus définis- nous donne le nombre de ‘sujets’ distincts renseignés dans la base: 451277.

et celle qui suite donne le nombre de triplets qui renseignent ces sujets: 3490865, soit environ 8 prédicats par sujet différent, ce qui est peu pour renseigner de façon détaillée des références bibliographiques. On peut supposer qu’on aura donc peu de données sur chaque référence.

Le relativement faible de prédicats par sujet me suggère de chercher les plus utilisés:

ce qui donne (en enlevant les moins utilisés, concernant essentiellement des questions de droits):

On voit que l’essentiel de l’information disponible sur un élément de la base consiste en: son type, son numéro DOI, son titre, de quoi l’élément est un chapitre, à partir de quelle page et jusqu’à quelle page. Les autres informations concernent notamment des conférences d’où peuvent provenir les documents.

Prédicats avec domain et range

On voit que les propriétés domain -qui nous donne la catégorie d’objets à laquelle s’applique le prédicat- et range -qui nous donne la catégorie des valeurs possibles pour ce prédicat- semblent renseignées pour certains prédicats .

Avec la même petite tricherie que ci-dessus pour les préfixes, la requête suivante nous donne en 15 secondes les domain et range utilisés:

Le résultat est:

Exploration de quelques prédicats

dc:creator

Je m’attendais à un usage de dc:creator pour les noms d’auteurs. Mais dc:creator ne prends qu’une seule valeur: « Springer »@en. Sans doute pour désigner le créateur de la base. Aucun autre prédicat ne semble pouvoir être porteur du nom des auteurs.

rdf:type

La requête suivante va nous permettre de voir la répartition des types utilisés:

donne

spr:bookDOI

Ce prédicat permet probablement d’associer un numéro DOI à chaque document. Par nature, il est désigne de façon unique un document. Je vais m’intéresser à la forme utilisée pour enregistrer le numéro DOI par Springer (j’ai noté, par exemple, que dans la base de Telecom ParisTech, diverses formes sont utilisées).

donne

On voit une représentation homogène des numéros DOI dans la base de Springer. J’ai vérifié cela sur un plus grand nombre d’exemple.

Des prédicats au sujet des conférences

Plusieurs prédicats semblent concerner des séries de conférences. Je vais chercher combien sont concernées et quelles séries conférences ont eu le plus d’occurrences.

On trouve 1477 sujets de type spc:ConferenceSeries (cf ci-dessus les types les plus fréquents).

La requête suivante va nous donner les 20 séries de conférences qui ont le plus donné lieu à publication par Springer:

donne

Cela donne probablement un aperçu des thématiques les plus abordées par Springer.

Actualisation de la base

Des documents scientifiques sont publiés chaque mois.

Pour me faire une idée de la fraîcheur des données disponibles ici, je fais un premier test sur un livre auquel j’ai contribué -« Multimodal Interaction with W3C Standards »- dont le DOI est: 10.1007/978-3-319-42816-1. Il n’est pas dans la base le 3/12/2016.

Quelques prédicats suggèrent des informations de date. Je vais chercher la date la plus récente présente dans la base. Je vais utiliser le prédicat de ce type le plus fréquent: spr:chapterRegistrationDate, qui donne des dates de la forme

La requête

donne le résultat surprenant suivant

Le dernier document enregistré l’a été dans le futur!?!

En tout cas, cela suggère que cette base est régulièrement actualisée -même si les dates affichées doivent être interprétées d’une façon que j’ignore pour le moment.

Conclusion

Cette exploration confirme ce dont j’ai l’intuition depuis le début du projet SemBib: il y a de plus en plus de sources de données bibliographiques, mais chacune a ses propres objectifs et est incomplète pour d’autres objectifs, comme ceux de Sembib.

Cela confirme aussi l’axe choisi pour Sembib: constituer un graphe de données propre à SemBib, mais interconnecté avec d’autres graphes. SemBib plaide pour une fédération de graphes bibliographiques interconnectés.

Publié dans Données publiques, SemBib, SPARQL | Laisser un commentaire

Sémantique de la virgule

Texte de Piaf - Hymne à l'amour

Il y a quelques temps, dans une rame de métro, mon regard a été attiré par une petite affiche avec le contenu suivant:

Le ciel bleu sur nous peut s’effondrer
Et la terre peut bien s’écrouler
Peu m’importe si tu m’aimes
Je me fous du monde entier

Un extrait de la chanson d’Edith Piaf « L’hymne à l’amour ».

Il m’a semblait qu’il manquait une virgule pour être cohérent avec le sens général de la chanson.

En fait, sans virgule, le texte est ambiguë. On peut le lire de deux façons diamétralement opposées, qu’on peut révéler avec l’ajout de virgules.

Une première lecture donne:

Peu m’importe si tu m’aimes, 
Je me fous du monde entier

Qui peut se lire: je me moque de savoir si tu m’aimes et de toute façon, je me fous de tout.

Une deuxième lecture, avec deux virgules donne:

Peu m’importe, si tu m’aimes, 
Je me fous du monde entier

Qui peut se lire: si tu m’aimes, rien d’autre n’a d’importance. Très différent de la première lecture.

Une subtilité difficile à saisir dans les traitements automatiques…

Publié dans Cuisine traitement de textes, Marquage sémantique | Laisser un commentaire

Thèse sur l’enrichissement sémantique de livres numériques

Vous êtes invités à la soutenance de thèse de Vincent Gros, intitulée « Modélisation d’un livre numérique adaptable par enrichissement sémantique des contenus – Réalisation par le  standard EPUB », menée dans le cadre d’un partenariat CIFRE entre Hachette Livre et Telecom ParisTech.

Elle aura lieu le 29 septembre à 15h00 à Télécom ParisTech, salle H2.

Modélisation d’un livre numérique adaptable par enrichissement sémantique des contenus – Réalisation par le standard EPUB

Résumé : Avant le fort développement du Web, le livre était la source d’information privilégiée et ce depuis l’invention de l’imprimerie. Les qualités du livres sont diverses : entre autres, les informations sont réunies en un ensemble cohérent, avec pour la plupart des ouvrages un fil conducteur du début jusqu’à la fin, qui se traduit par une lecture linéaire du contenu page après page. Mais un livre imprimé ne peut s’adapter directement aux besoins particuliers d’un individu : c’est un objet statique, imprimé une fois pour toute. L’évolution numérique a certes permis l’émergence de formats comme le standard EPUB, offrant davantage de fonctionnalités, notamment en termes d’interactivité et de multimédia. Mais le comportement des livres numériques ne diffèrent pas des principes du livre papier. Peut-on définir le livre numérique comme un objet dynamique, qui peut s’adapter aux besoins de l’utilisateur ?

Nous proposons de réfléchir à des livres dont les modes d’interaction et la présentation s’adaptent à l’utilisateur selon ses objectifs. C’est particulièrement intéressant pour les livres pratiques : les utilisateurs ne sont pas tous intéressés par les mêmes informations et n’ont pas les mêmes attentes, capacités ou centres d’intérêts. Pour cela, si le livre numérique tire ses origines depuis le livre papier, l’hypertexte, défini par Nelson dès 1965, peut en être une référence majeure. Des approches prometteuses dans la recherche viennent notamment des systèmes hypermédias adaptatifs et des documents virtuels personnalisables. Nous définissons le livre numérique comme un ensemble autonome de contenus organisé selon trois représentations : une représentation sémantique des données, une représentation logique de la structure du livre et la mise en forme esthétique du contenu présenté à l’utilisateur. Nous proposons ensuite d’intégrer un mécanisme d’adaptation du contenu au sein des livres numérique, déterminé par des caractéristiques utilisateurs. Nous implémentons cette approche en utilisant le standard EPUB et en facilitant la construction des fichiers par un workflow XML étendu par des règles de mise en correspondance entre la source et les représentations internes au livre.

 

Mots clés : Interaction homme-machine, Ingénierie documentaire, Ingénierie des connaissances, technologies XML, Web Sémantique, Hypermédia adaptatif, EPUB, chaîne de production éditoriale.

Publié dans Livre numérique, Marquage sémantique, Outils | Laisser un commentaire

Statistiques sur DBPedia-Fr

J’ai eu besoin du nombre d’entités distinctes décrites dans dbpedia-fr. Nous allons voir un problème à prendre en compte lors de l’utilisation des données liées faisant appel à des points d’accès publics.

Ma première tentative a été d’obtenir cette information avec la requête

mais celle-ci échouait systématiquement sur un timeout.

Alors que si je me limitais à compter les triplets avec

j’obtenais

185404575

Nandana Mihindukulasooriya m’a indiqué l’outil Loupe pour connaître des statistiques sur des jeux de données, mais je voulais pouvoir obtenir l’information directement par programme en interrogeant la source que j’utilisais: ici, DBPedia-Fr, mais potentiellement avec une méthode applicable à d’autres jeux de données.

Hugh Williams m’a indiqué que ma requête était fortement consommatrice de ressources (dans l’implémentation de Virtuoso qui héberge DBPedia et qui, semble-t-il passe par la construction d’une très grande table de hashage). Il m’a signalé que DBPedia (anglais) propose une description à jour de son jeux de données suivant les principes proposé par la note technique sur VoID: VoID pour DBPedia; cela évite que des requêtes lourdes à traiter soient effectuées de façon répétitives pour obtenir ces informations. Mais la version française ne propose pas cela à la date de rédaction de ce billet.

John Walker m’a proposé de réécrire ma requête de la façon suivante:

il semble que cette écriture consomme moins de ressources, et j’obtiens le résultat attendu:

10515620

Pourquoi cette écriture est plus efficace que l’autre? Elle me semble sémantiquement équivalente; il faudrait donc comprendre le détail de la façon dont elle est implémentée pour imaginer quelle écriture est préférable. A ce sujet, on trouve un chapitre entier sur l’optimisation de requêtes dans le très bon livre de Bob du Charme sur SPARQL.

Alasdair J G Gray me signale le rapport Dataset Descriptions: HCLS Community Profile et en particulier la section 6.6 où des exemples de statistiques à obtenir sur des jeux de données sont présentés avec les requêtes SPARQL qui permettent de les obtenir.

Les résultats ci-dessous correspondent à l’application de ces requêtes à DBPedia-Fr.

Description Requete Resultat
Nombre de triplets SELECT (COUNT(*) AS ?triples) { ?s ?p ?o } 185404575
Nombre d’entites typees distinctes SELECT (COUNT(DISTINCT ?s) AS ?entities) { ?s a [] } 6015375
Nombre de sujets distincts SELECT (COUNT(DISTINCT ?s) AS ?distinctSubjects) { ?s ?p ?o } time out
Nombre de proprietes distinctes SELECT (COUNT(DISTINCT ?p) AS ?distinctProperties) { ?s ?p ?o } 20321
Nombre d’objets distincts de type non litteral SELECT (COUNT(DISTINCT ?o ) AS ?distinctObjects){ ?s ?p ?o FILTER(!isLiteral(?o)) } time out
Nombre de classes distinctes SELECT (COUNT(DISTINCT ?o) AS ?distinctClasses) { ?s a ?o } 442
Nombre d’objets distincts de type litteral SELECT (COUNT(DISTINCT ?o) AS ?distinctLiterals) { ?s ?p ?o filter(isLiteral(?o)) } time out
Nombre de graphes dans le jeu de donnee SELECT (COUNT(DISTINCT ?g ) AS ?graphs) { GRAPH ?g { ?s ?p ?o }} 14

Les mêmes requêtes appliquées à DBPedia donnent:

Description Requete Resultat Donnes VoID
Nombre de triplets SELECT (COUNT(*) AS ?triples) { ?s ?p ?o } 438038746 438038866
Nombre d’entites typees distinctes SELECT (COUNT(DISTINCT ?s) AS ?entities) { ?s a [] } rien
Nombre de sujets distincts SELECT (COUNT(DISTINCT ?s) AS ?distinctSubjects) { ?s ?p ?o } rien 33996245
Nombre de proprietes distinctes SELECT (COUNT(DISTINCT ?p) AS ?distinctProperties) { [] ?p ?o } 64119 64119
Nombre d’objets distincts de type non litteral SELECT (COUNT(DISTINCT ?o ) AS ?distinctObjects){ ?s ?p ?o FILTER(!isLiteral(?o)) } rien 164615518 (?)
Nombre de classes distinctes SELECT (COUNT(DISTINCT ?o) AS ?distinctClasses) { [] a ?o } 370680 370680
Nombre d’objets distincts de type litteral SELECT (COUNT(DISTINCT ?o) AS ?distinctLiterals) { ?s ?p ?o filter(isLiteral(?o)) } 29883287
Nombre de graphes dans le jeu de donnee SELECT (COUNT(DISTINCT ?g ) AS ?graphs) { GRAPH ?g { ?s ?p ?o }} 19
Nombre d’objets distincts 164615518

Pour obtenir certains résultats, il a fallu augmenter le temps accordé à la requête pour être traitée; pour d’autres, la requête proposée dans le document ci-dessus a été un peu modifiée. DBPedia ne provoque pas de ‘time out’, mais renvoie une réponse vide quand il n’a pas pu traiter la requête (voir discussion ici). Les gestionnaires de DBPedia proposent de ne pas considérer leur serveur comme serveur de production et d’en installer une copie si on veut des résultats plus garantis; en effet, ils doivent faire face à une grande masse d’utilisateurs et ne peuvent offrir une totale garantie de service. Il en résulte que certaines requêtes, même en augmentant le délai de traitement, on n’obtient pas de résultat.

On constate néanmoins que DBPedia fait un usage beaucoup plus intensif des classes que DBPedia-Fr. Je reviendrais sur l’usage des classes dans un prochain billet.

Nous avons vu ici des contournements à certains problèmes de délai de traitement de certaines requêtes; mais ces contournements ne marchent pas toujours, même sur des requêtes qui paraissent simples et d’usage élémentaire (compter certains types d’éléments dans un jeu de données).

 

 

 

Publié dans DBPedia, SPARQL, Tutoriel | Laisser un commentaire

Héberger une instance de Fuseki sur OpenShift

Nous allons voir comment héberger une instance de serveur RDF Fuseki sur OpenShift, l’hébergement de RedHat.

Vous devez avoir un compte sur OpenShift (possibilité de comptes gratuits).

Sur la console d’administration OpenShift, créez une application de type ‘Do It Yourself’. Cela va prendre quelques minutes. Ici, je nomme l’application fuseki.

Chargez l’outil RHC , outil RedHat qui facilitera la configuration (attention: à la date d’écriture de cet article, rhc ne fonctionne bien qu’avec la version 1.9.3 de ruby, pas avec les versions ultérieures).

Dans une fenêtre de ligne de commande Windows, en tapant

rhc show-app fuseki

Vous verrez les caractéristiques de l’application créée, dont l’URL du git distant utilisé pour gérer l’installation de l’application. Comme vous avez créé l’application à partir de la console web, vous devez la cloner localement. Créez un directory pour contenir l’application (fuseki pour l’exemple), puis clonez le git

git clone <url du git distant> fuseki

Allez dans ce directory.

Pour récupérer sur github une installation de base toute prête, tapez

puis

Vous avez localement une version 0.2.7  de Fuseki (qu’il faudra mettre à jour).

Poussez-la sur OpenShift

L’application est alors accessible à l’URL

On ne va pas essayer tester de façon approfondie cette version ancienne, mais plutôt faire dès maintenant une mise à jour.

Mise à jour de Fuseki

Sur la page Apache Fuseki, on trouve un zip à télécharger; on va se limiter à la version 1.4, car la version 2.4 nécessite Java 8 qui n’est pas encore disponible en standard sur OpenShift et nécessite pas mal d’ajustements (la version 2.4 permet notamment un meilleur contrôle des autorisations). On va le décompresser dans le dossier de notre application. Cela va créer un dossier jena-fuseki-1.4.0.

Dans le dossier .openshift/action_hooks, dans le fichier start, modifier la ligne

par

 

Ajouter et commiter les modifications faites à votre application:

Pousser le tout sur OpenShift

Cela peut être assez long.

Quand c’est terminé, retournez sur

Tests avec Fuseki

Dans le fichier start du dossier .openshift/action_hooks  sont indiquées les commandes exécutées par OpenShift au lancement de votre application.

Sur la ligne

se trouve l’option –config suivie du chemin du fichier de configuration de Fuseki.

Remplacez ce chemin par config.ttl:

Commitez et poussez le résultat.

En allant à l’adresse, http://fuseki-$youropenshiftaccountname.rhcloud.com vous voyez l’interface d’utilisation de Fuseki. Clic sur Control Panel, puis sur books.

Apparaît une page avec une interface d’interrogation (query), une interface de mise à jour (update) et une interface de chargement de données (upload); ces deux dernières ne fonctionneront pas car, comme nous le verrons plus, la base n’est configurée qu’en lecture pour le moment.

Tapez une requête sparql dans la première interface, par exemple:

et vous obtiendrez une série de triplets définis dans le dataset books.

Ces données sont accessibles sur votre instance OpenShift de Fuseki parce qu’un ‘service’ est défini dans le fichier config.ttl:

Le format est du Turtle générique. les spécificités sont -modérément- documentées sur le site de Fuseki.

Il est indiqué ici

  • qu’un dataset du nom de books va être mis en place,
  • qu’il sera accessible par les commandes query et get,
  • que les données sont définies dans le dataset <#books> qui suit

suit la description du dataset:

  • il est associé au label Books
  • il sera exploité en mémoire
  • le contenu initial proviendra du fichier books.ttl du sous-dossier Data du dossier de lancement de fuseki

Vous pouvez sur ce modèle exploiter vos propres données en mettant à jour sur votre instance locale le fichier Turtle de vos données et en le référençant dans le fichier config.ttl. Cela permet d’éviter de laisser votre instance OpenShift ouverte en écriture et de publier vos données via git à partir de leur représentation locale.

Pour une utilisation par logiciel, vous avez le service query, par exemple, la requête de tout à l’heure peut être appelée avec l’URL

On voit l’URL de l’instance, le nom du dataset, la commande query, suivie de paramètres, ici:

  • query: la requête proprement dite, formattée pour une URL
  • output: le format de sortie
  • stylesheet: une éventuelle feuille de style pour mettre en forme la sortie si elle est au format xml

Vous y êtes: vous avez un entrepôt de triplets en place. A vous de jouer avec vos propres données!

Publié dans Outils, SPARQL, Tutoriel | Laisser un commentaire

Utiliser NLTK sur Heroku avec Python

Sur le principe du billet « Extraire le texte de PDF avec Python« , je vais créer un service qui utilise le package NLTK. NLTK est un ensemble d’outils pour construire en Python des programmes de traitement des langues. Il nécessite donc d’utiliser Python.

Phases de base

Je résume les étapes détaillées dans le billet mentionné ci-dessus:

  • créer un dossier pour ce service
  • créer un environnement virtuel pour le développement local avec la commande
  • créer un fichier requirements.txt avec la liste des dépendances (dont nltk, voir plus bas)
  • créer un dossier nltk_service
  • dans ce dossier, créer deux fichiers: __init__.py and resources.py (vides pour l'instant)
  • démarrer un serveur local (en remplaçant pdf_service par nltk_service dans runserver.py)
  • créer un dépot git
  • ajouter les fichiers du projet au dépot git local
  • mettre à jour le dépot git local
  • se connecter à Heroku
  • créer un nouveau service sur Heroku
  • pousser le développement local vers heroku
  • lancer une instance du service
  • tester en ligne

Là, on a créé un service vide. Nous allons le compléter avec une mise en oeuvre d’une des possibilités offertes par NLTK.

Un service avec NLTK

Je veux créer un service qui trouve les mots et autres éléments qui composent un texte, puis élimine les mots creux (stopwords) -ces mots qui ne contribuent pas fortement à certaines analyses du contenu d’un texte, comme ‘le’, ‘la’, ‘les’, ‘à’ en français- et enfin, compte le nombre de mots du texte et le nombre d’occurrences de chaque mot conservé.

Pour éliminer les stopwords -ainsi que pour de nombreux autres traitements- NLTK utilise des fichiers de données définis sous la dénomination ‘NLTK Data‘. Des fichiers listant  les mots creux d’un ensemble de langues sont disponibles. Mais Heroku n’est pas très adapté à l’utilisation de gros volumes de fichiers statiques; Heroku est fait pour héberger et exécuter des programmes.

Hébergement de fichiers statiques pour Heroku

Dans l’article « Using AWS S3 to Store Static Assets and File Uploads« , il est suggéré qu’une bonne scalabilité peut être obtenue en déployant sur Amazon S3 les fichiers statiques utilisés par une application. En effet, les fichiers hébergés sur Heroku peuvent être déchargés à chaque mise en veille d’une application, puis rechargés pour une nouvelle utilisation. S’il s’agit d’un gros volume de fichiers statiques, cela peut pénaliser les temps de réponse d’une application. Le système de fichier proposé par Heroku est dit ‘éphémère’.

Normalement, les données associées à NLTK sont téléchargées avec un programme interactif qui permet de sélectionner ce qu’on va télécharger et s’assure que les données chargées seront trouvées par les outils NLTK. Dans le cas d’Heroku, nous ne pouvons pas procéder ainsi, mais plutôt chercher à utiliser un chargement en ligne de commande.

C’est pourtant la première méthode que j’ai exploré. La première idée est de charger les données en local, puis de les pousser sur Heroku, mais cela chargerait le dépot GIT qui nous sert dans nos échanges avec Heroku avec toutes les données statiques de nltk-data. Une solution est proposée ici: http://stackoverflow.com/questions/13965823/resource-corpora-wordnet-not-found-on-heroku/37558445#37558445. C’est la solution que j’ai retenu en première approche. Un essai avec toutes les données de nltk_data échoue (all). Avec juste les corpus stopwords (python -m nltk.downloader stopwords) et wordnet (python -m nltk.downloader wordnet) et le tokenizer punkt (python -m nltk.downloader punkt), le déploiement se déroule correctement.

Une autre idée est d’utiliser AWS Simple Storage Service, service de stockage sur le Cloud d’Amazon. J’explorerai cette possibilité dans un prochain billet.

Le service

L’appel de <mondomaine>/words/<url d’un fichier texte> renvoie une structure json avec un tableau des mots associés à leur nombre d’occurrence (dans le tableau cnt) et le nombre total de mots pris en compte (dans wordscount »). ceci permettra d’agréger facilement les résultats de plusieurs fichiers et de calculer des fréquences d’occurrences de mots.

Conclusion

L’utilisation de NLTK avec Heroku est validée. Il faut maintenant définir la ou les structures (a priori json) qui vont nous permettre de transporter et d’enrichir progressivement les données associées à une source ou à un ensemble de sources.

Publié dans Cuisine traitement de textes, SemBib | Laisser un commentaire

Extraire le texte de PDF avec Python

Dans le cadre de notre projet d’analyse de la production scientifique de Télécom ParisTech, je récupère beaucoup de fichiers PDF. Pour en analyser le contenu, j’ai notamment besoin d’en récupérer le texte brut. Par ailleurs, comme indiqué dans le billet Des services pour l’analyse bibliographique, j’ai fait le choix d’appuyer nos développements sur des web services.

Je vais montrer ici comment je développe un service REST d’extraction de texte brut à partir de PDF en Python que je déploie sur Heroku (note: je développe sous Windows 10).

Note: je suis fraîchement convertit à Python; mon code n’a rien d’exemplaire et mérite surement d’être nettoyé/amélioré, mais il m’a suffit comme preuve de faisabilité

Créer un dossier pour mon service

Créer un environnement virtuel pour le développement local avec la commande

Créer un fichier requirements.txt avec le contenu suivant

Le fichier indique le package pdfminer pour le traitement de fichiers pdf.

(voir http://spapas.github.io/2014/06/30/rest-flask-mongodb-heroku/ pour des explications génériques sur les dépendances du projet)

Dans le dossier qui contient le fichier requirements.txt, créer un dossier pdf_service. Dans ce dossier, créer deux fichiers: __init__.py and resources.py.

__init__.py initialise l’application Flask qui va être créée

Et le fichier resources.py

Pour démarrer un serveur local

Pour les tests, j’ai créé le fichier runserver.py

lancé avec la commande

Pour créer un dépot git vide

Pour ajouter les fichiers locaux dans le git

Attention à créer un  .gitignore en indiquant les fichiers et directories à ignorer pour ne pas surcharger la communication

Pour alimenter le dépot git local

Qui va servir de référence pour les échanges avec Heroku

Pour se connecter à Heroku

puis les informations de votre compte

Pour détruire un service sur Heroku

Par exemple, pour se faire de la place, supprimer des tests devenus inutiles…

heroku apps:destroy –app <nom du service à détruire>

Pour créer le service sur heroku

heroku create

Pour pousser le développement local vers heroku

(par défaut, provoque le déploiement d’un Python 2.7 et des dépendances décrites dans requirements.txt)

Pour lancer une instance du service

Pour voir ce qui tourne

Renommer le service

Utilisation de la ligne de commande pour renommer le service (voir https://devcenter.heroku.com/articles/renaming-apps)

Commande pour changer le nom du service (à partir de celui généré automatiquement par les outils heroku) et du dépot git associé (à faire dans le dossier où a été créé le service)

 

Publié dans Cuisine traitement de textes, SemBib | 2 commentaires

Un pays sans guerre

J’ai vu passer la question « y a-t-il un pays qui n’a jamais été en guerre? » qui renvoie à

« World peace? These are the only 11 countries in the world that are actually free from conflict« 

et je me suis dit, voilà un bon exercice pour le web sémantique. Je pense qu’il va m’être utile pour illustrer le pouvoir et les limites des grosses masses de données rendues librement disponibles sur le web et exploitables par des machines (LOD, Linked Open Data).

Les articles ci-dessus suggèrent une dimension particulière de la question: la dimension temporelle! De quelle époque parle-t-on? J’y reviendrais. Mais, d’abord interrogeons quelques concepts: pays, guerre, région.

Pays

D’abord, voyons ce que nous avons comme pays dans DBPedia. Commençons par le concept Country

donne 3294. Surprenant! J’avais à l’esprit qu’il y a un peu moins de 200 pays dans le Monde. Une recherche google « nombre de pays dans le monde » donne d’autres indications. On trouve par exemple que l’IEP prend en compte 162 pays dans une étude récente. Et l’ONU semble en reconnaître 197. Dans ce cas, il s’agit seulement de pays constituant des états souverains.

Wikipedia nous donne des indications sur une dimension temporelle. L’article su la Liste des pays du Monde évoque l’évolution du nombre de pays au cours du temps.

Même si DBpedia recense des états aujourd’hui disparus, la disproportion est énorme. Nous allons devoir comprendre ce qui différencie le concept Country dans DBPedia et, par exemple, les pays reconnus par l’ONU et comment concilier les deux approches.

On constate par exemple sur http://dbpedia.org/resource/Venezuela que de nombreux types sont associés à cette entité, notamment: Country selon Yago (5528 entités), schema.org (5506 entités), umbel (2385 entités) et wikidata:Q6256 (5506 entités). Ces variantes ne vont surement pas nous aider.

Guerre

Voyons les conflits militaires recensés par DBPedia. J’ai retenu le concept MilitaryConflict.

donne 13354 (au 29/5/2016).

Maintenant, voyons les conflits explicitement reliés à un pays

donne 7750. Et le nombre de pays associés à ces conflits est donné par

On en trouve 1115. En se limitant à visualiser 100 pays concernés, on trouve , par exemple, « Province de Québec ». Pour arriver à une forme d’agrégation en rattachant un conflit aux pays actuels, nous devrons voir si un ‘pays’ associé à un conflit peut être identifié comme étant une partie d’un pays existant aujourd’hui.

32 propriétés différentes sont utilisées pour ces liens et j’ai un peu de mal avec l’interprétation à leur donner. Certaines se comprennent assez bien. Par exemple: la propriété Place est surement utilisée pour indiquer le lieu du conflit; la propriété combatant indique probablement l’origine des combattants impliqués. Dans les deux cas, on pourra bien considérer que les pays désignés étaient impliqués dans le conflit concerné.

Un autre regard peut être porté sur les données de DBPedia en constatant que certains conflits sont associés par la propriété wordnet_type au synset https://www.w3.org/2006/03/wn/wn20/instances/synset-war-noun-1.rdf.

Epoque

Dans l’idée de préciser l’époque sur laquelle nous allons porter notre intérêt.

Y a-t-il des dates ou des époques associées aux conflits recensés par DBPedia?

On en trouve associés à une ou plusieurs dates (de début? de fin?), d’autres avec endDate et startDate, d’autres sans indications directes, mais avec des liens vers des batailles ayant des indications de date.

Lorsque ces informations sont disponibles nous allons pouvoir affirmer qu’un pays concerné était en guerre aux périodes concernées. Dans le cas contraire, nous ne pouvons rien affirmer: nous ne savons pas à quelle époque le pays a été concerné par le conflit observé.

Nous allons déjà pouvoir tenter de recenser les pays qui ont été impliqués dans un conflit recensé par DBPedia (auxquels manquent probablement des conflits contemporains).

Région

Pour simplifier, j’ai cherché à identifier les pays reconnus par l’ONU. Il y a un concept dans DBPedia qui doit pouvoir nous aider: Member State of the United Nations. Mais sur quelques exemples, je constate que ce concept est associé à des pays par la propriété dc:subject, ce qui est un peu vague. Cela me donne l’occasion de voir que des pays sont associés par la propriété rdf:type à yago:MemberStatesOfTheUnitedNations, ce qui parait plus précis.

nous donne 186 pays.

Je vais m’intéresser à ces pays pour évaluer s’ils ont été associés à un conflit militaire à un moment ou à un autre.

donne 139. Ce qui semble indiquer que 47 pays des Nations Unies ne sont ou n’ont pas été en rapport avec un conflit militaire à la connaissance de DBPedia pour autant qu’on puisse en juger par des connaissances directement représentées dans DBPedia (et pas des connaissances induites).

Il va nous falloir exprimer une négation: pays qui ne sont pas dans la liste des pays ayant eu conflit militaire.

Je pense que la requête

va nous donner les pays n’étant reliés par aucune propriété de DBPedia avec un conflit militaire. Cela donne 15 résultats:

pays
http://dbpedia.org/resource/Côte_d’Ivoire
http://dbpedia.org/resource/Andorra
http://dbpedia.org/resource/Benin
http://dbpedia.org/resource/Kiribati
http://dbpedia.org/resource/Liechtenstein
http://dbpedia.org/resource/Malawi
http://dbpedia.org/resource/Monaco
http://dbpedia.org/resource/Tuvalu
http://dbpedia.org/resource/Vanuatu
http://dbpedia.org/resource/Zimbabwe
http://dbpedia.org/resource/Burma
http://dbpedia.org/resource/Federated_States_of_Micronesia
http://dbpedia.org/resource/Member_states_of_the_United_Nations
http://dbpedia.org/resource/Kingdom_of_the_Netherlands
http://dbpedia.org/resource/Timeline_of_the_United_Nations

2 résultats ne sont pas des pays de façon évidente (mais qu’il faudrait rendre détectable dans la requête). Reste 13 résultats qu’il va falloir regarder d’un peu plus près. Je ne vais pas tous les passer en revue, mais regarder quelques exemples significatifs.

Monaco est un tout petit état. La cité-état a été annexée par Jules César, par exemple; sans combat? sans usage de la force? Elle a réussi a garder une certaine neutralité pendant la Seconde Guerre Mondiale. A-t-elle vraiment évité tout conflit armé?

La Micronésie est constituée d’un ensemble d’îles du Pacifique. Elle a notamment été envahie par le Japon lors de la Première Guerre Mondiale. Je pense qu’elle a donc connu au moins un conflit armé. Mais, il n’apparait pas en tant que tel dans DBPedia.

Un cas intéressant est la Côte-d’Ivoire. Wikipedia sait que ce pays connait des problèmes politico-militaires (voir https://fr.wikipedia.org/wiki/Crise_politico-militaire_en_C%C3%B4te_d%27Ivoire), mais DBPedia semble l’ignorer. Peut-être la question est-elle trop récente et actuelle?

Conclusion

Nous voyons à travers cet exemple que des données sont disponibles qui peuvent contribuer à répondre à des questions -et c’est déjà un grand progrès- mais qu’il y a encore beaucoup à faire, beaucoup d’intelligence à mettre pour faire le chemin des données vers la réponse à une question. Il faut utiliser les données avec prudence en comprenant les limites des réponses obtenues. Par exemple, dans le cas exposé dans ce billet, une formulation correcte d’une réponse qu’on peut obtenir est: liste des pays des Nations Unies dont on est certain, à partir des connaissances représentées dans DBPedia, qu’ils ont été liés à un conflit militaire.

Publié dans DBPedia, Marquage sémantique, SPARQL, Tutoriel | Laisser un commentaire

Des services pour l’analyse bibliographique

Je présente ici les besoins liés à notre démarche d’analyse de la production et de la publication de documents scientifiques -essentiellement des articles- par Telecom ParisTech.

Les articles

Télécom ParisTech dispose d’une base bibliographique qui recense l’essentiel de nos publications. Pour chaque publication, nous avons le titre, le nom des auteurs, la date de publication et quelques autres metadonnées. Quelquefois figure un lien vers la publication. Ce lien n’est pas toujours renseigné et, quand il l’est, il peut présenter différentes formes:

  • il s’agit quelquefois d’un lien vers un accès direct, en ligne, à une version numérique de l’article, le plus souvent au format PDF
  • il s’agit quelquefois d’un lien vers une page web qui contient un lien permettant d’accéder, souvent de manière onéreuse, à une version numérique de l’article
  • quelquefois, il s’agit d’un lien mort

Il arrive que les liens vers les documents numériques ne soient pas exploitables par un robot pour constituer un stock de l’ensemble des documents. Nous verrons dans un prochain billet les solutions mises en oeuvre pour récupérer la plus forte proportion possible des documents.

Une évaluation sur 5 ans donne environ 4000 publications dont un quart comporte un lien, exploitable automatiquement et facilement dans un peu de la moitié des cas. Sur certains documents pèse une limitation des droits de publication qui nous empêche de les mettre en ligne. Cela a un impact significatif sur les solutions que nous allons pouvoir exploiter.

Le stockage

A la date de publication de ce billet, nous avons 420 documents nécessitant 180 Mo pour les documents sources. Si nous parvenons à récupérer les 4000 documents, nous aurons besoin d’environ 2 Go pour les documents sources.

Nous prévoyons de stocker des résultats intermédiaires de traitement; par exemple, nous allons stocker

  • le texte brut extrait des documents PDF
  • le dictionnaire des mots associés à un document
  • des metadonnées associées à un document, issues de différentes étapes du traitement

Nous sommes plusieurs à travailler sur ce projet et nous prévoyons d’y associer des étudiants pour lesquels ce type de travail peut donner lieu à des projets très formateurs. Nous devons donc rendre nos sources et nos résultats accessibles via le réseau.

J’ai un accès à un stockage en ligne illimité via une solution d’hébergement qui, par ailleurs, ne supporte que les développements en PHP. C’est cet hébergement que je vais utiliser.

Les traitements

Un très bon outil pour appliquer des traitements sur des textes en vue de les analyser est NLTK. NLTK est écrit en Python. Donc, les traitements ne vont pas pouvoir être effectués au niveau de l’hébergement de nos sources.

Pour les traitements de représentations sémantiques, nous utilisons d’une part des outils écrits en Java s’appuyant sur Apache Jena/Fuseki, d’autre part un serveur Virtuoso accessible seulement sur le réseau interne de Telecom ParisTech.

La nécessité d’héberger des services écrits en différents langages, ce qu’aucune de nos solutions directes d’hébergement n’assure, nous conduisent à adopter une solution distribuée, basée sur des web services. Nous verrons dans un prochain billet la marche suivie pour créer un service en Python, exploitant NLTK et hébergé sur Heroku.

Point de départ algorithmique

Nous nous sommes inspiré de l’article « Using Linked Data Traversal to Label Academic Communities » de Tiddi, d’Aquin et Motta (SAVE-SD 2015). Cependant, nous avons complété ou modifié la procédure proposée. Par exemple, nous devons prendre en compte des publications en plusieurs langues (au moins le français et l’anglais); nous avons aussi décidé de nous appuyer sur Wordnet, lorque cela avait du sens. Nous avons entrepris la mise en oeuvre des étapes suivantes

  • constitution d’une liste des chercheurs de l’école comportant leurs liens avec les départements et les équipes de recherche
  • récupération de la liste des publications des 5 dernières années; la base bibliographique nous donne un résultat au format BIBTEX que nous avons traduit dans une structure JSON; une réflexion doit être menée pour rendre la solution plus modulaire, par exemple, en récupérant la base année par année, en prenant en compte la nécessité de mises à jour, certaines publications étant déclarées tardivement dans la base; de plus, les données obtenues présentent une série de défauts traités manuellement dans notre première phase de travail,
  • pour chaque référence, tenter de récupérer une version numérique du document
  • pour chaque référence récupérée, extraire le texte brut du document (voir https://onsem.wp.imt.fr/2016/06/02/extraire-le-texte-de-pdf-avec-python/)
  • pour chaque référence récupérée, réunir des metadonnées (auteurs, références citées…) soit depuis le bibtex ci-dessus, soit par analyse du document,
  • pour chaque référence récupérée, identifier la langue du document
  • passer chaque texte en minuscule
  • éliminer les mots vides dans chaque texte ainsi que les chiffres et les ponctuations
  • stemmatiser et/ou lemmatiser les mots de chaque texte
  • remplacer chaque racine issue de la stemmatisation par un mot qui partage cette racine (ex: le mot le plus court)
  • filtrer la liste des mots conservés (blacklist, longueur minimale…)
  • chercher un mapping de chaque mot vers un concept du web sémantique/LOD par exemple en se référant à DBPedia, à schema.org,à Wordnet, au vocabulaire de référence de l’IEEE et celui de l’ACM…; nous devrons évaluer le nombre de termes non mappés et chercher une solution pour ces termes
  • évaluer le nombre de mots par article, par corpus (ex: corpus de Telecom ParisTech pour un intervalle d’années donné, idem pour un département, pour un auteur)
  • construire la matrice TfIdf du corpus; on met en oeuvre des méthodes qui facilitent la mise à jour de cette matrice par exemple lors de l’ajout d’un nouvel article
  • réduire cette matrice en éliminant les mots présents dans une forte proportion de documents (application d’un seuil, par exemple 25%); ces mots étant considérés comme faiblement discriminant; ils peuvent être gardés comme potentiellement représentatifs de la production globale de Télécom ParisTech
  • réduire cette matrice en éliminant les mots présents un trop petit nombre de fois sur le corpus; ces mots étant considérés comme structurants pour le corpus
  • application d’une méthode recherche de sémantique latente (LSA)
  • clustering des mots restants soit par des méthodes de clustering appliquées à la matrice, soit en regroupant les mots sur des critères structurels de Telecom ParisTech (départements, équipes, projets…)

Ces différentes étapes doivent nous fournir les données de base pour nos analyses. Dans de prochains billets, nous étudierons plus en détail certaines de ces étapes. Nous allons aussi proposer des approches s’appuyant sur les technologies du web sémantique.

 

 

Publié dans Marquage sémantique, Outils, SemBib, Virtuoso | Un commentaire

Co-auteurs des publications d’une institution scientifique, Telecom ParisTech

Graphe des coauteursCet article fait partie d’une série concernant l’analyse de la production scientifique d’une communauté scientifique à partir de ses publications. Il s’agit d’un travail entrepris par Cyril Concolato et Jean-Claude Moissinac pour donner divers points de vue sur notre production scientifique. Nous pensons que les visualisations produites peuvent aider à faire émerger des pistes d’amélioration.

Cet article s’appuie sur la base bibliographique de Telecom ParisTech sur les années 2011 à 2015. Les données obtenues de notre base bibliographique au format bibtex (obtenu à cette adresse http://biblio.telecom-paristech.fr/cgi-bin/consultform.cgi)

ont été traduites en JSON et sont accessibles à l’adresse

http://givingsense.eu/demo/tpt/data/18112015.5ans.json

Il s’agit d’une première étape vers une représentation sémantique de notre base bibliographique, accompagnée d’outils pour produire diverses visualisations de la base.

La visualisation proposée ici est un graphe pour lequel chaque noeud est un auteur d’un article et les liens relient deux auteurs qui ont au moins un article en commun. La couleur des noeuds est représentative du département de rattachement de l’auteur lorsqu’il s’agit d’un permanent. L’affichage par défaut ne comporte que les permanents. En ajoutant le paramètre filter=all sur l’url, on voit tous les co-auteurs, mais, en l’état, le graphe n’est pas vraiment lisible. En cliquant sur un noeud associé à un permanent, on passe à une page qui ne concerne que cet auteur et ses co-auteurs.

Cliquez sur la capture ci-dessus pour aller consulter le site dynamique.

N’hésitez pas à commenter ce que vous voyez dans cette représentation (ou à signaler si vous voyez un défaut: nous avons déjà du nettoyer un peu les données brutes pour les rendre exploitables).

Publié dans Uncategorized | Laisser un commentaire