Voici un petit complément d'info.
C'est en fait le md_editor qui supprime le bloc de "tef_desc_version" dans les thèses de STAR. Si on valide une fiche dans le workflow sans l'ouvrir dans le md_editor , ça passe.
J'essaie désespérément de trouver la raison en comparant les notice STAR problématiques et d'autre notices , mais je ne voie rien de particulier .
Alain
Le 13/09/2010 11:50, Yohan Colmant a écrit :
Alain,
J'avais regardé à ce problème vendredi et je ne vois pas comment contourner la chose rapidement côté md-editor.
le drezen alain a écrit :Concernant le message d'erreur ci dessous, le problème d'import ne se produit plus si on ajoute USE="maitre" à mets:file
Je ne m'explique pas ce comportement si ce n'est pas un problème lors du chargement du bloc suivant dans mets:structMap :
<mets:div TYPE="EDITION" CONTENTIDS="CONTENTIDS.ABES.STAR.THESE_5152.VERSION_COMPLETE.EDITION_ARCHIVAGE" DMDID="ABES.STAR.THESE_5152.VERSION_COMPLETE.DESCRIPTION.EDITION_ARCHIVAGE">
<mets:fptr FILEID="ABES.STAR.THESE_5152.VERSION_COMPLETE.EDITION_ARCHIVAGE.FILEGRP" />
</mets:div>
L'attribut USE dans mets:file est facultatif et son absence ne devrait donc pas poser de pb à l'import.
Sinon concernant le deuxième point très gênant relatif à la présence de BOM (Byte Order Mark) dans les notice STAR (merci à Yann Nicolas) est-il possible de corriger ORI pour palier à ce pb ou devons nous tourner vers STAR ?
Merci d'avance pour tout élément de réponse
Alain
Le 11/09/2010 09:05, Alain Le Drezen a écrit :
Je confirme aussi que ORI n'importe pas le bloc<mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="tef_desc_edition"> pour les thèses STAR ce qui explique le message d'erreur décrit par Jean-François :
"Toute EDITION de la thèse doit être associée à des métadonnées de type "tef_desc_edition"."
Nous ne rencontrons pas ce pb sur les TEF-Sudoc que nous importons.
Alain
Bonjour,
Un autre problème lié à l'import de STAR (en plus du caractère étrange en début de fichier et de l'erreur signalé par Jean-François dans le workflow) :
Ori importe :
<mets:FLocat LOCTYPE="URL" xlink:href="\\Sql01\depot_these\Theses\STAR\STOCK\THESE_5162\DepotEdition\khelfaanissa1\khelfaanissa2\Khelfa.Anissa.SMZ0915.pdf"/>
Ce qui fait que nous nous retrouvons avec une belle URL de type :
\\Sql01\depot_these\Theses\STAR\STOCK\THESE_5162\DepotEdition\khelfaanissa1\khelfaanissa2\Khelfa.Anissa.SMZ0915.pdf
L'URL correcte est dans tef:edition :
<dc:identifier xsi:type="dcterms:URI">
ftp://ftp.scd.univ-metz.fr/pub/Theses/2009/Khelfa.Anissa.SMZ0915.pdf
</dc:identifier>
<dc:identifier xsi:type="dcterms:URI">http://STARFileDirectory/khelfaanissa1</dc:identifier>
Bon week-end !
Alain
Salut Yann,
Elle est en PJ. Bon week-end !
Jean-François.
Yann Nicolas a écrit :
Un exemple de fiche TEF avec cette erreur ?
Yann
----- Mail Original -----
De: "Yohan Colmant"< >
Ã: ori-oai-utilisateurs@listes.univ-rennes1.fr
Envoyé: Vendredi 10 Septembre 2010 15:06:53
Objet: Re: [ori-oai-utilisateurs] Pb import TEF
Salut JF,
Je réponds dans le mail.
Yohan COLMANT
Direction des Systèmes d'Information
UVHC<http://www.univ-valenciennes.fr> - Université de Valenciennes et
du Hainaut Cambrésis
Coordinateur Technique du projet ORI-OAI<http://www.ori-oai.org>
Jean-François Lutz a écrit :
Bonjour Yohan,
Merci pour ton aide toujours aussi efficace !
Je me permets de répondre sur les imports de fiches issues de
STAR. Comme l'indiquait Alain nous ne pouvons pas nous contenter
de les moissonner car les laboratoires et les écoles doctorales
ont été saisies dans STAR sans aucune liste ou forme d'autorité,
d'où un nombre très élevé de doublons (un même labo décrit de 5
manières différentes par exemples, sachant qu'il y a 82
laboratoires...). Nous allons donc les importer et utiliser les
listes d'autorité internes à ORI-OAI.
1. au niveau de l'import du fichier XML le problème est résolu.
Les fiches TEF XML produites par STAR comportent les trois
caractères suivants  avant la première balise de l'entête et
ils font planter l'import. Il suffit pour l'instant de les
supprimer. Peut-être la nouvelle version de STAR corrigera-t-elle
ce bug.
bonne nouvelle :-)
2. dans le workflow, l'édition se passe sans problème mais au
niveau de la publication, outre le fait qu'il faut cocher la case
"fichier maître" ce qui est un détail, un problème persiste sans
qu'Alain et moi arrivions à déterminer son origine. Le message
suivant apparaît dans la colonne "Informations" et il empêche de
publier la fiche : "Toute EDITION de la thèse doit être associée à des métadonnées de type "tef_desc_edition"." Quelqu'un aurait-il
une idée de la solution ? Merci par avance.
Tu as l'erreur quand tu essayes de la publier simplement ou quand tu
tentes de l'envoyer à l'ABES ? Et le problème a lieu avec une fiche
importée ou saisie de zéro dans ORI-OAI ?
Si je regarde cette erreur, elle vient du schematron de l'ABES avec
cette règle :
<pattern name="mets_structMap_meta_Edition"
id="mets_structMap_meta_Edition">
<rule
context="/mets:mets/mets:structMap/mets:div/mets:div/mets:div[@TYPE='EDITION']">
<assert test="@DMDID =
/mets:mets/mets:dmdSec[mets:mdWrap[@OTHERMDTYPE='tef_desc_edition']]/@ID">tef_easy.schematron.tef-abes.structMap.meta_Edition.check_rule</assert>
</rule>
</pattern>
Donc autrement dit, l'erreur apparait quand
/mets:mets/mets:structMap/mets:div/mets:div/mets:div[@TYPE='EDITION']/@DMDID
n'est pas égal à /mets:mets/mets:dmdSec[mets:mdWrap[@OTHERMDTYPE='tef_desc_edition']]/@ID
dans la fiche TEF.
Est-ce que ça parle à quelqu'un ?
Bon week-end.
Jean-François.
Yohan Colmant a écrit :
Alain,
Nous venons d'avoir une réponse de l'ABES pour le PPN et tu
avais bien raison : "le dernier caractère est un chiffre de
contrôle, qui peut être soit un numéro soit un X, il n'y a pas
d'autre caractère alphabétique possible. ".
Je te propose donc ce correctif (qui sera intégré dans une
prochaine version).
Dans
ori-oai-md-editor\WEB-INF\resources\forms\ori-md-editor\tef-global\form\form.xhtml
il faut remplacer toutes les occurrences de
[0-9]{9}
par
[0-9]{8}[X0-9]{1}
Donc pour les fiches du SUDOC, Ã part les champs qui ne sont
pas remplis à fond, ceci corrige ton problème ?
Concernant les fiches qui proviennent de STAR, tu ne m'en
avais pas parlé ?
Peux-tu m'en envoyer une d'exemple stp ?
Quand tu dis que ça plante, c'est au niveau du md-editor ou
déjà dans le workflow ?
Merci
Yohan COLMANT
Direction des Systèmes d'Information
UVHC<http://www.univ-valenciennes.fr> - Université de
Valenciennes et du Hainaut Cambrésis
Coordinateur Technique du projet ORI-OAI<http://www.ori-oai.org>
le drezen alain a écrit :
Bonjour Yohan,
Voici les éléments de réponse.
Le 10/09/2010 10:31, Yohan Colmant a écrit :
Salut Alain,
Je commence ENFIN à me pencher sur ton problème.
En premier lieu, pourquoi importes-tu les fiches dans
ton workflow ? Tu ne peux pas les moissonner plutôt ?
Comment les as-tu récupérées ?
Pour le SUDOC pas de moissonnage possible. Pour Star le
moissonnage serait possible. Mais dans les deux cas nous
devons modifier les notices ce qui n'est pas possible sur
une notice moissonnée.
LÃ , les erreurs que tu mentionnes apparaissent dans le
md-editor, mais pas dans le workflow ? Si tu veux
juste importer ces fiches et les publier, rien ne te
bloque ?
En ce qui concerne l'import, en effet pas de problème pour
les notices SUDOC. Ce n'est pas le cas pour les notices
STAR qui elles plantent dès l'import..
Cependant certaines notices SUDOC ne sont pas éditable
dans le workflow ce qui empêchera de les compléter et donc
de les publier.
Si je n'arrivais pas à débloquer ton problème avant le
retour de Nolwen, est-ce que tu serais bloqué ? En
gros, as-tu besoin de modifier les fiches que tu
importes ou non ?
Oui, nous devons les modifier avant de les publier. Par
exemple la thèse nommée "Quelle formation pour le médecin
généraliste psychothérapeute de fait" ne s'ouvre pas dans
l'éditeur à cause des caractères spéciaux en début de titre.
Si non, tu peux simplement importer les fiches et les
indexer. Effectivement, si tu cherches à les
visualiser dans le md-editor, tu auras ces soucis,
mais cela te permet tout de même de faire l'import en
attendant ?
Second point, c'est Nolwen qui est plus à même de
répondre à tes interrogations sur le module, donc je
vais faire de mon mieux :-(
Pour commencer, j'ai pris en exemple la fiche
Metz_13738551X.xml
1) Les erreurs liées au nom et prénom qui ne doivent
pas être vides sont connues. Là on a des choses à faire par la suite, mais c'est juste un soucis
d'affichage. Il te suffit de cliquer sur le nom et
refermer la fenêtre de saisie de la personne pour voir
que l'erreur disparait. Nolwen n'avait pas réussi à contourner ce problème avant son départ.
Lorsque tu as un PPN composé de 9 chiffres comme prévu
jusqu'ici dans l'éditeur TEF, le même problème se
pose, ouvre et referme la fenêtre de saisie, tu verras
que ça marche en fait.
Ca c'est un pb connu
2) Il manque des mots-clefs en français. Ils sont
décrits comme obligatoires dans le TEF :
http://www.abes.fr/abes/documents/tef/recommandation/dc_subject.html
Ok normal
3) Pour le PPN qui comporte 8 chiffres et une lettre ....
J'ai essayé de joindre les collègues fonctionnels mais
ils ne sont pas joignables pour le moment. Les
quelques docs que j'ai trouvées parlent bien de 9
chiffres. Tu as une info ou une doc où ils parlent
d'une possibilité de caractères autres ?
Voici un extrait de la doc de l'ABES :
Zone 001 : Numéro d'identification de la notice
Zone système protégée, obligatoire, non répétable, sans
indicateurs et sans sous-zones.
Le contenu de la zone est générée automatiquement par le
système lors de la validation d'une nouvelle notice
Dans le Sudoc, l'identifiant unique de la notice est
appelé ppn (= Pica production number). Il comporte 9
caractères :
8 chiffres (attribués par le système de manière
séquentielle = numéro d'"ordre" de la notice dans la base
de données)
une clé de contrôle sur 1 caractère, qui peut être un
chiffre ou "X"
4) Concernant le fichier maintenant ...
Je ne connais pas assez le TEF, mais je sais que le
type mime et l'URL du fichier sont à 2 endroits dans
le TEF que nous générons.
Dans tes fiches, cela n'apparait qu'une fois. Il reste
la rubrique suivante qui est vide :
<mets:fileSec>
<mets:fileGrp USE="archive" ID="FGrID1">
<mets:file ID="FID1" MIMETYPE="" ADMID="file_1"
USE="maitre">
<mets:FLocat LOCTYPE="URL" xlink:href=""/>
</mets:file>
</mets:fileGrp>
</mets:fileSec>
D'où l'erreur dans l'IHM ...
Si on se réfère à cette doc, on lit "*Seule l'édition
d'archivage doit obligatoirement être représentée dans
cette section.* Cette présence est facultative pour
les autres éditions. ".
Dans ton cas, si je prends la fiche
Metz_13738551X.xml, on voit bien USE="archive" dans le
bloc mets:fileSec. Si je comprends bien, dans ce cas,
les métadonnées MIMETYPE et URL sont obligatoires. Ici
elles ne sont pas remplies.
J'ai corrigé mes fichiers en remplissant<mets:fileSec> et
je récupe^'re bien l'URL lors de l'import.
Pour l'anecdote je n'ai pas réussi à importer un fichier
TEF généré par ORI (pas de chance ???)
Je reviens vers toi quand tu auras pu me donner un peu
plus d'infos et fait un retour sur ce mail.
Je te dirai aussi ce que j'ai eu comme infos pour le PPN.
A bientôt,
Yohan COLMANT
Direction des Systèmes d'Information
UVHC<http://www.univ-valenciennes.fr> - Université de
Valenciennes et du Hainaut Cambrésis
Coordinateur Technique du projet ORI-OAI
<http://www.ori-oai.org>
Alain Le Drezen a écrit :
Bonjour,
Voici quelques problèmes rencontrés lors de
l'import de notices de thèses du SUDOC (import en
pièce jointe).
L'URL du fichier (<dc:identifier
xsi:type="dcterms:URI">) ne s'importe pas.
La notice de la thèse "Quelle formation pour le
médecin généraliste psychothérapeute de fait" ne
s'affiche pas dans l'éditeur (page grise vide). Il
semble que ce soit lié à la présence de caractères
étranges en début du titre. Mais ceci ne devrait
pas être bloquant.
Dans l'éditeur, l'erreur "Le PPN du mot sujet
Rameau doit être composé de neuf chiffres" est
erronée. Un PPN peu contenir des caractères.
Merci d'avance pour tout élément de réponse.
Alain