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.

• 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.

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

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

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

// I. exemple de Query SELECT

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

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

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

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

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

// II. Exemple de Query CONSTRUCT

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

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

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

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

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

Jars nécessaires

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

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

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

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

Démarrage rapide

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

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

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

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

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

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