sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [sdx-users] Conseil d'architecture


From: Emmanuel Bégué
Subject: RE: [sdx-users] Conseil d'architecture
Date: Wed, 30 Jun 2004 13:48:14 +0200

> -----Message d'origine-----
> De la part de julien bloit
> Envoyé : mercredi 30 juin 2004 11:41
>
> La raison pour laquelle je considère le multibase ou des applications
> multiples est que je voudrais qu'il y ait des modes de
> consultation/administration distincts à différents niveaux :
>
> - au niveau d'un organisme :

Qu'entendez-vous par "au niveau d'un organisme"? Si les personnes
doivent s'identifier pour utiliser l'application, alors on peut
facilement déterminer lors de leur identification de quel organisme
ils dépendent, et donc leur proposer des fonctions / une présentation
spécifique, à l'intérieur d'une application unique.

> 0.permettre la recherche de document parmi ceux de l'organisme
> seulement.

Aucun problème pour ça avec une seule base et la gestion d'un
champ "organisme".


> 1.permettre la consultation des métadonnées dans le
> format propre à l'organisme.

On peut également gérer la présentation en fonction du
champ "organisme", à la fois au niveau de la consultation de
chaque document et au niveau de la liste de résultats, mais
c'est vrai que si la présentation est vraiment totalement
différente ça serait peut-être un peu plus simple avec des
applications différentes (mais pas tellement avec des bases
différentes dans une application unique).


> 2.laisser à une tierce personne de l'organisme le soin
> d'administrer ses contenus.

Idem ci-dessus?


> 3.permettre une certaine personnalisation graphique pour son
> organisme.

Idem point 1 -- en fait je ne comprends pas très bien la
différence entre "format" (1.) et "présentation graphique" (3.)?


> - au niveau 'supra-organisme' (portail?) :
> 0.permettre la recherche de documents sur l'ensemble des
> organismes.
> 1.permettre la consultation des métadonnées dans un format commun.
> 2.ne pas avoir à gérer directement les contenus à ca niveau.
> 3.Avoir une uniformité graphique pour l'affichage des métadonnées
> dans le format commun.

Tous ces points sont évidemment beaucoup plus faciles à obtenir
avec une application unique...


> Même s'il existe une application de type portail qui indexe les documents
> des organismes exposés en OAI dans un format commun (Dublin Core au
> hasard...) ? La consultation en dublin core serait alors possible pour
> chaque document, non?

On pourra consulter ce qui aura été indexé, à savoir les données
exposées en OAI, mais pas le document lui-même, qui devra être
servi par l'application qui le gère; c'est à dire que je ne pense
pas qu'on pourra parcourir dans un même jeu de résultats à la
fois les documents locaux et les documents distants (toutefois
c'est peut-être possible, je n'ai pas essayé...?).


> Pour séparer les modes d'administration et de consultation que
> j'évoquais plus haut. Je ne sais pas si c'est un argument suffisant.

Les tâches d'admin seront réservées aux utilisateurs identifiés;
à partir du moment où l'utilisateur est identifié on peut lui
proposer les fonctions et les contenus qui le concernent, à
condition que cette information soit gérée au niveau utilisateur
comme au niveau document.

En résumé j'ai le sentiment que le développement d'une application
unique est possible mais demande sans doute un plus grand travail
de conception au début, pour un plus grand confort dans l'avenir;
au contraire le développement de plusieurs applications distinctes
peut sembler plus immédiat, mais multipliera les tâches de
maintenance futures.

Un argument en faveur de plusieurs applications c'est dans le
cas où chaque organisme peut souhaiter à terme héberger chez
lui son application; mais si la plate-forme technique est
commune et a vocation à le rester, il me semble que vous aurez
beaucoup à gagner en ne développant qu'une seule application.

(Ce n'est que mon avis et les conseils n'engagent que ceux
qui les écoutent... ;-)

Cdt,
EB





reply via email to

[Prev in Thread] Current Thread [Next in Thread]