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

[Dan Wells]

Hello again,

>>  pattern_code: 
> "['2','0','a','v.','b','no.','u','12','v','r','c','pt.','u','3','i','(year)',
> 'j','(month)','k','(day)','w','j']"
>> ]
>
> OK, so just an terminology mismatch so far. That's pretty much what I
> was thinking too (though we'd want to use JSON in the pattern_code
> column, IMO, which has different quoting semantics from your example
> ... but that's immaterial to the example).

Yes, surely this field will be JSON.  In the purest form of lazy-exampleness and an effort to edit the MARC original as quickly as possible, I just couldn't be bothered with pressing the shift key for all those double-quotes ;)  I also didn't realize until now that JSON was stricter than JS in that regard (using JSON outside of JS is still pretty new for me).

> 
> OK ... would this mean that a single MFHD would have two patterns, or
> there would be two MFHD records?  If the former, the l can see the
> duplicate/deleted link id problem, but IMO that's also easy to guard
> against by refusing to store an MFHD that is not self-consistent (and
> we can check for that in obvious ways).
> 

Yes, a single MFHD record can have several of the same type of pattern (and several of different types, of course).

> As for having two active patterns, it sounds like we just need to
> 1) include the link value in the serial.caption_and_pattern row
> (recall, we can enforce correctness on MFHD at insert/update time)
> 2) use that link value when looking for the pattern to deactivate
> 3) assume a link value of 1 (or 0, if 0-based counting, dunno) when
> there's only one.
> 

At the very least we would also need to consider $o (type of unit), but this only leads to other problems.  While we can reasonably infer that the highest link_id of any given $o is the most likely to be active, we simply *can't* tell (from the MFHD) if it actually is or is not.  For instance, maybe that supplement just doesn't come any more, got renamed, etc.

But this only matters if the MFHD is trying to be authoritative...

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