On 04.02.2014 17:00, Ferran Jorba wrote:
Hi!
Which is the correct way of getting this value, other than peeking
into the directory name of the file under
$INSTALL_DIR/var/data/submit/storage/done/running/?
I fear this is the only way, but you need to know the submission ID
then which might be equally complex to fiddle out.
That's why we acutally store submission id as well as submission
doctype in Marc along with the record. We need this for this fancy
[...]
I see. My way of extracting those equivalences is in batch every night,
using a somewhat less crude version of the script I posted to the list a
while ago:
https://www.mail-archive.com/[email protected]/msg00596.html
But in a new workflow I need to know it in a more realtime fashion.
As you can extract it from the curdir during submission, you could
probably just add a function to your websubmit workflows to add the Marc
field in question automagically right before the bibupload call.
We have something like this implemented for these "multiple type"
entries (proceedins in journals) that basically checks: if you enter
conference data to a journal article or journal data to a proceedings
article then add the missing doctypes. In our case it's a search request
for a proper authority against Invenio, output format JS and processing
of that. Our 3367_ notion is a bit complex as it handles also DRIVER,
BibTeX and Endnote doctypes, and in case of theses we also need to add
some 650 field and fiddle with the 502. (Degree subfields)
Unfortunately, I cannot easily add those values in my templates, because
I'm reusing a few templates for a larger number of websubmit forms or
doctypes. Given how long it takes to properly debug a template, I'm
trying to keep them under Ockham's rule.
Understood. Otherwise I'd have suggested to check out Tomeks automagic
Websubmit setup routin, but this will require a bunch of adoptions on
your end. Maybe worth the time as you have several sites. (This stuff
just takes a fancy config file and then sets up websubmit as a batch job
and can also handle multiple configs, defaults and stuff.)
Anyway, adding a funtion I think could be done in a microinvasive way.
We have a websubmit fuction Make_HGF_Record right before the
insert_record call and I think you should have something similar in
default/your websubmissions, that just generates the final recmysql that
goes to bibupload. This would probably be the place to go.
Or one step before that, depending on your layout of the submission dir.
In our setup it's pretty easy if we just add another file hgf_<marctag>
there it's just included in the final record. Probably this is similar
in your case?
Finally, even patchhacking ;) Insert_Record by just adding another XML
datafield before the final ingestion would be an option. But if it helps
I could dive into Tomeks code and search the APIs to add websubmit
functions at the proper place. Would be cleaner, I think. On the other
hand you have exactly one generic value to store.
In any case I think you'll need to have the submission doctype in your
Marc. At lease we did not find any other way though Tomek did quite some
searches within invenio for exactly that issue. I think the original
idea of webmodify doesn't need this info as you call the doctype by
hand, then modify and then the report number. As far as I got it it
doesn't care that you select the "correct" type.
--
Kind regards,
Alexander Wagner
Scientific Services / Scientific Publishing
Central Library
52425 Juelich
mail : [email protected]
phone: +49 2461 61-1586
Fax : +49 2461 61-6103
http://www.fz-juelich.de/zb/wp
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
