Allow importing from different OPACs
janusman - January 7, 2009 - 16:36
| Project: | Millennium Integration |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
This would let Drupal serve as a central search index for different OPACs.
Bonus points: The "same item" in different libraries occupies one node only (instead of having one node of the "same item" per OPAC). This would mean showing the user all holdings for all crawled OPACs from within the same node; would have to determine how to detect the "same item", which MARC record prevails (newest-changed? priority for each opac?)
#1
Probably "same record" would only be feasable by using LC or OCLC numbers in MARC.
#2
As of today, the underlying code and database tables are almost finished to allow this.
TODO:
* reimporting items, checking availability, etc. are still not looking at the originating URL from {millennium_node_bib} and instead assume the current URL.
* it should be possible to configure different opacs in the settings page, and then just pick which to import from during manual import.
* "This is the same item" (a.k.a. FRBR?) algorithms. Perhaps not in the scope for this project, but could be an add-on module that could intervene during the import process?
#3
Looks interesting! About FRBR-ish algorithms: I've come to the conclusion in my own project, that each FRBR entity type needs its own CCK-enabled node type. For example, I have a new node type for works, containing nodereferences to the different manifestations (which are actually the very nodes generated by Millennium Integration). I think this is a good solution: you can use different heuristics to derive works from manifestations, comparing titles, authors and other things (maybe even using WorldCat / LibraryThing APIs). The results so far are promising, not quite finished yet though. Same approach might work for this feature..
#4
I'm committing this patch for now; mainly it includes an optional base_url argument in lots of functions so that the information is fetched from the WebOPAC the record was imported from instead of the current module's settings.
#5
Setting to needs review
#6
Missed a few.
#7
Committed last patch.
Need more testing.
#8
I think the only thing missing is to explicitly let the admin configure different OPACs on the settings screen.
#9
Uh, no; the mass import functions are missing quite a bit. For instance refresing records will default to the currently-set WebOPAC instead of the source for that record.