Am 2013-10-10 um 18:36 schrieb Alexander Wagner <[email protected]>:
>>>> * I’ll get my metadata in Excel files. > [...] >> Or a bunch of public domain eBooks (just author and title, >> no hint about which edition was used etc.). > > Your collection shound't get too large with such little > amount of data. (Ok, I'm a librarian. ;) The collection won't get very big, as far as I can forsee. (My father is a bookseller & publisher, my ex-girlfriend is a librarian, I’m a typesetter…) >> Several authors are easy: >> Last1, First1 Middle1; Last2, First2; Last3, First3 Fathersname3 > > Good luck… I really believe it’s good enough for this project. >> I get different media/document types in different tables, >> the differences are marginal (e.g. number of pages vs. >> length in minutes), and I can handle them in my script. > > Just as a simple word of warning: this stuff tends to get > messy over time. Of course. We’ll stuff some thousand files at once into the database, and later probably just single additions. Nobody expects wonders - GIGO... >>> (BibTeX or friends are not an option? Would at least handle >>> the simple specialities correctly. Editing via Jabref e.g. >>> is quite easy…) >> >> The staff only knows "standard" office applications; I >> bother the translators to use POedit, but won't try to >> convince anyone to use some other program that I never >> used ;-) > > Any literature management tool (commercial stuff like > EndNote, Citavi, RefManager,... well I live more in the free > world of Latex) has some advantages here, if you want to go > for batch upload. Simply as it guides the user a bit to what > fields are required and picks them apart. > > OTOH, if they enter it manually anyway, you would probably > be better off with setting up simple websubmits, that handle > your fields. I’m also a TeX user (ConTeXt actually), but not an academic one - never used BibTeX & friends. WebSubmit is too laborious if you need to upload some hundred files at once. It’s good for later additions. Using Excel, the metadata can get enhanced/checked by several people before we process it. Esp. I can look over it without database queries. But I’ll ask is someone has experiences with literature management tools - but since most of our media won’t be "literature", but films, audio books, posters, pictures, brochures plus some eBooks I guess it wouldn’t help a lot. >> I'll still have to find out how to… >> - translate/alias keywords or taxonomy (we need to find >> media independent of language) > > Well you have fields for them. Indexing would go to the > 650-fields in Marc (check out indicators; 6507_ with > subfield 2 mentioning the source could be resonable), for > titles you have 24x fields. Translated titles would map to > 242, subfields a for main title, b for subtitle, y for > language code. Then you could expand your title-index in > invenio to cover those additional fields. > > Anyway, in a flat table you have some problem if not all > fields apply. Say you have in some cases an english, a > french and a german title you xls would require all three > columns all the time. In websubmits you'd just leave the > fields blank and let the submission functions handle it. We (probably) don’t need multilanguage titles (if, then the medium has several titles and we’ll put all of them into the title field). We just need translatable "tags", so that someone looking for "dog" also finds media tagged with "hund" and "chien". In fact, our languages are Russian, Kyrgyz and sometimes English, maybe Uzbek, Kazakh, Dungan, Tadjik. Most of our users’ mother tongue is Kyrgyz, but they also understand Russian. Can you hint me on the docs about setting up a (translatable?) taxonomy tree or similar structure? Is that what "collections" are about? >> - cope with media that consists of several files (e.g. >> audio book chapters) > > Several files is not that much an issue as you can just add > a bunch to any dataset. You can repeat the special fft-tag > in your MarcXML and upload them in one go eg. Ah, yes, saw that. And since I’ll generate MarcXML myself, it’s not an issue. >>> BTW: The upcoming Invenio User Group meeting might be of >>> interest to you. >>> http://indico.cern.ch/conferenceDisplay.py?confId=258575 >> >> Would be nice, but I'm sitting in Kyrgyzstan for the time being… > > Well, could have worked out. Especially, to give you a > helping hand at starting out, as many users/programmers will > be here in one spot. I’ll be back in Germany not before summer 2015. I don’t know, if my Invenio installation then still works, it’s just a pilot ATM. Greetlings, Hraban --- http://www.fiee.net https://www.cacert.org (I'm an assurer)
