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.

Voilà maintenant près d’un an et demi que FranceArchives, le Portail national des Archives de France, a annoncé le déploiement de l’outil « Supernatural » (comprendre Sparnatural) via ses réseaux, dans l’optique de proposer à ses usagers « un accès nouveau aux métadonnées archivistiques, complémentaire de la recherche classique par le moteur du portail ».

Porté par le Service interministériel des Archives de France, le portail FranceArchives offre une recherche fédérée dans près de 26 millions de métadonnées archivistiques produites par près de 170 institutions et entièrement sémantisées en RDF par le biais de l’ontologie RiC-O version 0.2 publiée en février 2021.

C’est une des premières utilisations de RiC-O à grande échelle (même s’il faudra à l’avenir qu’il se mette à jour sur la version 1.0 de RiC-O publiée depuis !), et c’est également l’un des premiers entrepôts de données archivistiques de cette taille sur le Linked Open Data.

… Un graphe de données qui a tout pour être « Supernaturalisé »

Des données de qualité à une recherche augmentée

… Enfin, il va surtout s’agir de ses « données de qualité », autrement dit les :

• inventaires avec leurs composants,
• notices descriptives de producteurs d’archives,
• fiches signalétiques des services d’archives,

 … tous objets liés à une autorité « personnes et institutions », « lieux » et « thèmes » de qualité (soit moins de 5% des métadonnées du portail avant conversion… et plus de 70% de l’ensemble du réservoir en RDF !), autorités de qualité elles-mêmes harmonisées et alignées vers des référentiels nationaux et internationaux.

Modèle particulièrement adapté à la description des archives en RDF, c’est l’ontologie RiC-O (v0.2) qui a été utilisée pour la sémantisation des données XML EAD – XML EAC-CPF vers RDF, complétée de schema.org pour les fiches signalétiques des services de l’annuaire au format XML EAG.

Les informations relatives aux archives et à leurs producteurs étant décrites dans des fichiers différents, la recherche avancée via SPARQL rend désormais possible une interrogation fédérée plus fine d’un vaste corpus de notices en « traversant » le graphe structuré selon le modèle RiC-O. En effet, l’intérêt de l’interrogation via SPARQL est de casser les silos entre types de métadonnées : il permet de faire une recherche transversale entre données provenant de fichiers EAD et de fichier EAC-CPF.

Les notices affichées en résultats de recherche montrent les alignements existants vers les notices de producteurs externes, Wikidata, data.bnf, GeoNames ou encore le Thesaurus pour l’indexation matières des archives locales. C’est ainsi dans l’onglet Personnes/indexations liées que sont exploités les résultats de la conversion en RDF, par le biais de suggestions de recherches complémentaires sur le portail classique.

Une façon de faire bénéficier le grand public du RDF de manière complètement transparente pour lui !

Quelques exemples de requêtes…

On accède à l’outil via le menu « Recherche SPARQL » en haut à droite du site du portail :

Plusieurs exemples de requêtes sont à disposition pour explorer les données :

De la requête la plus simple :

Personne est membre de Institution

À des requêtes de plus en plus élaborées et complexes, comme ici :

Lieux qui sont le sujet des archives reliées au fonds « Fabrique de berlingot Eysséric »

Où l’on voit que l’on peut retracer le cheminement de la requête à travers le graphe de l’ontologie RiC-O en cliquant sur « Afficher/masquer l’éditeur SPARQL ».

Des archives à la page…

À noter que le projet, qui avait fait l’objet d’une présentation à l’occasion de SWIB (Semantic Web in Libraries) et de SemWebPro 2023 a été entièrement déployé (et configuré !) à partir de la documentation disponible sur le site web de Sparnatural.

N’hésitez pas à aller la consulter !

Hello Sparnatural

How-to configure in SHACL

Reference documentation of Sparnatural widgets

Pour aller plus loin sur la sémantisation des archives…

Le déploiement de Sparnatural sur FranceArchives fait suite à une autre réalisation de l’année précédente, le démonstrateur Sparnatural des Archives nationales. Celui-ci avait permis de faire évoluer Sparnatural et de le déployer sur un graphe sémantique en RiC-O de 20 millions de triplets (hors inférence), alimenté avec le contenu de 1577 instruments de recherche décrivant les archives de 40 des 122 études notariales de Paris conservées aux Archives nationales, de 1120 notices décrivant ces études et les notaires qui y ont exercé, et d’autres référentiels des Archives nationales notamment sur les lieux de Paris. La réalisation de ce démonstrateur a été entièrement documentée en français et en anglais. Ce démonstrateur et ses interfaces évolueront d’ailleurs bientôt.

Depuis, Sparna s’est impliqué dans le domaine de la sémantisation des archives puisque nous développons également, pour les comptes des Archives Nationales, l’outil Ric-O converter.

Celui-ci permet la conversion de notices EAD et EAC vers du RDF exprimé en RiC-O. Nous finalisons actuellement une nouvelle version du convertisseur pour le rendre compatible RiC-O 1.0 (et même 1.1 dont la sortie est imminente).

Un nouvel article à paraître ici sur RiC-O ? … Stay tuned !

Cet article Retour sur … Le déploiement de Sparnatural pour FranceArchives est apparu en premier sur Sparna Blog.

“

The Sparnatural knowledge graph explorer leverages SHACL specifications to drive a user interface (UI) that allows end users to easily discover the content of an RDF graph. What is the best way to make this UI-oriented SHACL specification ? if a SHACL specification for the knowledge graph structure already exists, can it be used directly ? does it require customization ? or is the Sparnatural SHACL spec completely decoupled from an existing knowledge graph spec ? and what if no SHACL spec exists at all ?

We faced all these different situations while deploying Sparnatural, and used various approaches to produce a satisfying end-user oriented specification. In particular, the Nakala repository is one of the latest graph for which Sparnatural was deployed. Nakala is a data repository that aims to preserve and disseminate data produced by French research projects in the Humanities and Social Sciences, in compliance with the FAIR principles. Nakala is a service offered by Huma-Num, a research infrastructure dedicated to the digital humanities. The Nakala knowledge graph contains `dcterms` metadata provided by researchers to describe the resources they upload. Additional non-dcterms metadata can also be provided. The metadata varies in quality and quantity depending on the researcher. When exposed in a SPARQL endpoint, resources, collections of resources and agents are described using the Europeana Data Model (EDM).

As the EDM dissemination channel for Nakala was new, no SHACL specification existed for it. We could have designed one for Sparnatural from scratch, but the choice was make to generate it automatically, with no human intervention. This was for three reasons : ease of configuration, flexibility in maintenance over time, and pedagogical reason, as it was important to explain the structure of the graph to target users.

Sparnatural UI

Let’s first have a look at what the Sparnatural UI looks like on an example from Nakala:

Once you know that « ProvidedCHO » stands for « Provided Cultural Heritage Object », and that « asWKT » encodes the location of a Place, you will be able to understand that the query searches for all ProvidedCHO entries gathered into a certain collection (« Cartes Université Bordeaux Montaigne » – a collection of maps), and selects their location and an optional description (and yes, the results of this query are displayed on a map, but that’s out of scope).

SHACL is derived automatically

In this project we wanted the shortest path from the graph to the query UI. Hence we used a SHACL generation algorithm, available in SHACL Play. By issuing SPARQL queries on an RDF graph, the algorithm determines the NodeShapes (targeting the classes used as values of `rdf:type`), and PropertyShapes (from all predicates used on instances on each class) of the model, with their node kinds, datatypes, class range, and cardinalities. It generates `sh:or` constraints when multiple datatypes or ranges are found. Note that in the case of Nakala a large variety of ranges are used, since the data comes from very open user inputs : the same `dcterms` property can be either an IRI or a Literal, with varying datatypes.

In addition, the algorithm computes some statistics on the dataset : the number of targets of each NodeShapes, the number of occurrences and the number of distinct values for each property shapes. The statistics are expressed using the `void` vocabulary, and `dcterms:conformsTo` is used to link void partitions to the corresponding shapes.

The SHACL Play documentation tool was then used to generate a report of the generated SHACL combined with the statistics. A few errors were spotted in the exported data, and fixed. We also saw that around 70 properties were present only a few times out of 700.000+ ProvidedCHO records. These properties were applied by probably a single or very few researchers when describing their data. It was decided to filter them out to keep the final UI simple, with an extra filtering step : based on statistics, property shapes used less than 0.1% of the number of targets of their node shapes are removed.

Here is a screenshot of the report : the right column shows the number of distinct values, and the column before is the number of total occurrences; we can immediately see that `dct:isReplacedBy` occurs only once, and `dct:isRequiredBy` occurs 81 times. They will be filtered out.

Sparnatural reads SHACL

Sparnatural can then read the SPARQL specification, together with the dataset statistics. When designing a query, value selection widgets for literal properties are determined by looking at the `sh:datatype` constraint (for number, dates, boolean, or map widgets). For IRI properties, statistics are used to distinguish between list and autocomplete widgets. Predicates with less than 500 distinct values will use a dropdown list, and those with more will use an autocomplete search field. The range is determined by reading `sh:class` or `sh:node`. The label to show in dropdown lists or to search on autocomplete field is determined by looking at a `dash:propertyRole = dash:LabelRole` annotation.

How about labels ? Sparnatural can read them from classes and properties of the original OWL file, if provided with it. Otherwise local names of target classes or predicates are used.

Other configuration techniques

Other Sparnatural deployments, such as the DBPedia demo are designed in SHACL from scratch, using spreadsheets. This requires more manual work, but has the advantage of tailoring the UI to exactly what needs to be shown, including user-oriented labels/tooltips/icons, hiding some properties, taking shortcuts or declaring inverses using property paths, etc. In the case of DBPedia, no SHACL spec exists, and deriving it automatically for the entire graph would probably not make a lot of sense, hence the necessity for a manual design.

For other projects we are working on a third configuration technique : a SHACL spec that describes the exact content of the graph is first built. It is used to publish the documentation of the model and to validate the data. A separate shapes file containing a Sparnatural-specific configuration layer is then added on top of it. That layer can hide shapes by applying an `sh:deactivated` annotation on them, can specify the UI widgets to use, add additional `dash:LabelRole` flags, add shortcut or inverse properties, etc.

The 3 configuration paths are shown in the following diagram:

Your query UI in minutes

We combined 4 tools (all open-source) : an algorithm to generate a « profile » in SHACL of an RDF dataset, a statistical report generator, a SHACL filter based on statistics, and the Sparnatural query UI. The ability to generate the SHACL profile and review it in the report provided a way to understand the structure of the data in a matter of minutes, while hours would have been necessary with SPARQL queries, without a guarantee of completeness. The provision of the query UI was made by dropping the SHACL file and the statistics to Sparnatural, without manual intervention. This shows the pivotal role of SHACL for data quality and model-driven approaches for knowledge graphs projects.

”

We look forward to reading Veronika’s book, and you ?

Cet article Nakala : from an RDF dataset to a query UI in minutes – SHACL automated generation and Sparnatural 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.

To inaugurate my first article on Sparna’s blog, let’s share a little feedback of mine today about Sparna’s well-known SKOSPlay! whose 10 years’ birthday is to celebrate this year !

10 yo, quite a historic tool ! but more than ever actual in a context where the semantic technologies get front of the scene anew due to growing interest shown by the digital humanities movement to data interoperability projects via the standardized knowledge structuration (Wikipedia-Wikidata projects e.g., as semantic wiki devices), and also due to the last progress of artificial intelligence, now able to processing large amount of data and soon fully leveraging the potential of ontologies and knowledge graphs.

From asking for a taxonomy to querying RDF files with an API…

This said, in a more practical way, semantic web standards are not always easy to manipulate as a professional – if non-initiate to SPARQL and nor confirmed data scientist, and even when you have got to deal with a simple structured list of terms !

Either your data is already SKOS-standardized (great !), there sometimes come to have a gap between normalization step and visualization step that requires a bit more technical IT skills. Either – most of time – the common muggle-born is to start with a plain Excel spreadsheet, create a list, add some hierarchy, maybe other scope notes or definitions and… end far puzzled wondering how to get a 5-star data vocabulary ⭐ !

A SKOSPlay!-within-a-SKOSPlay!

Wink to @belett, anything possible now with SKOSPlay!

Aiming at visualizing (and printing !) SKOS thesauri, taxonomies and vocabularies at the very beginning, SKOSPlay! is a full online free and open source tool leveraging semantic technologies (RDF, SPARQL, inference, Linked Data) to generate downloadable HTML or PDF documents. More and more new features have been added since then : alignments display, OWL and SKOS-XL files processing, autocomplete fields and permuted indexes generating …

Hello @veronikaheim, maybe SKOSPlay! could match your need ?

… among other nice and useful developments.

But as an Excel aficionada, the one that I prefer is the Excel-to-RDF converter tool.

One sheet. One import. One result. Easy-peasy, happy terminologist :))

(And you can even keep your custom colors templates and formats !!! 🦄 )

Come on & let’s SKOSPlay!

Let’s figure out you want to display or construct a small vocabulary you could quickly visualize in a standardized SKOS-structured way :

Now to fit in the SKOS model your data has to follow a particular template you can fullfill by downloading on SKOSPlay! website.

First you have to define the header of the template : the global scheme of your vocabulary, its URI, title and description :

Adding the terms of your list (with the URIs)… Here with the “@en” language indication on top of the column as I am to create an English-French multilingual vocabulary :

Recreating the arborescent structure through the Excel template (don’t mind my color palette, I always like colouring my Excel sheets to better visualize the info at a glance !).

The hierarchical broader-narrower structure is to be recreated by adding a “skos:narrower” column (or skos:broader, as you want, with only 1 broader value per line) where you will list the different specific values front of the more generic one (separated by comas). Here I used a PREFIX too in order to shorten my http:// URIs, SKOSPlay! can process them anyway !

Then adding a few notes and other information (multilingual values, skos:notation, any other default properties known in the converter (see the documentation) or different custom elements of yours by adding other PREFIXes :

Your Excel template is ready to go ! quite an easy configuration in my demo here, but SKOSPlay! can also deal with skos:Collections, SKOS-XL and other advanced RDF structures : blank nodes, RDF lists, named graphs. And now possible to generate OWL and SHACL files with the converter too !

Now it’s time to turn your (finally-not-so-dirty-) data into a SKOS-charming file. Take your favorite magic wand SKOSPlay! Excel-to-RDF converter tool and load your Excel file in it (adding some optional parameters if needed).

Well done, it’s a wonderful RDF-ized vocabulary file (here in a Turtle format but you have also RDF/XML, N-Triples, N-Quads, N3 and TriG available) :

Wingardium Visualiza !

We’re almost done. Go back to the website, tab “Play!”, load your last RDF-serialized file and go to the next step to chose the kind of display you want to get, endly press (SKOS)Play! and … abracadataaaaaaa !

Many different options to visualize your arborescent data. Tree, static and dynamic, but also more « professional » and printable sorts of displays like alphabetical, hierarchical or permuted views :

And KWIC (as for « KeyWord In Context ») :

Even possible to load an online Google spreadsheet (mine is shared here), just by adapting a little its URL for the converter’s need. Interesting feature in a collaborative purpose when you are team-building a vocabulary !

The whole pack fully documented and findable on Sparna’s website & Git. Some recent users even produced a short video tutorial to show what they managed to do with different SKOSPlay! visualization tools.

Already knew about SKOSPlay! ? go see his little brother, SHACLPlay! and feel free to give us some feedback in the comments 

Happy Birthday SKOSPlay! & Long live Semantic Web !

A bit more Vouvray with your nougat de Tours ?

Cet article 2013-2023 : ‘Tis SKOSPlay!’s Birthday ! est apparu en premier sur Sparna Blog.

Les sources de l’ontologie RiC-O sont dans Github à https://github.com/ICA-EGAD/RiC-O.

4 entités au coeur de RiC-CM

RiC-CM défini 4 entités « noyaux » du modèle conceptuel : la Record Resource, ses Instantiations, des Agents et des Activités. La RecordResource est une description intellectuelle qui peut avoir plusieurs matérialités (typiquement document original vs. numérisation), ses Instantiations. Une « Record Resource » peut se préciser soit en Record Set (ensemble de notices), en Record (notice seule) ou en Record Part (partie de notice), la frontière entre ces 3 notions n’étant pas toujours facile.

Sous la notion générique d’Agent, RiC-CM déclare les 3 types d’agents archivistiques classiques Person, Family et Corporate Body, mais introduit également comme des Agents les « Positions » (Fonctions dans un organigramme) et les « Mechanisms » (typiquement les logiciels), qui peuvent donc être utilisés dans une relation de Provenance.

Ces 4 entités « noyaux » sont complétées par la notion de Rule (règle, loi, normes, « contexts that establish the conditions for the performance of the activities ») et les entités classiques de Date et Place.

Le modèle conceptuel RiC-CM défini un ensemble de 78 relations majoritairement entre les 4 entités noyaux du modèle, et c’est là que la notion de Contextes (au pluriel) prends tout son sens :

1. Relations Partitives tout/partie : Record has consituent Record Part, Event has subevent Event, Group has subdivision Group, etc…
2. Relations Séquentielles avant/après : Record is original of Record, Instantiation has derived instantiation Instantiation, Agent is antecedent of Agent, etc..
3. Relations de Sujet : Record Resource has subject Thing ou Record Resource describes Thing, etc.
4. Relations inter-Record Resource : Record Resource has copy Record Resource, Record Set includes Record, etc.
5. Relations de Record Resource à Instantiation : Record Resource has instantiation Instantiation, etc.
6. Relations de Provenance (Record Resource à Agent) : Record Resource created by Agent, etc.
7. Relations inter-Instantiations, typiquement Instantiation has derived instantiation Instantiation (cas de la copie numérique d’un orginal), etc.
8. Relations de Management : Group or Person or Position is owner of Thing, Agent controls Agent, etc.
9. Relations inter-Agent : Person is leader of Group, Person has child Person, Person occupies Position, Person knows Person, etc.
10. Relations des Events/Activities, typiquement Activity performed by Agent
11. Relations des Rules : Rule regulates Thing, Mandate authorizes Agent, etc.
12. Relations de Datation
13. Relations Spatiales

Ce diagramme (tiré de cette présentation de RiC-CM aux Archives Nationales et du code source de RiC-O dans Github) donne l’aperçu haut-niveau de RiC-CM et des relations qui articulent les entités de haut-niveau du modèle :

Diagramme haut-niveau du Modèle Conceptuel Records in Contexts 0.2

RiC dans la famille des modèles conceptuels

RiC s’inscrit dans la famille des modèles conceptuels développés depuis 3 décennies dans le domaine de l’infodoc : FRBR en 1992-1995 pour les notices bibliographiques des bibliothèques, puis le CIDOC-CRM à partir de 1996 pour la description des objets muséaux et patrimoniaux en général, puis l’intégration de FRBR dans le CIDOC-CRM, à partir de 2003, qui donnera naissance à FRBRoo en 2008. Et plus récemment, en 2017, IFLA-LRM qui consolide les modèles de la famille FRBR.

On notera la temporalité longue pour l’élaboration de ces standards internationaux : réunions internationales, disponibilité des participants, nécessaires discussions longues sur l’identification des concepts fondamentaux du métier. On notera aussi le retard de la communauté des archives, avec le début du groupe EGAD en 2012 et la version 0.1 de RiC-CM publiée en 2016, sur cette réflexion au niveau conceptuel, par rapport aux bibliothèques et aux musées. Cela peut s’expliquer par la présence d’un standard technique unique et utilisé mondialement, l’EAD, et par des moyens plus réduits dans la communauté archivistique.

La communauté du CIDOC-CRM s’est empressé de dénoncer la « secte des archivistes » qui réinventent leur propre modèle conceptuel plutôt que de s’appuyer sur les fondations théoriques du CIDOC-CRM. Mais cette phase de réflexion où sont réexaminés l’existence, le périmètre, la pertinence et l’articulation de de chaque concept métier est bien nécessaire à une communauté de pratique avant que celle-ci ne puisse proposer un éventuel accostage avec le point de vue – certes générique et théoriquement fondé, mais issu d’une autre communauté de pratiques – du CIDOC-CRM. Le document « Toward an International Conceptual Model for Archival Description… » mentionné plus haut mentionne déjà cela :

« Avant de collaborer, la communauté archivistique doit développer un modèle conceptuel qui réponde d’abord et avant tout aux principes et aux besoins des archivistes. Une fois ce modèle élaboré, la communauté sera bien placée pour se joindre aux communautés professionnelles apparentées dans une quête commune pour fournir un accès intégré à l’expression humaine sous toutes ses formes. »

Quelques années de patience, donc, avant une intégration RiC-CM / CIDOC-CRM  (RiCoo ? )

Ricoconverter : Un convertisseur EAD et EAC vers RiC-O, par les Archives Nationales

Florence Clavaud, responsable de la mission Référentiels aux Archives Nationales, a largement développé l’ontologie RiC-O au sein du groupe EGAD. Sous son impulsion avait déjà été développé en 2017-2018 le prototype PIAFF (Pilote d’interopérabilité pour les Autorités Archivistiques françaises), incluant 276 notices d’autorités des AN, de la BNF et du SIAFF, converties dans la première version de RiC-CM et RiC-O qui datait de 2016.

Les Archives Nationales ont souhaité un passage à l’échelle après le succès de PIAFF, pour la conversion de l’intégralité des 28000 instruments de recherche et 15000 notices d’autorité des Archives Nationales, dans la version la plus récente de RiC-O. Le travail a été confié à votre serviteur. Le résultat est ricoconverter, un logiciel opensource, permettant de lancer simplement en ligne de commande une conversion d’un ensemble de fichiers EAD ou EAC vers du RDF/XML structuré en RiC-O. Ricoconverter est essentiellement basé sur 2 feuilles de style XSLT qui font l’essentiel du travail, enrobées dans un script Java. La feuille de style convertissant l’EAC est assez générique et transposable dans d’autres contextes probablement assez directement, la feuille de style EAD répond à l’implémentation spécifique de l’EAD aux AN et demandera plus d’adaptions; mais l’objectif de Ricoconverter est bel et bien de pouvoir être adapté et utilisé pas d’autres services d’archives pour produire des graphes de données RiC-O.

Les sources de ricoconverter sont disponibles dans Github à https://github.com/ArchivesNationalesFR/rico-converter.

Cerise sur le gâteau, quand on a un joli graphe RiC-O, on peut avoir un joli Sparnatural (voir ce billet de blog) qui permet de naviguer dans le graphe et de chercher par exemple « toutes les archives numérisées des organisations ayant succédé à la Direction des Beaux Arts (1848-1852) » (cliquer sur l’image pour voir le screencast) :

Présentations de RiC-CM et RiC-O aux Archives Nationales le 28/01/2020

Pour aller plus loin on peut consulter les présentations sur RiC-CM, RiC-O, ricoconverter et plus encore faites lors de la journée d’étude du 28 janvier 2020 aux Archives Nationales.

Illustration : Institut, [salle des] archives : [photographie de presse] / [Agence Rol] Agence Rol. Agence photographique depuis Gallica.

Cet article RiC-CM, RiC-O : les Archives se dotent de leur modèle conceptuel (Records in Contexts) est apparu en premier sur Sparna Blog.

Le CIDOC-CRM est une ontologie formelle de haut-niveau permettant de structurer la description et l’histoire d’objets patrimoniaux (tableaux, sculptures, bâtiments, fouilles archéologiques, etc.) – ou d’autres informations similaires. L’objectif de ce modèle est de permettre l’intégration de données provenant de sources hétérogènes dans un graphe commun, cohérent, à l’échelle d’une institution ou au-delà, permettant ainsi l’accès et l’interprétation scientifique de ces informations.
Le périmètre du CRM, tel qu’il est défini, est « toutes les informations requises pour l’échange et l’intégration de données scientifiques à propos du passé humain et de toutes les preuves de ce passé arrivées jusqu’à nous ». Etant fait pour la description structurée de l’histoire d’objets patrimoniaux, le CRM utilise a plein une modélisation évènementielle; c’est-à-dire que fondamentalement, on ne dit pas « Le tableau Le Désespéré a pour date de création : [entre 1843 et 1845] », mais « Entre 1843 et 1845, Gustave Courbet a conduit une Activité de Création dont l’objet était le tableau Le désespéré« ; nuance. D’ailleurs, si j’en crois la notice Wikipedia, on ne dit pas non plus « ce tableau a pour titre Le Désespéré« ; on dit « Gustave Courbet a effectué une activité de nommage de ce tableau qu’il a baptisé Désespoir« , puis « Quelqu’un d’autre (qui ?) a (probablement) effectué une autre activité de nommage (quand ?) et a baptisé le même tableau Le Désespéré« .

Ce qui fait la force du CIDOC-CRM…

Le CIDOC-CRM est un modèle issu de plus de vingt ans de standardisation au sein du Comité International pour la Documentation (CIDOC) du Conseil International des Musées. Autant dire qu’il est le résultat d’une sédimentation de longues réflexions, ce qui rend ses fondations théoriques extrêmement solides. Le CRM a fait l’objet de 2 versions d’un standard ISO, ISO21127:2004 et ISO21127:2014. Il donne donc un cadre de modélisation rigoureux, mais avec une logique qu’il faut s’approprier.

Son paradigme de modélisation événementielle est très puissant et permet d’exprimer de nombreuses informations de façon très flexible. Les Evènements (ou plutôt, les Activités) sont les objets centraux que l’on décrit à l’aide du CIDOC-CRM : des Acteurs participent à des Evenements, qui se produisent dans un Lieu donné, une Temporalité donnée, et affectent des Objets donnés; tout cela pouvant être nommé avec des Appellations et typer avec des Types. Voilà, en une phrase, vous savez tout !

Le CIDOC-CRM est un modèle générique avec un fort niveau d’abstraction, et il ne descend volontairement pas dans le détail de spécifications de certains domaines métier particulier; c’est pourquoi il a fait l’objet d’extensions pour des domaines spécifiques. Dans le monde de l’infodoc on citera en particulier FRBRoo, l’intégration des principes du FRBR dans le cadre de la modélisation orientée objet du CIDOC-CRM, ou bien PRESSoo, lui-même une extension de FRBRoo pour la carctérisation des publication en série; dans d’autres domaines, on peut citer CRMarchaeo, une extension pour la description des données archéologiques, une communauté active autour du CIDOC-CRM.

…Et ce qui le rend compliqué

Ce n’est pas la taille de ce modèle qui le rend compliqué. Le CIDOC-CRM contient 84 classes et 154 propriétés (288 si on compte aussi les inverses) (chiffre approximatif). C’est peu, si l’on compare aux 602 classes et 877 propriétés de schema.org, et cela en fait une ontologie de taille moyenne.

Franchement, la chose qui le rend le plus compliqué, c’est peut-être sa documentation. Un sympathique fichier PDF de 115 pages (tiens, une nouvelle version sort aujourd’hui 26 mars 2019, un hasard), ça c’est sûr, c’est de la spécification formelle ! de bon vieux tableaux de propriétés à la schema.org pourraient être les bienvenus. MAIS MAIS mais, pour vous aider à vous plonger dans le CIDOC, voici une petite visualisation de l’arborescence des classes du modèle et de FRBRoo, construite à partir de SKOS-Play :

Par ailleurs, les diagrammes fournis pour les uses-cases, assez utiles, utilisent un formalisme auquel on n’est pas habitué dans la modélisation d’ontologies classiques. Pour d’autres documents d’introduction on pourra consulter avec profit la présentation du CRM et de FRBRoo sur le site de Doremus.

Un des autres aspects qui le rend compliqué c’est son fort niveau d’abstraction. Le CRM définit en effet des notions comme « Persistent Item », « Man-Made Thing », « Propositional Object »… pas évident de s’approprier la définition de ces notions. Ajoutez à cela que tous les identifiants du CRM commencent par un code : « E5_Event », « E70_Thing », « P94_has_created », et la lecture devient compliquée. Cette identification, rebutante au premier abord, n’est finalement pas pire qu’une autre, d’autant que les noms des propriétés et des classes sont associés à des définitions très précises, et on fini par connaître par coeur les plus importants (E55_Type, P14_carried_out_by…).

Par ailleurs le CRM est formellement défini dans le PDF de référence sus-mentionné, et il n’existe pas d’implémentations de référence du modèle en OWL. Les implémentations OWL fournies sur le site sont explictement non-officielles, et de toutes façons pas à jour. L’implémentation OWL la plus à jour (mais qui date tout de même d’il y a 2 ans, et de 3 versions du modèle) semble être celle d’Erlangen-CRM. Ce n’est donc pas forcément immédiat d’intégrer ce modèle dans une application basée sur les technologies du web de données.

Les projets qui utilisent le CIDOC-CRM

Mais qui qui qui (sont les snorkis) se sert du CIDOC-CRM ? L’implémentation la plus impressionnante est celle du British Museum, notamment au travers de l’interface ResearchSpace. Vous aimez les spaghettis ? voici la formalisation des données du catalogue du BM en CIDOC-CRM :

Vous voulez expérimenter avec les données CIDOC-CRM du BM ? je vous propose un tutorial d’interrogation des données du British Museum en SPARQL.

Aux Etats-Unis, le Yale Center for British Art publie également des données dans le CIDOC-CRM, mais semble-t-il assez light.

Le projet Doremus a créé une extension de FRBRoo / CIDOC-CRM pour la musique classique (composition, concerts), documentée ici.

Je travaille en ce moment sur une première version de la plateforme OpenArchaeo pour l’intégration de données de fouilles archéologiques, alignées sur le CIDOC-CRM à partir de base relationnelles (base ARSOL) et de fichiers XML (base AERBA).

Par ailleurs, dans le cadre de ELI (European Legislation Identifier), j’ai spécifié l’extension du modèle ELI pour la description des étapes et des documents lors de l’élaboration des projets de lois : ELI-DL (pour « draft legislation »); c’est un bon cas pour l’utilisation du CIDOC-CRM et de FRBRoo, puisque l’élaboration d’une loi est vue comme une séquence d’Activités utilisant ou produisant des documents, jusqu’à la publication finale de la loi au JO. C’est également un bon scenario d’utilisation du CIDOC-CRM comme cadre méthodologique, tout en utilisant uniquement des propriétés métier pour masquer les notions trop abstraites du CRM.

On peut également supposer que l’Institut National d’Histoire de l’Art (INHA) s’intéresse à ce genre de sujet. Le laboratoire LARHRA, laboratoire de recherche historique à Lyon, s’y intéresse également dans le cadre du projet SYMOGIH, pour lequel un autre modèle de données avait été initialement mis au point.

Les outils pour convertir

Le CIDOC-CRM étant un modèle fait pour l’intégration de données, le labo de FORTH, en Crète, qui abrite les cerveaux du CRM, a mis au point un language et un outil de mapping, X3ML, permettant de mapper et convertir des fichiers XML vers le modèle CIDOC-CRM. Pour convertir les données de bases relationnelles, on peut utiliser –Ontop–.

Alors, près à vous frotter au CIDOC-CRM ? avec toutes ces infos au moins, vous ne vous arracherez pas les cheveux !

Cet article Le CIDOC-CRM, ne nous arrachons plus les cheveux ! est apparu en premier sur Sparna Blog.

La vie des standards est parfois un peu difficile à comprendre, et c’est particulièrement vrai pour ce qui concerne le web de données. Pourquoi en effet existe-t-il depuis 2004 un standard – OWL – permettant de faire des raisonnements automatiques sur des données, ce dont on a rarement besoin, alors qu’il n’existe aucun standard W3C pour vérifier si des données sont conformes, ce dont on a toujours besoin ? la réponse est sans doute dans les besoins et les problématiques des participants au W3C à l’époque, et dans la vision d’un web « sémantique » qui penchait plus vers un idéal d’Intelligence Artificielle que vers un idéal de Données Liées. Seulement on a vite compris que pour faire du raisonnement il faut avoir des données correctes.

Une nouvelle recommandation W3C prévue pour juin 2017, SHACL (SHapes Constraint Language), va remédier à ce manque en permettant d’exprimer des contraintes de vérification sur un graphe RDF.

Le problème avec OWL

Je participe à beaucoup de projets qui impliquent des transformations et des publications de données RDF ou SKOS sur le web. Et c’est bel et bien d’abord des problématiques de validation et de vérification de données que nous avons, et pratiquement jamais des besoins de raisonnements. Or une ontologie n’est pas faite pour vérifier la conformité des données à une spécification, ni faite pour décrire la structure d’un formulaire de saisie de données répondant à ces spécifications.

Ce que nous faisons donc systématiquement est donc de quand même créer une ontologie, mais de « tordre » l’interprétation de cette ontologie en l’utilisant pour vérifier des contraintes. Par exemple le fait d’exprimer que la propriété « a_pour_auteur » a pour « domaine » la classe « Document » en OWL/RDFS veut dire « si X porte la propriété a_pour_auteur, alors c’est un Document », et certainement pas « la propriété a_pour_auteur ne devrait être exprimée que sur des Document »; mais c’est pourtant comme cela que l’ontologie créée est utilisée dans ce contexte (en dérivant par exemple des règles de vérification SPARQL à partir des axiomes OWL).

SHACL

SHACL permettra de spécifier la « forme » (Shape) à laquelle on souhaite qu’un graphe RDF réponde. Cette spécification s’exprime par exemple comme cela (Attention, cet exemple est extrait de la version temporaire de SHACL au 02/01/2017 et peut changer dans la recommendation finale) :

ex:PersonShape
	a sh:Shape ;
        # Applies to all persons
	sh:targetClass ex:Person ;
	sh:property [
                # Constrains the values of the ex:ssn property
		sh:predicate ex:ssn ;     
		sh:maxCount 1 ;
		sh:datatype xsd:string ;
		sh:pattern "^\\d{3}-\\d{2}-\\d{4}$" ;
	] ;
	sh:property [
		sh:predicate ex:child ;
		sh:class ex:Person ;
		sh:nodeKind sh:IRI ;
	] ;
	sh:property [
		rdfs:comment "A person's parents are represented via ex:child used in the inverse direction." ;
		sh:path [ sh:inversePath ex:child ] ;
		sh:name "parent" ;
		sh:maxCount 2 ;
	] .

Comment décoder cet exemple ? « Sur les ex:Person, il faut que la propriété ex:ssn (numéro de sécu) soit présente au maximum une fois, et qu’elle soit une chaine de caractère qui réponde à une certaine expression régulière. Il faut également que la propriété ex:child soit une référence à des IRI/URI qui soit une autre ex:Person. Il faut également qu’une ex:Person soit référencée au maximum 2 fois par ex:child ». Et ainsi de suite.

La version publique de SHACL est publiée à https://www.w3.org/TR/shacl/ mais je vous recommande d’ici juin de vous référer au document en cours d’écriture à https://w3c.github.io/data-shapes/shacl/.

Validateurs SHACL

De la même façon que des ontologies OWL peuvent être interprétées par des raisonneurs OWL, les contraintes SHACL seront vérifiées par des vérificateurs SHACL. L’implémentation la plus avancée est sans doute celle de TopQuadrant (les éditeurs principaux de la recommendations SHACL) qui a publié en open-source l’implémentation de SHACL utilisé dans TopBraid.

Europeana a également annoncé un ensemble de règles SHACL pour vérifier les données EDM (Europeana Data Model), ainsi qu’une implémentation d’un validateur SHACL.

Il faut également noter que, si SHACL permet de valider des données a posteriori, la recommandation inclut également ce qu’il faut pour utiliser les règles pour créer des formulaires de saisie (ordre des propriétés, libellés/regroupement des zones, etc.), ce qui permettra donc de spécifier la structure de formulaires de données sémantiques.

Une technologie importante pour la publication et l’intégration de données

SHACL va modifier profondément la façon dont on mène les projets web de données. Plutôt que de définir une ontologie forcément un peu bancale ou limitée (car pas utilisée pour son objectif principal qui est de donner un point de vue sur des données), on commencera par définir un jeu de contraintes SHACL que l’on souhaite vérifier sur les données. Tous les projets d’échange et d’intégration de données vont pouvoir tirer parti de cette nouvelle brique.

Cela assainira également le discours autour du web de données : il ne sera plus obligatoire de passer par une étape où l’on doit expliquer ce qu’est une ontologie ! Bref, je vois SHACL comme un composant important dans l’ensemble d’outils dont nous disposons pour partager et lier des données de qualité sur le web. Et vous, pensez-vous que SHACL vous sera utile ?

Illustration de l’article : By Deutsche Fotothek, Public Domain, https://commons.wikimedia.org/w/index.php?curid=6483869

Cet article SHACL (RDF Shapes Constraint Language) : enfin la possibilité de valider des données RDF est apparu en premier sur Sparna Blog.

Le web de données, de « l’information en réseau »

Le web de données (on préférera ce terme à celui plus ambigu de web sémantique), ce n’est pas compliqué ; ça marche et c’est utile, en particulier pour les bibliothèques.

Retour aux racines du web

Le web n’a pas été conçu pour n’être qu’un paquet de documents mis en lien. Il intègre, dès sa conception en 1989 par Tim Berners Lee¹, plus de sémantique que l’utilisation qui en sera faite ensuite. En particulier par la dualité Identifiant/Représentation :

• Identifiant : ce qui commence par « http://… » et que l’on voit dans la barre d’adresse de notre navigateur est une URL, où le « L » est mis pour « Locator ». C’est donc l’adresse d’un document sur le web; mais ce n’est qu’un cas particulier des URIs, où le « I » est mis pour « Identifier« , qui sont des identifiants, dans le contexte du web, de choses du monde réel. On comprend donc qu’on peut identifier sur le web n’importe quoi à l’aide d’une URI : Victor Hugo, les pizzas margherita, le terme de thésaurus « gouvernance », la Loire, la caractéristique « se situe à », etc. On parle d’une façon générale de ressources.

• Représentation : si une URI est l’identifiant d’une « ressource », alors quel « document » obtiendra-t-on en naviguant vers cette URI ? On a l’habitude d’obtenir pour une même adresse toujours le même document, mais d’une façon générale un identifiant peut être associé à plusieurs représentations qui varient – de façon transparente – en fonction de préférences de langue, de format, de lieu, etc. C’est ce qu’on appelle la négociation de contenu.

Cette capacité des URIs d’identifier absolument n’importe quoi, indépendamment d’une représentation particulière, est la clé de voûte de l’universalité du web (de données).

Une fois les « choses » identifiées et rendues indépendantes des documents qui les représentent, il devient possible de parler de ces choses : je peux publier sur le web l’assertion que « La Tour Eiffel se situe à Paris », en utilisant 3 URIs pour identifier les 3 composantes de cette assertion : La Tour Eiffel, la notion de « se situer à », et Paris. C’est le standard RDF (Resource Description Framework) qui permet d’employer ces assertions en triplets. Notons au passage que, le web étant par nature décentralisé, n’importe qui est libre :

• de créer une nouvelle URI pour identifier Paris ;

• ou de créer une assertion en se référant à une URI déjà existante pour Paris (par exemple celle définie par l’Insee²) ;

• ou encore d’exprimer des liens d’équivalence entre identifiants : l’URI que je définis pour Paris représente la même « chose » que celle définie par l’Insee.

On voit donc se dessiner ce qui nous occupe : un réseau décentralisé de données liées par des triplets.

Mais il faut aller plus loin pour que l’interopérabilité soit complète – puisque le web de données n’est qu’une solution à la problématique de l’interopérabilité. En effet, pour qu’une autre application puisse décoder mon assertion, il faut que je donne une définition précise des identifiants que j’ai utilisés, qui sont sans doute différents de ceux que comprend cette application. En particulier, il faut que je donne une définition précise de mes « verbes » (« est situé à ») et mes « types » (« Lieu », « Personne », etc.). C’est ce que permettent les ontologies, dont l’objectif est de donner un sens univoque à ce dont je parle, à l’aide de la logique formelle (on parle également de vocabulaire ou de modèle de données, un peu par abus de langage). Les ontologies permettent également de déclarer des équivalences entre verbes ou entre types, rendant ainsi interopérables des données hétérogènes. Par exemple, je peux dire que, dans mon contexte « est situé à  » relie quelque chose à un « Lieu » et que cela représente la même notion que l’identifiant « basedNear » défini dans une autre ontologie bien connue, FOAF³.

Les ontologies font donc émerger de cet océan de liens des structures interopérables, rendant ainsi les données liées plus « sémantiques », c’est-à-dire plus facilement réutilisables.

Quels enjeux et quelles conséquences ?

Souvenons-nous des fausses promesses entendues au milieu des années 2000 à propos du web de données : les machines allaient bientôt comprendre « le sens » des textes, on nous parlait de web 3.0, de « Twine » (un site qui n’existe plus maintenant mais qui promettait la révolution des réseaux sociaux), on cherchait quelle serait la « killer-app » – une application si attrayante qu’elle aurait justifié la technologie à elle seule, etc. Rien de tout cela n’est arrivé, mais d’autres conséquences ont eu lieu.

D’abord une quantité grandissante de « données ouvertes et liées » publiées par une variété importante de producteurs de données : c’est le fameux « Linked Open Data« ⁴. Citons-en quelques points notables: DBPedia francophone (une extraction en RDF des données de Wikipedia), data.bnf.fr (notices FRBRisées – voir plus bas -, autorités et thématiques de la Bibliothèque Nationale de France), ou encore VIAF (Virtual International Authority File, une mise en commun des fichiers d’autorité d’une quarantaine de bibliothèques et de musées).

Dans cet ensemble de données, il faut en mentionner certaines ayant un statut particulier : les thésaurus. Ceux-ci peuvent être représentés et publiés dans le modèle SKOS. Ce modèle permet d’aligner les thésaurus pour permettre l’interopérabilité de catalogues documentaires utilisant des vocabulaires d’indexation différents (« Désobéissance civile » dans Rameau est ainsi rapprochée de « Civil disobedience » dans les sujets de la librairie du congrès américain⁵). Quant aux ontologies, on se référera au projet LOV – Linked Open Vocabularies⁶.

Ensuite, une appropriation de cet enjeu des données structurées et liées par les grands moteurs de recherche : c’est l’initiative schema.org⁷, qui propose un modèle de description de « plein de choses dont on parle sur le web » (blogs, livres, films, produits, etc.), compréhensible par Google, Yahoo, Bing et consorts. On peut reprocher à schema.org son biais vers le e-commerce, sa vision occidentalisée et son manque de transparence dans la gouvernance, mais si les bibliothèques souhaitent rendre leurs données plus visibles par les moteurs, cela passe par la publication de données compatibles avec schema.org.

D’une façon plus profonde, ces technologies induisent une représentation générale de l’information en graphe décentralisé, en réseau. Ce mode de structuration, de pensée, fait suite à celui plutôt tabulaire des bases relationnelles, et plutôt hiérarchique de XML. La conséquence est flagrante sur les notices bibliographiques avec le modèle FRBR. Les « Functionnal Requirement for Bibliographic Records« , successeurs de l’ISBD (« International Standard for Bibliographic Record« ) proposent en effet un éclatement de la notice en 4 niveaux conceptuels, eux-mêmes reliés aux personnes ou aux organisations impliquées dans la vie du document (auteur, contributeur, éditeur, possesseur), lesquelles sont elles-mêmes reliées entre elles ou à d’autres données du web.

Cette tendance est à rapprocher du constat que de plus en plus de systèmes informatiques de diffusion des catalogues utilisent une base de graphe RDF (« triplestore« ) pour centraliser les métadonnées des notices FRBRisées, les fiches d’autorité et les thésaurus. Cette base devient le pivot central des canaux de diffusion (sites web, flux RSS, formats d’échange métier, etc.). Les lois européennes sont notamment diffusées sur ce mode, via la base Cellar et le portail Eur-Lex⁸.

Prochaines promesses ?

Sans retomber dans les promesses hasardeuses évoquées plus haut, on peut néanmoins esquisser les lignes de force du web de données pour les prochaines années : une utilisation grandissante de schema.org par les moteurs de recherche et les projets de diffusion de données; l’intégration native des fonctions de publication/récupération de données du web dans les Content management system (CMS) et les SIGB; la publication et l’alignement de plus en plus de données – dont des thésaurus ou des données de la recherche; la généralisation de FRBR et de ses dérivés pour la description des notices bibliographiques, etc.

Au-delà des aspects technologiques, ce sont des logiques de partage, de réutilisation, de mise en réseau, de collaboration, ou d’insertion dans un écosystème d’acteurs, qui sont favorisés par cet artefact unique qu’est le web de données.

Cet article Article ArABESque – Le web de données, de « l’information en réseau » est apparu en premier sur Sparna Blog.