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

[Repke de Vries]

Thanks Mike - could you also confirm or comment on our understanding  
of your Class 1 scenario ?

Class 1 would be the IISH's other Serials case where we have:
" .. periodicals arriving at the Institute with a collection of  
books, archive, photos etc. .. these do not
have to be linked with all the serial management data, they only  
have / need a 852 (call number) and a 866 (textual holding)..."

meaning that such "legacy MFHD records" sit as MARC column in the SRE  
and can be edited, added to and exported again as MFHD records   
(legacy + maintenance)

and for this scenario the system can be told *not* to interpret  
imported MFHD data  - "nothing hanging off the other side" - and that  
MFHD MARC Editor functionality is enough ?

Seems like it.

Repke, IISH


Op 30-mei-2010, om 17:16 heeft Mike Rylander het volgende geschreven:

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