I just wanted to re-ask this so I am absolutely clear. Once your (Dan
Wells) development is complete, to migrate serials all we should have to do
is
1. Export Bib records with MFHD from old system
2. Import bib records through Vandelay
3. Evergreen will display existing holdings based on the MFHD holdings info
4. Prediction schedule for tracking and receiving of serials will be created
Thanks, i just want to be sure I have no false assumptions.
Tim Spindler
Manager of Library Applications
tspind...@cwmars.org
508-755-3323 x20
C/W MARS, Inc.
http://www.cwmars.org
On Wed, Jan 5, 2011 at 4:15 PM, Repke de Vries re...@xs4all.nl wrote:
Hello's Dan (Wells)
sounds very reasonable - though I may have some questions for you tomorrow
to fully understand your approach (like: your point of departure are the
raw MFHD data Dan Scott's marc2sre import script puts into the Evergreen
database?)
And will send you a sample of the IISH MFHD records.
Your statements 1 and 2 anyway are very reassuring: to preserve the
original, already existing MFHD record(s) belonging to a bibliographic
record, keep these as a fall back mechanism and at the same time have all
new, serials *management* related data available, should mean that even
after a few years it will still be possible to export to MFHD and have the
full original again + any changes additions that happened along the way.
Coming back to you off list with those example records, Repke
Op 5-jan-2011, om 20:30 heeft Dan Wells het volgende geschreven:
Hello Repke,
Would it be possible to get a few of your MFHD records for testing? I am
interested to see if they are very different from my own experience.
As it stands, the general assumption is that MFHD records are used to
describe holdings for the primary purpose of generating a holdings
statement. The new database tables do that too, but also other things
concerning the day-to-day management of serials. As opposed to the actual
holdings statement, this management data is very much ephemeral.
Our plan right now is to *not* immediately populate the new tables with
historical data. Rather, since the new data is internally converted to MFHD
anyway, both the MFHD and the internal data will be considered
simultaneously when generating the holdings statement (the last bits of
logic to make this happen are still being tested, but I am confident they
will be ready to commit soon). This provides several immediate benefits:
1) The original MFHD record is fully preserved, with no chance of being
mangled by the system.
2) The MFHD record can be used at any time as a fallback mechanism should
the new system not properly accommodate a given situation.
3) We do not need to write an import script :)
All of this is likely to change as the system matures, but the weaning can
be gradual and perhaps always optional.
Does this sound reasonable?
Thanks,
Dan
--
*
Daniel Wells, Library Programmer Analyst d...@calvin.edu
Hekman Library at Calvin College
616.526.7133
On 1/5/2011 at 12:31 PM, Repke de Vries re...@xs4all.nl wrote:
Hi all
with Serials in 2.0 I mean the new database setup introduced by
Dan Wells + two sets of functionalities on top of that: Serial
Control View and Alternate Serial Control (by two different
programming teams).
And my question goes back to an early november 2010 Evergreen 2.0
alpha4 discussion [1] where we had to conclude that an importing
script for MARC MFHD records to populate all the Serials 2.0
database tables, did *not* yet exist - though several libraries (ours
among them) expressed the need for it [2].
I wonder where we are now: anyone working on such a MFHD MARC records
importing script or approach?
Our library might be able to contribute but one would expect that at
least some script exists by now that could be further refined.
How else could we seriously introduce these new Evergreen 2.0 Serials
features if we can't get the data in (not to mention: export them
again) :-)
Yours, Repke de Vries, IISH
[1] http://markmail.org/message/75tlejvni3mit5ke
[2] I do *not* mean the MFHD options + importing scripts introduced
by Dan Scott in EG 1.6
--
__
Tim Spindler
tjspind...@gmail.com