Hi all, So here's a problem. Say a library has a system that allows a single MARC21 record to specify record types within the record in the 852$6 and allows issuing rules to happen on the item level rather than on the record level. I'm not sure if this is valid MARC21 practice, but I do know of at lease one system that works this way. When such a library converts to Koha, only one of the itemtypes is valid for the whole record, meaning that they will lose the ability to define issuing rules at the item level. The only solution seems to be to break up each record into multiple records, one for each itemtype (as a temporary fix). So I'm wondering, should we be defining issuing rules at the item level in Koha 3.0 for MARC21? or should we continue to define them soley on the record level? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hi all, I sent a mail one week ago about this same problem for a library who has books for adults and books for children with different issuing rules but the same notice. I'm in favour of linking the itemptype to the item, not to the biblioitem. hope there'll be an elegant fix for that ... Sylvain ----- Original Message ----- From: "Joshua Ferraro" <jmf@liblime.com> To: <koha-devel@lists.sourceforge.net> Sent: Friday, September 30, 2005 3:45 PM Subject: [Koha-devel] Itemtype and MARC21 Quandry
Hi all,
So here's a problem. Say a library has a system that allows a single MARC21 record to specify record types within the record in the 852$6 and allows issuing rules to happen on the item level rather than on the record level. I'm not sure if this is valid MARC21 practice, but I do know of at lease one system that works this way.
When such a library converts to Koha, only one of the itemtypes is valid for the whole record, meaning that they will lose the ability to define issuing rules at the item level. The only solution seems to be to break up each record into multiple records, one for each itemtype (as a temporary fix).
So I'm wondering, should we be defining issuing rules at the item level in Koha 3.0 for MARC21? or should we continue to define them soley on the record level?
Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
Sylvain Machefert wrote:
Hi all, I sent a mail one week ago about this same problem for a library who has books for adults and books for children with different issuing rules but the same notice. I'm in favour of linking the itemptype to the item, not to the biblioitem.
hope there'll be an elegant fix for that ...
Hi All I honestly dont think this is the problem, whether the itemtype is on items, or biblioitems. The problem is that the import is only making 1 biblioitem. If you have a MARC record that contains multiple record types, you should get 1 biblio -> multiple biblioitems -> multiple items. This is not what is happening, and this is what is causing the problems. So we need to fix this. Chris
Chris, I think you mean for a *non*-MARC record you (may) get 1 biblio -> multiple biblioitems -> multiple items. MARC records always produce 1 biblio -> 1 biblioitem -> multiple items. Stephen Chris Cormack said:
Sylvain Machefert wrote:
Hi all, I sent a mail one week ago about this same problem for a library who has books for adults and books for children with different issuing rules but the same notice. I'm in favour of linking the itemptype to the item, not to the biblioitem.
hope there'll be an elegant fix for that ...
Hi All
I honestly dont think this is the problem, whether the itemtype is on items, or biblioitems. The problem is that the import is only making 1 biblioitem.
If you have a MARC record that contains multiple record types, you should get 1 biblio -> multiple biblioitems -> multiple items.
This is not what is happening, and this is what is causing the problems. So we need to fix this.
Chris
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
Stephen Hedges wrote:
Chris, I think you mean for a *non*-MARC record you (may) get 1 biblio -> multiple biblioitems -> multiple items. MARC records always produce 1 biblio -> 1 biblioitem -> multiple items.
Yes, thats what I meant, They *should* produce 1 biblio -> multiple biblioitems -> multiple items. (if needed) But are instead producing 1 biblio -> 1 biblioitem -> mulitple items. And this is the problem in a nutshell, issuing rules work on the biblioitem level. Chris -- Chris Cormack Katipo Communications Programmer www.katipo.co.nz 027 4500 789
On Sat, Oct 01, 2005 at 08:57:37AM +1200, Chris Cormack wrote:
If you have a MARC record that contains multiple record types, you should get 1 biblio -> multiple biblioitems -> multiple items.
I think this is how UNIMARC is handled, but not MARC21. When bulkimporting MARC21 records, there is 1 biblio, 1 biblioitem, multiple items (and the biblio number and biblioitemnumber are the same for the initial import). How should we handle the (repeatable) 852 fields in a record when they contain some biblioitem-level stuff and some item-level stuff (like barcode). While we're on the topic: Chris's original db design (biblio->biblioitem->item) comes very close to the (fairly) new Functional Requiremente for Bibliographic Records (FRBR) (http://www.oclc.org/research/projects/frbr/default.htm). Looking forward, are we aiming to come closer to FRBR or are we going to stick with the original design and fix MARC21 support to use that design? Any opinions? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro wrote:
On Sat, Oct 01, 2005 at 08:57:37AM +1200, Chris Cormack wrote:
If you have a MARC record that contains multiple record types, you should get 1 biblio -> multiple biblioitems -> multiple items.
I think this is how UNIMARC is handled, but not MARC21. When bulkimporting MARC21 records, there is 1 biblio, 1 biblioitem, multiple items (and the biblio number and biblioitemnumber are the same for the initial import).
How should we handle the (repeatable) 852 fields in a record when they contain some biblioitem-level stuff and some item-level stuff (like barcode).
While we're on the topic: Chris's original db design (biblio->biblioitem->item) comes very close to the (fairly) new Functional Requiremente for Bibliographic Records (FRBR) (http://www.oclc.org/research/projects/frbr/default.htm). Looking forward, are we aiming to come closer to FRBR or are we going to stick with the original design and fix MARC21 support to use that design? Any opinions?
It depends entirely what we are planning for Koha 3.0. Im not sure I see the point in changing the database to be closer to FRBR if we are going to be using MARC records in the background. IE if we are planning to have our new textual db, in Zebra, with all the bibliographical data in it, and just the item status stuff. (Plus all the borrowers, circ, accounts etc) in the relational db, then I dont see much point. If we do it that way, its all just interface, we can provide whatever interface we want for the cataloguers, as long as the data is stored ok. The way we store something, is not the way we have to display it, thats what my entire bone of contention with MARC is, people have confused a storage and exchange standard, with a interface standard. But thats a whole other rant. :) In my opinion, we should be looking for a storage structure, that allows for robust and fast access. And I think zebra will do this for our catalogue data, and i think the relational db willl do it for our more time critical (issues etc) data. As long as we can put people like Brookes mind at rest, that changing the underlying structure wont bust the way koha works, just make it faster/better. Then I think we are all good. Chris -- Chris Cormack Katipo Communications Programmer www.katipo.co.nz 027 4500 789
If MARC 21 852 $6 has been used for designating a circulation rule it must have been catalogued that way because the formal use of $6 for designating an alternate script would seldom need to apply to 852. 876-878 $h would be the proper place to store circulation rules or more usually restrictions on use. KOHA ITEM BASED ASSINGMENT OF CIRCULATION RULES I will continue with another example derived from an analytical features list that also includes features not yet implemented and not on the roadmap. The following edited, rearranged and reduced, extract from a combined form is never meant to be seen because it is difficult to read and follow at length. The edited outline extract is followed by a descriptive explanation based on the outline. ANALYTICAL FEATURES OUTLINE 16. Circulation. 1. Circulation Rules. 1. Circulation Material Type Based. 2. Library Based. 3. Item Based. 1. Administrative Reassignment. 1. Item Circulation Material Type Reassignment. 1. Original Non-MARC Koha. [current, version 2.2.3] 1. Reassignment to other circulation material types already specified at the expression-manifestation level (Koha biblioitems table) for the same work. [current, version 2.2.3] 2. Reassignment to any circulation material type. [forthcoming, version 3.0] 2. MARC Koha. 1. Reserve specification (designated as not for loan in Koha). [current, version 2.2.3] 1. MARC Formats. 1. MARC 21 Format for Bibliographic Data. 1. User Definable. [current, version 2.2.3] 2. Prepackaged Frameworks. [forthcoming, version unspecified] 1. Subfield Appearance in Editor. 1. Prepackaged default. 3. Value List Selection from Pop-Up Windows. [forthcoming, version unspecified] 1. Prepackaged default value list. 1. UNIMARC Bibliographic Format. [current, version 2.2.3] 1. User Definable. 2. Prepackaged Frameworks. 1. Subfield Appearance in Editor. 1. Prepackaged default. 3. Value List Selection from Pop-Up Windows. 1. Prepackaged default value list. 2. Reassignment to any circulation material type. [forthcoming, version 3.0] 3. Automatic reassignment by acquisitions recency setting. [forthcoming, version unspecified] 1. Item Library Reassignment. [current, version 2.2.3] 4. Patron Privilege Type Based. CIRCULATION RULE TYPES Circulation periods in Koha are currently set by circulation material types (implemented as biblioitems.itemtype); library (branches); and patron privileges. [I have edited out the detail of the outline section relating to circulation periods except for that affecting items.] NON-MARC KOHA ITEM CIRCULATION REASSIGNMENT Non-MARC Koha allows the reassignment of items (itemnumber) to a different circulation material type (biblioitems.itemtype) provided that the desired circulation material type has been assigned to another expression-manifestation (bibloitemnumber) for the same work (biblionumber). The following untested SQL statement should return the limitation of circulation material type reassignments for an itemnumber. SELECT biblioitems.itemtype FROM biblioitems WHERE biblioitems.biblionumber = (SELECT biblio.biblionumber FROM biblio, biblioitems, items WHERE biblio.biblionumber = biblioitems.biblionumber AND biblioitems.biblioitemnumber = items.biblioitemnumber AND items.itemnumber = $yourItemNumber); MARC KOHA LENDING RESTRICTION REASSIGNMENT The MARC frameworks can provide for reassigning the circulating or noncirculating status provided that items.notforloan is assigned to a MARC subfield in whatever MARC field has been chosen for items mapping and also provided that the subfield is set to managed in Koha. This is the prepackaged default in UNIMARC Koha controlled by a value list for the record editor. GENERAL WORKAROUND A common workaround for inadequacies in the Koha data model is to create virtual library branches. Library branches must have different codes. However, virtual library branches may be assigned a name beginning with the name of the actual library branch to ensure that humans know which library branch actually has the material. A library may then have an additional virtual parameter to use. A particular item can be assigned to a virtual library branch. Circulation rules can be set by library branches. This sort of workaround is what users of closed source systems have to use because they have no other option. Koha is open source and does not need to force inadequate data models on users so proper provision for needed parameters should be provided at the next best opportunity. GENERAL PROBLEM The problem derives from a mistaken bibliographic data representation in the original non-MARC Koha record representation. The Non-MARC Koha record was not modelled on the FRBR but is broadly similar in its basis in addressing practical problems of bibliographic relations. However, the treatment of itemtype as a circulation rule is both practically and theoretically problematic. Conflated within the intended usage is both the media format type, general material designation and specific material designation; and a circulation material rule type. The set of all circulation material rule types and all media format types may intersect but they do not necessarily intersect. Forcing them to intersect makes Koha awkward to use despite the limited advantage of having only one assignment to make when they do intersect. Koha should be flexible enough to support legitimate user needs to give flexible access to the collection to best serve a variety of patron use and to meet administrative needs as they arise. All copies of a book should not necessarily circulate for the same period. GENERAL SOLUTION Non-MARC Koha should have a separate media format type and separate circulation material rule type. Media format type would be most consistent with its rather flat somewhat FRBR like model if it is put in the items table. Circulation material rule type would be most flexible if it were available in the items table. While the virtual library branch work around may be adequate for now, addressing the conflated media format type ought to be sufficiently important to correct the combined issue for version 3.0. Media format type should be designated at the record level. Binding, unlike media format type, is an items level distinction in both FRBR and the current English language publishing tradition. The fact that binding is usually different at the manifestation level in other publishing cultures does not change its place in the FRBR. However, binding fits at the expression-manifestation level in the flattened somewhat FRBR-like original Koha record model. The Version 3.0 roadmap provides for an acquisitions recency status. That should certainly be in the items table. The roadmap specifies the recency status to be noted in the OPAC. Recency status could also be used to automatically reassign a circulation material rule type. An adequate model for reassignment configuration would have to be provided. Recency based circulation rules for popular material are certainly in common use at many libraries. However, I have not given much thought to the requirements for a configuration model. Developing a good configuration model may be sufficiently complex to mitigate against use of receny status outside the OPAC until libraries actually express a strong interest in recency based assignment. Thomas D Quoting Sylvain Machefert <smachefert@doxulting.fr> :
---------------- Beginning of the original message ------------------
Hi all, I sent a mail one week ago about this same problem for a library who has books for adults and books for children with different issuing rules but the same notice. I'm in favour of linking the itemptype to the item, not to the biblioitem.
hope there'll be an elegant fix for that ...
Sylvain
----- Original Message ----- From: "Joshua Ferraro" <jmf@liblime.com> To: <koha-devel@lists.sourceforge.net> Sent: Friday, September 30, 2005 3:45 PM Subject: [Koha-devel] Itemtype and MARC21 Quandry
Hi all,
So here's a problem. Say a library has a system that allows a single MARC21 record to specify record types within the record in the 852$6 and allows issuing rules to happen on the item level rather than on the record level. I'm not sure if this is valid MARC21 practice, but I do know of at lease one system that works this way.
When such a library converts to Koha, only one of the itemtypes is valid for the whole record, meaning that they will lose the ability to define issuing rules at the item level. The only solution seems to be to break up each record into multiple records, one for each itemtype (as a temporary fix).
So I'm wondering, should we be defining issuing rules at the item level in Koha 3.0 for MARC21? or should we continue to define them soley on the record level?
Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
------------------- End of the original message ---------------------
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com
participants (5)
-
Chris Cormack -
Joshua Ferraro -
Stephen Hedges -
Sylvain Machefert -
Thomas D