From validation of the data in the knowledge graph to further projects of data integration and dissemination, many different usages of SHACL specifications were explored…

… and more exploratory usages of SHACL are foreseen !

“

A knowledge-graph powered open data portal

The European Parliament Open Data Portal (EPODP) went live in January 2023. Its particularity is that it is not a mere aggregation of documents or dump files from business applications in custom formats; but rather a collection of datasets each extracted from a central semantic knowledge graph, itself aggregating data migrated from approximately twenty business applications. The result is a semantically interoperable open data portal : the semantic of its data model is clearly defined and documented, and reuses widely deployed existing ontologies. It already provides its data to different consumers (most notably the europarl website and the EU law tracker) in a context of cross-institutions interoperability. The data captures the activity of the parliament : as co-legislator together with the Council of the EU, the European Parliament (EP) holds plenary sittings, in which reports originating from committees, as well as motion for resolutions, are amended and voted; after the vote, the final adopted texts are published.

The focus on semantic interoperability of EPODP maximizes the potential of reuse and linkage of its datasets, and maximizes the quality of the offered data. It comes however at a cost when building the portal : deep analysis and understanding of the existing data and documents structure is required to capture the business semantic. SHACL is the way to formally encode this business semantic – but how is it deployed in practice ? how is it maintained ? what are the different types of SHACL specifications used ?

SHACL at the center of a model-driven approach

SHACL in the EPODP is at the basis of multiple model-driven usages depicted in the following diagram:

There was two key drivers for introducing the use of SHACL in the EPODP project : validation of the data in the knowledge graph, and generation of public documentations of the models. The same SHACL specification that captures the business semantic is directly actionable to be published as a documentation and to validate the data. The produced documentation is a set of public files, such as the ELI-EP application profile documentation and others accessible from the EPODP developer’s corner. The SHACL Play documentation generator is used to produce the documentation pages. Data validation happens at earlier stages, after data transformation steps.

Two additional usages of SHACL specifications were explored : one was to generate SPARQL queries to extract the content of datasets from the larger knowledge graph. The SHACL specification of a dataset content is interpreted to generate SPARQL CONSTRUCT queries, executed against the entire knowledge graph, to return a subset of data corresponding to the specification. The query generation was implemented in SHACL Play, however the EPODP chose to continue using manually crafted SPARQL queries to generate the datasets. The other usage was to complement the SHACL specifications with the mapping rules used to feed the corresponding properties or classes in the graph. This has the advantage that the mapping rules are documented and maintained alongside the specification and not in a separate document. This work is ongoing.

More exploratory usages of SHACL are foreseen : generating a query user interface based on the SHACL specification, using the Sparnatural query builder, and also input forms to facilitate the creation of DCAT datasets descriptions. Additionally, automated generation of the JSON-LD context and the JSON schema of the API are foreseen.

Not « 1 SHACL to rule them all », but application profiles, dataset definitions, and migration specifications

The definition of the EPODP knowledge graph is not captured in a single SHACL specification, but rather in three different application profiles, each being a selection of classes and properties of one sub-domain : ELI-EP covers the description of documents and activities, ORG-EP covers the definitions of EP organisations (such as committees, political groups, etc.) and members of the parliament, and SKOS-EP covers how controlled vocabularies are structured. In addition, DCAT-EP is the specification for how dataset records are described in the EPODP catalog – but this is not part of the knowledge graph per se.

Together, ELI-EP, ORG-EP and SKOS-EP specify the structure of the entire knowledge graph from which the datasets are extracted. In addition, the structure of each dataset family available in the EPODP (such as adopted texts, plenary documents, parliamentary questions, etc.) is also described in SHACL, referred to as « DSD » for « Dataset Definition ». While the application profiles describe every possible properties on generic shapes, the DSDs will specify only the subset of properties used in a dataset, with possibly different cardinalities or range. For example, ELI-EP specifies that « a Work may have the property eli:adopts«  (with no minimum cardinality (eli:adopts is defined as « Indicates that the work represents the adopted work of one or several related works »). The DSD for adopted texts datasets specifies the shape of « Adopted texts » as a subset of the Works, and indicates that the minimum cardinality of eli:adopts is 1 for this particular subset. Besides, some properties, such as eli:amends are not available for adopted texts, thus not declared in the DSD.

In addition, specifications of the conversion of some data sources are also specified in independent SHACL files. The articulations of these 3 kinds of SHACL files and the reused ontologies is depicted in the following diagram:

There is currently no reuse or reference of shapes across the different specifications. Each is independent. A nice improvement would be to study how SHACL DSDs could be derived from the application profile SHACL, without redeclaring the identical constraints.

Editing SHACL in spreadsheets

In total 16 SHACL specifications are currently published in the EPODP, and around 80 are used to validate data migrated from each individual sources. The first step in the specification of each model is the design in a diagram such as the ones visible in the public documentations of the models. The EPODP team is then using spreadsheets to encode the specifications, adapted from the one provided in the SHACL Play suite. The spreadsheet is converted to SHACL using the xls2rdf converter. Spreadsheets provide a simple editing solution, with an easy learning curve, made even easier with a few formulas to compute cell values automatically. It even provides ways for editing advanced patterns (such as the ability to directly turtle lists for sh:or, or blank nodes for property paths), but of course still limits the expressivity. The following screenshot shows how property shapes look like in the spreadsheet:

Results and future perspectives

The EPODP use-case shows how SHACL can be applied in a systematic way in a data integration and dissemination project : at the data transformation step, at the knowledge graph level, and at the data dissemination. Public documentation, data validation, data extraction are tasks that can be be automated based on a SHACL specification. While the context is one of a large public institution, the same approach can be applied in industrial contexts. The SHACL specifications are a cornerstone of such projects, enabling semantic interoperability at large and a mutual understanding between business experts, data analysts, developers, and data consumers.

”

Veronika’s book will be divided into three parts :

1. Back to Basics
Introduction to logic and RDF, brief skimming of the topics. Also covering various world assumptions.

2. Getting to know the stuff
Introduction to SHACL, including core, sh-sparql, advanced features.

3. Working with the stuff
SHACL Stories. Use cases, user stories and implementations.

Image : © European Union, [2024] – EP

Cet article European Parliament Open Data Portal : a SHACL-powered knowledge graph est apparu en premier sur Sparna Blog.

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.

Voici un tutorial guidé d’interrogation SPARQL des données de Doremus, autour de Gabriel Fauré; ce tutorial explore la modélisation de « création » entre un compositeur et une oeuvre musicale (ou plutôt son expression au sens FRBR). Il montre comment :

• Trouver un compositeur dans le navigateur Overture de Doremus, le navigateur à facette et le service SPARQL;
• Naviguer dans ses activités de création, vers ses oeuvres et leurs expressions, et récupérer les dates de création des oeuvres; le tout en illustrant les opérateurs SPARQL de property path, aggrégation, COUNT, assignation, etc;
• Générer une timeline des compositeurs classiques de façon semi-automatique en utilisant le service timelinejs :

CIDOC-CRM + SPARQL Tutorial sur les données Doremus

Introduction aux requêtes SPARQL sur les données du projet Doremus (http://data.doremus.org) qui modélise et diffuse les données de création d’oeuvres musicale…

Pour réutiliser ce document dans un cadre non-commercial vous pouvez me contacter.

Dans la même veine, vous pouvez consulter le tutorial SPARQL sur les données data.bnf.fr.

Image du post : Carte postale éditée en 1900 lors de la représentation de l’opéra Prométhée de Gabriel Fauré au Théâtre des Arènes, à Béziers. Sur Wikimedia Commons.

Cet article SPARQL sur DOREMUS : une balade autour de Gabriel Fauré est apparu en premier sur Sparna Blog.

A partir des fichiers de données du Répertoire Opérationnel des Métiers et de l’Emploi, j’ai mis en ligne des visualisations de données du ROME, après nettoyage, traitement, et conversion des données en SKOS.

Le Répertoire ROME

Ce répertoire ROME m’avait intéressé il y a 4 ans lorsque j’avais effectué une mission pour l’optimisation sémantique du moteur de recherche SolR d’un job board. Nous nous étions demandé à l’époque si nous pouvions réutiliser une partie de ce référentiel pour effectuer un rapprochement (automatique ou manuelle) des titres d’annonces d’emplois vers le référentiel. Cela aurait permis, à partir de l’identification du nom du poste, de catégoriser automatiquement les annonces dans la catégorie ROME appropriée. Le ROME contient en effet plus de 11000 dénominations de postes/métiers, catégorisés dans une double classification : une arborescence principale, et une arborescence thématique. On y trouve donc des entrées comme :

• Accompagnateur / Accompagnatrice en écotourisme
• Responsable de rayon produits alimentaires
• Assistant / Assistante mise en scène
• etc.

Ces noms de postes sont organisés dans une classification à 3 niveaux : « AGRICULTURE ET PÊCHE, ESPACES NATURELS ET ESPACES VERTS, SOINS AUX ANIMAUX > Espaces naturels et espaces verts > Bûcheronnage et élagage ». Le 3eme niveau (ici « Bûcheronnage et élagage ») correspond à une fiche métier (ici http://candidat.pole-emploi.fr/marche-du-travail/fichemetierrome?codeRome=A1201) et est associé à un code (ici A1201).

Arborescence principale du code ROME dans SKOS-Play

Conversion en SKOS

Je suis reparti ici des fichiers bruts fournis sur data.gouv.fr, et j’ai passé un peu de temps à les convertir en SKOS avec le convertisseur Excel vers SKOS de SKOS Play :

• ajustement manuel de certaines valeurs mal séparées par des virgules dans le fichier CSV de départ;
• suppression des guillemets simples et doubles;
• fusion des 2 fichiers fournis (arborescence principale et arborescence thématique);
• réorganisation des colonnes;

Il s’agit ensuite de construire un tableau Excel au format adéquat pour une conversion vers SKOS, en adaptant la structure des fichiers, typiquement en calculant le contenu de nouvelles colonnes avec des formules Excel. En particulier, il s’agit de donner des identifiants URI à toutes les entrées du code ROME, pour arriver ainsi à des données open data « 4 étoiles ».  Cette conversion SKOS est relativement aisée à réaliser, sans écriture de code ni script. Elle est accessible à toute personne capable de manipuler Excel.

Ces données SKOS du ROME sont publiées à http://data.sparna.fr/vocabulaires/code-rome.

Je ne rentrerai pas dans les détails de modélisation du ROME en SKOS, sauf sur 1 point : on peut se demander ce qu’il convient d’identifier comme « Concept » dans ce référentiel. J’ai pris le parti de considérer chaque nom de poste comme un skos:Concept, et tous les éléments de classification thématiques comme des skos:Collection (donc des tiroirs, qui ne sont pas utilisables dans une indexation). Un point de vue différent mais tout aussi valable serait de considérer non pas les noms de poste comme des concepts, mais bien les noms de métier, chaque métier ayant une correspondance avec une fiche sur le site Pôle Emploi; les noms de poste seraient alors des synonymes (skos:altLabel) du métier (dans l’exemple au-dessus, le métier A1202 « Bûcheronnage et élagage » aurait alors pour synonymes « Agent / Agente d’aménagement des haies et fossés », « Agent / Agente d’entretien des espaces naturels », « Ouvrier / Ouvrière d’entretien des espaces naturels », etc.).

Visualisations de données

A partir des données SKOS, on peut ensuite générer des visualisations avec SKOS Play : ces visualisations sont publiés à http://labs.sparna.fr/code-rome.html. 3 visualisations ont été produites :

1. Un champ de recherche assisté (avec une autocompletion sur les noms des métiers), permettant de lancer une recherche d’annonces sur le site Pôle Emploi à partir d’un nom de métier; on pourrait imaginer quelque chose de similaire pour accéder aux fiches métiers plutôt qu’aux annonces;
2. Une vue arborescente avec d3js, permettant de naviguer visuellement dans l’arbre;
3. Un listing indenté en HTML, que l’on peut plier et déplier;

On notera que, sauf pour l’articulation entre le champ de recherche assisté et le site de Pôle Emploi qui demande 10 lignes de javascript, ces visualisations sont produites directement par SKOS Play sans avoir à écrire de code.

Un « Web des données de l’emploi » ?

On a donc ici fait passer le référentiel ROME à un meilleur niveau de qualité des données, permettant une intégration facilitée dans d’autres systèmes, d’autres outils de recherche. Au delà de la démonstration sur la conversion et la visualisation de données, j’aimerai dans une deuxième étape illustrer l’alignement des données du ROME avec d’autres référentiels (probablement ESCO), en utilisant OnaGUI, qui permet de simplifier les alignements de vocabulaires. On aurait alors un beau référentiel 5 étoiles, _dans_ le web (et pas simplement _sur_ le web), avec des correspondances vers d’autres données. Un « web des données de l’emploi » ? il fallait bien ça à quelques jours des présidentielles !

Dans une deuxième étape je publierai le SKOS généré pour que les URIs soient déréférençables, en utilisant SKOSMOS, dans un déploiement similaire à celui utilisé pour publier le thesaurus de l’UNESCO.

J’espère que cette conversion de données en SKOS permettra une diffusion et une intégration plus large de ce référentiel utile pour la recherche d’emplois. Dites-moi si vous réutilisez ces données pour d’autres visualisations ou d’autres systèmes, ou si vous souhaitez de l’aide pour son intégration.

Illustration de l’article tirée de Wikimedia Commons : https://fr.wikipedia.org/wiki/Fichier:Metro_de_Paris_-_Ligne_2_-_Rome_07.jpg

Cet article Référentiel ROME de Pôle Emploi en SKOS (à partir de data.gouv.fr) est apparu en premier sur Sparna Blog.

The new thesaurus browser

The first objective was to replace the thesaurus publication platform, while maintaining existing backoffice tools for thesaurus management. This choice allowed to quickly demonstrate a publicly available interface for searching and browsing the vocabulary, without waiting for the deployment of the complete system.

Skosmos was used as the thesaurus browser; it is easy to deploy, well documented, and the team behind it from the National Library of Finland is super-reactive for fixing bugs. It offers out-of-box features like alphabetical/hierarchical browsing, autocomplete search, URI-based content negociation, and a feedback form. Important aspects for UNESCO were the ability to have a multilingual interface (English, French, Spanish, Russian), the possibility to customize the stylesheets/logo/help page, or the order of the fields in a concept display page. We added a direct link to trigger a search in the UNESDOC database from a concept page in Skosmos, thus easily linking the new thesaurus browser to the existing resource center.

UNESCO thesaurus published in Skosmos

2 additionnal components were used for a complete vocabulary publishing solution; SKOS Play was used to generate downloadable PDF documents generated from the SKOS thesaurus : complete editions of the thesaurus with alphabetical index, hierarchical tree and translation tables, and KWIC indexes, each in French, English, Spanish and Russian. The documents are regenerated automatically each time a new version of the thesaurus is published. Fuseki with a customized SPARLQ form is used as the frontend for public SPARQL querying of the thesaurus.

Meron Ewketu, responsible for the UNESCO thesaurus, describes the benefits of the new publication platform : « The obvious benefit is the enhanced user interface : a nice hierarchical display, a powerful search, an easy navigation between the different language versions. Thanks to these features the platform was immediately endorsed by our user community. What is also very much appreciated is the possibility of responding to various user needs in terms of format and content. Being able to extract part of the thesaurus as per our users’ requirements, and being able to deliver the content in a variety of formats, including PDF, using the SPARQL endpoint and SKOS Play. We have also noticed an increase in user participation. The feedback form enabled us to engage with our users more easily.« 

The Collaborative Thesaurus Management Software

The second phase of the project aimed at replacing the old thesaurus management software, and integrating it with the new thesaurus browser. UNESCO and Sparna chose to deploy VocBench, an open-source SKOS-based thesaurus management solution from the Tor Vergata University in Rome. We also considered Ginco as a possible alternative; VocBench was chosen mainly for its ability to properly handle collaborative multi-user maintenance of the thesaurus; this was an important aspect for UNESCO, having remote contributors to the thesaurus in Russia, and translations in Chinese and Arabic coming in the future; the ability to work remotely and to have a validation workflow of the modifications was essential. In addition, Vocbench is already deployed by other international organizations, and the upcoming v3 of Vocbench is funded by the ISA2 program of the European Union, thus giving garantees as to the maintenance of the application in the next few years.

UNESCO Thesaurus managed in VocBench

VocBench is SKOS-XL from the bottom up and stores the thesaurus data in an RDF triplestore. We chose to deploy GraphDB from Ontotext as the backend for VocBench. VocBench offers user profile management and edition workflow management, multilingual thesaurus editing, and the possibility to add custom attributes to the thesaurus concepts and terms. We used this to capture corresponding country codes and language codes for certain concepts in the UNESCO thesaurus with a small UNESCO vocabulary publishing ontology describing these 2 properties.

The deployment in production of Vocbench is fairly complex, essentially due to the middleware component on which it relies, called SemanticTurkey; VocBench requires a total of 4 pieces of software (relationnal database, RDF triplestore, SemanticTurkey server, VocBench application server). But, once you are familiar with the procedure, and again with the precious help of the community on th mailing-list, everything works fine. Another limitation of VocBench v2 is that it does not support SKOS Collections, only ConceptSchemes.

Ms Ewketu explains the benefits of VocBench : « Apart from the obvious functionalities of collaborative and distributed maintenance, other important aspects for us were the ability to manage several vocabularies and the ability to make alignments with other thesauri. Being able to document changes through history notes is something very interesting, which I am sure we will exploit in the future. This is quite interesting for researchers who study the evolution of terminology, within an organization.« 

« leverage the thesaurus to achieve interoperability« 

The project clearly is a success story for Semantic Web technologies : with URIs, RDF and SKOS as W3C standards, the UNESCO has achieved its mission of transforming its thesaurus into open, reusable data. The thesaurus is now available for browsing by humans and in machine-readable formats. URIs makes it open for linking from/to other knowledge organization systems on the web, thus enabling interoperability between document databases of multiple organizations.

The project is also a great success story for Open Source; the support from the community and the maintainers of both Skosmos and VocBench was essential for such a quality achievement, and Sparna and UNESCO contributed to both communities by providing translations, filing bug reports and testing new versions. It shows how these tools have enabled the UNESCO to replace an entire thesaurus management platform with no licensing cost, no vendor or data lock-in.

« The main benefit of this project for us will be to leverage the thesaurus to achieve interoperability between our different repositories, as well as with external datasets. » concludes Ms Ewketu from UNESCO. « We are currently working on integrating the new thesaurus within the various information systems. Next phase will be mapping our thesaurus with vocabularies such as the UN Thesaurus and Eurovoc. »

Want to learn more ? reach me at thomas /dot/ francart /at/ sparna /dot/ fr.

Cet article UNESCO Thesaurus published with Semantic Web standards and Open-Source software est apparu en premier sur Sparna Blog.

ELI : une « mise en lien » des textes juridiques européens

La législation est, pour les pays d’Europe et pour l’Union européenne, un élément structurant de la vie des citoyens, de l’activité économique et du débat politique. La législation nationale et régionale s’impose aux citoyens qui peuvent également invoquer le droit européen auprès des juridictions nationales ou lors d’un appel auprès de la Cour de justice européenne. Les entreprises qui opèrent en Europe doivent appréhender la réglementation d’une trentaine de pays, mais également les évolutions des législations techniques, commerciales et financières que préparent la Commission et le Parlement européens et qui seront transposées en droit national.

Face à l’importance du droit mais aussi à la complexité d’accès à des corpus juridiques linguistiquement hétérogènes et géographiquement dispersés, les Journaux officiels (JO) européens ont voulu innover en imaginant un système original d’identification, de signalement et de mise en relation des corpus juridiques à travers l’Europe : le standard ELI (European Legislation Identifier)¹. Cette initiative a reçu le soutien officiel de l’Union européenne en 2012². Les premiers résultats sont exploitables depuis 2015 grâce aux précurseurs qu’ont été les JO anglais, français, italiens, luxembourgeois et européens. D’autres états membres le déploient actuellement, sur la base du volontariat.

ELI utilise les technologies du web de données

ELI permet d’identifier, décrire et relier les textes de lois sur le web de données dont il utilise les technologies pour arriver à son objectif :

• les identifiants des textes de loi sont des URIs ;
• ceux-ci sont décrits suivant un modèle de données formalisé, comme une ontologie ;
• ces descriptions sont ajoutées aux portails web de diffusion des lois à l’aide de marquage sémantique RDFa ;
• les liens se font à l’échelle du Web, d’un URI vers un autre.

Dans une logique d’accès simplifié à la loi, ELI impose que les identifiants soient signifiants, « lisibles » par l’humain et associés à une logique de navigation dans le corpus législatif. Par exemple, la directive européenne 2003/98/CE sur l’ouverture des données publiques³ (qui a ouvert la voie à l’Open data) est identifiée par le ELI : http://data.europa.eu/eli/dir/2003/98/oj ; sa transposition dans la loi française (décret n° 2005-1755 du 30 décembre 2005) peut être identifiée par https://www.legifrance.gouv.fr/eli/decret/2005/12/30/2005-1755/jo/texte, et une métadonnée indiquera que le décret français « eli:transposes » la directive européenne.

Modèle FRBR et graphe de données législatif

Le modèle FRBR prescrit le découpage des notices documentaires en niveaux conceptuels : Oeuvre, Expression, Manifestation, Item⁴, auxquels FRBRoo⁵ ajoute – entre autres – le niveau d’« Oeuvre complexe »⁶. Ces modèles proposent également de nombreuses propriétés pour décrire chacun des niveaux, créant des modèles précis mais complexes.

ELI se veut à la fois générique (applicable aussi bien pour la common law que pour le droit codifié), simple à implémenter, mais rigoureux dans la description des lois ; il a donc défini un modèle compatible avec l’idée-clé du découpage des notices en 4 niveaux conceptuels, mais dépouillé du reste de la complexité de FRBRoo. Une quarantaine de champs sont spécifiés, en particulier les liens entre lois : « modifie », « cite », « baséSur », etc.

Les niveaux FRBR – plus l’« Oeuvre complexe » FRBRoo – sont donc appliqués à la description des lois :

• Oeuvre complexe : texte juridique identifié par un certain nombre de composants invariants dans le temps (Directive 2003/98/CE) ;
• Oeuvre : version spécifique du texte au cours du temps ; typiquement sa version d’origine (publiée au JO) ou l’une de ses versions consolidées ;
• Expression : variante linguistique d’une version particulière, dans des systèmes législatifs multilingues (comme la loi européenne) ;
• Manifestation : format de fichier spécifique d’une variante linguistique d’une version particulière ; typiquement, le PDF authentifié pour la version opposable du JO ou la version HTML.

En accord avec la logique des données (et modèles) liées, chaque État membre peut spécialiser les descriptions ELI avec ses propres champs, conservant ainsi une sémantique précise tout en restant compatible avec le cadre général.

Un cadre flexible pour une adoption progressive

L’approche d’ELI n’est pas contraignante : chaque État peut spécifier sa propre structure d’URI à partir des composantes définies par ELI, choisir de publier seulement certaines métadonnées ou implémenter ELI uniquement sur une partie de son corpus.

Pour les JO qui ont une pratique de catalogage des textes légaux, ELI dans sa forme la plus simple a peu d’impact sur les chaînes de production documentaires ; il peut être implémenté en ajoutant uniquement des métadonnées en RDFa dans les pages web finales, sans impact ni sur le reste du flux ni sur l’expérience utilisateur, la principale tâche du JO étant de publier ses métadonnées à l’aide des champs de l’ontologie. ELI constitue donc pour les JO une première marche vers le web de données ; une fois la dynamique enclenchée, les flux documentaires pourront être enrichis avec plus de métadonnées ou des descriptions plus précises.

Le graphe des données ELI, en cours de constitution, est un objet original dans le paysage du web des données ; par sa publication décentralisée, son adaptabilité et la légèreté des moyens mis en œuvre, il se différencie d’un projet tel qu’Europeana⁷ qui vise à constituer un catalogue centralisé d’œuvres d’art. En effet, dans ELI, chaque acteur garde la charge de publier son propre graphe de notices documentaires en s’appuyant sur sa propre infrastructure. Il se différencie également du projet multilingue Wikipedia/Dbpedia⁸ car les données sont publiées dès l’origine pour le web des données à partir d’une activité de catalogage professionnelle. Il s’en différencie encore par la variété des acteurs dont les statuts sont très divers : administrations nationales, régionales ou européennes mais aussi éditeurs privés assurant une mission de service public.

ELI concilie adaptabilité et interopérabilité en s’appuyant sur un mix de référentiels partagés publiés par l’Union européenne (langues, lieux, statuts des documents, formats de fichiers) comme sur des référentiels propres à la législation nationale (acteurs juridiques, types de texte).

Cette coordination originale d’acteurs divers qui publient avec leurs moyens propres des graphes complémentaires dans le web des données exige une implémentation simple et économique, mobilisant un minimum de compétences spécialisées. Simple, car la mise en œuvre est réalisée par les JO qui n’ont pas au départ de compétences dans les technologies du web sémantique. Économique, car le coût de mise en œuvre ne devrait pas dépasser quelques dizaines de milliers d’euros pour les JO aux budgets les plus réduits. Les solutions pour répondre à ce challenge sont le partage de retours d’expérience entre JO, des formations pour chaque pays et un standard stable pour éviter des coûts de maintenance élevés.

Premiers exemples de réutilisation

L’objectif d’ELI est de permettre de construire au meilleur coût des applications qui s’appuient sur le graphe de données des législations européennes. Grâce au travail de vulgarisation réalisé par le mouvement associatif, comme Open Law en France, des premiers projets de réutilisation apparaissent. On peut citer, par exemple, le tableau de bord d’Open Law⁹ qui, avec environ 12 jours de travail, a permis de récupérer et exploiter les données ELI françaises, italiennes et européennes, ou le travail en cours par un éditeur de logiciels, KBCrawl, pour exploiter les données ELI dans une application de veille juridique sectorielle. Leur point commun est d’avoir abouti à la création de services à haute valeur ajoutée pour des investissements de quelques jours à quelques dizaines de jours, avec la possibilité d’étendre le service sur les données d’autres pays utilisant le standard ELI.

En combinant ontologie générique, adressage à plusieurs niveaux, liens entre lois nationales et loi européenne, le tout dans un contexte multilingue, ELI crée donc un véritable graphe de données législatives à l’échelle européenne. Le web coopératif et décentralisé entre ici en résonance avec le projet européen, lui aussi coopératif et décentralisé.

Cet article Article dans la revue I2D – ELI : une « mise en lien » des textes juridiques européens est apparu en premier sur Sparna Blog.

ELI (European Legislation Identifier) est une initiative européenne pour identifier, décrire et relier les lois de l’Union européenne et de ses états membres. D’abord issue du forum des journaux officiels des pays membres de l’UE, l’initiative est en cours de déploiement en Europe, pour les pays qui le souhaitent. ELI utilise l’infrastructure du web et les technologies du web sémantique pour arriver à cet objectif :

• les identifiants de législation sont des URIs;
• les législations sont décrites suivant un modèle de données formalisé comme une ontologie;
• ces descriptions viennent structurer les pages web existantes en utilisant du balisage RDFa;
• les liens se font à l’échelle du web, d’un URI vers un autre.

Si les lois sont accessibles depuis longtemps aux citoyens via les portails de diffusion nationaux (Legifrance en France), ELI va permettre une véritable mise en réseau des données des lois européennes, dans des formats ouverts et permettant leur réutilisation.

Pour donner un exemple très concret :

• la directive européenne « PSI » sur l’ouverture des données publiques (celle qui a ouvert la voie à l’open data) sera identifiée par le ELI http://data.europa.eu/eli/dir/2003/98/oj
• sa transposition dans la loi française (Décret n° 2005-1755 du 30 décembre 2005) sera identifiée par le ELI http://legifrance.gouv.fr/eli/decret/2005/12/30/JUSC0520903D/jo, et une métadonnée indiquera que le décret français « eli:transposes » la directive européenne (l’URI eli:transposes n’est pas encore déréférençable, voir plus bas pour le lien vers le fichier d’ontologie).

Les avantages d’ELI ?

Pour les états membres c’est un mécanisme d’identifiant homogène pour les lois sur le web; Il ne serait pas surprenant d’ailleurs que ce mécanisme d’identifiant URI devienne partie intégrante des systèmes de production législatifs dès les premières étapes de production d’un texte. C’est également un élément facilitateur d’accès à la loi pour le citoyen (et le réutilisateur de données). C’est un moyen de faciliter l’échange de données entre systèmes informatiques à l’intérieur de l’état ou entre états.

Pour les institutions européennes ELI est un moyen d’automatiser l’échange de données entre institutions ou depuis les états membres vers les institutions européennes. Eur-Lex (portail de la loi européenne) contient par exemple les références des « mesures nationales d’exécution », c’est-à-dire les lois nationales qui transposent les directives européennes. On retrouve par exemple le décret français cité plus haut dans Eur-Lex. Ces informations sont transmises manuellement par les états membres, mais leur récupération pourrait être automatisée grâce à ELI.

Pour les utilisateurs finaux ce seront des URIs homogènes, « user-friendly » (voir plus bas) – si tant est qu’une URI puisse être user-friendly !! – donc une pose de lien plus facile vers la loi, dans des tweets ou des billets de blog. Ce seront aussi des applications et des services à valeur ajoutée qui seront développés à partir des données mises à disposition en ELI; on imagine bien par exemple des tables de droit comparé entre plusieurs pays générées de façon automatique, montrant comment une directive a été implémentée dans différents pays.

URI user-friendly et modèle FRBR

Les URI ELI restent lisibles pour l’humain. Il ne s’agit pas d’URIs opaques composées de lettres ou chiffres incompréhensibles, mais d’URIs :

• qui utilisent des éléments relativement homogènes dans les différents états membres; ELI n’impose pas de schema d’URI unique, mais des éléments à assembler, comme le type de document ou l’année de publication; les pays décident de leur schéma d’URI en fonction des habitudes de citation de leurs citoyens; les schémas d’URI de chaque pays seront documentés dans un registre au niveau européen;
• qui sont « hackable » c’est-à-dire qu’en étant un peu débrouillard on peut raccourcir l’URI pour obtenir une liste de résultats (http://data.europa.eu/eli/dir/2003 doit ramener les directives européennes de 2003), ou bien on peut facilement accéder à un autre texte en modificant l’URI une fois qu’on a « compris le truc »;

L’ontologie ELI, quant à elle, en bonne européenne, est le résultat de compromis, et cherche à accommoder tout autant la « common law » anglo-saxonne que notre droit civil. C’est un modèle d’échange, de publication de métadonnées, et donc relativement simple; il reprend les informations essentielles de description des textes législatifs, en mettant l’accent sur les liens entre les textes, et notamment les liens d’implémentation et de transposition des directives européennes en lois nationales.

L’ontologie se base sur deux modèles :

• FRBR pour le squelette LegalResource > LegalExpression > Format;
• et Dublin Core (dcterms) à partir duquel certaines propriétés ont été étendues, quand ça avait du sens;

Coopération européenne et web de données

<attention_lyrisme>

L’Europe est une belle chose, on l’oublie un peu. Son fonctionnement technocratique est certainement critiquable, mais l’idée est belle; c’est celle de la coopération entre des peuples différents. Et quand, lors d’une réunion de projet ELI, des luxembourgeois, anglais et français, des employés des institutions européennes allemands et hongrois, écoutent un irlandais aider la délégation maltaise à spécifier ses URIs ELIs, l’idée de la coopération européenne s’impose. Parce que tous ces gens auraient pu choisir de rester dans leur pays plutôt que d’essayer de travailler ensemble.

Le web est une belle chose, on l’oublie un peu. Son fonctionnement de plus en plus mercantile et centralisé est certainement critiquable, mais l’idée est belle; c’est celle de la liberté pour chacun de s’exprimer, c’est celle de la mise en commun et de la mise en lien des connaissances de chacun. Et quand des projets collaboratifs internationaux comme ELI choisissent tout naturellement ce socle technologique pour se concrétiser, cette idée de la mise en commun et de la mise en lien des connaissances de chacun s’impose. Parce que toutes ces données auraient pu rester cloisonnées plutôt que d’essayer de se lier ensemble.

Phil Archer au dernier semweb.pro 2014 a dit (la phrase m’était restée) « don’t let anyone tell you that the semantic web doesn’t work. Because it does.« . Des projets comme ELI sont non seulement la preuve que ça marche (mais donner encore une preuve serait entrer dans le jeu de ceux qui objectent que cela ne marche pas), mais aussi la preuve que les valeurs qui sous-tendent les technologies du web (de données) sont en adéquation avec les besoins des projets actuels.

Et le mouvement ne peut que s’amplifier : car le web est tout à la fois ce qui permet à des projets collaboratifs comme ELI de se concrétiser, mais aussi ce qui déclenche de nouvelles collaborations, puisque c’est par l’ouverture (des opinions, des documents, des données) que naît la confiance, la compréhension, et la coopération.

</attention_lyrisme>

Références ELI

• Conclusions du Conseil préconisant l’introduction d’un identifiant européen de la législation (ELI) (dont la description du modèle de données est périmée)
• Ontologie ELI publiée sur le site de l’Office des Publications
• Site présentant ELI, maintenu par la France : eli.fr
• Page wikipedia ELI en français
• Applications :
  • En France, un exemple sur Legifrance de loi affichant un ELI (basé sur le NOR) et son alias
  • Au Luxembourg : le prototype eli.legilux.lu
  • ELI sera intégré à Eur-Lex pour les lois européennes

(illustration de l’article : Justitia (Maarten van Heemskerck, 1556) disponible sur wikimedia commons ici)

Cet article ELI – European Legislation Identifier : une voie pour le web de données législatif européen 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.