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

[Mike Rylander]

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