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.

La documentation de référence de cette installation est disponible ici. Virtuoso est disponible dans les dépôts Linux, cependant cette version date quelque peu, et compte-tenu des dernières évolutions sur le produit il est de bon ton d’essayer de se bien se tenir à jour. La procédure d’installation ci-dessous est donc celle qui compile Virtuoso à partir des sources.

# Télécharger les sources depuis http://sourceforge.net/projects/virtuoso
# Télécharger le fichier virtuoso-opensource-6.1.7.tar.gz

# D'abord installer toutes les dépendances requises
su -
yum install gcc gmake autoconf automake libtool flex bison gperf gawk m4 make
yum install openssl-devel readline-devel wget

# Créer un répertoire dans lequel on va dézipper les sources
mkdir virtuoso
cd virtuoso
cp ../Downloads/virtuoso-opensource-6.1.7.tar.gz .

# untar
tar xvpfz virtuoso-opensource-6.1.7.tar.gz

# configure
# c'est ici que l'on peut changer le prefixe racine de l'installation avec le parametre --prefix
cd virtuoso-opensource-6.1.7
./configure --prefix=/usr/local/ --with-readline

# Voilà ce qu'on obtient :

Virtuoso Open Source Edition (Row Store) 6.1.7 configuration summary
====================================================================

Installation variables
  layout                  default
  prefix                  /usr/local
  exec_prefix             ${prefix}

Installation paths
  programs                ${exec_prefix}/bin
  include files           ${prefix}/include
  libraries               ${exec_prefix}/lib
  manual pages            ${datarootdir}/man
  vad packages            ${datarootdir}/virtuoso/vad
  database                ${prefix}/var/lib/virtuoso/db
  hosting                 ${exec_prefix}/lib/virtuoso/hosting

Options
  BUILD_OPTS               xml ssl imsg pldebug pthreads readline

# compiler (prend plusieurs dizaines de minutes à plusieurs heures en fonction de la puissance de la machine)
nice make

# installer
su -
cd /home/thomas/virtuoso/virtuoso-opensource-6.1.7
make install

# vérifier que virtuoso.ini est au bon endroit
cd /usr/local/var/lib/virtuoso/db/
ls
# virtuoso.ini

# démarrer le serveur
virtuoso-t -df
# cette commande demarre le serveur dans le terminal, si on ferme la fenêtre le process s'arrete.
# pour demarrer dans le background :
virtuoso-t -f &
# et pour arreter le serveur :
ps -edf | grep virtuoso-t
kill -9 <numero du process>
# accéder à http://localhost:8890/conductor/

# se logguer avec le super-admin : dba/dba

# changer tout de suite le mot de passe du super-admin
isql
set password dba new_password

# accéder au endpoint public à http://localhost:8890/sparql
# et voilà :-)
# avertissement : cette procédure ne convient pas pour un déploiement en production

Cet article Installation du triplestore OpenLink Virtuoso sous Linux est apparu en premier sur Sparna Blog.

Le schéma de données, quel schéma de données ?

Facilite les phases de prototypage

Dans les approches à base de RDF+SPARQL, on n’a pas besoin d’avoir un schéma de données pour commencer à travailler. On a juste besoin des données. Le schéma peut venir après. « Data first, model after ». C’est une approche « bottom-up », là où les SGBD+SQL ont nécessairement une approche « top-down » : « model first, data after ». Cela permet un prototypage rapide des projets : plus besoin d’attendre d’avoir défini un modèle de base de données avant de faire une première requête.

Intégration de données hétérogènes

Ces absence de schéma, de modèle, dans les bases de données RDF (triplestores) donne la possibilité d’y intégrer des données :

• hétérogènes : exprimées avec des modèles différents, en ayant ensuite la possibilité de les réconcilier sur un modèle unique si besoin;
• incomplètes : avec des valeurs manquantes, en ayant la possibilité de repérer ces objets anormaux si besoin;
• incohérentes : venant de sources différentes qui donnent des informations contradictoires, en ayant la possibilité de repérer ces incohérences et de les corriger si besoin;

Une infinité de points de vue

Zéro schéma signifie aussi une multiplicité de schémas. Les technologies sémantiques permettent d’exprimer les mêmes données suivant plusieurs schémas dans la même base, offrant alors plusieurs « points de vue », plusieurs façons de voir les mêmes données. Et ceci automatiquement avec de l’inférence OWL. Chaque application consommant les données pourra alors s’appuyer sur le schéma qu’elle comprend. On favorise ainsi l’interopérabilité entre applications. Un exemple ? le standard de représentation SKOS permet une représentation simple de systèmes d’organisation de connaissances (thesaurus, arbres de classement, …) , à base de « Concept » qui portent des « prefLabels » (libellés préférentiels). C’est un format d’échange commode, mais inadapté à la représentation de bases de connaissances riches, comme une base de personnes. Il est tout à fait possible de dire « ce que tu appelles une Personne dans ton système je l’appelle également un Concept SKOS, et la propriété foaf:name que tu utilises correspond à la propriété skos:prefLabel SKOS », pour ainsi obtenir une « vue » SKOS d’une base de personnes.

Ce faisant, on permet également de séparer les métadonnées initiales des contenus (riches et compliquées) des catégories de ces contenus pour la diffusion, en fonction des supports ou des publics (souvent plus simples et liées à l’usage). L’exemple classique est l’hôtel rangé dans une catégorie « bon marché » alors que ses métadonnées initiales sont plus complexes : prix par nuit, nombre d’étoiles, labels, piscine, etc.

Flexibilité maximale

Le fait que le schéma ne contraigne pas les données donne une flexibilité et une évolutivité importante au système. On peut rajouter, supprimer, modifier un attribut ou une classe à la volée. On peut modifier le schéma, sans toucher aux données. On peut même changer de schéma facilement. Prenons un cas d’intégration de données : une application intégrant une source de données externe avec ses propres données, et se retrouvant confronté au cas où cette source de données change de format et de modèle :

• dans le monde du XXème siècle, en SGBD+SQL, confronté à un tel cas on doit 1/ modifier le parsing des données qui ont changé, 2/ modifier les tables du système pour prendre en compte ce nouveau format, 3/ modifier les requêtes de l’applicatif.
• Dans le monde du XXIème siècle, en RDF+SPARQL : 1/ pas de parsing à modifier (les données arrivent toujours en RDF), 2/ pas de schema à modifier (il n’y en a pas) et 3/ il faut toujours modifier les requêtes de l’applicatif… plus qu’un 1/3 du travail. Et encore, il est possible, le temps de modifier les requêtes, d’ajouter de l’inférence pour recréer les données dans l’ancien modèle à partir du nouveau, de façon à ce que les requêtes continuent à répondre.

Le raisonnement, ou les manipulations automatiques des données

Réconciliation

Le raisonnement est la capacité des outils RDF à déduire automatiquement de nouvelles informations à partir des informations existantes. Notons bien que ces capacités de raisonnement ne sont ni proposées par tous les outils RDF, ni forcément utiles dans tous les contextes. Elles vont par exemple permettre de réconcilier les données hétérogènes sur un modèle commun : « Ensemble des personnes = ensemble des contacts qui viennent de mon répertoire de téléphone + ensemble de mes contacts dans les réseaux sociaux ».

Classification

Le même mécanisme est utilisé pour des besoins plus proches de la classification (« repurposing » de contenu), pour définir les ensembles d’objets dans des points de vue multiples, tel qu’évoqué plus haut. On peut par exemple avoir d’un côté l’ensemble des objets « Hébergements », et de l’autre l’ensemble des objets « Hôtels pas chers » défini comme « l’ensemble des objets Hébergements qui sont de type hôtel et ont un prix par nuit inférieur à 60 euros ». Le deuxième ensemble sera calculé à partir du premier, automatiquement.

Inférence

L’inférence permet de précalculer des liens ou des données qui facilitent l’écriture des requêtes et améliorent les temps de réponse. Le total des buts marqués par une équipe de football dans une compétition est calculé comme la somme de tous les buts marqués par cette équipe dans les matchs de cette compétition. La donnée est calculée une fois, et peut ensuite être présentée directement sur la page de l’équipe, il n’y a pas de calcul à faire au moment de l’affichage (voir le site de la coupe du monde de la BBC, réalisé à partir des technologies du web de données en utilisant le raisonnement).

Consistance

L’inférence est aussi ce qui permet de contrôler la consistance par rapport au modèle de données. Car si en RDF il est possible de ne pas avoir de schéma, dans les cas où il y en a un, le moteur d’inférence sera capable de déterminer si les données sont consistantes par rapport à ce schéma ou non.

Conclusion…

Ce travail d’analyse partiel est une synthèse des expériences acquises avec ces technologies, et des lectures spécialisées (le forum answers.semanticweb.com contient beaucoup de réponses intéressantes). Il doit permettre de bien situer les avantages de ces technos pour ne pas en faire une évangélisation aveugle, et de les utiliser au mieux pour résoudre des problèmes concrets. Il y aurait peut-être d’autres avantages à étudier, comme la réutilisation possibles de schémas existants, comme ceux que l’on peut trouver dans le LOV (Linked Open Vocabularies).

De plus en plus de projets vont vouloir soit tirer parti de ce qui est publié librement sur le web de données, soit rationnaliser des intégrations d’API compliquées, ou encore améliorer leurs chaines de traitement et de diffusion de contenus, ouvrir des données de bases auparavant fermées, aligner des référentiels avec du raisonnement, etc… tous ces projets peuvent bénéficier d’une approche basée sur le web de données. Si vous voulez en savoir plus, n’hésitez pas à réagir ici ou à me contacter.

Cet article Bénéfices clés des technologies du web de données 2/2 – absence de modèle, raisonnement est apparu en premier sur Sparna Blog.

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

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

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

// I. exemple de Query SELECT

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

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

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

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

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

// II. Exemple de Query CONSTRUCT

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

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

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

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

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