Re: [Koha] Idea: Basing Cart off Items instead of Biblios
You can still have items of different item types attached to a single biblio; that's no problem. And you could still have patrons add the biblios to their Carts, for tagging, putting on Lists or placing Biblio-level holds (amongst many others). This should work just fine. If this does break your use-case, though, you can disable the Cart for patrons by turning off opacbasket in the system preferences area. -Ian On Thu, Mar 10, 2011 at 1:06 AM, <hansbkk@gmail.com> wrote:
2011/3/10 Robin Sheat <robin@catalyst.net.nz>:
Or, maybe having two separate Carts, Biblios and Items, would be the way to go, though that seems to be overcomplicating things.
Presumably an option so that a cart can contain both items and biblios would be a good middle-ground. A little more complex to deal with programmatically, but if written properly it shouldn't be too bad. It would also be easy to have a syspref that lets this be items only/biblios only/both, as it would just have to change a bit of OPAC UI.
Wow, the fact that carts are biblio-level is news to me, and actually throws a bit of a spanner in the works for my plans for using item-level item-types.
I was really hoping to take advantage of the fact that I could have different types of items associated with a single biblio record. But it seems if I go this route, then I should disable Carts for patrons? Is that even an option?
To review my situation with an example:
My current use case is that I have multiple media types for a single film. It's all exactly the same video, not a different edition, but one might be a disc that's playable on a consumer player (Disc-Video), another may contain computer files (Disc-Data), another combines both (Disc-Mixed), some of our VHS tapes haven't been converted yet, and some really old home movies are even on 35mm!
If I catalog these as separate biblios, this will creates multiple identical copies of the biblio-level MARC data, and just different ("holdings level") data in the items table, including item type. So when a patron searches for "2009 Proms Gala" they will get four identical but separate results.
Also, I'm planning on using user tagging, virtual shelves, etc. which if I use duplicated biblio-level item-types will somehow need to be synchronized between duplicate biblio records - yech!
Any advice would be appreciated
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
On Thu, Mar 10, 2011 at 6:47 PM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
You can still have items of different item types attached to a single biblio; that's no problem. And you could still have patrons add the biblios to their Carts, for tagging, putting on Lists or placing Biblio-level holds (amongst many others). This should work just fine.
OK, so far so good. However I didn't realize there was such a thing as a "Biblio-level" hold, and in my case I can't imagine it would be much use, since most patrons wouldn't want "whatever item type of this biblio is returned next", only a specific item type. But I imagine an item-specific hold would still be available - perhaps just not through carts/baskets?
If this does break your use-case, though, you can disable the Cart for patrons by turning off opacbasket in the system preferences area.
Good to know, thanks.
On Thu, Mar 10, 2011 at 1:06 AM, <hansbkk@gmail.com> wrote:
I was really hoping to take advantage of the fact that I could have different types of items associated with a single biblio record. But it seems if I go this route, then I should disable Carts for patrons? Is that even an option?
To review my situation with an example:
My current use case is that I have multiple media types for a single film. It's all exactly the same video, not a different edition, but one might be a disc that's playable on a consumer player (Disc-Video), another may contain computer files (Disc-Data), another combines both (Disc-Mixed), some of our VHS tapes haven't been converted yet, and some really old home movies are even on 35mm!
If I catalog these as separate biblios, this will creates multiple identical copies of the biblio-level MARC data, and just different ("holdings level") data in the items table, including item type. So when a patron searches for "2009 Proms Gala" they will get four identical but separate results.
On Thu, Mar 10, 2011 at 8:38 AM, <hansbkk@gmail.com> wrote:
OK, so far so good. However I didn't realize there was such a thing as a "Biblio-level" hold, and in my case I can't imagine it would be much use, since most patrons wouldn't want "whatever item type of this biblio is returned next", only a specific item type.
Traditional cataloging rules state that you shouldn't be attaching multiple item types to one bib record, so if you have multiple copies of the book those should be on one bib record and if you have an audio book that should be a different record. Not all libraries follow that rule, but if that rule is followed then yes patrons would just want the next copy of the item returned, not a specific item. Thanks Nicole C. Engard
What we really need here is Arbitrary Biblio Relationships, so we can have these distinct biblios broken down by item type (or, rather GMD), but also have a 'higher level' biblio that patrons can place holds upon if they don't care about the format. I've got this all spec'ed out, I just need some time and funding to make it happen. Cheers, -Ian On Thu, Mar 10, 2011 at 8:42 AM, Nicole Engard <nengard@gmail.com> wrote:
On Thu, Mar 10, 2011 at 8:38 AM, <hansbkk@gmail.com> wrote:
OK, so far so good. However I didn't realize there was such a thing as a "Biblio-level" hold, and in my case I can't imagine it would be much use, since most patrons wouldn't want "whatever item type of this biblio is returned next", only a specific item type.
Traditional cataloging rules state that you shouldn't be attaching multiple item types to one bib record, so if you have multiple copies of the book those should be on one bib record and if you have an audio book that should be a different record. Not all libraries follow that rule, but if that rule is followed then yes patrons would just want the next copy of the item returned, not a specific item.
Thanks Nicole C. Engard
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
What we really need here is Arbitrary Biblio Relationships, so we can have these distinct biblios broken down by item type (or, rather GMD), but also have a 'higher level' biblio that patrons can place holds upon if they don't care about the format. I've got this all spec'ed out, I just need some time and funding to make it happen.
Isn't that what the original intention was behind the three hierarchical levels in the Koha database? If this were the case there would be no need for ItemType at the item level, only at BiblioItem. The choice could then be "1:1 Biblio:BiblioItem" (what we have now with the old style biblio-level itemtypes) or 1:many. Biblio = "2009 Proms Gala" BiblioItemA "DVD-VDO" BiblioItemB "DVD-MKV" BiblioItemC "DVD-AVI" BiblioItemD "VHS" with the Items (holdings) level being identical copies of their parent BiblioItem. My understanding is that Biblio and BiblioItem effectively merged to become a single table via code-enforced one-to-one relationship around the time of Koha adopting Marc record frameworks. It seems to me that must mean that few libraries needed that flexibility, much less the ability to specify an Abritrary relationship (?). I would advocate KISS at such a fundamental level, the whole code base seems to have not yet fully adapted to having the relatively simple choice between item-level and biblio-level itemtypes.
On Thu, Mar 10, 2011 at 8:42 AM, Nicole Engard <nengard@gmail.com> wrote:
Traditional cataloging rules state that you shouldn't be attaching multiple item types to one bib record, so if you have multiple copies of the book those should be on one bib record and if you have an audio book that should be a different record. Not all libraries follow that rule, but if that rule is followed then yes patrons would just want the next copy of the item returned, not a specific item.
Well, there must have been compelling reasons for Koha to evolve to accommodate item-level ItemTypes, and they seem a great fit for my use case. Note that my scenario is very different from "paper book" vs "audio book", which are actually different in content and patron experience, not just the carrier medium. My example is more of a simple "tech detail" difference, like VHS vs Betamax, or say a set of biblio records, available in both MARC and XML. If we only had biblio-level itemtypes, maintaining a large set of Biblio records for such resources (that are identical except for carrier medium) would be a nightmare, not only for staff-level editing of the biblio information (updating cast lists, genre, subject headers) but especially when making use of dynamic features like user tagging and lists - which I fully intend to do! IMO the current database architecture at this level strikes a good balance, just some ongoing tweaking of the support module/scripts is needed to accommodate that level of flexibility.
Item type does not necessary need to mean material type; You could have 3 different "Book" types if for some reason these materials circulated differently (like one was a regular material, the other reference, and the third an archival copy). In this case, you'd want a single biblio, because they're all essentially the same material, just different copies that have different circulation rules attached. -Ian On Thu, Mar 10, 2011 at 9:21 AM, <hansbkk@gmail.com> wrote:
On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
What we really need here is Arbitrary Biblio Relationships, so we can have these distinct biblios broken down by item type (or, rather GMD), but also have a 'higher level' biblio that patrons can place holds upon if they don't care about the format. I've got this all spec'ed out, I just need some time and funding to make it happen.
Isn't that what the original intention was behind the three hierarchical levels in the Koha database? If this were the case there would be no need for ItemType at the item level, only at BiblioItem. The choice could then be "1:1 Biblio:BiblioItem" (what we have now with the old style biblio-level itemtypes) or 1:many.
Biblio = "2009 Proms Gala"
BiblioItemA "DVD-VDO" BiblioItemB "DVD-MKV" BiblioItemC "DVD-AVI" BiblioItemD "VHS"
with the Items (holdings) level being identical copies of their parent BiblioItem.
My understanding is that Biblio and BiblioItem effectively merged to become a single table via code-enforced one-to-one relationship around the time of Koha adopting Marc record frameworks. It seems to me that must mean that few libraries needed that flexibility, much less the ability to specify an Abritrary relationship (?). I would advocate KISS at such a fundamental level, the whole code base seems to have not yet fully adapted to having the relatively simple choice between item-level and biblio-level itemtypes.
On Thu, Mar 10, 2011 at 8:42 AM, Nicole Engard <nengard@gmail.com> wrote:
Traditional cataloging rules state that you shouldn't be attaching multiple item types to one bib record, so if you have multiple copies of the book those should be on one bib record and if you have an audio book that should be a different record. Not all libraries follow that rule, but if that rule is followed then yes patrons would just want the next copy of the item returned, not a specific item.
Well, there must have been compelling reasons for Koha to evolve to accommodate item-level ItemTypes, and they seem a great fit for my use case. Note that my scenario is very different from "paper book" vs "audio book", which are actually different in content and patron experience, not just the carrier medium. My example is more of a simple "tech detail" difference, like VHS vs Betamax, or say a set of biblio records, available in both MARC and XML.
If we only had biblio-level itemtypes, maintaining a large set of Biblio records for such resources (that are identical except for carrier medium) would be a nightmare, not only for staff-level editing of the biblio information (updating cast lists, genre, subject headers) but especially when making use of dynamic features like user tagging and lists - which I fully intend to do!
IMO the current database architecture at this level strikes a good balance, just some ongoing tweaking of the support module/scripts is needed to accommodate that level of flexibility.
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
On Thu, Mar 10, 2011 at 9:30 PM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
Item type does not necessary need to mean material type; You could have 3 different "Book" types if for some reason these materials circulated differently (like one was a regular material, the other reference, and the third an archival copy). In this case, you'd want a single biblio, because they're all essentially the same material, just different copies that have different circulation rules attached.
Yes, since the itemtype field determines circulation rules, charges etc. that is a good use for them. I considered using Collection Code simply for my "media format" facet, but decided it would make more sense to tie that to itemtypes. In my case, I'm combining the material type and an arbitrary "charge level" facet for those categories subject to non-default circ policies. I'm using Ccodes as an Advanced Search limiter, so I'm "stacking the facets" a bit to hopefully make sense from the patron's POV - here are some sample Ccodes (if no audience mentioned, means OK for both adults or kids, if no video resolution mentioned, means "not hi-res") Juvenile Videos Adult Videos Videos - high-resolution Juvenile Games - PC-disc Games - PS3 Juvenile Books Sorry to go so OT, but as a final aside, I'm using "Shelving Location" for cross-linked sets - "Harry Potter", "Disney", "James Bond", "David Lynch", "1940's films", "Criterion Collection" and making sure my call numbers sequence these for sensible "shelf browsing" in the OPAC.
Once, again to build off Han's model. How would you handle the 300 (physical description) field (which is repeatable) for videocassettes or beta that have been digitized or converted to another format but are exactly the same information? Having multiple bibliographic records, such as Nicole describes doesn't work. There are also collections that contain multiple formats - 2 reels, 8 cassettes, 4 c.f. boxes. On 1:59 PM, Ian Walls wrote:
Item type does not necessary need to mean material type; You could have 3 different "Book" types if for some reason these materials circulated differently (like one was a regular material, the other reference, and the third an archival copy). In this case, you'd want a single biblio, because they're all essentially the same material, just different copies that have different circulation rules attached.
-Ian
On Thu, Mar 10, 2011 at 9:21 AM, <hansbkk@gmail.com <mailto:hansbkk@gmail.com>> wrote:
On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls <ian.walls@bywatersolutions.com <mailto:ian.walls@bywatersolutions.com>> wrote: > What we really need here is Arbitrary Biblio Relationships, so we can have > these distinct biblios broken down by item type (or, rather GMD), but also > have a 'higher level' biblio that patrons can place holds upon if they don't > care about the format. I've got this all spec'ed out, I just need some time > and funding to make it happen.
Isn't that what the original intention was behind the three hierarchical levels in the Koha database? If this were the case there would be no need for ItemType at the item level, only at BiblioItem. The choice could then be "1:1 Biblio:BiblioItem" (what we have now with the old style biblio-level itemtypes) or 1:many.
Biblio = "2009 Proms Gala"
BiblioItemA "DVD-VDO" BiblioItemB "DVD-MKV" BiblioItemC "DVD-AVI" BiblioItemD "VHS"
with the Items (holdings) level being identical copies of their parent BiblioItem.
My understanding is that Biblio and BiblioItem effectively merged to become a single table via code-enforced one-to-one relationship around the time of Koha adopting Marc record frameworks. It seems to me that must mean that few libraries needed that flexibility, much less the ability to specify an Abritrary relationship (?). I would advocate KISS at such a fundamental level, the whole code base seems to have not yet fully adapted to having the relatively simple choice between item-level and biblio-level itemtypes.
> On Thu, Mar 10, 2011 at 8:42 AM, Nicole Engard <nengard@gmail.com <mailto:nengard@gmail.com>> wrote: >> Traditional cataloging rules state that you shouldn't be attaching >> multiple item types to one bib record, so if you have multiple copies >> of the book those should be on one bib record and if you have an audio >> book that should be a different record. Not all libraries follow that >> rule, but if that rule is followed then yes patrons would just want >> the next copy of the item returned, not a specific item.
Well, there must have been compelling reasons for Koha to evolve to accommodate item-level ItemTypes, and they seem a great fit for my use case. Note that my scenario is very different from "paper book" vs "audio book", which are actually different in content and patron experience, not just the carrier medium. My example is more of a simple "tech detail" difference, like VHS vs Betamax, or say a set of biblio records, available in both MARC and XML.
If we only had biblio-level itemtypes, maintaining a large set of Biblio records for such resources (that are identical except for carrier medium) would be a nightmare, not only for staff-level editing of the biblio information (updating cast lists, genre, subject headers) but especially when making use of dynamic features like user tagging and lists - which I fully intend to do!
IMO the current database architecture at this level strikes a good balance, just some ongoing tweaking of the support module/scripts is needed to accommodate that level of flexibility.
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com <mailto:ian.walls@bywatersolutions.com> Twitter: @sekjal
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
On Thu, Mar 10, 2011 at 10:15 PM, Linda Culberson <lculber@mdah.state.ms.us> wrote:
Once, again to build off Han's model. How would you handle the 300 (physical description) field (which is repeatable) for videocassettes or beta that have been digitized or converted to another format but are exactly the same information? Having multiple bibliographic records, such as Nicole describes doesn't work. There are also collections that contain multiple formats - 2 reels, 8 cassettes, 4 c.f. boxes.
Linda, Seeking clarification here, not wanting to assume anything. It seems to me you might be responding to Nicole's
Traditional cataloging rules state that you shouldn't be attaching multiple item types to one bib record.
As Ian pointed out, the idea of "material type" or "physical description" as described by various Marc data points, is completely independent of Koha's concept of "item type". Koha lets us use it to convey whatever meaning we like, with the proviso that it's the only way to set up circulation rules, charges & fines, etc. (in combination with patron categories and branches if we need to get complicated.) Other than that it's just like collection code, can represent whatever facet you like, and (for me) the nice thing is that both are item-level attributes, so a parent biblio can contain multiple items in any combination of the two, and either one can be used to filter advanced searches. There are obviously good applications for allowing different types of child items under a biblio parent, that do adhere to proper library science principles, and I don't think anyone's talking about Koha becoming **less** flexible here. I was in fact throwing out my opinion that Ian's idea of "Arbitrary Biblio Relationships"- which I interpret as making Koha **more** flexible - might make things needfully complex. Please understand that opinion isn't worth much, as A I don't know the details of Ian's ideas, they might have a lot of merit, and B I don't even understand Koha in any depth in its present state, much less where it might be headed. In other words, I'm really just talking off the top of my head, if not out of my hat. 8-)
Our situation is very much as Hans describes. I'm afraid if we get too far away from that model, Koha will no longer be an option for archival institutions like ours. On 1:59 PM, hansbkk@gmail.com wrote:
On Thu, Mar 10, 2011 at 8:49 PM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
What we really need here is Arbitrary Biblio Relationships, so we can have these distinct biblios broken down by item type (or, rather GMD), but also have a 'higher level' biblio that patrons can place holds upon if they don't care about the format. I've got this all spec'ed out, I just need some time and funding to make it happen.
Isn't that what the original intention was behind the three hierarchical levels in the Koha database? If this were the case there would be no need for ItemType at the item level, only at BiblioItem. The choice could then be "1:1 Biblio:BiblioItem" (what we have now with the old style biblio-level itemtypes) or 1:many.
Biblio =2009 Proms Gala"
BiblioItemA "DVD-VDO" BiblioItemB "DVD-MKV" BiblioItemC "DVD-AVI" BiblioItemD "VHS"
with the Items (holdings) level being identical copies of their parent BiblioItem.
My understanding is that Biblio and BiblioItem effectively merged to become a single table via code-enforced one-to-one relationship around the time of Koha adopting Marc record frameworks. It seems to me that must mean that few libraries needed that flexibility, much less the ability to specify an Abritrary relationship (?). I would advocate KISS at such a fundamental level, the whole code base seems to have not yet fully adapted to having the relatively simple choice between item-level and biblio-level itemtypes.
On Thu, Mar 10, 2011 at 8:42 AM, Nicole Engard<nengard@gmail.com> wrote:
Traditional cataloging rules state that you shouldn't be attaching multiple item types to one bib record, so if you have multiple copies of the book those should be on one bib record and if you have an audio book that should be a different record. Not all libraries follow that rule, but if that rule is followed then yes patrons would just want the next copy of the item returned, not a specific item.
Well, there must have been compelling reasons for Koha to evolve to accommodate item-level ItemTypes, and they seem a great fit for my use case. Note that my scenario is very different from "paper book" vs "audio book", which are actually different in content and patron experience, not just the carrier medium. My example is more of a simple "tech detail" difference, like VHS vs Betamax, or say a set of biblio records, available in both MARC and XML.
If we only had biblio-level itemtypes, maintaining a large set of Biblio records for such resources (that are identical except for carrier medium) would be a nightmare, not only for staff-level editing of the biblio information (updating cast lists, genre, subject headers) but especially when making use of dynamic features like user tagging and lists - which I fully intend to do!
IMO the current database architecture at this level strikes a good balance, just some ongoing tweaking of the support module/scripts is needed to accommodate that level of flexibility.
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824
If the items attached to a biblio are for a best seller, patrons DO WANT a bib level hold. They don't care which particular item is received because they want to read the first available copy (item returned first). Item specific holds become necessary for multi-volume sets or a particular format, or a particlar part of a series. Gary Harris New Mexico State Library -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of hansbkk@gmail.com Sent: Thursday, March 10, 2011 6:39 AM To: Ian Walls Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] Idea: Basing Cart off Items instead of Biblios On Thu, Mar 10, 2011 at 6:47 PM, Ian Walls <ian.walls@bywatersolutions.com> wrote:
You can still have items of different item types attached to a single biblio; that's no problem. And you could still have patrons add the biblios to their Carts, for tagging, putting on Lists or placing Biblio-level holds (amongst many others). This should work just fine.
OK, so far so good. However I didn't realize there was such a thing as a "Biblio-level" hold, and in my case I can't imagine it would be much use, since most patrons wouldn't want "whatever item type of this biblio is returned next", only a specific item type. But I imagine an item-specific hold would still be available - perhaps just not through carts/baskets?
If this does break your use-case, though, you can disable the Cart for patrons by turning off opacbasket in the system preferences area.
Good to know, thanks.
On Thu, Mar 10, 2011 at 1:06 AM, <hansbkk@gmail.com> wrote:
I was really hoping to take advantage of the fact that I could have different types of items associated with a single biblio record. But it seems if I go this route, then I should disable Carts for patrons? Is that even an option?
To review my situation with an example:
My current use case is that I have multiple media types for a single film. It's all exactly the same video, not a different edition, but one might be a disc that's playable on a consumer player (Disc-Video), another may contain computer files (Disc-Data), another combines both (Disc-Mixed), some of our VHS tapes haven't been converted yet, and some really old home movies are even on 35mm!
If I catalog these as separate biblios, this will creates multiple identical copies of the biblio-level MARC data, and just different ("holdings level") data in the items table, including item type. So when a patron searches for "2009 Proms Gala" they will get four identical but separate results.
Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On Thu, Mar 10, 2011 at 10:14 PM, Harris, Gary, DCA <Gary.Harris@state.nm.us> wrote:
If the items attached to a biblio are for a best seller, patrons DO WANT a bib level hold. They don't care which particular item is received because they want to read the first available copy (item returned first).
Item specific holds become necessary for multi-volume sets or a particular format, or a particlar part of a series.
In my case the "particular format" actually determines the usability of the item for that patron. Maybe not as extreme as the Braille release of the latest Harry Potter, but "Xbox 360" vs "Playstation3" is pretty similar. Of course, I could choose to make these separate records at the biblio level, but then I create a nightmare of data maintenance, probably have to disable lists and tagging. In either case I have to make the decision before I actually start cataloging the collection or I'm creating a lot of double-work to change my mind! Regarding the hold feature from the patron's POV - IMO the ideal would be - user goes to place a hold on a resource and up pops "would like your hold to apply to the next copy of this title that becomes available (any item), or to a specific copy?" With the former being the default?
participants (5)
-
hansbkk＠gmail.com -
Harris, Gary, DCA -
Ian Walls -
Linda Culberson -
Nicole Engard