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.

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.