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 >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. > > And I'm sorry if I sounded snippy in my previous email, it wasn't intended. I didn't take it that way, but in any case, it can certainly be frustrating to try to work through ideas using text when it could probably be hashed out in 20 minutes in person. At least we will have some good documentation about why we did things we did :) Thanks again, Dan
