Last modified 5 years ago Last modified on 11/01/11 16:09:28

Go back to the table of modules

Triple Store

The Triple Store module is the main, low-level graph database where COMETE's metadata is stored. It is responsible for graph operations, full text indexing and primary (resource metadata) and secondary (vocabularies, identities, etc.) metadata storage.

Un triple store est tout simplement une base de données Graphe (RDF). Fedora a besoin d'un moteur de stockage RDF pour les relations. Nous voulons également nous en servir pour l'indexation plein-texte afin d'intégrer les relations et la recherche plein texte, particulièrement pour l'intégration des collections.

Implementation choices/alternatives

Choix d'un moteur de stockage pour les métadonnées

Matériel d'introduction

Critères spécifiques au projet

  • Indexation plein texte
    • Voir: The RDF Fulltext Benchmark, et particulièrement l'article lui-même.
      • D'un intérêt particulier sont les fonctionnalités des questions 18 à 21 de la section 2.3.1. En gros, seulement supporté par Jena + LARQ et Sesame2 + LuceneSail?.
    • Malheureusement, la performance du score pour une phrase ou des mots clef multiples pour le même champ n'a pas été testé dans les solutions plus haut.
  • Scaling jusqu'à ? triplets sur un serveur unique
  • Inférence entre vocabulaires performante

Options libres

Mulgara

http://www.mulgara.org/, licence: OSLv3.0

  • Mulgara est l'implantation par défaut dans Architecture/Modules/FedoraRepository
  • Mulgara offre, en plus d'un triple store, des resolvers qui donnent une vue triplifiée d'une ressource autre.
  • En particulier, Mulgara l'indexation plein-texte dépend d'un Resolver qui donne une vue triplifiée de Lucene.
  • Mulgara offre des vues combinées sur un ensemble de graphes RDF (chacun correspondant à un TripleStore ou un Resolver)
  • Mulgara permet de coupler un Resolver Lucene automatiquement à un TripleStore (peut-être combinés à l'aide d'une vue? à vérifier.)
  • L'implantation de Lucene (dans org.mulgara.resolver.lucene.LuceneIndexerCache.WriterInfo) crée un index avec un StandardAnalyzer?, qui emploie une liste de mots vides anglaise. Non-configurable.
  • Quand un triple est stocké par Mulgara dans lucene, les informations de langue et de type y sont perdues (mais sont encore dans le triple store correspondant.)
  • Mulgara offre des opérations de query en sparql et d'update en iTQL, un language qui a précédé la solidification de la norme Sparql. En particulier, Mulgara ne supporte donc pas Sparql-update.
  • Dans le cadre de Fedora, Fedora parle à Mulgara à travers Trippi, et les "update" se font un triple à la fois, pas nécessairement par le biais de iTQL. Les query peuvent être faites en SPARQL ou iTQL.

Les requêtes plein-texte dans Mulgara suivent une syntaxe sujet-prédicat-fragment de littéral. Donc, on n'a pas naturellement accès au score, ou à un fragment. Il y a une transformation syntaxique non-documentée dans org.mulgara.resolver.lucene.LuceneTransformer qui permet d'obtenir le score en iTQL, avec une requête du type

alias <rmi://localhost/server1#> as server;
alias <http://mulgara.org/mulgara#> as mulgara;
select $x $score from <server:lucene1> where
 $x <mulgara:search> $s in <server:lucene1> and
 $s $p 'keyword' in <server:lucene1> and
 $s <mulgara:score> $score in <server:lucene1>;

Noter que la requête Sparql équivalente échoue; qu'elle dépend du resolver lucene (et échoue sur une vue), et qu'on n'a pas accès à l'extrait.

Note: TraitementLinguistiqueDansLesBasesRdf

Virtuoso Open-Source edition

Virtuoso, licence: GPLv2

Se distingue surtout pas son support mixte de l'approche Graphe, relationelle et XML.

Lucene Sail

http://dev.nepomuk.semanticdesktop.org/wiki/LuceneSail, licence Apache

Description de l'architecture

La solution du projet Nepomuk au problème de la recherche plein texte dans les triple store. C'est une approche Lucene du problème, assez semblable à ce que Benoit et Marc-Antoine considéraient comme plan B. Basé sur Sésame, les données sont entièrement stockées dans Lucene. Deux requêtes sont lancées. La première est une requête exacte sur les données graphe. La seconde est une requête inexacte sur l'index plein texte. Les résultats sont ensuite combinés dans le code de Lucene Sail.

Open Sahara Indexing Sail

https://dev.opensahara.com/projects/os/wiki/IndexingSail, licence: Apache

Une solution au problème de la recherche plein texte et géomatique utilisant l'indexeur de PostGIS, Sesame, et un triple de son choix.

Open Sahara utilise GATE (General Architecture for Text Engineering). Inclut du stemming.

Garlik 4store

http://4store.org/, licence: GPLv3

  • Recherche plein texte dans 4 Store
  • On peut contrôler la langue du Stemmer dans 4 store, mais de la documentation, il ne semple même pas avoir moyen d'obtenir le score, encore moins le snippet. Si c'est le cas, à éliminer.

Jena

http://jena.sourceforge.net, licence: BSD

  • Indexation plein-texte pour Jena: LARQ
  • Dépend du back-end sélectionné

Sesame

http://www.openrdf.org/, licence: BSD

  • Dépend du back-end sélectionné

Évaluations de performance

Contexte: Gilbert Paquette a communiqué avec M. Frans Van Aasche, de KTH (Suède), qui a eu des résultats décevants avec SCAM (qui semble employer Sesame.) C'est ce qui m'a amené (MAP) à examiner le benchmark de Berlin.

0.9.8 © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.70874 sec.)