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.

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.

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.

Voici un tutorial guidé d’interrogation SPARQL des données de Doremus, autour de Gabriel Fauré; ce tutorial explore la modélisation de « création » entre un compositeur et une oeuvre musicale (ou plutôt son expression au sens FRBR). Il montre comment :

• Trouver un compositeur dans le navigateur Overture de Doremus, le navigateur à facette et le service SPARQL;
• Naviguer dans ses activités de création, vers ses oeuvres et leurs expressions, et récupérer les dates de création des oeuvres; le tout en illustrant les opérateurs SPARQL de property path, aggrégation, COUNT, assignation, etc;
• Générer une timeline des compositeurs classiques de façon semi-automatique en utilisant le service timelinejs :

CIDOC-CRM + SPARQL Tutorial sur les données Doremus

Introduction aux requêtes SPARQL sur les données du projet Doremus (http://data.doremus.org) qui modélise et diffuse les données de création d’oeuvres musicale…

Pour réutiliser ce document dans un cadre non-commercial vous pouvez me contacter.

Dans la même veine, vous pouvez consulter le tutorial SPARQL sur les données data.bnf.fr.

Image du post : Carte postale éditée en 1900 lors de la représentation de l’opéra Prométhée de Gabriel Fauré au Théâtre des Arènes, à Béziers. Sur Wikimedia Commons.

Cet article SPARQL sur DOREMUS : une balade autour de Gabriel Fauré est apparu en premier sur Sparna Blog.

ReNom propose une façon étonnante et ludique de parcourir des œuvres littéraires, en l’occurrence celles des auteurs emblématiques de la région : Pierre de Ronsard et François Rabelais. Le site invite à la lecture (entre autres) de Gargantua et Pantagruel en « rentrant dans l’oeuvre » selon de multiples axes; soit en feuilletant le livre de façon classique, mais aussi en sélectionnant sur une carte un lieux cité dans l’oeuvre, puis en rebondissant vers la/les pages qui citent ce lieu; ou en recherchant un personnage de, puis en accédant à tous les passages qui le citent.

Lorsqu’on feuillette le livre, les personnages et les lieux mentionnés dans le texte sont mis en surbrillance, et les lieux présentés sur une carte en regard de la page. Un clic, et on rebondit à la fiche du personnage ou du lieu en question.

Le projet est développé à Tours dans le Centre d’Etude Supérieure de la Renaissance (CESR) par l’équipe des Bibliothèques Virtuelles Humanistes (BVH), spécialisée dans l’édition électronique d’œuvres de la renaissance, en collaboration avec le Laboratoire d’Informatique de Tours pour la reconnaissance des entités nommées. On sait que Rabelais s’est beaucoup inspiré des lieux de sa terre natale près de Chinon, et qu’on peut voir des références à François 1er et Charles Quint dans les personnages de Grandgousier et Picrochole. Et ce travail d’édition scientifique pointue associé à une interface ludique permet une approche plus éclairée de l’ouvrage.

Tout cela s’articule avec une valorisation touristique autour de l’œuvre puisque la carte permet de mettre en regard des lieux du texte les offices de tourisme et les sentiers de randonnée (pour l’instant un sentier thématique sur les guerres pichrocolines).

Les fichiers bruts des œuvres, issus d’un travail d’édition considérable (il a bien fallu repérer dans les textes ces noms de lieux et de personnages !) sont mis en ligne sur le site des BVH, au format XML TEI, dans une licence creative commons; consulter par exemple l’édition de Gargantua.

Un seul regret, à mon sens : qu’il n’y ait pas plus de liens vers les données du web. Sans aller jusqu’à des liens vers Wikipedia/DBpedia qui auraient pu brouiller le message scientifique, des correspondances avec des vocabulaires d’autorité comme Rameau, data.bnf.fr ou les données de l’INSEE auraient été les bienvenues !

Alors, l’application de cette « discrétisation » de la littérature en « données », en « data », est-elle une bonne façon de valoriser les œuvres ? et que nous dit-elle sur le lien entre littérature et technique ? qu’elles ne sont pas sur le même plan, et que, on aura beau essayer, on ne réduira pas la littérature à de l’informatique, et que l’informatique ne fera pas de la bonne littérature (mais les data, ça fait causer !).

Et il faut relire Gargantua, si vous avez l’occasion dans sa version en français de la Renaissance, pour le plaisir infini d’entendre rouler dans sa gorge ses sonorités :

J’ay (respondit Gargantua) par longue et curieuse experience inventé un moyen de me torcher le cul, le plus seigneurial, le plus excellent, le plus expedient que jamais feut veu. Quel? dict Grandgousier. Comme vous le raconteray (dist Gargantua) presentement. Je me torchay une foys d’un cachelet de velours de une damoiselle: et le trouvay bon: car la mollice de sa soye me causoit au fondement une volupte bien grande. Une aultre foys d’un chapron d’ycelles et feut de mesmes. Une aultre foys d’un cachecoul, une aultre foys des aureillettes de satin cramoysi. (…) Puis me torchay de Saulge, de Fenoil, de Aneth, de Marjolaine, de roses, de fueilles de Courles, de Choulx, de Bettes, de Pampre, de Guymaulves, de Verbasce (qui est escarlatte de cul) de Lactues, et de fueilles de Espinards…  la suite de ce célèbre extrait sur ReNom.

Cet article ReNom – de l’oeuvre littéraire aux data est apparu en premier sur Sparna Blog.

Contexte

Le réseau Canopé a pour objectif de « renforcer l’action de la communauté éducative en faveur de la réussite des élèves », en particulier en fournissant des ressources documentaires et pédagogiques pour les enseignants, mais aussi en proposant des espaces de formation et d’animation. Canopé Poitiers a ceci de particulier que, tout en étant une émanation régionale du réseau Canopé, il a une activité d’éditeur logiciel d’envergure nationale en proposant et en hébergeant les portails de recherche documentaire des CDI de plus de 7000 collèges et lycées, dans sa solution e-sidoc (7013 portails exactement au moment de la rédaction de cet article, vous pouvez regarder la carte des déploiements d’e-sidoc pour voir si le collège ou le lycée du coin est équipé avec cette solution. Voici le portail d’un lycée à Tours pour vous faire une idée).

Objectifs

L’objectif de Canopé Poitiers est d’évaluer la faisabilité et l’intérêt d’enrichir les portails e-sidoc avec les données de data.bnf.fr. Les possibilités d’enrichissement sont ouvertes mais peuvent schématiquement se subdiviser en trois :

1. L’amélioration de la recherche et des modes d’accès aux catalogues ; cette partie recouvre elle-même deux parties :
   1. l’amélioration des fonctions de recherche (nouvelles facettes ou de nouveaux critères de recherche) ;
   2. l’amélioration de la présentation des résultats de recherche;
2. L’ajout de nouvelles notices, tirées de data.bnf.fr, au catalogue « local » du CDI; c’est ce qui est déjà fait par Canopé Poitiers qui propose au CDI des « réservoirs de notices« , comme le dépouillement des titres de la presse, ou une sélection de sites internet pour les collèges et les lycées. Cela pourrait avoir du sens pour inclure dans ces portail des œuvres numériques de Gallica, ou des liens vers les expositions virtuelles de la BNF, etc. Cela permettrait ensuite au collégien/lycéen d’accéder à ces ressources via le portail de recherche;
3. L’enrichissement des notices documentaires (comme celle-ci) avec des informations tirées des données de data.bnf.fr;

Par ailleurs, Canopé Poitiers a de fortes contraintes de production, la réindexation de 7000 bases documentaires chaque nuit, et l’hébergement de tous ces portails pour avoir de bons temps de réponse posant un certain nombre de challenges techniques dont je ne soupçonne pas le quart…

Pour ces raisons de contraintes de production, nous expérimentons d’abord la piste de l’enrichissement des notices documentaires qui n’impacte ni sur la structure des index de recherche (ou de façon mineure), ni sur leur taille.

Quels enrichissements et comment ?

Le premier enrichissement envisagé est l’ajout d’un lien vers une version numérisée dans Gallica de l’œuvre présentée dans la notice. (voir par exemple Alice au pays des merveilles dans Gallica) La récupération de ces liens est possible car :

1. Les notices du portail documentaire portent (pour la plupart) un ISBN ou un EAN;
2. Les éditions d’ouvrages publiées dans data.bnf.fr portent également (pour la plupart) un ISBN ou un EAN, ce qui permet de faire un rapprochement avec nos notices;
3. Les éditions d’ouvrage de data.bnf.fr sont regroupées ensemble sous des entrées correspondant à l’œuvre abstraite par une organisation FRBR, ce qui permet, même s’il n’existe pas de version numérisée pour l’ISBN exact de départ (ce qui est toujours le cas, car les versions numériques dans Gallica sont celles d’éditions anciennes), de voir si une autre édition de la même oeuvre a son équivalent numérisée;

Pour ce qui nous intéresse ici, la structuration FRBR des oeuvres est donc la principale valeur ajoutée des données data.bnf.fr, par rapport aux flux OAI ou Z3950 de la BNF, qui ne structurent pas les données de cette façon.

Donc, en résumé :

• on cherche l’édition de l’oeuvre dans data.bnf.fr via l’ISBN ou l’EAN;
• et si on l’a trouvée, on cherche une autre édition de la même oeuvre ayant une version numérique (on prend l’édition la plus récente);

Retour d'expérience technique

Pour faire ce travail de récupération des liens :

• On télécharge les données de dump de data.bnf.fr;
• On les stocke dans un triplestore Jena Fuseki avec un stockage TDB;
• On fait un prétraitement sur les ISBNs (voir ci-dessous), et on fait nos requêtes de rapprochement en SPARQL;

On s’aperçoit que :

• Les données ont quelques petits soucis de format. (ne dérogeant donc pas à la règle d’or du traitement des données sur le web : « les données sont pourries » ) en effet quelques fichiers RDF des dumps de la BNF (ceux des manifestations, le 11971, le 11975 et quelques autres) contiennent des erreurs de syntaxe qui empêchent de les charger dans une base RDF. Avant de lancer un chargement, il est préférable de vérifier les fichiers avec le script Jena ntriples et son option « validate » :
  • ntriples –validate /chemin/databnf_editions_nt/databnf_editions__manif_* > /chemin/temp.txt
  • le plus simple a été de supprimer tout simplement ces fichiers pour ne pas faire échouer le chargement, mais si vous voulez avoir 100% des données il faudra les corriger, ce qui n’est pas tout à fait trivial;
• Le chargement des données est plutôt rapide.  105 millions de triplets, sur un portable classique, en 1h40. Pour ce chargement, j’ai utilisé le script tdbloader2 de Jena;
• Le format des ISBN est variable (aussi bien dans les données BNF que dans les notices de départ). Parfois en format ISBN-10, parfois en format ISBN-13, parfois avec tirets, parfois sans (978-2-7116-2455-3, 1-4051-3618-9, 3832202560, etc.) Je me suis donc ramené à une version sans tirets pour tous les ISBN pour limiter le problème, mais il reste la différence entre les ISBN-10 et les ISBN-13 qui n’a pas été traitée;

Quels résultats ?

Nous avons voulu valider la couverture des données de data.bnf.fr en terme de liens vers les versions numériques des œuvres : est-ce que le jeu en vaut la chandelle ? pourra-t-on sortir suffisamment de liens vers des œuvres numériques pour justifier le travail ? Pour cela, on a d’abord testé sur 4 auteurs classiques : Jules Verne, Victor Hugo, Emile Zola, Molière, en extrayant des notices la liste des ISBN/EAN des éditions de leurs œuvres.

Voici ce qu’on obtient en terme de couverture du rapprochement des données pour ces ISBNs :

On trouve une version électronique de l’oeuvre pour un ISBN sur quatre. Mais certaines œuvres ont plus d’exemplaires (d’items au sens FRBR) que d’autres (on trouvera plus d’exemplaires de « Au bonheur des dames » que de « Comment on meurt » de Zola), c’est pourquoi il était aussi intéressant de donner la couverture en nombres d’exemplaires :

Pour exprimer autrement le dernier chiffre de 53% :  il y a une chance sur deux de trouver une version numérique dans Gallica de l’oeuvre d’un livre d’un de ces 4 auteurs pris au hasard dans les rayonnages d’un CDI.

Globalement cela encourage à continuer la démarche et montre que ce travail sera visible dans les portails e-sidoc. La récupération des versions numériques des oeuvres est un premier prétexte à ce travail de rapprochement qui permettrait ensuite de récupérer de nombreuses autres données.

Update du 16/12/2014 : les dernières versions des données de data.bnf qui seront mises en ligne fin 2014 devraient 1/ corriger le petit souci de format mentionné plus haut (si ce n’est déjà fait) et 2/ contenir plus de données (entre 1 et 2 millions d’éditions supplémentaires, et 400 000 auteurs supplémentaires), ce qui devrait améliorer le ratio de rapprochement des notices sur les ISBNs.  Cela amènera data.bnf.fr à être de plus en plus incontournable par sa couverture (l’intégralité des éditions de la BNF devraient être publiées d’ici fin 2015).

Cet article data.bnf.fr pour enrichir un portail de recherche documentaire : le cas de Canopé Académie de Poitiers est apparu en premier sur Sparna Blog.

Si vous avez un corpus documentaire, comme une base d’articles scientifiques, et que votre besoin est d’accéder aux informations dans ce corpus, ne commencez pas par développer une ontologie. C’est ce que j’ai essayé de résumé sur ce schéma qui donne, par ordre croissant de complexité de mise en œuvre, les problématiques à traiter dans le couplage entre de la recherche non-structurée et des vocabulaires métiers structurés.

Par ordre croissant de complexité, et de bas en haut sur l’image :

Niveau 1: traiter le plein-texte

S’assurer que l’indexation est capable de prendre en compte tous les formats de fichiers (HTML, PDF, Word s’il y a lieu); qu’elle ne tient pas compte des majuscules/minuscules, qu’elle traite correctement les mots vides (voir par exemple la liste des mots vides qu’utilise SolR), qu’elle fait un stemming correct (l’algorithme de stemming peut être ajusté pour être plus ou moins « aggressif »).

Bénéfice de ce premier niveau : vous pouvez chercher en plein-texte sur votre corpus.

Niveau 2 : tirer partie de la structure des documents

L’idéal ici est d’avoir des documents déjà structurés, typiquement en XML. De façon à pouvoir faire 2 choses : d’une part, pondérer certains champs (donner plus d’importance au titre qu’au reste, typiquement) et d’autre part, si certains champs contiennent un nombre limité de valeurs possible (des champs de tags, de mots-clés, d’année, de type de document, de source, etc.), pouvoir en faire des facettes.

Bénéfices de ce deuxième niveau : vous avez des résultats plus pertinents car mieux pondérés, et vous pouvez filtrer sur certains critères supplémentaires;

Niveau 3 : injecter du vocabulaire métier

Sans aller jusqu’à des ontologies très structurées (au sens logique, ou intelligence artificielle, du terme), on peut bénéficier dans le moteur de l’injection de terminologies ou de thesaurus. Cela permet de déclarer des équivalences entres des mots ou des groupes nominaux, et ainsi de faire augmenter le rappel du moteur : si l’utilisateur cherche sur un synonyme, ou un acronyme présent dans le thesaurus, il va trouver les documents qui contiennent les termes préférentiels ou les termes complets.

Bénéfices de ce troisième niveau : une augmentation du rappel, et éventuellement l’utilisation du vocabulaire métier pour l’autocompletion de la recherche ;

Niveau 4 : indexation des entités et des concepts métier

Là-encore, on utilise la terminologie métier, mais, en plus d’étendre les fonctionnalités de la recherche plein-texte, il s’agit de réaliser une indexation des documents sur les entités ou les concepts métiers. Dans les systèmes de recherche qui nous intéressent ici, cette indexation doit être automatique et ne pas faire intervenir de validateur humain. Il va donc s’agir de repérer dans les textes les occurrences des entités ou des concepts du vocabulaire métier. Un outil de text-mining est typiquement nécessaire pour cela (par exemple Gate), a minima pour pour traiter les singuliers/pluriels, masculins/féminins, conjugaisons, etc. Attention au niveau de qualité de ces outils, et au paramétrage des règles grammaticales qui prennent du temps. A partir de là, on pourra présenter une facette complètement basée sur le vocabulaire métier, donc éventuellement hiérarchique.

Bénéfices de ce niveau : des facettes hiérarchiques sur le vocabulaire métier;

Niveau 5 : classification ou clustering automatique

Certains outils proposent soit de classifier les corpus sur des catégories prédéfinies (typiquement l’IPTC pour les articles de presse), soit de faire du clustering de documents à la volée, en déterminant automatiquement les clusters au fur et à mesure. C’est par exemple le cas de la belle application de visualisation de données sur l’actualité des jeux vidéos réalisée par Dataveyes et Antidot. Ici, on est déjà sur une problématique avancée nécessitant d’avoir un outil précis.

Bénéfice : des facettes additionnelles, par catégories;

Niveau 6 : indexation à partir de règles linguistiques

C’est la même idée que le niveau 4, à savoir le repérage d’entités ou de concepts dans les textes, mais non plus à partir d’une liste prédéfinie, mais en analysant la structure grammaticales des phrases (« le sujet d’un verbe d’action qui commence par une majuscule est sûrement une personne »). Autant dire qu’ici, le travail de paramétrage d’un analyseur grammatical est très coûteux. Le bénéfice qu’on en tire est de pouvoir trouver de nouvelles entités, donc d’alimenter des bases d’entités ou de concepts (qui nécessitent une validation humaine). C’est important dans l’optique de la constitution d’une base d’informations indépendante du corpus des documents, mais, pour le contexte d’un moteur de recherche sur un corpus, le bénéfice ne sera pas immédiat.

Niveau 7 : repérage d’attributs sur les entités et de relations entre les entités

Même chose que le niveau précédent, mais avec des règles plus poussées permettant non seulement de reconnaitre les entités, mais des informations sur ces entités : l’âge d’une personne, la date de sortie d’un film, le poste occupé dans une entreprise, etc. Ici encore, l’intérêt est d’alimenter une base de connaissances. On notera que ces données, s’il s’agit d’entités assez connues, peuvent se récupérer depuis le web sur DBPedia ou Wikidata.

Alors bien sûr, des problématiques à traiter dans la recherche d’information, il y en a d’autres (éventuellement, traitement des logs de recherche des utilisateurs, suggestions de recherche, etc.). J’apprécierai d’ailleurs des pointeurs sur des synthèses de ces problématiques, si vous en avez. Mais ma perspective était ici la réflexion sur le couplage entre un moteur de recherche non-structuré et de la connaissance structurée, par ordre croissant de complexité. Les ontologies, que je n’ai pas décrites dans ces différents niveaux, arrivent encore après, et on est alors bien plus dans des problématiques de constitution d’une base de connaissance (à la Google Knowledge Graph) que des problématique d’accès à un corpus.

Cet article Recherche d’informations : du plein-texte aux ontologies est apparu en premier sur Sparna Blog.

Les wiki sont de bons moyens d’amener les membres d’une communauté à contribuer collectivement à une base de connaissance partagée. C’est sur ce principe que repose Wikipedia, mais la même idée peut s’appliquer à une entreprise, une association ou une administration.

Un wiki, c’est l’anarchie, et c’est son point fort. L’approche « contribuer d’abord, structurer (un peu) ensuite » assure que la barrière d’entrée pour un contributeur est très faible, qu’il n’est pas obligé de respecter une quelconque structure, et peut même s’approprier ou modifier les structures existantes (en modifiant l’organisation d’un article ou en modifiant des catégories dans le wiki). Cela assure la contribution du plus grand nombre de personnes possibles.

Un wiki, c’est l’anarchie, et c’est son point faible. C’est son point faible si l’exhaustivité ou la qualité des données sont un de ses objectifs, ou si l’on veut pouvoir réutiliser la connaissance contenue dans le wiki dans d’autres applications informatiques. Qualité, exhaustivité, structuration des données pour la machine peuvent difficilement être atteintes par le mode d’organisation classique du wiki [1. Un exemple sur wikipedia/dbpedia ? cette requête SPARQL sur DBPedia francophone ramène toutes les sociétés avec leur slogan. 1/ qualité : certains slogans contiennent des chiffres 2/ exhaustivité : le slogan n’est parfois pas renseigné 3/ structuration : cette requête est possible sur DBpedia qui a structuré les données, mais pas sur wikipedia.]

Les technologies du web sémantique sont un bon moyen pour structurer les informations et les partager sur le web. En miroir des wiki, on peut dire que cette structuration est à la fois leur point faible et leur point fort : point fort car c’est cette structuration des données qui les rend partageables et réutilisables par des machines (mais certains en doutent), point faible car arriver à ce niveau de structuration peut augmenter significativement la barrière d’entrée pour publier et partager des données, en particulier dans des projets de capitalisation de connaissances. Par ailleurs des solutions simples, paramétrables et gratuites de formulaires de saisie pour des données RDF ne courent pas les rues.

Vous me voyez venir. Les wikis sémantiques sont la solution de synthèse du meilleur des deux mondes : le wiki pour son côté « faible barrière d’entrée à la contribution » et la sémantique pour son côté « structuration et partage des données » [2. D’autres dans la sphère francophone l’avaient mentionné bien avant, ici et là.].

Semantic Media Wiki = Media Wiki + Structuration

Semantic Media Wiki (SMW) est une extension du logiciel de wiki Media Wiki, celui qui est utilisé par Wikipedia. Cette extension propose de pouvoir gérer des données structurées dans le wiki, et de publier de ces données dans les formats du web sémantique, dans une base RDF.

Je résume les fonctionnalités indiquées dans la page d’introduction de SMW :

• générer automatiquement des listes d’objets dans le wiki, plutôt que de les saisir à la main
• présenter les données visuellement dans des graphes, des cartes, des calendriers
• améliorer la structure du wiki en évitant les catégories ad-hoc du type « films des années 50″
• rechercher des informations de façon structurée (et plus uniquement plein-texte)
• mettre à disposition les données du wiki pour d’autres applications et intégrer les données d’autres applications dans le wiki via SPARQL

Voilà ce qu’il ressort de mes premières impression après avoir testé SMW :

1. L’installation de Media Wiki est facile (package « mediawiki » sur Debian), et de Semantic Media Wiki assez simple avec Semantic Bundle, un ensemble d’extensions regroupées dans un même paquet;
2. Le paramétrage est un peu alambiqué mais est bien documenté; il faut notamment suivre les pages qui expliquent comment importer un vocabulaire existant (type FOAF, DC, ORG ou autre), comment paramétrer les propriétés et les classes, et comment paramétrer un formulaire; une fois le paramétrage bien compris, on a à notre dispostion une vraie solution de création de formulaires de saisie pour des données RDF.
3. La synchronisation avec un triplestore Sesame fonctionne bien, et on arrive à récupérer les données structurées du wiki en RDF, et à les interroger en SPARQL.

Paramétrer Semantic Media Wiki pour saisir des données RDF

D’abord, synchroniser SMW avec Sesame

La doc est ici.

1. Installez Sesame en suivant cette procédure
2. Utilisez les valeurs suivantes dans le fichier de config (attention de bien mettre « /statements » à la fin de l’URL de service d’update)

$smwgDefaultStore = 'SMWSparqlStore';
# location of query service
$smwgSparqlQueryEndpoint = 'http://localhost:8080/openrdf-sesame/repositories/nomDuRepository';
# location of update service
$smwgSparqlUpdateEndpoint = 'http://localhost:8080/openrdf-sesame/repositories/nomDuRepository/statements';
# location of SPARQL over HTTP service, set it to ''; in case of problems
$smwgSparqlDataEndpoint = '';
# optional name of default graph
$smwgSparqlDefaultGraph = 'http://example.org/mydefaultgraphname';

Ensuite, si vous voulez, paramétrer SMW pour utiliser un vocabulaire externe

La doc est ici.

1. Assurez-vous d’être connecté en tant qu’admin du wiki
2. Créez une page MediaWiki:smw_import_PREFIXE_DU_VOCABULAIRE, par exemple MediaWiki:smw_import_org pour importer l’ontologie des organisations
3. Déclarez dans cette page les types et les propriétés du vocabulaire que vous voulez réutilisez, de cette façon :

   http://www.w3.org/ns/org#|[http://www.w3.org/TR/vocab-org/ The Organization Ontology]
    Role|Category
    Post|Category
    hasMember|Type:Page
    memberOf|Type:Page
    holds|Type:Page

4. Déclarez des propriétés et des catégories dans le wiki;
5. Déclarez la correspondances de ces propriétés et ces catégories avec les éléments du vocabulaire externe, en utilisant les marqueurs

[[imported from::org:Organization]] (pour une catégorie)
[[imported from::org:hasMember]] (pour une propriété)

Puis, paramétrer des formulaires de saisie

La doc est ici et là.

Je ne suis pas certain de comprendre tout l’enchainement du paramétrage, notamment les différences entre une « catégorie », un « template » ou « modèle », et le « formulaire ». Mais l’exemple de la doc fonctionne bien et peut ensuite être adaptée facilement avec la doc de paramétrage du formulaire sous les yeux. Pour paramétrer un formulaire qui a du sens pour des données structurées, on va surtout s’intéresser aux options suivantes :

• values from category= qui permet de restreindre la saisie d’un champ à une catégorie, c’est-à-dire en termes RDF à une classe – c’est l’équivalent d’un paramétrage de range RDFS;
• existing values only si vous ne voulez pas qu’un utilisateur qui remplisse le formulaire puisse choisir une valeur qui n’existe pas;

On va ensuite vouloir bloquer l’édition classique d’une page, pour ne permettre l’édition qu’à travers le formulaire. Pour cela il faut changer 2 paramètres dans SMW comme décrit dans la doc ici.

Finalement…

Tout projet d’outil de saisie va de pair avec une reprise de données, il faudrait étudier ce que les fonctions d’import/export de données de Media Wiki permettent, en tous cas l’utilisation de cette brique comme outil de contribution collaborative à une base de connaissances structurée est tentante !

Cet article Le wiki sémantique : solution de capitalisation des connaissances (structurées) est apparu en premier sur Sparna Blog.