http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662
--- Comment #31 from David Cook <[email protected]> --- _HOLDINGS_ Diagramming this now... OAI ID -> Koha ID -> Original 001 -> Parent 001 oai::1 -> bib1 -> 1a -> null oai::2 -> bib1 -> 1b -> null oai::3 -> item 3 -> 3a -> 1a oai::4 -> item 4 -> 4a -> 1b So here we've downloaded oai::1 and added it as bib1. We've downloaded oai::2 and determined that it is a duplicate of bib1. We can either overwrite bib1 or we can simply link to it. We've downloaded oai::3. It's original parent 001 is 1a, so we can link oai::3 to bib1. We've downloaded oai::4. It's original parent is 1b, so we can link oai::4 to the entry for oai::2, which is bib1. In this case, the only problems we have are determining what makes a match, and determining whether oai::1 or oai::2 should provide the metadata for bib1. We probably need another field to say which OAI record is the source of truth for bib1. I might be able to use the existing C4::Matcher() for this... It's worth noting that the downloaded metadata will need to be used every time there's an item update, because the National Library of Sweden requires that item-level data be merged into the host bibliographic record... and the only way to do that cleanly is to start with a virgin bibliographic record each time. (Otherwise, when you change a 863 in a holdings record, you won't be updating a 863 in the bib record, you'll be adding a new one and the old one will stay there incorrectly.) Every holdings record will also need to be merged in as well, which could probably cause load problems with records with lots of holdings... Actually, I'm not sure how that's even possible now that I think about it... since you're harvesting from the holdings endpoint every 2 seconds... I suppose you could queue updates to a bibliographic record from the holdings records... but that wouldn't make sense as every updated holdings record would require a full update of the bibliographic record from all holdings records... so any update would need to be processed. I suppose you could queue updates in terms of... if there's a holdings-bibliographic merge in progress, don't start another one as things will explode... still seems like a potentially intensive operation. -- Problems to consider and solve (anyone can chime in here): 1) Precedence of bibliographic-bibliographic merges 2) Merging holdings records into bibliographic records (e.g. 852 and 863 into the bibliographic record... not 952 into bibliographic record) 3) Any local changes to a record will be erased by future downloaded updates -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
