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.

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.

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.

Cet article Partarger et réutiliser des données structurées sur le web est apparu en premier sur Sparna Blog.

Il y a une différence entre les informations/données publiques et les informations/données ouvertes. La différence, dans cette notion d’ouverture, est avant tout une question de conditions de réutilisation des informations/données. Conditions de réutilisation juridiques et techniques. Toute donnée publique n’est pas de l’Open Data (voir les présentations de Calimaq sur ce sujet), des tas d’informations sont déjà publiques sans être ouvertes : comptes-rendus de conseils municipaux, journaux officiels, etc. Par ailleurs, une fois ouverte, une information l’est pour n’importe qui, n’importe quand, et pour faire n’importe quoi :

• pour n’importe qui : si l’information/donnée n’intéresse pas le cercle de ses destinataires premiers, il est possible que quelqu’un, quelque part, en ait une utilité;
• n’importe quand : une fois publiée, une information/donnée va rester accessible. A moins qu’elle ne soit supprimée ? non, trop tard, elle aura déjà été copiée de ci de là, téléchargée par vos copains, indexée par Google, archivée dans les archives du web;
• pour faire n’importe quoi : si l’information/donnée n’a pas de sens toute seule, elle peut faire sens si elle est mise en contexte avec d’autres informations/données. Tableaux, cartes, hiérarchies de classement, les données ne prennent sens que mise dans un contexte, avec d’autres.

1ère partie : de la misère humaine en milieu publicitaire [1. « De la misère humaine en milieu publicitaire » est livre du Groupe Marcuse dénonçant les méfaits de la publicité.]

Les institutions politiques et les gouvernements n’ont plus les moyens suffisants d’influer sur l’avenir. Qui croit encore que la conquête de pouvoir est un passage obligé vers les lendemains qui chantent [2. l’originalité des mouvements contestataires récents – Zapatistes, Indignés, Anonymous, Décroissants, etc. – est justement que la conquête du pouvoir est absente de leurs objectifs.] ? Le prétendument libre marché a plus d’influence sur nos vies que les politiques publiques. La sphère économique influence notre façon de consommer, de travailler (ou de chômer), de nous détendre : tout devient prétexte à marchandisation. Elle le fait en particulier en redirigeant nos pulsions, qui sont traditionnellement « canalisées » à travers des structures sociales complexes – mariage, sport, mathématiques, dessin, etc. – et forment ainsi la base d’un « vivre-ensemble », vers des objets de consommation [3. C’est la philia de Bernard Stiegler]. Cette manipulation du désir est orchestrée par les plans marketing et publicitaires s’appuyant sur les médias de masse.

Le monde des entreprises et en particulier de celles dirigées par des gestionnaires qui ne viennent pas du « métier » mais des écoles de gestion est à l’opposé de l’idéal de démocratie vanté par les sociétés occidentales [4. ce qui n’est pas incompatible avec l’approche du travail psychologique/psychiatrique de Christophe Dejours, dans laquelle le travail est pour l’individu le lieu d’apprentissage de la délibération, de la solidarité, des interactions avec les autres pour trouver la meilleure solution, bref le lieu d’apprentissage des processus démocratiques. Autant d’apprentissages cassés par les méthodes de management gestionnaires.]. Les salariés ne sont pas associés aux décisions et sont des variables d’ajustement de stratégies économiques qu’ils n’ont pas choisies [5. ce que prennent à contre-pied les formes coopératives d’organisation du travail comme les SCOP]. Les quelques organisations (syndicats) ou mécanismes de régulation (droit du travail) sont soit dépassés, soit mis en danger. Les entreprises ne recherchent pas notre mieux-être collectif; elles recherchent leurs profits. C’est pourquoi il apparaît nécessaire de réclamer plus de transparence sur les données des entreprises, notamment à des fins de régulation.

2ème partie : du constat de la quasi-absence de données ouvertes concernant les entreprises

L’ Open Data ou ouverture des données est « une philosophie visant à rendre certaines données accessibles à tous et s’affranchir des restrictions imposées par les licences payantes (…) qui en limitent notamment l’exploitation et la reproduction ». Ce mouvement concerne certaines données publiques des administrations centrales ou locales (le portail data.gouv.fr en France), mais pas les données du privé. Les registres publics en France relatifs aux entreprises ont des modes d’accès variés; la base Sirene est payante, la base infogreffe permet une recherche gratuite mais un accès payant aux fiches détaillées, les bases de l’INPI sont d’accès gratuits – même si on nous suggère de ne pas nous y fier et de commander une recherche payante; et si l’accès est gratuit, les données ne sont pas ouvertes et il est interdit de réutiliser le contenu de la base.

Quid des données concernant les entreprises sur le reste du « web de données » ? Hé bien dans DBPedia francophone c’est la joyeuse anarchie propre aux projets communautaires, donc il ne faut s’attendre ni à la complétude ni à l’exactitude ni à l’objectivité des données – même si cela permet de récupérer quelques petites choses amusantes comme des slogans. Quant au « Google Knowledge Graph« , comme on le fait remarquer ici, il ignore de façon spectaculaire les entreprises : quelques données sur Carlos Goshn, mais rien sur Renault, quelques infos sur Xavier Niel mais rien sur Iliad, etc.

Début 2011 a été lancé opencorporates.com [6. Voir la press-release de l’annonce de lancement], une initiative d’une société britannique visant à rendre accessibles de façon ouverte de nombreuses données sur les entreprises, notamment les montants des contrats publics qu’elles ont remportés, ou le nom de leurs administrateurs. Si l’initiative semble répondre à mon désir de données ouvertes (avec toute la couche technique qui va bien : API, identifiants, liens, etc.), elle se heurte aux contraintes légales et ne propose aucune données sur les entreprises françaises. Rien. (Voir cet article du Monde.fr).

Pourquoi une telle difficulté à accéder à des données ouvertes sur les entreprises ? Si le constat fait précédemment de la prééminence de ces organisations privées sur nos vies est fondé (n’importe quel reportage à propos d’un n-ième plan social ou d’un n-ième scandale sanitaire servirait d’illustration), alors nous avons le droit à une information ouverte sur le fonctionnement des entreprises. Une information ouverte : accessible et réutilisable par n’importe qui, n’importe quand, pour faire ce que bon nous semble.

3ème partie : de ce que les données ouvertes sur les entreprises pourraient changer.

Il faut travailler, des points de vue légal, militant et technique, à l’obtention, la constitution ou l’ouverture de données ouvertes simples et fiables, pour toutes les sociétés privées qui structurent notre quotidien plus que ne le fait l’action publique, concernant :

• les chiffres : chiffre d’affaires, bénéfice, montant des contrats publics, etc.
• l’actionnariat et les dirigeants : qui dirige, qui contrôle, le salaire des dirigeants ou le montant des jetons de présence au conseil d’administration, etc.
• les produits : marques et les filiales, les sites de production, fournisseurs et clients, etc.
• le social : nombre de salariés, salaires, politique sociale, etc.

Il me semble que c’est sur ce type d’information que l’Open Data peut avoir un apport réellement disruptif, pas sur des données qui étaient de toutes façons déjà publiques. De la même façon que la logique de l’Open Data dit qu’en tant que citoyen « ce sont nos impôts qui financent l’action publique, donc nous avons le droit aux données résultant de cette action », en tant que consommateurs nous pourrions dire « c’est notre consommation qui finance votre entreprise, donc nous avons le droit aux données résultant du fonctionnement de votre entreprise ». Par ailleurs, la « concurrence libre et non-faussée » de la constitution européenne dans la lignée des dogmes libéraux ne peut se réaliser que dans un contexte d’égal accès à l’information pour tous, et l’ouverture des données privées va dans ce sens.

L’accès à ces informations éviterait entre autres les scandales équino-bovins ou l’opacité patissière. Elle permettrait :

• d’améliorer l’information du consommateur sur les produits ou service qu’il achète;
• de réguler le fonctionnement des entreprises; comme l’espère opencorporates.com de « donner aux citoyens, ONG, médias et aux autres entreprises le moyen de comprendre, contrôler et réguler les entreprises »;
• de servir de base aux processus démocratiques au sein même des entreprises;

Quelles pistes concrètes ?

• Sensibiliser les entreprises de l’économie sociale et solidaire à la problématique de l’Open Data afin qu’elles ouvrent leurs données [7. à ce propos si vous êtes dans la région de Tours rendez-vous ce vendredi 5 avril pour un atelier Open Data dans le cadre des assises de l’Economie Sociale et Solidaire];
• Obliger par l’accord de licence de réutilisation les entreprises qui ré-utilisent des données à publier elles-mêmes des données sur leurs activités; cela éviterait peut-être certaines dérives comme la copie pure et simple du contenu de Wikipedia (légalement autorisée mais éthiquement condamnable) dans les moteurs de recherche Orange et Voilà à la seule fin d’y ajouter un contenu publicitaire, relatée dans cet article de fond sur savoirscom1.info;
• Faire valoir dans le cadre de la nouvelle feuille de route de l’état sur l’Open Data l’intérêt du citoyen, du consommateur, du travailleur à disposer d’informations ouvertes sur les entreprises; n’hésitez pas si vous êtes sensibles à cette question à commenter cette proposition dans la boite à idées d’Etalab;

Cet article Données Ouvertes et Entreprises Privées est apparu en premier sur Sparna Blog.

Le web de données, de son côté, n’a jamais permis autre chose que la diffusion et l’interconnexion de données à l’échelle du web. Il aura fallu attendre la libération des données publiques pour que cet enjeu devienne clair. L’open data offre le cas d’usage idéal pour le web de données – car en fait, on pourrait presque dire que ces 2 mots désignent la même chose et ont le même objectif.

Soyons clair : avancer vers les technologies du web de données, pour un producteur de données, demande un effort supplémentaire. Que peut-il en attendre ? J’y vois 5 enjeux :

1. Devenir un producteur de données de référence. La possibilité offerte par les standards du web de données de faire des liens entre les instances décrites dans les données, permettent à un producteur d’obtenir des liens entrants vers ses données, devenant ainsi un « hub », un acteur central dans le réseau de données. C’est un enjeu stratégique : si vous n’ouvrez pas vos données aujourd’hui, d’autres le feront à votre place, et deviendront les référents.
2. L’enrichissement de ses données avec celles des autres; La possibilité de relier les éléments décrits dans les données à d’autres, comme celles de la BNF, de l’INSEE, d’Eurovoc, de DBPedia, va permettre aux consommateurs des données de suivre ces liens et d’enrichir le système qu’ils construisent avec ces nouvelles données.
3. La normalisation de son catalogue de données au format DCAT, le rendant ainsi interopérable avec les catalogues des autres producteurs. Cela améliore la visibilité et la réutilisation du catalogue des datasets.
4. La réutilisation de modèles existants pour décrire les données; les données publiées depuis 10 ans couvrent de nombreux domaines du savoir, et la problématique de description de beaucoup de données a donc déjà été traitée. De nombreux vocabulaires sont déjà disponibles (sur le LOV par exemple) et prêts à l’emploi pour décrire le contenu des données.
5. Le bénéfice d’outils existants, et de futures évolutions. Poussé par le W3C, les standards du web de données sont ouverts, pérennes, et formeront la base d’autres technologies, par exemple pour indiquer la traçabilité et les versions des données. Les outils compatibles avec ces standards existent et continueront d’exister.

Y a-t-il, y aura-t-il convergence ? les projets de recherche comme Datalift proposent des outils basés sur les technologies du web de données pour que les producteurs de données « sémantisent » les données. Et moi aussi, je peux vous aider !

Update

Etalab vient de publier le compte-rendu de l’événement « Datalift Camp » qui adressaient ces problématiques et dont ces réflexions personnelles sont issues.

Cet article Open data et web de données : convergence ? est apparu en premier sur Sparna Blog.

• Principal hochement de tête approbateur : le concept de dataware et d’autonomisation des données, les données en elles-même et pour elles-mêmes, comme dans mon précédent billet. Avec ce que cela implique de bouleversement dans la façon de concevoir les systèmes et les interactions au sein du SI.

• Principale grimace de désaccord : la notion de « vérité éternelle des données ». Je crois que c’est une vue de l’esprit qui n’a pas cours dans la réalité. Tous les projets de gestion d’ontologies, de thesaurus, de catalogues, demandent et requièrent maintenant des fonctions de versionnement et de prise en compte des évolutions des données dans le temps. Toutes les données changent dans le temps. Toutes. Même le classement d’un catalogue d’archives évolue dans le temps. On s’étonnera que cette notion d’évolution dans le temps des données (« diachronicité des données ») n’ait pas été prise en compte au niveau le plus bas des standards du web, RDF, ou même les URI (et on consultera le projet memento [2] avec intérêt si on est titillé par le sujet). Quel orgeuil, quand on y pense, de croire que les éléments d’information que l’on encode à un certain instant sont obligatoirement les bons, ou qu’ils resteront valides éternellement.

• Bref. Pour passer à un autre point, effectivement, le principe de base du Linked Data est que la connaissance de l’identifiant d’une chose suffit pour accéder à une représentation de cette chose; inutile de connaitre une API, ou de passer par le biais d’une interface pour accéder à cette représentation.

• Ce n’est pas étonnant que l’ouverture des systèmes à travers des API soit plus populaire que l’ouverture des données « tout court » : l’API est pensée pour le développeur, elle prend en compte ses cas d’usage pour les simplifier, là où le Linked Data se garde bien de lui faciliter la tâche car justement, cette approche se concentre sur les données en elles-mêmes, sans préjuger de leur mode de réutilisation. Pour un développeur, il est bien plus facile de développer des applications à partir d’une API qu’à partir de données brutes; comment faire pour implémenter un simple écran de liste (de lieux, de bâtiments, de n’importe quoi) uniquement à partir des URIs des données ? cela nécessite plusieurs appels et un parsing du résultat non trivial. Là où une API fournira un seul appel, renvoyant uniquement les données utiles, dans un format simple.

• On en arrive donc à dire que publier des données sous forme de Linked Data ne permet pas leur réutilisation simple. C’est paradoxal, puisque c’est l’objectif affiché. Il faut que l’ouverture des données fasse un pas de plus vers le développeur. Des outils comme Elda [3] et la proposition du Linked Data API [4] sont exactement là pour franchir ce pas : »For some web developers the need to understand the RDF data model and associated serializations and query language (SPARQL) has proved a barrier to adoption of linked data. [The Linked Data API project] seeks to develop APIs, data formats and supporting tools to overcome this barrier. Including, but not limited to, accessing linked data via a developer-friendly JSON format. »

—

Cet article Open Data versus API est apparu en premier sur Sparna Blog.

L’événement est gratuit et les détails et inscriptions sont ici

Cet article Producteurs de données – datalift camp les 9 et 10 octobre 2012 est apparu en premier sur Sparna Blog.

Cet article Rencontre de l’Open Data à Grenoble le 5 juin est apparu en premier sur Sparna Blog.

Les mouvements du « Data Is King »

Le principe « Data is King » sous-tend les mouvements suivants :

L’Open Data : l’ouverture des données (publiques avec data.gouv.fr ou privées) induit une structuration de l’écosystème des acteurs en deux : d’un côté ceux qui produisent la donnée, de l’autre côté ceux qui l’utilisent ou la réutilise (par une posture de neutralité nécessaire, le producteur de la donnée ne peut pas être celui qui illustre son utilisation dans une application, sous peine de perdre cette impartialité quant à la donnée). Cette structuration illustre parfaitement la notion de réutilisation des données dans plusieurs applications.

Le Web de données, ou sémantique : la notion de web de données, tout en étant antérieure dans le temps à la notion d’Open Data, en est en fait l’aboutissement, la dernière marche au niveau qualitatif. Un peu comme si, se rendant compte que la barre du web sémantique avait été mise trop haut, les architectes du web avaient mis là une marche intermédiaire : publiez vos données d’abord, peu importe le format. Pour ce qui est des aspects propres au web de données, à savoir l’identification des concepts avec des URI et les relations avec d’autres données, hé bien, on verra plus tard, une fois que cette marche aura été franchie. Sous cette problématique se retrouve là encore le « Data is King », les promesses du web en plus : décentralisation, liens, accès par tous et partage par tous.

Gestion du contenu et SEO. Finit le SEO à base des quelques mots-clés mis au bon endroit dans la page. Depuis schema.org, ce qu’il faut pour « ranker », ce sont des données structurées. La promesse de remonter dans les résultats de recherche va inciter les web agencies et les producteurs de contenu à publier leurs métadonnées, voire à produire lorsqu’elles n’y sont pas. On va pouvoir se passer de moteur de recherche dans les systèmes, se contenter de publier de la donnée structurée, et tout faire reposer sur Google pour l’indexation.

L’autre buzzword du moment, Big Data, n’est pour moi pas lié à cette philosophie « Data Is King ». Le Big Data, c’est d’abord de gros algorithmes permettant de traiter beaucoup de données, l’accent est plus mis sur l’infrastructure, la performance, et la scalabilité, que sur les données elles-mêmes.

Les échelles du « Data Is King »

Le principe « Data is King » se retrouve à plusieurs échelles. A l’échelle des applications d’abord, où l’on va privilégier la modélisation claire des schémas de données, et – au minimum – s’assurer que les données ne sont pas prisonnières des applications, voire privilégier dès le départ une politique d’ouverture des données des applications. On le voit avec un peu de recul, les applications passent, les données restent, il est donc capital de faire en sorte que les données ne sont pas propres aux applications, qu’elles peuvent être réutilisées dans d’autres contextes. On ne développe plus des applications, on développe des données; d’autres développeront les applications qui viendront tirer avantage de ses données. La donnée fait partie du capital de l’entreprise, l’application n’en fait pas partie.

A l’échelle des architectures applicatives ensuite, où l’on passe d’architectures orientées services (SOA) à des architectures orientées données, qu’on pourrait appeler DOA par jeu d’opposition. Cela est directement lié aux architectures REST, mais va un peu au-delà, dans la mesure où REST, bien que nécessitant d’identifier des ressources par des URIs, ne privilégie pas nécessairement les données sur le document. Il est plus facile de décentraliser les données et de centraliser les services que de décentraliser les services et de centraliser les données. La promesse d’interopérabilité du SOA et de SOAP est d’emblée dépassée par les architectures REST.

A l’échelle du web enfin, où l’on est en train d’ajouter au web des documents un web des données. Les liens de cette nouvelle couche de la toile ne se font plus de page à page, mais de données à données. Les données sont publiées, interreliées, interprétables par les machines, réutilisables.

Vive le roi Data !

Cet article Data Is King ! est apparu en premier sur Sparna Blog.