Last modified 6 years ago Last modified on 09/01/11 13:00:52

Go back to the table of modules

Harvester

The Harvester module is responsible for the generic logic of harvesting a remote repository, independent of the actual protocol used for harvesting. It will ultimately include several submodules, one for each protocol we want to support.

While most learning object repositories have indicated they wanted an actual multi-protocol Harvester, except in research projects, all of them seem to only have a OAI-PMH implementation.

Obviously our initial focus is also OAI-PMH, but we may have a very real need to Harvest other protocols like EurekaSpider, SRU, and atom. Ultimately, we hope the Harvester submodules will be neatly separated, with central logic for most functions.

List of critical functionality

  • Handle the logic of updating/replacing/deleting according to date and peeking in the metadata
  • The Harvester is also the module within which broken link checking functionality will be implemented (as a submodule), including acting on the presence of broken links according to User Story #18. This is a service of the Harvester module, not a process that runs during harvesting.

Implementation choices/alternatives

The two main contenders were ORI-OAIs, Fedora's and Ariadne's Harvesters. ORI-OAIs was chosen.

Open questions

  • Should some validation be done BEFORE writing data in Fedora?
  • Whether it is before or after, should the decision to accept or reject the resource involve the workflow, or be taken by the Harvester?

Submodules

OAI_PMHClient

OAI-PMH client is a Harvester submodule to implement harvesting over the OAI-PMH protocol. In this first iteration, the OAI-PMH client isn't actually a submodule, as it's already supported in ORI-OAI's harvester, and there is no point in separating it out before the module's logic is made more generic to support a second protocol.

HTMLSpider

A Harvester submodule to implement harvesting over the Eureka HTML spider protocol

SRUClient

A Harvester submodule to implement harvesting over the SRU protocol used by Library Management Software

Algorithms

Flux d'importation visé

Ce diagramme représente le flux d'importation d'une ressource

GraphViz image

État des ressources

Une métadonnée importante qui doit être conservée dès le départ par COMETE est l’état de la fiche. La liste des états possibles est sujette à changement, mais incluera probablement:

  • validée (ou publiée): Fiche disponible publiquement. État normal des fiches.
  • rejetée: Fiche rejetée en permanence, généralement par choix éditorial
  • problématique: Fiche moissonnée ayant des problèmes (ex: liens brisés), ou fiche éditée localement qui n'est pas publiée en attente de révision humaine.

Vérification des liens brisés

La vérification des liens brisés peut changer l'état d'une fiche (passer la fiche de publiée à problématique si les liens sont brisés depuis plus d'une semaine, puis repasser à validée lorsque les liens sont corrigés). La vérification des liens brisés ne se fait pas (du moins pas seulement) au moment du moissonnage. Elle sera probablement implantée dans le module Harvester, simplement parce qu'il faut la mettre quelque part, et que c'est une tâche similaire.

Exemples de corrections au moment du moissonnage

  • Exemple de correction propre à un dépôt: Corriger les termes de vocabulaires utilisés (ex: dans LomFr?, assurer master vs mastère) ou encore les sources des vocabulaires utilisés (ex: CDD 22e éd. -> http://www.oclc.org/dewey/)
  • Exemple de correction inconditionnelle: Corriger la syntaxe des VCard (les problèmes sont nombreux. Vont des dépôts qui ne mettent pas leur VCard dans un CDATA, perdant ainsi les espaces qui délimitent les changements de champs, au mauvais folding, mauvais encodage des images, etc.)
    • Il est utile de noter que ce genre de correction se fait dans des modules externes (Identité dans ce cas-ci). Le résultat de l'échec d'une telle transformation est normalement l'échec de l'importation en général.

Les corrections/changements sémantiques aux fiches

Les corrections automatiques ci-haut sont des corrections pour lesquelles on est convaincu qu'elles ne changent pas la sémantique (il est possible qu'il y ait perte dans des cas accidentels, mais même dans ce cas on se retrouve dans une meilleure situation que sans correction du tout. Par exemple, mieux vaut un VDEX partiel que pas de VDEX du tout.)

Il ne s'agit pas de corrections représentant des changements sémantiques (ex: Corrections de faute d’orthographe, de VCard, etc.), ni d'ajouts d'informations (commentaires, vocabulaires de classifications issus d'un algorithme de correspondance ou d'un ajout manuel). Ces changements:

  • Ne seront pas implantés initialement dans COMETE
  • Seront représentés comme différences pouvant être ré-appliquées lors du re-moissonnage de la fiche originale.
    • Seront représentés dans un standard normalisé (ex: ILOX)

Ré-exposition des fiches

  • Par défaut, toute fiche validée est ré-exposée au moissonnage.
  • Identifiants:
    • Une fiche qui origine du dépôt actuel de COMETE
      • exposée avec son identifiant OAI normal (ex: oai:nom.domaine-du-depot-comete-original.org:4c990268eff494.67622046)
    • Une fiche qui avait été moissonnée
      • exposée avec les données contenues dans "Original Metadata", et son identifiant d'origine.
      • Si on désire ré-exposer la fiche incluant nos corrections automatisées, on l'expose avec les données contenues dans "Native Record", re-transformée dans le format original (ex: champ source de LOM a la valeur LOMv1.0 pour les vocabulaires de LOM), et avec un identifiant local indiquant clairement que ce n'est pas le dépot original de la fiche, et contenant l'identifiant original (encodé). (ex: si on réexpose la fiche plus haut, on aurait quelque chose du genre: oai:nom.domaine-du-depot-comete.org/reexpose_corrected/oai%3Anom.domaine-du-depot-comete-original.org%3A4c990268eff494.67622046)
      • Si on désire ré-exposer la fiche incluant des corrections sémantiques (nouvelles classifications, commentaires, etc.), on l'expose après application des données de corrections, avec un identifiant dépendant du mécanisme de correction.

Métadonnées à conserver sur l'état du moissonage

Voici les informations conservées dans Eurêka comme point de départ. Mettre à jour pour COMETE.

  • Raison du rejet
  • URL d'importation
  • Dates:
    • Date de création: Date de création de l'instance. Dans le cas d'Eurêka, fait aussi office de date de dernier remplacement dû au moissonnage. Peut donc être plus récent que toutes les autres dates dans certains cas.
    • Date de validation: Date où la ressource a été rendue publique dans le dépôt pour la première fois. Devient normalement plus ancien que la date de création au fil du temps.
    • Date de modification: Date de dernière modification de la fiche. Tirée des métadonnées lors du moissonnage (pour les fiches moissonnées) ou mises à jour à chaque modification (pour les fiches locales)
    • Date de dernier moissonnage: Date du dernier moissonnage avec succès de la fiche (qu'elle ait été modifiée ou non)
    • Identifiant de la dernière araignée ayant moissonné la fiche
      • Avec COMETE, il faudra prévoir le cas où plus d'une araignée moissonnent la même fiche.
  • Remplacement forcé au prochain passage (true ou false). Pour certains protocoles (ou dépôts), il peut être nécessaire de forcer un remplacement même si les dates de modification indiqueraient de ne pas le faire. Un exemple typique est si un dépôt a mis a jour son code pour corriger des problèmes d'exportation.

Algorithme d'importation pour l'araignée HTML

Voir: http://projects.coeus.ca/eureka/wiki/doc/importExport#EurekaHTMLSpiderprotocolSpiderHTML

Algorithme utilisé par Eurêka pour transformer/valider un VDEX

TODO

Algorithme utilisés par Eurêka pour déréférencer les identités

Voir Architecture/Modules/Identity

Informations concernant l'analyse du module ORI-OAI-harvester

Attention
ne compile pas avec les librairies de Tomcat 7.0, utiliser la version 6.0

Dépendances externes

Le module ORI-OAI-harvester repose principalement sur les technologies suivantes:

  • Spring
  • Hibernate
  • OCLC Harvester
  • Struts-Tiles
  • Quartz
  • Lucene
  • Compass

Ces frameworks/projets viennent très souvent avec beaucoup de dépendances, d'où une multitude de librairies importées au projet. Une première analyse à la compilation et à l'exécution a mis en relief l'utilisation minimale des librairies du tableau suivant:

Note: il se peut que d'autres librairies présentes dans le module soient utilisées, les rajouter en conséquence.

LibrairieDescriptionURLversion utilisée (date)dernière version (date)
AxisAPI pour développer des services web SOAPhttp://axis.apache.org/axis1.3 (oct 2005) 1.4 (avr 2006)
Apache Java librairiesExtensions de Javasous projets de http://commons.apache.org : digester, lang, logging, beanutils, codec, collections, discovery
HttpClientclient HTTPhttp://hc.apache.org/httpcomponents-client-ga/3.04.1.1
MyFacesImplementation JavaServer Faceshttp://myfaces.apache.org1.2.82.0.4 (fev 2011)
log4jAPI de logginghttp://logging.apache.org/log4j1.2.151.2.16 (janv 2011)
TilesFramework de templates pour interfaces usagerhttp://tiles.apache.org2.1.42.2.2
XercesParsing et validation XMLhttp://xerces.apache.org
JAXRPCAPI pour XML-Based RPChttp://java.net/projects/jax-rpc3.03.6.1 (fev 2011)
CompassSearch facility over Lucenehttp://compass-project.org2.1.0 (nov 2008) 2.2.0 (avr 2009)
dom4jmanipulation XML, XPath et XSLThttp://www.dom4j.org1.6.12.0.0 (avr 2010)
esup commonsFramework de développement basé sur Springhttp://www.esup-portail.org/pages/viewpage.action?pageId=1867791
HibernateFramework gérant la persistence d'objets javahttp://www.hibernate.org3.03.6.1 (fev 2011)
JDOMautre API manipulation XMLhttp://www.jdom.org1.01.1.1
JUnitFramework de testhttp://www.junit.org4.04.9 (janv 2011)
QuartzServices de Job Schedulinghttp://www.quartz-scheduler.org1.5.21.8.4 (oct 2010)
SpringFramework de construction d'applicationhttp://www.springsource.org2.5.63.0.5 (20 oct 2010)
XStreamSerialisation/Deserialisation XMLhttp://xstream.codehaus.org/1.21.3.1
JavassistBytecode manipulation au runtimehttp://www.csg.is.titech.ac.jp/~chiba/javassist/3.41.3.1
JTAJava Transaction APIhttp://www.oracle.com/technetwork/java/javaee/jta/index.html 1.1
Luceneà dégagerhttp://lucene.apache.org
SerializerSerializer XML de Xalanhttp://xml.apache.org/xalan-j
SLF4JSimple Logging Facadehttp://www.slf4j.org1.5.61.6.1
wsdl4jManipulation de WSDLhttp://sourceforge.net/projects/wsdl4j1.5.61.6.2 (nov 2006)
XBeanInstallation de plugin sur internethttp://geronimo.apache.org/xbean2.1.02.8 (dec 2006)
XFire (maintenant CXF)Framework SOAPhttp://xfire.codehaus.org1.2.51.2.6 (mai 2007)
XMLSchemaManipulation XML Schemahttp://ws.apache.org/commons/XmlSchema1.1 (sept 20061.4.7 (sept 2010)
OCLC Havester (actif ??)Librairie OAIhttp://www.oclc.org/research/activities/past/orprojects//harvester2/harvester2.htm(2006)

Attachments

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