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.

To make it short, Sparnatural is a client-side component that allows non-expert users to explore an RDF Knowledge Graph by building SPARQL queries with little effort. 

Fully configurable – and customizable – it can be plugged to any existing SPARQL endpoint, without additional server required to adapt to your knowledge graph ontology. 

Innovative and intuitive, it aims at bringing your knowledge graph to your end-users in a visual way that « gamifies » the knowledge graph experience. 

Nb : Sparnatural is open source, under a LGPL-3.0 license.

So far, the configuration was made through an OWL ontology…

Sparnatural in SHACL ! 

… until now,

But the times they are a-changin’ …

You can now configure Sparnatural starting from a SHACL configuration spreadsheet !

SHACL in a nutshell 

Defined by a W3C Working Group, SHACL, as for « Shapes Constraint Language », is « a language for validating RDF graphs against a set of conditions. These conditions are provided as shapes and other constructs expressed in the form of an RDF graph. » 

First published in 2017, it has become a widely used standard to :

• describe structural constraints on data graphs ;
• validate that data graphs satisfy a set of conditions ;
• but also build user interface, generate code and integrate data !

The latter we will leverage for our brand new Sparnatural SHACL configuration.

Yes, in a spreadsheet !

SHACL may be quite unfamiliar for our users.

A good thing is you don’t need to be a SHACL expert to build your SHACL-shaped Sparnatural configuration.

Indeed ! the entire configuration is done via a spreadsheet whose columns correspond to the SHACL model.

Still, you can observe that all the Sparnatural features are here :

• the nodes & the edges of the knowledge graph, of course ;
• its labels and literal attributes (different kind of notes) ;
• but also the Sparnatural search widgets, icons, etc.

Give it a try ! 

Go to the DBpedia Museums demo :

Navigate the graph 

Start with picking up a class from the list and navigate through the properties to another class of the graph, search for a value…

… then click on the arrow to launch the query ▶️

Click on « Toggle SPARQL editor » below the query builder to display the corresponding SPARQL query :

… no need to say that you can create even more elaborate queries, just by adding new parameters when navigating through the knowledge graph !

Sample queries 

To give you a quick overview of it, you can also try to launch one of the sample queries we added to the demo.

On the screenshot below we can observe this one is a quite more complex query, using an optional parameter as we noticed that some values happen to be missing on DBpedia, either for Movements or Artworks…

Can we deduce that 19th-Century French women artists records are rather incomplete in English DBpedia ?

We’ll let you investigate on this point.

Multilingual 

It is also possible to translate (and display) your configuration in any language of your choice, so that you can showcase your knowledge graph in different languages – even if the graph itself does not contain labels or values with this language… 

Here translated in French :

Fully documented 

This new version of Sparnatural comes with an extensive documentation of all the features that can be used to date, from basic installation to more advanced configuration of the tool.

Get started with Hello Sparnatural !

Cet article Sparnatural : say it with SHACL ! est apparu en premier sur Sparna Blog.

1. développer une nouvelle version de Sparnatural (http://sparnatural.eu/), un éditeur open source de requêtes SPARQL (qui est le langage utilisé pour faire des recherches dans des graphes RDF) ;
2. mettre en place deux démonstrateurs web pleinement opérationnels, pour permettre l’exploration et la recherche intuitives dans des graphes de métadonnées culturelles grâce à des interfaces construites à l’aide de cet outil.

La BnF a donc construit avec Sparna un démonstrateur web pour interroger l’ensemble de ses données RDF, soit tout le contenu de data.bnf.fr. Les Archives nationales (le Lab, en concertation avec le Département du Minutier central des notaires des Paris) ont construit avec Sparna un démonstrateur web qui permet d’interroger les métadonnées décrivant un tiers des archives notariales conservées aux Archives nationales, qu’elles ont préalablement converties en RDF conformément à l’ontologie RiC-O.

Une demi-journée le 17 juin après-midi permettra de présenter en détail les travaux réalisés et les résultats obtenus, puis d’évoquer les perspectives qu’ils ouvrent pour les institutions partenaires et pour d’autres projets.

Elle aura lieu à l’auditorium des Archives nationales sur le site de Pierrefitte-sur-Seine (voir https://www.archives-nationales.culture.gouv.fr/fr/web/guest/site-de-pierrefitte-sur-seine), et sera également accessible à distance via une plateforme de visioconférence.

Le programme de la demi-journée de présentation du projet Sparnatural est désormais téléchargeable depuis l’agenda des Archives nationales (https://www.archives-nationales.culture.gouv.fr/fr/web/guest/235?sia-agenda-parameter=0010111111111) ou directement à https://www.archives-nationales.culture.gouv.fr/documents/10157/277814/Programme+Sparnatural+2022/.

La demi-journée est accessible à tous gratuitement, sur inscription. Pour vous inscrire vous pouvez, soit utiliser le formulaire disponible à https://framaforms.org/inscription-a-la-demi-journee-de-restitution-du-projet-sparnatural-17-juin-2022-1652342598), soit écrire à l’adresse  le-lab.archives-nationales@culture.gouv.fr en précisant si vous viendrez sur place ou si vous participerez à distance.

Cet article Evènement : Sparnatural et les démonstrateurs Archives Nationales + BNF est apparu en premier sur Sparna Blog.

UPDATE avril 2021 : Sparnatural a un nouveau site web a http://sparnatural.eu !

Dans la copie d’écran ci-dessus, on demande « Toutes les oeuvres exposées dans un musée Français qui expose une oeuvre du Caravage, et dont l’auteur est Italien ».

Démo de Sparnatural sur DBPedia

Le screencast ci-dessus est extrait de la démo de Sparnatural paramétrée sur DBPedia avec laquelle vous pouvez jouer en ligne.

Le développement de ce composant a été réalisé dans le cadre du projet OpenArchaeo où il est utilisé pour naviguer dans des données archéologiques. Il est autonome du projet et peut être réutilisé dans le cadre de sa license LGPL. Le code source est ouvert et il est interdit de « refermer » le code source, toute modification doit être publiée sous la même licence, et idéalement reversée dans le dépôt Github du projet.

Sparnatural s’inspire en grande partie de la navigation proposée par l’interface ResearchSpace du British Museum.

Et pourquoi c’est cool ?

• Parce que ça n’existait pas !  (en dehors de ResearchSpace, mais dont le source est en React), en tout cas pas comme un composant autonome et paramétrable
• Parce que le composant est paramétrable à souhait pour construire des requêtes sur différentes structures de graphe, en changeant le paramétrage des classes et des propriétés; vous pouvez jeter un oeil au fichier de paramétrage de la démo.
• Parce qu’il est orienté end-user et que, en particulier, la structure du graphe que l’on présente à l’utilisateur n’est pas obligatoirement – en fait n’est jamais – celle du graphe de données sous-jacent:
  • Chaque classe dans le composant peut être mappé sur un critère plus complexe (On présente à l’utilisateur « Type d’activité », qui est mappé sur « tous les skos:Concept ayant un skos:inScheme ex:ActivityType »)
  • Chaque lien dans le composant peut être mappé sur une séquence de liens RDF dans le graphe (un property path) (Le lien « Musée expose oeuvre » dans le composant de construction de query est l’inverse du lien RDF « Oeuvre dbpedia:museum Musée »). Typiquement le paramétrage de tous les liens inverses permet à un utilisateur d’explorer le graphe en le prenant par n’importe quel bout;
  • On peut limiter les types d’objets et les types de liens que l’on présente dans le composant pour ne permettre d’interroger qu’une sous-partie des données;
• Parce qu’il offre plusieurs mode de sélection des valeurs :
  • un champ d’autocompletion, à associer à une requête SPARQL (ou pas SPARQL) qui ira proposer des valeurs sur la base des caractères tapés dans le champs;
  • un champ de dropdown, pour les petites listes;
  • un champ de recherche texte;
  • un champ d’input de date (début / fin);
• Parce que la requête peut s’exécuter au fur et à mesure de la construction de l’équation de recherche; pas besoin d’appuyer sur un bouton; cela fait beaucoup pour obtenir une expérience utilisateur de découverte des données;
• Parce que c’est multilingue : on peut associer des libellés en plusieurs langue à chaque classe et chaque propriétés;
• Parce que c’est facile d’injecter des icônes fontawesome pour illustrer chaque classe dans les menus;
• Parce qu’on peut post-traiter la requête après que le composant l’a construite : ajouter la sélection de plusieurs colonnes, ajouter des préfixes, etc.
• Parce que ça peut joliment égayer la platitude morne des formulaires de requêtes SPARQL que l’on expose à des utilisateurs, en s’intégrant avec YASGUI, pour permettre une découverte intuitive des données;

Le résultat, au-delà d’un simple éditeur SPARQL, offre une vraie expérience d’exploration des données, avec des mécanismes d’essai-erreur, retour arrière, prise du graphe par un autre bout, etc.

Limites de l’exercice

L’objectif est d’offrir un moyen simple et compréhensible de naviguer dans des données. En conséquence, Sparnatural n’est capable que de construire des motifs de graphe SPARQL simple, et ne sais pas gérer les UNION, OPTIONAL, sous-select, BIND, etc.

Par ailleurs le composant s’arrête à sélectionner les URIs des objets cherchés, il n’est pas possible pour un utilisateur de choisir les colonnes présentées dans le tableau de résultats. Il faut post-traiter la requête pour injecter la sélection des valeurs de colonnes.

Si, comme pour la démo DBPedia, vous intégrez Sparnatural avec YASGui et YASR et que la page HTML envoie la requête SPARQL, faites attention que le service SPARQL doit supporter les requêtes CORS (Cross-Origin Resource Sharing), ce qui n’est pas le cas de tous les services SPARQL… mais ça devrait !

Envie d’essayer ?

Rendez-vous sur le dépôt Github de Sparnatural si vous voulez un peu plus de doc ou que vous voulez remonter un ticket, un bug, ou contribuer au code. D’autres démos devraient suivre, stay tuned !

Cet article SPARNAtural : écrire des requêtes SPARQL, tout naturellement est apparu en premier sur Sparna Blog.