Paired with the CIDOC-CRM in a federated way, OpenArchaeo aims at :

• making available the archaeological datasets produced by the MASAplus consortium’s partners on the semantic web, in the form of a triplestore with data aligned with the ontology and its extensions dedicated to archaeology ;
• providing an intuitive query interface for archaeological data.

The latter query interface integrates the Sparnatural knowledge graph exploration component. The UI of this component was heavily inspired by the British Museum’s ResearchSpace semantic search feature, as the system proposes the user to build his own queries based on the CIDOC-CRM model underlying the data.

About ResearchSpace platform

Initiated in 2009 by a cross-disciplinary team at the British Museum, ResearchSpace is « A full CIDOC-CRM authoring and search system, based on an exhaustive collection of forms that reflects all applicable relationships from the CIDOC CRM ontology. »

Among a wide range of semantic tools to create, manipulate, analyse and visualise data, the platform provides a semantic structured search component based on categories and relations.

While open source, ResearchSpace’s code didn’t fit our architecture : we just chose to follow the simple visual elements of ResearchSpace’s query interface to develop our own Sparnatural query builder for OpenArchaeo, and set up a system of icons to identify the main components of the archaeological data.

ResearchSpace has recently (december 2024) released a brand new 4.0.0 version. This latest can be installed easily and now comes with a default setup of forms based on the CIDOC-CRM. It enables image annotations, knowledge maps creations, semantic narratives writing, timeline productions, and more semantic tools.

Sparnatural’s first use-case was OpenArchaeo’s CIDOC-CRM model !

The structure of the knowledge graph of OpenArchaeo relies on the CIDOC-CRM and some of its extension (CRMarchaeo, CRMsci and CRMba). It is a generic model that covers the basic concepts found in most archaeological corpuses (site, operation, structure, feature, wall, burial, stratigraphic unit and artifact).

Here a focus on Class S19 :

Several external thesauri were added too for querying the datasets : PACTOLS thesaurus for archaelogy, but also Geonames and Periodo for spatial and temporal searches.

This way, when users wish to connect two elements (artifact and site for example), the interface automatically suggests the available relationships between these entities, enabling users to formulate their request in a simple way without having to know either the entities and properties of CIDOC CRM, or the structure of the system : the SPARQL queries that correspond to the sentences visually built by users will be automatically computed. In addition, the usage of thesauri allows the users to cross-reference easily multiple datasets through the different widgets proposed in Sparnatural.

Get the latest release of Sparnatural !

Since it was created for OpenArchaeo in 2019, Sparnatural UI has been fully redesigned. It now offers a large panel of features, from different widgets for value selection (dropdown lists, ordered by occurrence count or alphabetically, autocomplete search fields, date pickers, tree widgets…) to brand new result display plugins : the default visualisation is a table of results, but if the results are geolocalized they can be shown in a map. Also grid, stats, pie or bar charts, and a timeline plugin have been made available and documented.

To go further on OpenArchaeo’s platform …

See a presentation of the project on the CIDOC Museum Documentation Channel
(« Semantic modelling of archaeological data online workshop series »)

The platform : http://openarchaeo.huma-num.fr/

The project : https://masa.hypotheses.org/openarchaeo

Read full research paper about the project : https://ceur-ws.org/Vol-2375/paper1.pdf

Image : Vestiges of a large villa in Courbehaye « les Deux Muids / le Moulin de Mongé », photo Alain Lelong (2003), Atlas des Établissements Ruraux de Beauce Antique, licence CC BY-NC-SA

Cet article The Genesis of Sparnatural in the context of the OpenArchaeo platform est apparu en premier sur Sparna Blog.

Another star to light on EU’s linked open data maturity flag !

Not talking about 2024 exceptional Northern Lights to come, but this one’s also good news for science !

➡️ Late 2023, the Publications Office of the European Union announced on social media the public release of the new CORDIS SPARQL endpoint.

CORDIS, aka « the Community Research and Development Information Service of the European Commission », is « the […] primary source of results from the projects funded by the EU’s framework programmes for research and innovation, from FP1 to Horizon Europe ». Described as a « rich and structured public repository with all project information held by the European Commission such as project factsheets, participants, reports, deliverables and links to open-access publications », the CORDIS catalog has also been made available in 6 European languages by Publications Office’s editorial team.

Cherry on top of a whole process, the CORDIS SPARQL endpoint release comes to crown a long-term linked open data project. The aim identifying, acquiring, preserving and providing access to knowledge in a common will to share with the widest public possible a trust-worthy, qualified and structured information (see Publications Office 2021 Annual Management Report).

In the context of the pandemic (and recent opening of data.europa.eu, the official portal for European data, as defined in 2017–2025 European Open Data Space strategy), the EuroSciVoc taxonomy of fields of science was released April 2020, followed December 2021 by the publishing of European research information ontology (EURIO) on the EU Vocabularies website .

As presented at ENDORSE conference March 2021, the redesign of CORDIS data-model in accordance with Semantic Web standards contributed to bring the platform « from acting as a data repository to finally playing an active role as data provider », where EuroSciVoc taxonomy & EURIO ontology both played key roles in the creation of future CORDIS knowledge graph and SPARQL endpoint :

EuroSciVoc […] is a multilingual, SKOS-XL based taxonomy that represents all the main fields of science that were discovered from the CORDIS content, e.g., project abstracts. It was built starting from the hierarchy of the OECD’s Fields of R&D classification (FoRD) as root and extended through a semi-automatic process based on NLP techniques. It contains almost 1 000 categories in 6 languages (English, French, German, Italian, Polish and Spanish) and each category is enriched with relevant keywords extracted from the textual description of CORDIS projects. It is constantly evolving and is available on EU Vocabularies website […].

In order to transform CORDIS data into Linked Open Data, thus aligning with Semantic Web standards, best practices and tools in industry and public organizations, the need for an ontology emerged. CORDIS created the EURIO (European Research Information Ontology) based on data about research projects funded by the EU’s framework programmes for research and innovation. EURIO is aligned with EU ontologies such as DINGO and FRAPO and de facto standard ontologies such as schema.org and the Organization Ontology from W3C. It models projects, their results and actors such as people and organizations, and includes administrative information like funding schemes and grants.

EURIO, which is available on EU Vocabularies website, was the starting point to develop a Knowledge Graph of CORDIS data that will be publicly available via a dedicated SPARQL endpoint. »

(Enrico Bignotti & Baya Remaoun, « EuroSciVoc taxonomy and EURIO ontology: CORDIS as (semantic) data provider  » , ENDORSE March 16, 2021. PDF VIDEO)

… A Knowledge graph that was soon released in 2022-2023 (see INDUSTRY TRACK 1 on Tuesday, 25 October of ISWC 2022 Conference for more detail), until final opening of a CORDIS SPARQL endpoint late november 2023.

Now fancy a few SPARQL queries in there ?

Follow the SPARQL

CORDIS SPARQL endpoint is actually made available on CORDIS Datalab (and already referenced in EU Knowledge Graph among other European SPARQL endpoints ! see the query / see the results)

Here you can access a quick documentation guide to CORDIS Linked Open Data : https://cordis.europa.eu/about/sparql.

Let’s have a look at EURIO ontology first : we need to understand it to query CORDIS knowledge graph.

As we are told in the guide, the latest version can be downloaded on EU Vocabularies website. When we unzip the archive we access the whole documentation about EURIO Classes & properties that we need to write our SPARQL queries – and a diagram of main classes and properties of CORDIS data model : 

At first sight we can observe on the schema 3 main groups of entities :

• On the top right, the projects & publications associated, key ressources of CORDIS ;
• On the top left, the fundings & grants materials, on « monetary » side of the project ;
• On the bottom, the organisations & persons implied, with references & coordinates.

Let’s open CORDIS SPARQL endpoint – some easy queries can be run to begin exploring CORDIS knowledge graph.

Nb : the data on SPARQL endpoint is a snapshot, but freshest dumps can be found on European data portal !

Here a simple one to find a list of FundingSchemes with their titles and IDs corresponding to « Horizon 2020 » programme :

▶️ See the results

The FILTER REGEX enables us to display the IDs corresponding to H2020 Funding Schemes.

We can make another query to get the projects with the Funding Scheme Programme they are related to (note that, in EURIO a eurio:hasFundingSchemeProgramme is a sub-property of eurio:fundingScheme) :

▶️ See the results

(Here we used a property path with a « / » to shorten the query to get the acronyms of projects & Funding Scheme Programmes codes).

… and combining with the first query we can find the projects depending on H2020 Funding Scheme Programme in particular :

▶️ See the results

It is also possible to get the list of all existing Funding Scheme Programmes CORDIS projects have been funded by – we observe 27 of them here (from the SPARQL endpoint) – while adding a count function to know how many projects per FundingSchemeProgramme :

▶️ See the results

Querying the organisations properties will return other kind of useful informations about geographical location of the projects stakeholders. Let’s figure out we want to find the projects whose coordinating organisations have sites located in France :

Projects whose coordinating organisations have sites located in France  PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX eurio: <http://data.europa.eu/s66#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?project ?acronym ?role ?organisation ?country WHERE { # select the projects with their acronyms … ?project a eurio:Project. ?project eurio:hasAcronym/eurio:shortForm ?acronym. # … and organisations with ‘coordinator’ role and name … ?project eurio:hasInvolvedParty ?organisationrole. ?organisationrole eurio:roleLabel ?role. ?organisationrole eurio:roleLabel « coordinator ». ?organisationrole eurio:isRoleOf/eurio:legalName ?organisation. # … with address country for the sites defined at ‘FR’ ?organisationrole eurio:isRoleOf/eurio:hasSite/eurio:hasAddress/eurio:addressCountry ?country. VALUES ?country { ‘FR’ } } LIMIT 100

▶️ See the results

Depending on available data, you can either query via PostalAddress info (eurio:addressCountry ‘FR’) or AdministrativeArea (eurio:hasGeographicalLocation) … Here we’re lucky as both fields are mandatory ones.

Last but not least, we can also play with CORDIS vocabularies : here you’ll have the choice to investigate via plain keywords of Projects or Publications items, querying titles, abstracts or other types of literals…

An example of projects with abstracts containing string ❄ ‘winter’ ❄ – the URL giving the exact link to the project online :

▶️ See the results

But funniest way will be using EuroSciVoc taxonomy (and navigating through thesaurus hierarchy) : to do so we need to navigate through property « eurio:hasEuroSciVocClassification » to get the Concepts skosxl:prefLabel property … to finally obtain the thesaurus labels (don’t forget to choose a prefered language with a FILTER (lang parameter) :

Projects with their associated EuroSciVoc keywords (English prefLabels ) PREFIX skosxl: <http://www.w3.org/2008/05/skos-xl#> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX eurio: <http://data.europa.eu/s66#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?project ?acronym ?ESV WHERE { # select the projects with their acronyms … ?project eurio:hasAcronym/eurio:shortForm ?acronym. # … with EuroSciVoc Classification prefLabels … ?project eurio:hasEuroSciVocClassification/skosxl:prefLabel/skosxl:literalForm ?ESV. # … only returning ‘English’ prefLabels FILTER (lang(?ESV) = ‘en’) } LIMIT 100

▶️ See the results

A bit more complex one using first level of hierarchy of the taxonomy : here we are searching for all skos:broader concepts « with no other broader concept » (the FILTER NOT EXISTS formula), aka the top concepts or root concepts of the vocabulary used to describe the projects. Then counting the projects by each category :

▶️ See the results

… and maybe again more explicit results if refined to level 2 of hierarchy  :

▶️ See the results

And a little last one with a count, to enumerate most used EuroSciVoc Concepts for indexing projects :

▶️ See the results

This one an ideal one to generate a word cloud maybe ?

What if we send the CSV data to some nice online word cloud generator then ?

(OMG they also have a shooting star shape  in there 🤩)

As a conclusion…

According to Science (CORDIS saying !), New Year’s resolutions appear difficult to be held… because most of time too ambitious, restrictive or unprecisely formulated : indeed, « the effectiveness of resolutions depends on how they are framed. »

Horizon 2024, let’s suggest a(n RDF ?) well-framed one : may CORDIS SPARQL endpoint initiative be an example for other structures who want to share Linked Open Data !

Wishing you Best Interoperability and a Very Merry ✨ Sparqling New Year ! ✨

Cet article CORDIS : a SPARQL endpoint is born ! est apparu en premier sur Sparna Blog.

On trouve pourtant tout un tas de projets ou de logiciels pour visualiser des graphes RDF natifs : RDF gravity, Visual RDF, Welkin, ou d’autres qui sont listés ici, là, ou bien encore là (voir également WebVOWL pour la visualisation d’ontologies OWL, donc sur un sujet un peu différent).

Une cartographie des acteurs du numérique pour #ToursTech

Et pourtant je suis tombé sur une problématique où la visualisation des données natives d’un graphe RDF avait vraiment du sens : représenter la cartographie des acteurs d’un territoire ou d’une communauté. En l’occurrence la cartographie des acteurs du numérique en Touraine, dans le cadre de la candidature de Tours au label #FrenchTech (#ToursTech). On peut donner plusieurs représentations possibles de cet ensemble d’acteurs :

• en graphe type réseau social (l’approche que j’explore ici, donc);
• en zones type TreeMap pour montrer les grandes masses (par exemple la répartition des entreprises par code APE en utilisant d3.js);
• en courbes temporelles pour montrer des évolutions d’indicateurs;
• en cartes géographiques pour visualiser les zones et les lieux dans l’agglomération
• en arbres pour mettre en évidences des catégories d’acteurs;
• etc.

Dans notre cas les triplets RDF correspondent exactement aux liens entre les acteurs, et sont des relations du type « est adhérent de (une association professionnelle) », « est fournisseur de », « a un partenariat avec », etc. Le besoin d’avoir une représentation du réseau social des acteurs devient donc le même que celui de représenter le graphe RDF natif.

Le résultat et quelques explications

Voici le résultat de cette cartographie (cliquez pour agrandir) (et jouer à « où est Charlie ? » en cherchant Sparna dans l’image !) :

(je précise que cette représentation est partielle, exploratoire, et ne se veut pas représentative de la réalité du territoire)

Qu’est-ce qu’on y voit ?

• des noeuds : organisations, personnes, lieux ou projets;
• des liens : relations de type réseau social entre ces noeuds (« travaille dans ce lieu », « participe à ce projet », etc.); ces liens ne sont pas distingués par un label ou une couleur dans la cartographie, mais ils sont bien typés dans les données;
• La taille d’un noeud est fonction de son nombre de liens;
• La couleur d’un noeud est fonction de sa « centralité » dans le graphe, c’est-à-dire de sa proximité avec un maximum d’autres noeuds dans le graphe (enfin c’est ce que j’en ai compris !);
• Les noms des personnes ne sont pas affichés pour des raisons de confidentialité;

On met ainsi rapidement en évidence :

• les acteurs majeurs de la communauté, soit en terme de « taille » soit en terme de positionnement dans le réseau (PaloAltours, la cantine numérique bêta de Tours, CoopAxis le PTCE qui marie numérique et innovation sociale, Centre & TIC association professionnelle au service du numérique, etc.) ;
• les liens qui les unissent (« comment puis-je rentrer en contact avec telle personne ou telle organisation ? »);
• les communautés, qui sont plus apparentes si on partitionne le graphe et qu’on colorie les communautés :

D’autres projets ont utilisé une approche et des outils similaires pour cartographier les acteurs d’une communauté : l’écosystème du cluster CapDigital en île-de-france, ou bien cette cartographie des acteurs de l’Intelligence Economique en PACA.

Le dispositif : Wiki sémantique + triplestore + Gephi / sigma.js

Le dispositif que nous avons exploré pour réaliser cette cartographie est en 3 parties :

Le beurre : un wiki sémantique

Semantic Media Wiki (que j’avais exploré précédemment ici) nous donne une solution de centralisation des connaissances :

1. collaborative, avec toute la machinerie wiki (versionning des pages, pages de discussion, etc.)
   
2. structurée,  puisque la solution Semantic Media Wiki et ses divers plugins permet d’avoir des fiches à plusieurs champs, avec choix multiples, autocompletion, dates, etc.
3. flexible, puisque le modèle de données et les formulaires de saisie peuvent évoluer au fil des besoins, et l’outil est facile à prendre en main pour des utilisateurs non-experts, jugez plutôt  les formulaires de saisie avec assistance à la saisie :
4. ouverte pour partager les données avec d’autres territoires (important sur l’aspect « mise en réseau des archipels territoriaux »);

C’est cet outil qui est utilisé pour renseigner les fiches des acteurs du territoire et leurs liens. Ces liens sont de types :

• liens formels ou contractuels : fournisseur de, client de, travaille pour ;
• liens de collaboration : a un partenariat avec, adhère à telle association, participe ou porte tel projet;
• liens géographiques : se situe dans tel lieu;
• liens capitalistiques : a du capital dans;

L’argent du beurre : une diffusion des données en RDF

Semantic Media Wiki c’est bien, mais nativement on ne peut pas réutiliser les données en dehors du wiki. On le synchronise donc (via sa fonction d’export RDF) avec un triplestore RDF Sesame, qui rend les données accessibles sur le web (via SPARQL), permettant ainsi à d’autres applications de tirer parti des données.

On a donc une solution de capitalisation des connaissances PAR le territoire (wiki sémantique collaboratif) et POUR le territoire (diffusion des données pour leur réutilisation).

Le sourire du crémier : Gephi pour exploiter les données

Le sourire du crémier : Gephi (et d’autres applications) qui peuvent réexploiter les données saisies dans le wiki. En particulier Gephi dispose d’un plugin d’intégration à partir de SPARQL (« Gephi Semantic Web Import Plugin » – Attention à la date de rédaction de ce billet le lien vers la page de documentation de ce plugin est cassé). Il devient donc possible de générer un visuel de notre réseau social à partir des données ainsi exposées.

On peut même automatiser la génération du visuel (ce qu’on a fait ici) avec un bout de Java grâce à l’API Gephi (Gephi Toolkit).

Mon retour d’expérience sur Gephi est très positif : facile à prendre en main, intégration SPARQL aisée et sans bug, on peut générer assez facilement des rendus intéressants. Inconvénient : cela reste des images statiques, ca ne bouge pas et ce n’est pas cliquable. Pour avoir quelque chose de plus interactif il faut se tourner vers SigmaJS. C’est ce que l’agence de communication Mwebius a expérimenté :

Notez les options de sélection de ce que l’on veut afficher sur la gauche. Tout cela est branché en direct sur les données exportées du wiki.

Vous voulez utiliser les données ? pas encore…

La question de la licence des données récoltées pour ce travail de cartographie n’étant pas encore tranchée (ouvertes ou pas ? dans quel périmètre), je ne peux malheureusement pas mettre ici les liens ni vers le wiki sémantique, ni vers le service SPARQL de diffusion des données – je le fais dès que l’initiative #ToursTech a statué là-dessus, mais ce serait en tout cas un bel exemple de système d’intelligence économique territorial collaboratif diffusant ses données en open data. Rien que ça ! En attendant si vous voulez en savoir plus laissez un message ici et suivez la candidature #ToursTech !

Cet article Gephi pour visualiser des graphes RDF est apparu en premier sur Sparna Blog.

Contexte

Le réseau Canopé a pour objectif de « renforcer l’action de la communauté éducative en faveur de la réussite des élèves », en particulier en fournissant des ressources documentaires et pédagogiques pour les enseignants, mais aussi en proposant des espaces de formation et d’animation. Canopé Poitiers a ceci de particulier que, tout en étant une émanation régionale du réseau Canopé, il a une activité d’éditeur logiciel d’envergure nationale en proposant et en hébergeant les portails de recherche documentaire des CDI de plus de 7000 collèges et lycées, dans sa solution e-sidoc (7013 portails exactement au moment de la rédaction de cet article, vous pouvez regarder la carte des déploiements d’e-sidoc pour voir si le collège ou le lycée du coin est équipé avec cette solution. Voici le portail d’un lycée à Tours pour vous faire une idée).

Objectifs

L’objectif de Canopé Poitiers est d’évaluer la faisabilité et l’intérêt d’enrichir les portails e-sidoc avec les données de data.bnf.fr. Les possibilités d’enrichissement sont ouvertes mais peuvent schématiquement se subdiviser en trois :

1. L’amélioration de la recherche et des modes d’accès aux catalogues ; cette partie recouvre elle-même deux parties :
   1. l’amélioration des fonctions de recherche (nouvelles facettes ou de nouveaux critères de recherche) ;
   2. l’amélioration de la présentation des résultats de recherche;
2. L’ajout de nouvelles notices, tirées de data.bnf.fr, au catalogue « local » du CDI; c’est ce qui est déjà fait par Canopé Poitiers qui propose au CDI des « réservoirs de notices« , comme le dépouillement des titres de la presse, ou une sélection de sites internet pour les collèges et les lycées. Cela pourrait avoir du sens pour inclure dans ces portail des œuvres numériques de Gallica, ou des liens vers les expositions virtuelles de la BNF, etc. Cela permettrait ensuite au collégien/lycéen d’accéder à ces ressources via le portail de recherche;
3. L’enrichissement des notices documentaires (comme celle-ci) avec des informations tirées des données de data.bnf.fr;

Par ailleurs, Canopé Poitiers a de fortes contraintes de production, la réindexation de 7000 bases documentaires chaque nuit, et l’hébergement de tous ces portails pour avoir de bons temps de réponse posant un certain nombre de challenges techniques dont je ne soupçonne pas le quart…

Pour ces raisons de contraintes de production, nous expérimentons d’abord la piste de l’enrichissement des notices documentaires qui n’impacte ni sur la structure des index de recherche (ou de façon mineure), ni sur leur taille.

Quels enrichissements et comment ?

Le premier enrichissement envisagé est l’ajout d’un lien vers une version numérisée dans Gallica de l’œuvre présentée dans la notice. (voir par exemple Alice au pays des merveilles dans Gallica) La récupération de ces liens est possible car :

1. Les notices du portail documentaire portent (pour la plupart) un ISBN ou un EAN;
2. Les éditions d’ouvrages publiées dans data.bnf.fr portent également (pour la plupart) un ISBN ou un EAN, ce qui permet de faire un rapprochement avec nos notices;
3. Les éditions d’ouvrage de data.bnf.fr sont regroupées ensemble sous des entrées correspondant à l’œuvre abstraite par une organisation FRBR, ce qui permet, même s’il n’existe pas de version numérisée pour l’ISBN exact de départ (ce qui est toujours le cas, car les versions numériques dans Gallica sont celles d’éditions anciennes), de voir si une autre édition de la même oeuvre a son équivalent numérisée;

Pour ce qui nous intéresse ici, la structuration FRBR des oeuvres est donc la principale valeur ajoutée des données data.bnf.fr, par rapport aux flux OAI ou Z3950 de la BNF, qui ne structurent pas les données de cette façon.

Donc, en résumé :

• on cherche l’édition de l’oeuvre dans data.bnf.fr via l’ISBN ou l’EAN;
• et si on l’a trouvée, on cherche une autre édition de la même oeuvre ayant une version numérique (on prend l’édition la plus récente);

Retour d'expérience technique

Pour faire ce travail de récupération des liens :

• On télécharge les données de dump de data.bnf.fr;
• On les stocke dans un triplestore Jena Fuseki avec un stockage TDB;
• On fait un prétraitement sur les ISBNs (voir ci-dessous), et on fait nos requêtes de rapprochement en SPARQL;

On s’aperçoit que :

• Les données ont quelques petits soucis de format. (ne dérogeant donc pas à la règle d’or du traitement des données sur le web : « les données sont pourries » ) en effet quelques fichiers RDF des dumps de la BNF (ceux des manifestations, le 11971, le 11975 et quelques autres) contiennent des erreurs de syntaxe qui empêchent de les charger dans une base RDF. Avant de lancer un chargement, il est préférable de vérifier les fichiers avec le script Jena ntriples et son option « validate » :
  • ntriples –validate /chemin/databnf_editions_nt/databnf_editions__manif_* > /chemin/temp.txt
  • le plus simple a été de supprimer tout simplement ces fichiers pour ne pas faire échouer le chargement, mais si vous voulez avoir 100% des données il faudra les corriger, ce qui n’est pas tout à fait trivial;
• Le chargement des données est plutôt rapide.  105 millions de triplets, sur un portable classique, en 1h40. Pour ce chargement, j’ai utilisé le script tdbloader2 de Jena;
• Le format des ISBN est variable (aussi bien dans les données BNF que dans les notices de départ). Parfois en format ISBN-10, parfois en format ISBN-13, parfois avec tirets, parfois sans (978-2-7116-2455-3, 1-4051-3618-9, 3832202560, etc.) Je me suis donc ramené à une version sans tirets pour tous les ISBN pour limiter le problème, mais il reste la différence entre les ISBN-10 et les ISBN-13 qui n’a pas été traitée;

Quels résultats ?

Nous avons voulu valider la couverture des données de data.bnf.fr en terme de liens vers les versions numériques des œuvres : est-ce que le jeu en vaut la chandelle ? pourra-t-on sortir suffisamment de liens vers des œuvres numériques pour justifier le travail ? Pour cela, on a d’abord testé sur 4 auteurs classiques : Jules Verne, Victor Hugo, Emile Zola, Molière, en extrayant des notices la liste des ISBN/EAN des éditions de leurs œuvres.

Voici ce qu’on obtient en terme de couverture du rapprochement des données pour ces ISBNs :

On trouve une version électronique de l’oeuvre pour un ISBN sur quatre. Mais certaines œuvres ont plus d’exemplaires (d’items au sens FRBR) que d’autres (on trouvera plus d’exemplaires de « Au bonheur des dames » que de « Comment on meurt » de Zola), c’est pourquoi il était aussi intéressant de donner la couverture en nombres d’exemplaires :

Pour exprimer autrement le dernier chiffre de 53% :  il y a une chance sur deux de trouver une version numérique dans Gallica de l’oeuvre d’un livre d’un de ces 4 auteurs pris au hasard dans les rayonnages d’un CDI.

Globalement cela encourage à continuer la démarche et montre que ce travail sera visible dans les portails e-sidoc. La récupération des versions numériques des oeuvres est un premier prétexte à ce travail de rapprochement qui permettrait ensuite de récupérer de nombreuses autres données.

Update du 16/12/2014 : les dernières versions des données de data.bnf qui seront mises en ligne fin 2014 devraient 1/ corriger le petit souci de format mentionné plus haut (si ce n’est déjà fait) et 2/ contenir plus de données (entre 1 et 2 millions d’éditions supplémentaires, et 400 000 auteurs supplémentaires), ce qui devrait améliorer le ratio de rapprochement des notices sur les ISBNs.  Cela amènera data.bnf.fr à être de plus en plus incontournable par sa couverture (l’intégralité des éditions de la BNF devraient être publiées d’ici fin 2015).

Cet article data.bnf.fr pour enrichir un portail de recherche documentaire : le cas de Canopé Académie de Poitiers est apparu en premier sur Sparna Blog.

La documentation de référence de cette installation est disponible ici. Virtuoso est disponible dans les dépôts Linux, cependant cette version date quelque peu, et compte-tenu des dernières évolutions sur le produit il est de bon ton d’essayer de se bien se tenir à jour. La procédure d’installation ci-dessous est donc celle qui compile Virtuoso à partir des sources.

# Télécharger les sources depuis http://sourceforge.net/projects/virtuoso
# Télécharger le fichier virtuoso-opensource-6.1.7.tar.gz

# D'abord installer toutes les dépendances requises
su -
yum install gcc gmake autoconf automake libtool flex bison gperf gawk m4 make
yum install openssl-devel readline-devel wget

# Créer un répertoire dans lequel on va dézipper les sources
mkdir virtuoso
cd virtuoso
cp ../Downloads/virtuoso-opensource-6.1.7.tar.gz .

# untar
tar xvpfz virtuoso-opensource-6.1.7.tar.gz

# configure
# c'est ici que l'on peut changer le prefixe racine de l'installation avec le parametre --prefix
cd virtuoso-opensource-6.1.7
./configure --prefix=/usr/local/ --with-readline

# Voilà ce qu'on obtient :

Virtuoso Open Source Edition (Row Store) 6.1.7 configuration summary
====================================================================

Installation variables
  layout                  default
  prefix                  /usr/local
  exec_prefix             ${prefix}

Installation paths
  programs                ${exec_prefix}/bin
  include files           ${prefix}/include
  libraries               ${exec_prefix}/lib
  manual pages            ${datarootdir}/man
  vad packages            ${datarootdir}/virtuoso/vad
  database                ${prefix}/var/lib/virtuoso/db
  hosting                 ${exec_prefix}/lib/virtuoso/hosting

Options
  BUILD_OPTS               xml ssl imsg pldebug pthreads readline

# compiler (prend plusieurs dizaines de minutes à plusieurs heures en fonction de la puissance de la machine)
nice make

# installer
su -
cd /home/thomas/virtuoso/virtuoso-opensource-6.1.7
make install

# vérifier que virtuoso.ini est au bon endroit
cd /usr/local/var/lib/virtuoso/db/
ls
# virtuoso.ini

# démarrer le serveur
virtuoso-t -df
# cette commande demarre le serveur dans le terminal, si on ferme la fenêtre le process s'arrete.
# pour demarrer dans le background :
virtuoso-t -f &
# et pour arreter le serveur :
ps -edf | grep virtuoso-t
kill -9 <numero du process>
# accéder à http://localhost:8890/conductor/

# se logguer avec le super-admin : dba/dba

# changer tout de suite le mot de passe du super-admin
isql
set password dba new_password

# accéder au endpoint public à http://localhost:8890/sparql
# et voilà :-)
# avertissement : cette procédure ne convient pas pour un déploiement en production

Cet article Installation du triplestore OpenLink Virtuoso sous Linux est apparu en premier sur Sparna Blog.

Concept Schemes et Concepts de premier niveau

L’interface de SKOS Play commence par lister les concepts schemes triés par langue :

On utilise un OPTIONAL pour le cas où le libellé du concept scheme ne serait pas connu, et on tri par langue. Notez par ailleurs que la requête s’attend à un skos:prefLabel. SKOS ne dit rien sur le nommage des concept schemes, on peut trouver aussi bien du skos:prefLabel que du rdfs:label que du dcterms:title, aucune de ces 3 propriétés ne définissant un domaine.

Ensuite, on essaie de trouver les langues utilisées. Pour cela on regarde les langues utilisées sur les prefLabel, altLabels et hiddenLabels :

On utilise l’opérateur ‘|’ (alternative) des property path SPARQL 1.1 pour sélectionner les prefLabel ou les altLabels ou hiddenLabels, et on sélectionne la liste dédoublonnée de leurs langues. A noter que les valeurs sans langues (ce qui ne devrait pas arriver en SKOS en principe), ne sont pas traitées par la query.

Une fois un concept scheme sélectionné, on a souvent besoin de trouver les concepts de premier niveau de ce scheme. 2 solutions : première solution, interroger la propriété hasTopConcept ou isTopConceptOf du scheme :

Ici on combine l’opérateur d’alternative ‘|’ avec celui d’inverse ‘^’ pour sélectionner soit les skos:hasTopConcept du scheme vers le concept soit les isTopConceptOf du concept vers le scheme; comme SKOS Play ne connait pas a priori la « tête » des thesaurus à traiter, il faut mieux être prudent et essayer de lire tout ce qu’on peut. La variable ?scheme est « bindée » avec le mécanisme de binding de variables Sesame à la valeur du scheme sélectionnée.

Deuxième solution, si le vocabulaire contrôlé n’indique aucun concept de premier niveau explicitement, et si donc la première requête ne ramène rien, c’est de récupérer les concepts sans parent dans la hiérarchie broader/narrower :

On utilise la construction SPARQL 1.1 « FILTER NOT EXISTS » pour vérifier la non-existence d’un lien broader du concept vers un parent, ou bien d’un lien narrower d’un parent vers le concept (là encore, on est prudent et on teste toutes les possibilités). La variable scheme est bindée à la bonne valeur avec le mécanisme de binding de variables Sesame.

Quelques requêtes sur les concepts

Une fois trouvé un concept scheme et les concepts de premier niveau, c’est parti pour le traitement des concepts ! on va essentiellement avoir besoin de faire deux choses : premièrement, lire les libellés d’un concept :

On sélectionne les prefLabels dans la langue voulue. Dans l’application, on gère un cache de ces libellés pour éviter de les requêter plusieurs fois. On pourrait aussi utiliser l’opérateur GROUP_CONCAT pour concaténer plusieurs valeurs entre elles (ce qui ne devrait jamais arriver en SKOS pour le prefLabel, tous les concepts devrait avoir au maximum un prefLabel par langue).

Deuxième opération essentielle, naviguer dans la hiérarchie des concepts. Pour cela on exploite les liens skos:broader et skos:narrower :

On retrouve la même combinaison de l’opérateur d’alternative ‘|’ et de celui d’inverse ‘^’ pour interroger d’un seul coup les broaders et les narrowers. On filtre sur l’URI du concept scheme pour s’assurer qu’on ne sélectionne que les enfants qui restent dans le même ensemble de concepts.

Un peu plus compliqué !

L’affichage alphabétique du thesaurus dans SKOS Play demande de sélectionner tous les prefLabels et les altLabels, en gardant la correspondance entre un altLabel et le prefLabel pour pouvoir faire un lien, et en prenant en compte les cas où le concept n’a pas de libellé dans la langue demandé. Voici cette belle requête :

}
}[/sql]

3 clauses se combinent ici avec UNION pour sélectionner plusieurs cas : lignes 7 à 9, pour sélectionner le prefLabel, sans histoire de « correspondance » avec un prefLabel; ligne 11 à 14, pour sélectionner tous les altLabels et leur correspondance avec le prefLabel; ligne 15 à 21, pour traiter le cas où le prefLabel n’existe pas dans la langue demandée. On utilise un BIND pour ramener l’URI du concept comme un label dans ce cas. Pas mal, non ?

Enfin, je reproduis ici une requête dont SKOS Play ne se sert pas (encore ?) pour faire de l’autocompletion sur des libellés SKOS, publiée de l’autre côté de la terre, quelque part en Australie, par Ben Chadwick qui travaille sur le thesaurus SCOT :

Pratique pour implémenter un composant d’autocompletion sur les libellés d’un thesaurus.

Cet article Exemples de requêtes SPARQL sur le modèle SKOS est apparu en premier sur Sparna Blog.

Voilà maintenant comment effectuer des query SPARQL SELECT et CONSTRUCT sur un Repository, et traiter les résultats. Les deux types de query utilisent des objets différents : TupleQuery et TupleQueryResult pour les SELECT, GraphQuery et GraphQueryResult pour les CONSTRUCT. Les commentaires dans le code ci-dessous parlent d’eux-même, et n’hésitez-pas à vous reporter à la documentation des API Sesame pour d’autres exemples.

[java] // création du Repository en mémoire.
Repository repository = new SailRepository(new MemoryStore());
// initialisation du Repository : cet appel est obligatoire une fois et une seule
repository.initialize();

// on ouvre une connection au repository
// comme en JDBC, c’est à travers cette connexion que sont envoyées toute les querys
RepositoryConnection connection = repository.getConnection();

// I. exemple de Query SELECT

// on initialise la query.
TupleQuery selectQuery = connection.prepareTupleQuery(
QueryLanguage.SPARQL,
"SELECT ?x ?foafName WHERE { ?x <http://xmlns.com/foaf/0.1/name> ?foafName }"
);

// on l’execute
TupleQueryResult selectQueryResult = selectQuery.evaluate();

// on itère sur les résultats
while(selectQueryResult.hasNext()) {
// chaque ligne du résultat est un BindingSet
BindingSet aBinding = selectQueryResult.next();

// on print les valeurs de cette ligne
System.out.println("Personne "+aBinding.getValue("x")+" a pour nom "+aBinding.getValue("foafName"));

// si on ne connait pas les noms de variables de la query, on peut les récupérer dynamiquement
for (String aBindingName : selectQueryResult.getBindingNames()) {
System.out.println("La valeur de "+aBindingName+" est "+aBinding.getValue(aBindingName));
}
}

// II. Exemple de Query CONSTRUCT

// on initialise la query
GraphQuery constructQuery = connection.prepareGraphQuery(
QueryLanguage.SPARQL,
"PREFIX foaf: <http://xmlns.com/foaf/0.1/> " +
"PREFIX vcard: <http://www.w3.org/2006/vcard/ns#>" +
"CONSTRUCT {?x vcard:n _:n . _:n vcard:given-name ?name .} WHERE { ?x foaf:name ?name }"
);

// on l’execute
GraphQueryResult constructQueryResult = constructQuery.evaluate();

// on itère sur les résultats, qui sont des Statement RDF, pas des binding
while(constructQueryResult.hasNext()) {
Statement anRDFStatement = constructQueryResult.next();
// ici on se contente d’afficher le Statement
// typiquement on devrait en faire quelque chose : écrire dans un fichier, ou
// l’insérer dans un autre Repository, etc.
System.out.println(anRDFStatement);
}

// quand on n’a plus besoin de la connexion, on la ferme
connection.close();[/java]

Cet article Tutoriel : exemple de query SPARQL avec l’API Sesame est apparu en premier sur Sparna Blog.

Jars nécessaires

Pour utiliser l’API Sesame de manipulation de RDF dans votre programme Java, récupérer les jars suivants :

• Depuis openrdf.org, suivez « Download > Sesame 2.x releases > here > [numéro de version de Sesame] » et téléchargez le fichier openrdf-sesame-x.y.z-onejar.jar. Attention de bien prendre le « onejar », pas le sdk ;
• Téléchargez SLF4J, dézippez-le, et extrayez slf4j-api-a.b.c.jar et slf4j-jdk14-a.b.c.jar ;
• Ajoutez à votre classpath openrdf-sesame-x.y.z-onejar.jar, slf4j-api-a.b.c.jar et slf4j-jdk14-a.b.c.jar ;

Optionnellement, seulement si vous voulez vous connecter à un serveur Sesame distant, ou un endpoint SPARQL (en utilisant la classe HTTPRepository), ajoutez les étapes suivantes :

• Téléchargez httpclient, en prenant le fichier commons-httpclient-3.0.zip. (Attention de ne pas confondre avec httpcomponents-client), et dézippez commons-httpclient-3.0.jar ;
• Téléchargez commons-logging et dézippez commons-logging-1.1.1.jar
• Téléchargez commons-codec et dézippez commons-codec-1.6.jar ;
• ajoutez à votre classpath commons-httpclient-3.0.jar, commons-logging-1.1.1.jar et commons-codec-1.6.jar ;

Démarrage rapide

L’exemple de code Java ci-dessous illustre l’initialisation d’un Repository, le chargement de données RDF, l’écriture de RDF dans un fichier, et l’interrogation d’un serveur Sesame distant ou d’un endpoint SPARQL public. Les commentaires dans le code parlent d’eux-mêmes.

// I : création du Repository
// création du Repository en mémoire.
Repository repository = new SailRepository(new MemoryStore());
// initialisation du Repository : cet appel est obligatoire une fois et une seule
repository.initialize();

// II : chargement de fichier RDF
// le fichier RDF contenant les données à charger
File fileToAdd = new File("/fichier/à/charger.rdf");
// charger les données dans le Repository
repository.getConnection().add(
 // référence au fichier à charger
 fileToAdd,
 // namespace par défaut à utiliser pour les URIs relatives contenues dans le RDF
 RDF.NAMESPACE,
 // format du fichier RDF à charger (RDF/XML, N3, TRIG, etc.)
 // le format est déterminé dynamiquement à partir de l'extension du fichier
 // (.rdf, .n3, .trig, etc.)
 RDFFormat.forFileName(fileToAdd.getName())
);

// III : écriture de fichier RDF
// on utilise RDFXMLWriter qui génère du RDF/XML
repository.getConnection().export(new RDFXMLWriter(new FileOutputStream("/fichier.rdf")));
// on peut remplacer par N3Writer pour sortir du N3
// dans ce cas, bien mettre l'extension du fichier à .n3
// repository.getConnection().export(new N3Writer(new FileOutputStream("/fichier.n3")));

// IV. connection à un serveur Sesame ou un endpoint SPARQL distant
// pour se connecter à un serveur Sesame : utiliser le constructeur avec 2 String
// en donnant l'adresse du serveur et le nom du repository
Repository sesameServer = new HTTPRepository("http://localhost:8080/openrdf-sesame","Test");
sesameServer.initialize();
// pour se connecter à un endpoint SPARQL public : utiliser le constructeur avec 1 String
// en donnant l'adresse du endpoint
Repository dbpedia = new HTTPRepository("http://dbpedia.org/sparql");
dbpedia.initialize();

Cet article Tutoriel : exemple avec l’API Sesame RDF est apparu en premier sur Sparna Blog.

On a vu précédemment quelles étaient les différences entre Sesame et Jena. Voyons comment installer un serveur Sesame pour manipuler facilement des données RDF. Pas de fichiers configuration compliqués à éditer, c’est du facile, et une fois dans l’interface web d’administration, vous trouverez tout ce dont vous avez besoin : ajouter des fichiers RDF, faire une query SPARQL, naviguer dans les données, etc.

Première partie : Installer le serveur

1. Prérequis : Java doit être installé sur votre machine.
2. Téléchargez Sesame en suivant les liens de téléchargement depuis http://www.openrdf.org (version 2.6.5 au moment de l’écriture de ces lignes) et en prenant le fichier nommé openrdf-sesame-x.y.z-sdk.zip
3. Téléchargez Tomcat en suivant les liens de téléchargement depuis http://tomcat.apache.org/ (version 7.0.27 au moment de l’écriture de ces lignes). Sous « Binary Distribution > Core », choisissez le format zip.
4. Dézippez le fichier apache-tomcat-a.b.c.zip dans le répertoire de votre choix.
5. Dézippez le fichier openrdf-sesame-x.y.z-sdk.zip dans le répertoire de votre choix.
6. Copiez les fichiers openrdf-sesame-x.y.z/war/openrdf-sesame.war et openrdf-sesame-x.y.z/war/openrdf-workbench.war dans le répertoire apache-tomcat-a.b.c/webapps
7. Démarrez Tomcat à l’aide des commandes apache-tomcat-a.b.c/bin/startup.bat (ou .sh)
8. Accédez dans votre navigateur à l’adresse http://localhost:8080/openrdf-workbench : c’est la console web d’administration de Sesame.

Deuxième partie : Paramétrer un entrepôt RDF

1. Dans la console d’administration, cliquez sur « New Repository » en haut à gauche ;
2. Dans le menu qui s’affiche, sélectionnez « In Memory Store », et donnez un ID et un titre à votre repository, par exemple « Test » et « Mon repository de test » ; c’est dans cet écran que vous pouvez choisir le mode de stockage du repository, dans une base, dans des fichiers, etc. Si vous avez besoin de stocker le RDF dans une base de données, c’est ici que ça doit se faire. Pour le moment, on va garder le RDF en mémoire, avec une synchronisation dans un fichier pour ne pas perdre les données en cas d’arrêt du serveur. Cliquez sur Next ;
3. Le formulaire affiche maintenant les champs « Persist Yes/No » et « Sync Delay » ; Laissez « Persist » à « Yes », et rentrez la valeur « 100 » pour « Sync Delay » ; cliquez sur Create ;
4. Le repository est créé et vous avez maintenant accès aux fonctions d’admin sur la gauche, notamment « Add » pour uploader des données RDF; allez-y, vous pouvez uploader un fichier de données RDF !

Important : il faut bien comprendre que le repository Sesame est maintenant accessible comme un endpoint SPARQL. Le serveur sesame donne de base accès aux données des repository comme des endpoints. L’URL du repository/endpoint est indiquée dans l’interface d’administration et est http://localhost:8080/openrdf-sesame/repositories/<ID_du_repository> (http://localhost:8080/openrdf-sesame/repositories/Test si vous l’avez appelé Test). On se servira de cette URL pour accéder au repository via les API Sesame.

Cet article Tutoriel : comment installer un serveur RDF Sesame ? est apparu en premier sur Sparna Blog.

Dans le monde des développeurs d’applications basées sur le web sémantique, il y a 2 grandes écoles en ce qui concerne les triplestores : les adeptes de Jena, et ceux de Sesame.

Personnellement j’ai un faible pour Sesame. Sesame propose des fonctionnalités proches de Jena, moins complètes, mais sans doute un peu plus facile à intégrer ; la philosophie de son API est différente, et, s’il s’agit de faire simplement de la manipulation de données RDF (sans inférence compliquée, sans gestion d’ontologie OWL), le choix entre les deux est essentiellement une question de goût ! Son interface web d’administration vous facilitera par contre énormément le travail s’il s’agit de configurer rapidement un triplestore et de charger des données RDF dedans.

On donne ci-dessous un tableau comparatif des fonctionnalités entre Jena et Sesame, au 1er mai 2012 ; il faut noter que, là où Jena propose d’emblée un certain nombre de modules avec beaucoup de fonctionnalités, pour Sesame ces fonctionnalités peuvent être présentes dans l’ « écosystème » autour de Sesame : OWLIM ou Ali Baba.

Cet article RDF : Sesame, Jena, comparaison des fonctionnalités est apparu en premier sur Sparna Blog.