[Koha] MARC importing tool?

[Wolfgang Pichler]

MJ Ray wrote:

>Wolfgang Pichler <wolfgang.pichler at ivv.tuwien.ac.at> wrote:
>  
>
>>MJ Ray wrote:
>>    
>>
>>>Existing data from what? 
>>>      
>>>
>>source : ms-access data (id,author, title, maybe isbn and many other 
>>fields, all heavily postprocessed by exporting cvs and running heavy 
>>    
>>
>
>You store access data in CVS?
>
a typo : data exported as csv ...

>
>  
>
>>perl-scripts to check if isbn is valid, to try to figure out multiple 
>>authors, since they are given with various delimiters [ John & Jack Doe 
>>/ Doe, John and Jack / Doe, John ; Smith, J. / and all that funny things 
>>an unconstrained user may do :-(((,  -- size about 16000 items !)
>>    
>>
>
>OK.  You could output MARC records, would be my best guess.  Maybe someone
>here can point at helpful things about MARC.
>  
>

i am experimenting /w marc, esp. Net::Z3950 and have good pointers about 
it, though in this complex subject one will never stop learning :-)

i am missing some MAB2 -> MARC21 conversion tool and good MAB2 
documentation, since this all is related to  g e r m a n  literature 
where the relevant austrian Z3950 servers will often deliver just MAB 
record syntax, and no MARC.

also if someone has a sophisticated html-postprocessor, which can do 
good reformatting from html-opac-queries (which are free vs. z3950 !), 
it would be a great help.

of course i intend to design my scripts for reuse and make them 
available too.

>
>I'm not 100% clear on this just now and I doubt it will become clearer
>until you have a testbed running.  Maybe other library users can explain
>how they cope with current issues while moving to koha?  Just reenter,
>run the two systems alongside, or something smarter?
>
there must be a clear switch, the old system is too stupid to be run in 
parallel.

of course there will be a testing/target environment and i will try to 
migrate most of the old data in incremental batch runs followed by 
interactive "smoothing", but these will be customized Perl/Tk's tailored 
to the specific actions necessary and yielding sets of importable data 
which will be fed in one go when switching will happen (formerly tested, 
of course)

since it is acceptable to inhibit deletions for a while there should be 
no problem with ghost items or dup's.

remember, since i will have to build/keep  "shadow"-data of the current 
system and feed it in one go, everything should work just fine, if koha 
just works fine.

the only problem is : what to feed where in mysql :-)

>>they wish to reorganize the current overall shelving and collection 
>>systematics (not sure where to find it in koha : 
>>biblioitems:classification ?)
>>    
>>
>
>Again, this is probably something other library users on this list can
>advise on, but I think that's where you should be looking.
>

>>there are many tinyint's and char(1-4) in the db-scheme, which are 
>>obviously sometimes booleans, or other indicators for some status
>>(biblio:serial == boolean : is a serial?, borrowers:categroycode, 
>>reserves:found...).
>>    
>>
>
>Yes, I admit that I'm not sure why they are those types instead of
>enumerated or foreign keys in another table, unless it's because we're
>*still* working without foreign keys in MySQL :-(
>
>  
>
>>any summaries about these ? or just RTFC ?
>>    
>>
>
>A better question for -devel.  If you can post a complete list of these
>unexplained ones, developers of the relevant parts will explain it
>eventually, I guess.
>
i hope so. but i fear, that a lot of reverse engineering by me will be 
necessary.
since everyone who will have to migrate data will have to do so 
currently, lacking overall docs ARE a major factor to inhibit using koha.

cu wolfgang

>
>  
>