[OPEN-ILS-DEV] Serials Schema Proposal - Further De-emphasis of MARC as Record Format

[Repke de Vries]

Hi Mike

the following continues comments by my colleague Marjolein Kremer +  
team to this thread here and to the related one that  Dan Wells  
posted on the General List (both by Marjolein on May 27):

1) the IISH will be migrating from the INFOR Advance ILS to  
Evergreen, works closely with the Conifer consortium and like they  
did will migrate hundreds of thousands of Bibliographic - full MFHD  
record(s) combinations to Evergreen.

Call them "legacy MFHD data" if you wish but reason for IISH to  
choose Evergreen over other contenders was the fact that Conifer's  
work on MFHD made it possible to read in MFHD records and then  
(capital letters !) keep and maintain these in MARC as well. In other  
words: would  we have to export again from Evergreen, we would have  
exact MFHD copies of what we put in including possible edits + of- 
course the newly added MFHD records. No data lock-in by Evergreen. No  
losses.

I am trying to figure out from this Serials Schema Proposal  
discussion if  that original "always keep the legacy MFHD data fully  
available"  idea is getting abandoned - but at least your position  
Mike seems to keep allowing "legacy MFHD records" and  they sit as  
MARC column in the SRE and can be edited, added to and exported ? [1]
And this would be your Class 1 scenario and cover what Marjolein  
described on this list as
"..
2.	 Periodicals we receive in bulk parts. They arrive at the
Institute with a collection of books, archive, photos etc. We have
around 100.000 serial records in the database These periodicals do not
have to be linked with all the serial management data, they only need a
852 (call number) and a 866 (textual holding).
.."

Please correct me if I am wrong.

2) and your Class 2 scenario would cover the other type of Serials  
Marjolein described:
"..
1.	Subscriptions. We have about 1500 subscriptions  in our present
Serial Module  (Advance ILS  and migrating to Evergreen later this
year), in which we control the predictions, receiving, claiming and so
on. We would like to continue this.
.."

Correct ?

Here we would like the imported MDHD record to be be interpreted and  
available for Evergreen's new  Serials Management functionalities but  
expect an Export from Evergreen to consider both the originally  
imported MFHD record(s) and any of the changes recorded in separate  
tables outside the MFHD record.

Does that makes sense ?

Thanks, Repke de Vries, IISH, Amsterdam

[1] what Dan Wells coined the "conservative approach" on the General  
List recently and Marjolein / IISH also replied to

Op 28-mei-2010, om 2:13 heeft Mike Rylander het volgende geschreven:

> On Thu, May 27, 2010 at 5:32 PM, Dan Wells <dbw2 at calvin.edu> wrote:
>> Hello again,
>
> [ snip stuff we agree violently on ;) ]
>
>>> If we say "the MARC stored in SRE is completely non-authoritative",
>>> I'm cool with that.  But we still need something that sits at the  
>>> top
>>> of the "tree" and links through to a bib record.  Ignoring the fact
>>> that SRE contains MARC, it also fills those two roles.  And, there's
>>> the benefit that we /could/ generate patterns in batch from that  
>>> data.
>>>  But think of that as a one-time conversion, not the "normal"  
>>> process.
>>>  Also, the legacy/stop-gap is restricted to a single column  
>>> instead of
>>> a whole table.
>>>
>>> If we make the MARC field nullable (so that we don't require a real
>>> MFHD to do our work) would you be OK with using SRE as the top of  
>>> the
>>> tree and link to BRE, and using your pattern editor to populate  
>>> SCAP?
>>>
>>
>> I am certainly on board with the SRE being "completely non- 
>> authoritative" and using it in a one-time conversion role!  I am  
>> also fine with it keeping its place in the tree if we don't want  
>> to bother with a 'sister' serial.serial table.  It just *seems*  
>> clearer to me from an organization perspective to keep them  
>> different.  For instance, the OPAC logic might say:
>>
>> BRE -> has SRE? -> draw section from current display logic
>>
>> and completely separate:
>>
>> BRE -> has SS? -> draw section from new display logic
>>
>> From a schema perspective, the SRE would link to BRE and AOU, but  
>> nothing else would link to it.  The SS table would take its place  
>> in the new tree, and likely discard not only the 'marc' column,  
>> but also the 'creator', 'editor', and 'edit_date' as well.  It  
>> also seems odd to me to retain a table named 'record_entry' which  
>> we hope eventually won't have any live MARC records in it.  That  
>> said, now that it is clear we are at least talking the same  
>> language, it actually *doesn't* (honestly!) really bother me to  
>> keep serial.record_entry as is with nullable 'marc' (and perhaps  
>> company).  I also know from this whole process that you have  
>> developed very good instincts in working this stuff out, so if  
>> your gut is telling you we need to stick with the SRE table,  
>> that's good enough for me.
>>
>
> Well, it is, but I'd rather convince you on the merits, if I can.  ;)
>
> Lets say we are using SRE and there is no SS.  Now, there are several
> combinations and amounts of data we might expect to find, but
> generally they can be classified into 3 sets:
>
>  Class 1
>     * The SRE points at a BRE (as all SREs must)
>     * It has a non-NULL marc column, IOW there's legacy MFHD attached
> to the BRE via the SRE
>     * There are no subscriptions or SCAPs hanging off the other side
> of the SRE from the BRE's perspective
>
>  Class 2
>     * The SRE points at a BRE (as all SREs must)
>     * It has a non-NULL marc column, IOW there's legacy MFHD attached
> to the BRE via the SRE
>     * There are subscriptions, and SCAPs and issuances and
> "controlled" holdings hanging off the other side of the SRE from the
> BRE's perspective
>
>  Class 3
>     * The SRE points at a BRE (as all SREs must)
>     * It has a NULL marc column, IOW there's /no/ legacy MFHD attached
> to the BRE via the SRE
>     * There are subscriptions, and SCAPs and issuances and
> "controlled" holdings hanging off the other side of the SRE from the
> BRE's perspective
>
> For Class 1, the display logic is obvious, we use the current setup.
>
> For Class 2, it's a little more complex.  I believe what we should
> have is a set of options
>  1) Prefer the legacy holdings display
>  2) Prefer the "controlled" holdings display
>  3) Display /both/ (this would be the default)
>
> These can be one OU setting that specifies either legacy or
> "controlled" exclusively, and in the absence of that setting we would
> display both.  Now, why would we want this? Well, if there are
> generated statements from the "controlled" holdings and textual (I
> think that's the right term -- free-text) statements in the legacy
> data, the cataloger would want both to be displayed.  Or, and this is
> a stronger argument I think, displaying both removes the need for a
> "dummy" subscription to cover what is in the legacy data -- just
> display the legacy holdings /and/ the "controlled" holdings, and only
> "control" serials going forward, and maybe work your way back to "the
> beginning of time" for each record.
>
> Class 3 is obvious in the same way as Class 1 -- just display what you
> have, i.e. the "controlled" holdings.
>
> In practical terms this means that we're just walking the path from
> BRE to SRE to SCAP-based holdings, and displaying everything we can
> along the way, subject to one preference check in the middle along the
> way.  (I'd argue that the OU setting could come later, after v1, which
> would make this even simpler for a first cut.)
>
> If we conceptually split SRE-based and SCAP-based holdings then we
> have two code paths to maintain, and less (or, at least, more
> difficult to code) options on what to display and when.  If we leave
> them "serialized" (heh, sorry, couldn't resist) then it's one code
> path and simpler integrating logic AFAICT.
>
> As for the utility of the creator/editor/etc columns, they're
> important in the legacy data context, but even when the marc field is
> NULL they are informative.  They tell us who created the BRE link to
> the attached SCAP data and when.  Also, I dont think there should be
> any restriction to stop the SRE from getting legacy MFHD /after/
> creation even if it starts NULL, and the editor will tell us about
> changes to that data.
>
> Thoughts?
>
> -- 
> Mike Rylander
>  | VP, Research and Design
>  | Equinox Software, Inc. / The Evergreen Experts
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  miker at esilibrary.com
>  | web:  http://www.esilibrary.com
>