Hello Henning, contrary to Alexander, I can easily find scenarios where ingesting records from external sources is a good (or the best) strategy, and we have done quite a bit here at UAB, from all kind of sources. So, after taking a look at your example, you may be interested in avoiding some of the mistakes I've run into.
> Today I had a meeting with my manager, and we decided to use a simple > plain text input format (instead Excel/CSV) that should be convertible > with BibConvert, e.g.: > > FILE Literature/Educational/16527.epub > CAT Educational;Math > TITLE 1001 задача для умственного счета > AUT Rachinskij, Sergej Aleksandrovich > DESC A collection of mathematical puzzles > LANG rus > YEAR 1899 > PUBL Project Gutenberg > SRC gutenberg.org > LIC Project Gutenberg License > REFNO 16527 > KEY sadanye > KEY puzzle > > Most key codes can appear several times, and we defined some more > codes than shown here. (Of course most contents will be in Russian, > but I wrote my documentation and samples in English.) First of all, please, please, make sure that those records have an unique identifier. You'll find yourself loading and reloading them, either on your test or your production server. This unique identifier will allow Invenio to replace the older version with the new one reusing the same Invenio identifier. You can find a similar thread here: http://www.mail-archive.com/[email protected]/msg00468.html If you have different «sources», you can use a simple subfield $9 for the source identifier and $a for the number. The second lesson is that, if you end up using «simple» office applications, I think that repeteable values are better solved with a known character, like the semicolon you seem to use, rather than multiple columns, because you can repeat the value zero or more times without wasting fields. And finally, I don't know how flexible is BibConvert, as I don't use it, but if you feel confortable with Python, probably in the long run it will pay to invest on it, as probably you'll have to fiddle with some subtle cases where the flexibilty of a real programming language will help you. >> For a unified search you'd like to have I think at least >> Invenio 1.2 (current head master, if Tibor managed to merge >> authority based searches yet). > > Grmbl, I forked at v1.1.2.473-1ab71 and decoupled. But I must learn > how to manage upstream changes in git anyway. At the moment, I set my > personal server repository as origin, develop on my Mac and pull > changes from the development web server. All my changes > (e.g. configuration, web style, docs) are in a personal branch, so it > should cause no problems to pull master. You may take a look at guilt. I did a brief introduction during last year Invenio Users Meeting that I hope to expand this november. The slides are here http://ddd.uab.cat/record/93913 My 2 cents, Ferran
