Summary: | Create a bound with function | ||
---|---|---|---|
Product: | Koha | Reporter: | SJeffery <steven_jeffery> |
Component: | Cataloging | Assignee: | Galen Charlton <gmcharlt> |
Status: | REOPENED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | angela.berrett, chris, flyingendpaper, h.jones, J.P.Knight, lauren_denny, martin.renvoize, mathsabypro, viktor.sarge |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 20447 | ||
Bug Blocks: |
Description
SJeffery
2012-06-08 20:34:21 UTC
I think EasyAnalytics would do most of what you want. The one existing item will show with all related information (call number, availability, etc.) on all records that are connected to it. There is a need for a record, that actually has the item, but this record could be the first record in the bound volume or a collection record. Closing this, please reopen if I was too fast. While it is possible to accomplish this task in the most basic of ways with the current Koha version, that is not the intent of this ticket. This is a feature commonly available in other catalog software that needs to be coded into Koha at some point. (In reply to comment #2) > While it is possible to accomplish this task in the most basic of ways with > the current Koha version, that is not the intent of this ticket. This is a > feature commonly available in other catalog software that needs to be coded > into Koha at some point. Nothing 'needs' to be done, of course if it is a feature you really want you can send a patch, or hire someone to do it. Or ask really nicely for someone to give up their time to do it for you. Also barcode is unique, so this feature as described won't work. (In reply to comment #4) > Also barcode is unique, so this feature as described won't work. It could be that the way it is implemented on the back end is different than described above. For example, an auto-generated barcode might be used. The link below describes the workflow in one ILS. https://staff.lib.ncsu.edu/confluence/display/MNC/Bound-with+Feature+with+Examples (In reply to comment #5) > (In reply to comment #4) > > Also barcode is unique, so this feature as described won't work. > > It could be that the way it is implemented on the back end is different than > described above. For example, an auto-generated barcode might be used. The > link below describes the workflow in one ILS. > > https://staff.lib.ncsu.edu/confluence/display/MNC/Bound- > with+Feature+with+Examples I look forward to seeing your patch then I'm looking at some of the old reopened bug reports in Koha. I wonder if this one could be thought of as similar to Bug 11175, which is talking about searching "host" records and showing their "child" component parts? That sounds terribly similar to searching for the bound USGS volume (the "host" record) and showing details of bulletins 12 and 13 inside it (the "child" records). If 11175 is covering the same ground as this patch, could we mark this one as a duplicate, as 11175 seems to be further along and has patches (although the code will need rebasing if it is to get into master)? There is a difference: "Bound withs" are on item level. The library might have something twice, but once it's bound with something else and once it's on its own. That can happen especially in libraries with old and rare books. bug 11175 is talking about showing relationships between bibliographic records, so it's on a different level. For example in Germany for a multi volume work you'd usually have a 'set record' that represents the whole work and then a record for each volume. They are tied together using 7xx and 8xx. The goal of bug 11175 would then be to show the volume records on the set record. (In reply to Katrin Fischer from comment #8) > There is a difference: > > "Bound withs" are on item level. The library might have something twice, but > once it's bound with something else and once it's on its own. That can > happen especially in libraries with old and rare books. > > bug 11175 is talking about showing relationships between bibliographic > records, so it's on a different level. For example in Germany for a multi > volume work you'd usually have a 'set record' that represents the whole work > and then a record for each volume. They are tied together using 7xx and 8xx. > The goal of bug 11175 would then be to show the volume records on the set > record. Oh, I wasn't thinking of this at the item level.. so does this really need the Holdings level MARC support before it can be implemented then? i.e. should it depend on bug 20447 (In reply to Martin Renvoize from comment #9) > (In reply to Katrin Fischer from comment #8) > > There is a difference: > > > > "Bound withs" are on item level. The library might have something twice, but > > once it's bound with something else and once it's on its own. That can > > happen especially in libraries with old and rare books. > > > > bug 11175 is talking about showing relationships between bibliographic > > records, so it's on a different level. For example in Germany for a multi > > volume work you'd usually have a 'set record' that represents the whole work > > and then a record for each volume. They are tied together using 7xx and 8xx. > > The goal of bug 11175 would then be to show the volume records on the set > > record. > > Oh, I wasn't thinking of this at the item level.. so does this really need > the Holdings level MARC support before it can be implemented then? i.e. > should it depend on bug 20447 No, I think the holdings are more for grouping several items or holdings of one record. A bound with would be items from different records, I believe this is yet another use case. So many similar but different functions.. how would this relate too the recently pushed bundles and item groups bugs. Almost sounds like an automatic multi-checkout? I.e if you checkout an item that's bound with another you automatically get the other item checked out too. Spitballing, I have no idea how this works really I think it would be more like EasyAnalytics (actually that could be used as a bound with). There would only be one physical thing, so only one barcode to check out.. and ideally you'd see it's gone on all the records/titles it contains. I have been struggling with bound-withs in Koha. The systems that I have worked with previously had a function whereby you could attach multiple bib records to one item record. The item displayed with each bib record, so if the item was borrowed, the fact that it was on loan was immediately obvious no matter which bib record you were looking at. If there is only one item, the unique barcode is not a problem. Could this functionality be developed in Koha? From my point of view, it would solve all the issues that I have with the current workflow: 1. The item is not displayed in the OPAC with the bib records for the subordinate items, which is baffling to anyone actually trying to find the publication (this is in Bugzilla but does not seem to have been solved: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29606). 2. We are part of Library Hub Discover (UK) and there, the subordinate records do not appear at all 3. Creating a host record for unrelated items is often quite difficult if the items are not thematically linked You can of course squeeze everything into one record with lavish usage of 505 and 700 + $t but if you have a lot of items in the bound-with, records like this can quickly become very messy. This feature would be completely different from analytics--analytics have hierarchical relationships, those of "parent-child." A bound-with feature in most systems simply links an item to multiple bib records and *doesn't require* a "parent record" for the entire entity--analytics require a parent record for the child records. "Bound with" bib records would be like members of a team; all the bibs created for the one physical entity are equal, and the cataloging standards pre-RDA use a "Bound with" note explaining the relationship. It's easier cataloging, too, because catalog records may exist for the items which one library has all bound together, so they can be copy cataloged and the "bound with" note inserted. Creating a parent record and then using analytical relationships creates a lot more work, usually, than simply copy cataloging existing cataloging for the titles in the physical item, and then being able to link an item record to all the bibs, because a "bound with" is usually a unique physical items only held by one library. I know this sort of "bound with" workflow is difficult to describe to those who've only worked with Koha, and may not seem easier to people who understand linking entry fields & relationships, but for libraries that find themselves with a physical volume containing lots of bound together small titles, just copy cataloging some or all of them & then linking one item to all of the bibs is almost always a faster & easier cataloging operation than locally creating parent-child relationship records. Thank you, Heather! That describes the different approaches to bound-withs very well. This was the workflow for bound-withs that I used to use (Dynix/Voyager/Millennium/Sierra): 1. Create a completely standard bibliographic record for the first title [title A] in the bound-with volume. Add 501 Bound with: Title B / by author 2 -- Title C / by author 3. Add 590 Item No. x in classmark. $5 library code Add an item record with the classmark and barcode 2. Create bibliographic records for titles B and C. Do not add an item. 3. Using the bib record numbers of the bib records for titles B and C, link the item from title A to the bib records for titles B and C. And that's it. No parent record, no hierarchy. The item appears with each bib record just as it usually would for a non-bound-with bib-item record pair. |