Post by Christoffer LandtmanPost by Wolfgang Pichlerwill emilda have scheduled some layer to translate other
record-syntaxes than MARC and/or will there be a shift from MARC-only
internal storing of bibliographic data ?
i would like contribute regarding MAB since this is essential for krauts :-)
(but i fear this could only happen with perl-code and you have
committed to shift to pure php ...)
Hello Wolfgang,
I do not believe that we at least for the moment will move away from
MARC as the internal data format, due to the strong linkage into
Zebra. Of course one could discuss wether the usage of e.g. MARCXML
would be a good idea, but I consider this to be a secondary issue.
MARCXML sounds great insofar that the only possible path seems to be
MAB -> MABXML (java classes from DDB - the german library, no source code)
MABXML ->MARCXML (ahem ** to be done ** : possibly via some xslt, i
will try to get expertise how to map them accordingly)
but anyway the final step should not be a problem :-)
MARCXML -> MARC (MARC::File::XML,MARC::Record or java classes from
www.loc.gov/marcxml/ incl. source code)
as zebra can index virtually anything it would be maybe a good idea to
discuss any including cql/srw/sru,oai, .... ok ok i am stupid now :-)
<jokes/>
1) MARCXML would solve probably some encoding and presentation issues
(utf8!) at least for _Native Data since all codepage translations could
be designed to take place in the import-filter/converter and nowhere else
2) MARCXML would be a good idea to be ready for future requests of
external representation/delivery such as OAI, (zing seems dead,) and i
think of virtally any other newer thingies to come or exist already
2)a) yaz-proxy would help to migrate "old" records into "new" ones :
just configure a yaz-proxy pointing at the "old" MARC-based-z3950 and
fetch them as MARCXML from the proxy if the record does not yet exist in
the "new" MARCXML-based-z3950 and feed them in on the fly !
3) IMPORTANT : i think it is more efficient to write PHP_MARC _now_ for
XMLMARC and not for MARC21 (you will save time and work, because it will
happen anyway :-)
Post by Christoffer LandtmanAs a matter of fact, it should be fairly simple to make Emilda
understand any random dataformat, as long as there is a
module/extension to PHP-MARC that can convert this random data blob
into a PHP_MARC object. Then Emilda will store this record as MARC in
the database, but the initial import was made from an external format.
Of course I have not tested this, so I cannot guarantee anything, but
it might be worth while to at least investigate. I have absolutely no
experience of MAB, so I cannot tell you how difficult it would be to
create a MAB->PHP_MARC parser, but if it was possible to create a
USMARC->PHP_MARC class, I cannot imagine that it would not be possible.
i see i will have a closer look at PHP_MARC and its functionality
i think it is a good idea to implement a ZOOM-binding for php (is it ?)
Post by Christoffer LandtmanIf you could link me to some definitions on MAB and maybe give me an
example record, I could be of more help.
oh there are tons. but i think it is better that i will work out some
summary infos and do some "pre"-work - but thanks for the offer i will
come back to it :-)
as outlined above it is a good idea to map MABXML->MARCXML for sake of
simplicity
yea regards too - hope you have a fine time
w.p.