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

[Mike Rylander]

On Fri, May 28, 2010 at 4:41 PM, Repke de Vries <repke at xs4all.nl> wrote:
> Hi Mike
>

[snip]

> 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 ?
>

Exactly.

> 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 ?
>

It does, and my proposal easily supports this by creating, at export
time, a derived record by starting from the MFHD and pushing the
non-MFHD data into the derived record.


--miker

> 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
>>
>
>



-- 
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