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

[Mike Rylander]

On Mon, May 31, 2010 at 10:46 AM, Repke de Vries <repke at xs4all.nl> wrote:
> 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.

I can, indeed, confirm that that's what I meant.  I snipped too much
in my response, I guess ... the "exactly" was for everything you'd
said above that.  Class 1 is "what exists today."

--miker

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



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