IRC log for #koha, 2005-07-23

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
12:15 thd Paul is gone away to the pleasant sea but I have the answer to his price question without consulting autocat.  The answer suggests a little revision for my attempted links mapping.
12:18 "multiple 852 fields may exist in the record with related item information in fields 876-878, specifying the copy number to which they apply using subfield $t (Copy number) or the subset using subfield $3 (Materials specified)."
12:18 http://www.loc.gov/marc/holdings/echditem.html
12:25 kados thd: so copy number here would be Koha's itemnumber?
12:25 thd 876 $c is cost.  I missed cost when searching for price.  876 $t and 852 $t is copy number, but the copy number must match with the itemnumber used by Koha.
12:26 kados thd: so that's actually a very neat way of doing it then ...
12:26 thd: could you post your result to koha-devel explaining the question and the answer ?
12:27 thd: it would be helpful to have it in the archive to point to
12:27 thd: and paul may read it too ;-)
12:30 thd kados: certainly
12:33 kados I don't think bulkmarcimport puts itemnumbers in by default
12:33 into the marc record that is
12:34 at least for MARC21
12:34 I don't see any itemnumbers in NPL's 952s
12:34 thd kados: How was that problem dealt with at NPL?
12:35 kados well it's not really a a problem right? just prevents deep linking using the MARC record
12:36 thd kados: How does NPL distinguish itemnumbers?
12:37 owen It does make it hard to link to the item detail screen from the MARC detail screen.
12:37 But that's not a big deal
12:37 kados using Koha tables I guess ...
12:37 the barcode will match in both if you need to link them
12:37 I'm still not sure whether when you delete a given item it deletes it from the MARC record as well
12:37 and if it does, how it knows which entry in 952 to delete
12:38 thd What is the NPL linking for itemnumber?
12:38 kados 952$u
12:39 select * from marc_subfield_table where tag=952 and subfieldcode='u' limit 0,20;
12:39 | subfieldid | bibid | tag | tagorder | tag_indicator | subfieldcode | subfieldorder | subfieldvalue | valuebloblink |
12:39 |         16 |     1 | 952 |       10 |               | u            |             4 | 1             |          NULL |
12:40 so I was wrong
12:40 the itemnumber is there
12:40 owen We have noted problems with updates to the MARC record when modifying item information
12:40 holdingbranch, for instance.
12:41 thd owen: To what do you attribute those problems?
12:41 kados Koha's hendling of MARC21 is far less than ideal ;-)
12:42 owen thd: neglect
12:42 thd :)
12:42 owen: neglect of what?
12:42 kados here are two entries:
12:42 |        359 |    13 | 952 |       17 |               | u            |             4 | 13            |          NULL |
12:42 |        363 |    13 | 952 |       18 |               | u            |             4 | 14            |          NULL |
12:42 both have the same itemnumber
12:43 sorry ... (these columns are making my eyes crazy) ... they have the same bibid and different itemnumbers
12:44 owen It's just a missing piece of the puzzle, I think.  The process of updating the MARC record in that case wasn't written.  Maybe because of neglect, maybe deliberately (how much overhead is there to update the MARC record every time a book is transferred to another branch?)
12:45 kados owen: so the real question is ... if I export my MARC21 stuff out of Koha does it have the up-to-date item info or am I stuck with the original MARC I imported from the beginning ;-)
12:46 owen Yeah, I know: imagine the havoc if you reloaded your data and all of a sudden no book was listed as being in the right branch
12:46 kados (and i don't really care whether holdingbranch is updated ... what I'm most concerned about is whether the static item info is kept in the record
12:47 we should do some tests
12:47 owen: any books you've recently deleted?
12:48 thd kados: that is the test question for every system.  But I imagine even if the MARC information is still orginal, you can painfuly match it all together with the separate item information from an SQL dump :)
12:49 kados thd: of course ... but that's supposed to be worse-case-scenerio ;-)
12:49 thd kados: :-)
12:50 kados thd: the problem we've had sofar
12:50 thd: is that none of us is really a MARC21 expert
12:50 thd: paul is somewhat of a UNIMARC expert
12:50 thd: and has done a great job of making Koha usable for libraries who need MARC
12:50 thd: but it's time to bring our MARC compatibility up to the next level
12:51 thd: so we don't have to cower embarassingly when we talk about missing implementation features
12:51 thd: or stay up at night worrying about whether the whole database is slowly corrupting itself with every transaction ;-)
12:53 owen: have you deleted any items recently ? if so, we could check to see if they are still in MARC
12:53 owen: btw, this may explain why some 'lost' items are showing up in the catalog search
12:53 thd kados: I have the beginnings of a plan but I have not finished my overly long email to you yet.
12:54 kados thd: cool ... I'm looking forward to parsing it ;-)
12:54 owen kaods: Yes, from the production machine.
12:55 kados owen: ok ... got itemnumbers?
12:56 owen Checking.
12:56 kados owen: titles, etc will work too, but itemnumbers would be easiest
12:56 owen (connection sucks today, I'm moving pretty slow)
12:56 kados owen: should be fixed this weekend
12:56 owen: at least partly
12:56 owen: (the connection that is)
13:05 thd kados: Paul is not around to answer for himself now but I think he has the idea of finding a common solution for the same problems that occur in UNIMARC and MARC21 using local use fields for issues like holdings in Koha.  This allows a common approach for both UNIMARC and MARC21, and therefore, simplifies coding.  However, it may not be standards compliant for both flavours.  UNIMARC seems to have a more complete solution than MARC21 for some
13:05 issues; but not for holdings, when they are stored in the bibliographic record.
13:09 Of course, neither MARC21 or UNMARC addresses every issue an ILS needs to manage so creative use of local use fields or some other solution with data external to a MARC record is necessary in those circumstances.
13:13 kados yep
13:13 owen: so ... are you back with us?
13:13 owen barely
13:14 kados owen: any itemnumbers or titles, etc.?
13:15 owen It must not have gotten through before: I deleted an item from this biblio: 155720
13:16 I can't even manage to get the necessary bits through an ssh session to query the deleteditems table.
13:16 Yup, my Putty session just died.
13:16 kados I'm having similar problems
13:17 so it's not just chauncey ... the apl connection's got problems ...
13:17 when I get discriminet working there that should fix some of them
13:18 select * from marc_subfield_table where tag=952 and subfieldcode='u' and bibid='155720'limit 0,20;
13:19 |    6301515 | 155720 | 952 |       36 |               | u            |             7 | 324420        |          NULL |
13:20 well that's distirbing
13:20 oh wait ... bibid is not biblionumber ... dou!
13:23 so that looks ok I think
13:24 there's one entry in marc_subfield_table and one entry in items
13:24 owen: look ok to you?
13:24 owen: http://intranet.athenscounty.l[…]=intra&bib=155673
13:24 owen: wait ... I think I did it in reverse :-). you gave me a biblionumber
13:24 grrr
13:25 so the bibid is 155767
13:25 and the biblionumber is 155720
13:25 owen: is that right?
13:26 owen http://intranet.athenscounty.l[…]=intra&bib=155720
13:26 kados select * from marc_subfield_table where tag=952 and subfieldcode='u' and bibid='155767';
13:26 | subfieldid | bibid  | tag | tagorder | tag_indicator | subfieldcode | subfieldorder | subfieldvalue | valuebloblink |
13:26 +------------+--------+-----+----------+​---------------+--------------+---------​------+---------------+---------------+
13:27 |    6304382 | 155767 | 952 |       38 |               | u            |             6 | 324507        |          NULL |
13:27 |    6304167 | 155767 | 952 |        4 |               | u            |             6 | 324493        |          NULL |
13:27 |    6307561 | 155767 | 952 |       39 |               | u            |             6 | 324620        |          NULL |
13:27 |    6378682 | 155767 | 952 |       41 |               | u            |             6 | 326726        |          NULL |
13:28 interesting ... I don't see itemnumber listed anywhere on the intranet screen
13:28 there's "group number" and Biblio number which are the same number
13:28 and there's barcode
13:29 owen It's not
13:29 kados ahh ... I think I see it now ... when you roll over circ history
13:29 owen It's not even listed on the additem screen
13:29 kados owen: is that variable not available?
13:30 owen: does the 'view circulation history' link come preformed?
13:30 owen It's there (that's how it shows up in the link), but it's not printed anywhere on the screen
13:30 kados are group number and biblio number always the same?
13:31 owen I know they *usually* are.  I don't know if they *always* are.
13:32 kados owen: select * from marc_subfield_table where tag=952 and bibid='155767';
13:32 owen: (too long to paste)
13:34 owen: so how do we tell that item number 324620 has barcode 37000000011087 and belongs in ALB from the MARC record?
13:35 owen: all the info is there but I can't find a way to associate it
13:35 owen Sorry, everything's grinding to a halt here. I'm not getting anywhere
13:36 kados owen: seems like select * from marc_subfield_table where tag=952 and bibid='155767' order by subfieldid;
13:36 owen: is ordering it correctly
13:36 owen: so maybe the subfieldid is used to determine what goes with what
13:58 pate hmmm, might as well unlurk a bit today, since i blew my cover last night
13:58 kados hey pate !
13:58 long time no read ;-)
13:58 so what's become of you these days?
13:58 :-)
13:58 still at amazon?
13:59 pate no, i left amazon about a month ago
13:59 moved to Utah
13:59 now I'm working for the LDS church
13:59 on the www.familysearch.org website
13:59 kados sweet ...
14:00 neat ... I'll have to check that out
14:12 pate hmmm, i guess i'll go back into lurk mode and try to get some real work done.
15:20 kados here's another quandry
15:20 Koha includes some special itemtypes like bindry
15:20 erp bindery
15:20 but as far as I know NPL doesn't use those
15:21 I'm wondering if we could set a damaged item to itemtype bindery
15:21 and then staff could reserve the item
15:22 so when it comes in it doesn't recirculate
15:22 (we can't reserve a specific item but we can reserve an itemtype right?)
15:22 that might be a nice workaround in the meantime
15:24 owen: what do you think?
15:28 owen Is itemtype in items or in biblioitems?
15:28 kados biblioitems
15:29 but it doesn't matter
15:29 owen But it means you couldn't attach a special itemtype to one item
15:31 kados hmmm
15:32 but you could attach a item to a biblioitem with the special itemtype
15:33 maybe?
15:34 owen How?
15:34 thd kados: At some point you would run out letters and numbers for all possible subfields from one field in the items table once you start matching condition etc.
15:42 Condition should be in the items table why would it ever be in the biblioitems table as an itemtype?
15:45 kados: except maybe, as the workaround you are trying to imagine just now to solve your problem for today :-)
15:51 kados: You should be able to reserve a specific item.  That way you can have a fragile rare copy of a book with the author's own margin notes in a glass case or refrigerated vault, while other ordinary copies circulate freely.
15:52 chris you can do that now
15:52 just put it in its own group
15:52 that was one of hlts requirements
15:53 thd chris: where are groups? I missed that part of the discussion.
15:55 chris 2 secs
15:58 thd chris: kados had suggested a few minutes ago that specific items could not be reserved but itemtypes could.
15:58 chris not quite right
15:58 specific groups can be reserved
15:59 and groups often correspond to itemtypes
15:59 but they dont have to
15:59 http://photos.bigballofwax.co.[…]imageViewsIndex=1
16:01 you can make groups, and move items under each group .. usually you have one group per itemtype, per biblio
16:01 but there is no reason you cant make a 2 groups with the same itemtype
16:04 at least there never used to be :) perhaps the latest MARC work has broken this .. but groups are an arbitrary construct
16:05 thd chris: where do I make groups and in what table are groups stored?
16:05 chris biblioitems
16:05 and i have no idea where you make them if you are using the MARC cataloguing interface
16:05 but they are quite simple to make using hte non-marc one
16:06 id show you, but i dont have any non-live kohas running at the moment and i dont want to make a mess in peoples catalogs
16:06 ill see if i can find a screenshot
16:07 http://photos.bigballofwax.co.[…]oha/acq3.png.html
16:08 thats if you were acquisitioning a new copy, ill get you a screenshot of moving an existing copy
16:10 http://photos.bigballofwax.co.[…]imageViewsIndex=1
16:12 i can select an item, reassign to an existing group, or i can just select one item, make a change to the group record, and it will split into 2 groups .. the new one with the item i attached, and the old one will have the item i didnt
16:12 does that make sense?
16:18 thd chris: My system is thrashing a bit, I think my worst is a leaky Flash implementation on my system.  If I leave a page with Flash based ads open too long I eventually start thrashing.
16:18 chris ahh, you use firefox?
16:18 thd chris: yes is that a known bug?
16:19 chris im not sure, but i get the same thing
16:19 so its known to me :)
16:19 if you watch top, you can watch firefoxs memory usage slowly creep up :)
16:20 when it gets near 10% i usually restart it .. that usually lasts me a week or 2 :)
16:20 thd chris: I do not find biblioitems.group
16:21 chris biblioitems=group
16:21 biblio, biblioitems, items
16:21 is the structure
16:21 a biblio owns biblioitems, biblioitems own items
16:22 thd chris: where is group?
16:22 chris group is the word we call biblioitems
16:22 a group is a biblioitem
16:22 thd oh...
16:22 chris but ppl go huh? when you say biblioitem
16:23 they nod when you say group .. so group is what we call them :)
16:23 thd I go huh when you say group
16:23 chris the biblio, biblioitem, item split was my attempt to normalise the data
16:24 and to remove some redundancy
16:25 so if you had 6 items all of the same itemtype, all with the same publisher etc, you didnt need to hold that info in 6 places
16:25 makes searching faster, makes updating faster etc
16:26 and it has the side affect of you can group items together, by some arbitrary criteria thats useful to your library
16:27 ill bbiab
16:30 back
16:33 thd kados: are you present?
16:34 chris i think that if you are using the MARC interface to koha, then you can do this so easily
16:34 can=cant
16:34 thd chris: So I am discovering.
16:35 chris most of our clients are quite happy to know its being stored as MARC in the background, and that they can export and import .. but they dont want to see MARC .. so I dont play with the MARC interfaces much
16:36 thd chris: Maybe the issue is even further hidden by the NPL templates that I am using.
16:36 chris my job is making sure whenever new work is done on the MARC side, it doenst break the simple interface
16:36 could be thd
16:43 thd I will try the default templates now.  I have been primarily working with cataloguing and the OPAC, my area of interest.  I have not explored the rest of the interface yet.
19:58 chris: I have turned off MARC and turned on the default templates, yet I still fail to be able to locate the screen for assigning items to biblioitems.  Would you please help me identify the steps required to get there starting from the admin home page.
20:43 rach ah - I suspect what you really need is our recently modified templates
20:43 I think there is a bug in the default (and NPL) ones, and we had to make a change
20:43 chris is out for a couple of hours I believe
20:50 thd rach: Do you mean that I may be searching for something unfindable with any standard Koha template?
22:16 rach um I fear it
22:17 if you're trying to get to the bit of the record which is where you change an items associated group (biblioitem) then I think we had to change something in the template to get the edit button to work
22:17 you go find the title
22:17 then click ont he barcode
22:23 thd rach: So I have managed to go that far and I have the moredetail.pl page.
22:25 chris you should be able to craft the url by hand
22:25 thd rach: For group I have '()'
22:26 suggesting no groups (biblioitems) have been assigned?
22:26 chris hmm
22:26 whats the url look like thd?
22:26 something like
22:26 /cgi-bin/koha/moredetail.pl?t​ype=&item=728&bib=728&bi=728
22:27 (with different numbers)
22:27 thd exactly
22:27 chris ok
22:27 if you change it to /cgi-bin/koha/moditem.pl?bibitem=728&submit.x=1
22:28 where 728 is the number at bi=728
22:28 you should end up at the page where you can modify groups
22:31 the group() could be caused by the fact your group has an itemtype that isnt defined in koha
22:31 thats just one possible reason
22:31 thd I have:  Barcode
22:31 ItemNotes
22:31 Home Branch
22:31 Lost Yes No
22:31 Cancelled Yes No
22:31
22:33 A form form with an image button represented as a floppy disc.  '()' is at the top of the form.
22:33 chris hm whats the url?
22:34 that sounds like moditem.pl
22:34 not modbibitem.pl
22:34 thd The page title is KOHA: INTRANET: Catalogue
22:35 chris yep, whats the url?
22:35 thd yes moditem.pl
22:35 chris you want to be at modbibitem.pl
22:35 thd I copied your example :)
22:35 chris ahh sorry
22:36 i cut and paste the wrong page
22:38 thd the page shows with no groups in the selection box
22:39 chris right it looks like it didnt make groups properly then ... can you get to any moredetail.pl page
22:39 that has a group?
22:41 thd I only have one biblio in the db at the moment with 2 items
22:44 correction I have 3 biblios one of which has 2 items.  I have been experimenting so much I forgot what state I had left things in
22:45 chris thd: you could jump into mysql and do a
22:45 select * from biblioitems;
22:45 and see if it has actually created one
22:59 thd sorry I had forgotten the db name and mysql was refuing my password
23:00 chris ahh, i always cheat and look at /etc/koha.conf :)
23:05 thd what value am I loking for?
23:06 chris are there any rows?
23:06 thd 3 rows
23:06 chris hmm so it looks like it did make biblioitems
23:06 ok, what are the itemtypes?
23:07 select itemtype from biblioitems;
23:07 thd | biblioitemnumber | biblionumber | volume | number | classification | itemtype | isbn           | issn | dewey | subclass | publicationyear | publishercode                   | volumedate | volumeddesc | timestamp           | illus          | pages           | notes | size   | place                   | lccn         | marc | url  |
23:07 +------------------+--------------+--------+----​----+----------------+----------+---------------​-+------+-------+----------+-----------------+--​-------------------------------+------------+---​----------+---------------------+---------------​-+-----------------+-------+--------+-----------​--------------+--------------+------+------+
23:07 |                1 |            1 | NULL   | NULL   | NULL           | NULL     | NULL           | NULL |  NULL | NULL     |            NULL | University of California press, | NULL       | NULL        | 2005-07-19 04:58:39 | front., illus. | 3 p. l., 120 p. | NULL  | 20 cm. | Berkeley, Calif.,       |    40028301  | NULL | NULL |
23:07 |                2 |            2 | NULL   | NULL   | NULL           | NULL     | NULL           | NULL |  NULL | NULL     |            NULL | Prentice-Hall,                  | NULL       | NULL        | 2005-07-19 05:02:41 | NULL           | 239 p.          | NULL  | 22 cm. | Englewood Cliffs, N.J., |    63008287  | NULL | NULL |
23:07 |                3 |            3 | NULL   | NULL   | NULL           | NULL     | 0738532797 (pb | NULL |  NULL | NULL     |            2004 | Arcadia,                        | NULL       | NULL        | 2005-07-19 05:14:13 | chiefly ill. ; | 126 p. :        | NULL  | 24 cm. | Charleston, SC :        |   2004103635 | NULL | NULL |
23:07 chris ahhh
23:08 they all have NULL for their itemtype eh?
23:08 what does select * from itemtypes;
23:08 give you?
23:09 or go to /cgi-bin/koha/admin/itemtypes.pl
23:09 in koha
23:09 thd +----------+----------------+---------​--------+--------------+------------+
23:09 | itemtype | description    | renewalsallowed | rentalcharge | notforloan |
23:09 +----------+----------------+---------​--------+--------------+------------+
23:09 | BOOK     | books          |               0 |       0.0000 |          0 |
23:09 | WORM     | crawling worms |               0 |       0.0000 |          1 |
23:10 chris right
23:10 we could try this
23:10 update biblioitems set itemtype='BOOK' where itemtype is NULL;
23:10 and then if we go to the moredetail.pl page hopefully stuff will show
23:11 thd chris: I had used bulkmarcimport.pl to enter the biblios so it did not assign a default itemtype?
23:11 chris yeah that sounds plausible
23:12 thd evidently :)
23:16 The group was assigned
23:16 chris yay
23:17 hopefully the modbibitem.pl?bibitem=somenumber&submit.x=1 will work too now
23:20 thd worms is not listed though
23:20 in the selection box
23:22 chris: that would be 'crawly worms' but I have only 'books' in the selection box.
23:23 chris was the space in the description 'crawly worms' deadly?
23:23 chris its because we made them all books i think
23:24 thd how does that help when I want to populate a new item type that I just created?
23:27 chris where is the drop down
23:28 in the reassign bit?
23:29 thats for assigning an item to an existing group
23:29 thd Ancient libraries (Thompson, James Westfall,)
23:29 Modify Group - books
23:29 RE-ASSIGN TO EXISTING GROUP
23:29 [drop down]
23:29 OR MODIFY DETAILS
23:29 chris if you wanted to change the item type, or if you had 2 items, and wanted to shift one to a new group, you would check the checkbox for that item, and you can just change the itemtype by typing in the itemtype
23:30 so the drop down only shows the existing groups attached to that biblio
23:31 thd chris could there be more than one group assigned?
23:31 chris http://photos.bigballofwax.co.[…]imageViewsIndex=1
23:31 yep, like this .. the help on this page kinda explains it better
23:33 thd that drop down contains more than just 'adult rental video'
23:34 the groups in the drop down from your example are not already assigned to the item.
23:35 chris sorry?
23:35 groups are assigned to biblios
23:35 and items assigned to groups
23:35 so for the 2 towers
23:36 there are 7 groups
23:36 and 9 items
23:36 the 2 items in my example are assigned currently to the adult rental group
23:39 thd Do you mean that if you had a 'crawly worms' group, it would not appear in the drop down for the item unless it had already been assigned to the group?
23:39 s/group\?/biblio\?/
23:40 s/group\?/biblio for the selected item\?/
23:40 chris that drop down lists all the groups assigned to a biblio
23:41 so that if i decided, to shift an item from the adult video group to the adult rental video group i could
23:41 it doesnt list all groups that exist
23:42 because if you shifted it to a group assigned to another biblio
23:42 thd only the relevant groups are listed, very thoughtful :)
23:42 chris suddently your two towers video has turned into harry potter :)
23:45 thd Does the biblio editor allow the assignment of multiple groups to a biblio?
23:47 chris not as such, but any new group you create on that modbibitem.pl page will automatically be assigned to that biblio
23:47 or you create using acquisitions
23:49 rach I will go find it and put it up
23:50 thd Do I need to create the group for a particular item or can I create it in advance of having a particular item to which it may be assigned?
23:51 chris the former
23:51 http://katipo.co.nz/gallery/al[…]_group_edit_scree <-- that one rach?
23:54 rach http://katipo.co.nz/gallery/ko[…]elp/how_cat_works
23:56 chris ahh cool
23:56 rach explains the relationship better
23:56 thd So I cannot have a group 'damaged--send for rebinding' that exists in all biblios without creating a damaged item for each biblio.
23:56 chris nope
23:56 rach nope - not really
23:57 chris but you could have an itemtype that means the same thing
23:57 rach groups need items to exist
23:57 yeah we would do that as an itemtype
23:57 chris actually i lie you could do it thd
23:57 thd groups are not itemtypes?
23:58 chris no
23:58 they just usually end up being used that way
23:58 itemtype is just one field of information on a group
23:59 you could create empty groups for every biblio, but youd have to do it in the database
23:59 there is no interface to do it
23:59 thd: 99% of the time ppl have a group per itemtype for a given biblio
00:00 thd now I am confused again, thd goes to look at the diagram
00:00 chris but you can have 2 groups with itemtype DVD
00:00 if something else was different on the group record
00:01 imagine you had the two towers dvd
00:01 and one was 173 mins long and the other was 180 mins (im making up an example here)
00:02 thd the diagram would be better if you had 2 different groups for itemtype video for example
00:02 chris yep, its just that as i said 99% of the time thats how it exists
00:02 rach sure - you could have different publishers for example
00:02 chris but it doesnt have too
00:02 so perhaps we should amend the diagram
00:03 rach so something like romeo and juliet, you could have a penguin copy, and a harper collins one or something
00:03 chris yep rach, both of type paperback
00:04 thd two different goups for video, group 1 is juvenile and group 2 is adult
00:04 rach maybe - but probably not
00:04 as in you'd tend to have 2 itemtypes
00:04 one being VJ and V
00:04 chris yeah, ud probably have different issuing rules for that case, so different itemtypes
00:05 rach so to have the same itemtype but 2 groups, one of the other fields would need to be changing
00:05 Most likely  the ISBN, the publisher or the physical dimensions
00:05 chris or the notes
00:05 rach yep or the notes
00:06 thd different groups cannot have different issuing rules unless there is an identity betweent the group and an itemtype?
00:06 chris issuing rules works with itemtypes and borrower categories
00:06 they dont care about groups
00:07 so when you go to issue a book
00:07 rach OK - http://katipo.co.nz/gallery/ko[…]how_cat_works_001
00:07 how about that
00:07 chris it only looks at the group record which owns that item, to find the itemtype, then it looks at the borrowers record to find what borrower type you are
00:08 and uses itemtype, and category to work out if you are allowed it, and for how long etc
00:08 rach group is just so you can do less typing
00:08 chris and the search can be more efficient
00:08 rach and have less "stuff" on screen to
00:09 chris that looks good rach
00:12 thd why are groups less typing?
00:15 rach http://katipo.co.nz/gallery/koha-help/HLT_holding
00:16 so that if you have a whole class load say of books come in, you just have to barcode each one after you've done the first group
00:16 and attach them to the same grou[
00:16 rather than entering it all in each time
00:17 It has some other advantages for the punters if you're a library that has multiple copies of things - for example you can put a reserve either on the whole title - first available, any group
00:17 or on a specific group - like large print, and you get the first available in that group
00:19 if you're the sort of library that only has one of each title, then hopefully it won't get in your way
00:22 thd Often only one.  however, I am thinking of the sort of library that has every different type and many multiple copies in common cases and many different issueing rules.
00:26 It seems helpful for me to think of item type in terms of a functional purpose.  I would think of itemtype as circulation type.  The rules for a given circulation type can be redefined.
00:26 rach yep - they are generally to distinguish between either audience - junior, teen, adult
00:27 and/or format -  video, cd, dvd
00:27 and/or content - fiction/non fiction
00:27 oh and more format - large print, talking book
00:28 and things that can't be issued - reference, stack
00:28 and sometimes popular things - bestsellers
00:28 thd I am not sure how to assign a functional purpose to group itself.
00:28 rach you don'
00:28 you don't
00:28 the functional purpose should be on the itemtype
00:30 thd I mean I am not sure what group does other than possibly represent a manifestation of an expression defined in a biblio.
00:30 rach the group is there to group a bunch of things which are the same - other than that they have different barcodes, together, so that they are quicker to catalogue, group together in the display, involve less disk space, are quicker to search, and to make it easy to reserve the next avialable paperback
00:31 rather than item xxx
00:31 thd could be a manifestation
00:32 iin the FRBR model
00:32 rach people who get excited about frbr tend to get excited about our groups
00:33 because it simplifies the info held in the biblio, without just loosing it
00:33 thd I am excited.  I also need to convince other people that this is exciting and works well so that they understand it very clearly.
00:34 rach we did it for pragmatic reasons rather than because we had library schollarship behind us :-)
00:35 thd Therefore, I must understand it intuitively so that I can persuade others of its importance in the library jargon that they understand.
00:36 rach we tend to come from the "but it makes sense, why doesn't everyone do it " school, which makes it harder to understand I'm sure :-)
00:36 yep, we really appreciate all efforts to translate
00:36 FRBR is a good one, the folks at our national library got very excited about that
00:37 thd FRBR exists for pragmatic reasons and it also fails to work reliably for the pragmatic reason that library records had not originally been developed with FRBR in mind.
00:37 rach this I suspect is what came out of not having to worry about MARC when we wrote the first version
00:39 we got to concentrate on what we wanted users to see, and what would make for the "cleanest" records
00:39 lucky for us other people were into MARC :-)
00:39 thd FRBR is a natural model that you identified but was missed in the earlier history of cataloguing practise.
00:43 Where is the unique ID of a group stored?
00:43 rach in the biblioitems table I would think
00:43 chris biblioitemnumber
00:43 in the biblioitems table
00:46 thd Can I associate more than one itemtype with the same group?
00:47 rach nope
00:47 thd Group is not a perfect fit for manifestation then.
00:48 s/manifestation/expression/
00:48 chris if you have more than one itemtype in a group, then not everything in the group is the same
00:48 thd s/expression/manifestation/
00:49 chris so you would need to groups
00:49 thd what I posted the first time :)
00:49 chris to=2
00:49 rach is manifestation something with a technical/defined meaning in frbr?
00:51 chris the biblio, biblioitems and items structure is an attempt to get as close to 3NF normalisation as possible
00:51 rach because my plain english meaning of the word manifestation wouldn't allow for you having different itemtypes - particularly if your itemtypes implied a different format
00:51 in the same manifestation
00:52 chris it just so happens it can be bent to practical usage
00:52 but thats a by product
00:52 thd work = all variants of an author's effort including the adaptations of others : expression = biblio : manifestation : copy = item
00:52 chris it seemed retarded to me, to store the publishers name 3 times, for 3 items
00:53 so i made biblioitems to group together like information
00:53 data redundancy is bad wrong and evil
00:53 because there are mulitple places that need to be updated
00:53 its a recipe for corruption
00:54 thd library records have never been known for their data efficiency except for the use of authorities to control terms and names.
00:54 chris exactly
00:55 which is why koha was perhaps is quite different
00:55 im a lazy programmer, i dont want to have to write a routine to change the same information in 3 different places, when i could store and change it one
00:56 so thats why it ended up the way it did
00:56 its been bent a little out of shape to deal with the importation and display of MARC records .. but it can be hammered back
00:57 thd all good programmers are lazy.  The lazier you are, the harder you work to make things efficient :)
00:59 chris id never heard of FRBR .. id worked with MARC before .. and thought it was a horribly inefficient way to store data, so i built something different .. and it seemed to work .. so i left it that way :)
01:00 thd MARC is a product of its time of origin but it will not be changing into anything better for many decades.
01:01 chris yeah, the thing that gets me with MARC is that ppl seem to forget the M stands for machine
01:01 humans shouldnt have to deal with it :-)
01:01 thats just inhumane :)
01:02 the MA even
01:02 but anyway, #koha has heard my marc rant before, so ill shut up about it now :)
01:02 thd I know the debates about newer better models but there is too much invested in MARC and there are always different newer better models every decade or so.  Changing formats every decade would be a real problem.
01:03 chris i dont see a problem exporting and importing to and from MARC
01:04 seems a good way to share catalog data
01:04 thd Library systems should hide the codes of MARC so that people do not have to worry about them if they have no need to worry.
01:04 chris exactly :-)
01:05 well its been fun chatting with you, and I hope it was useful, but im going to retire to the lounge and spend some of my friday evening with my wife
01:05 catch you later thd
01:06 thd good evening chris
01:14 If there were a group of groups (bibliotems), that could be a manifestation representing primarily a unique format in which an expression (biblio) is issued.
01:16 The common distinguishing factor of a manifestation is merely binding.
01:16 rach so would a paperback and a hardback be different manifestations?
01:16 thd yes
01:17 rach but two paperbacks by different publishers be the same manifestation?
01:17 or would they be different as well because they would have a different picture on the cover?
01:18 ie - would the first paperback edition of lord of the rings, be the same manifestation of the latest edition?
01:18 of = as
01:19 thd a different picture from the same publisher could be a different manifestation but publishers change covers all the time and libraries seldom ever catalogue cover varients except for rare books.
01:20 rach in koha you might end up with 2 groups in that example, because they would have different publication dates
01:20 even if they had the same itemtype
01:20 but in practice, I suspect you wouldn't
01:21 I *think* that our groups are easier to implement than the manifestations - they require les thinking by the librarians :-)
01:22 so you don't have to think wether these things are pretty much the same or not
01:23 it's a bit more cut and dried I suspect
01:23 thd different publishers are usually catalogued as different primary records for different expressions.  Different publishers often means different editions.  The biblio is the primary record in Koha.
01:23 rach yes - but we recomend that different publishers are catalogued under one biblio, if it is the same intellectual work
01:24 and if that's going to make the best sense to your borrowers
01:24 and edition, publisher, and other details like that are what's on the group - so you still have that info
01:25 only the barest details that identify a particular work are on the biblio - so that you can have all the items that a punter would think of as being the same thing, collected together
01:26 but for the serious schollar, you can still see that you have an original 1956 edition, as well as the 2005 reprint
01:27 thd the analogy kados drew between FRBR and Koha is work = biblio : expression = group (biblioitems) : manifestation ? [he omitted if I remember well] : copies = items
01:28 rach sounds likely
01:29 if manifestation is a group of groups, or a group of itemtypes in practice, then we don't have that
01:29 thd kados understands how Koha works better, his analogy is better than the one I was drawing to Koha.
01:32 manifestation would be a group of items but would generally map uniquely to some of the columns of the biblioitems table such as ISBN and size.
01:39 MARC bibliographic records are often expressions, sometimes having multiple ISBNs in the same record for hardcover and softcover in the same record.   MARC bibliographic records also include multiple copies for holdings in the same record.  MARC authority records can have an authority for a uniform title which would be a biblio in Koha.
01:46 rach yep - koha does all that too
01:46 it just does it without having to look at the confusing numbers
01:46 or you can if you want :-)
01:48 thd Well, the biblio table has both a title and a unititle column.  The real world problem is that the title serves as a unittle in most cases where most works have only one expression and never become popular enough to be revised, translated, or filmed.
01:48 rach and now you've lost me :-)
01:49 thd works are supposed to be distinguised by a uniform title.
01:50 The uniform title does not change when a work is translated or adapted.
01:50 rach ah yep
01:51 thd Uniform titles are an abstract that are usually given in the form of the title of the first appearance of the work in its original language.
01:59 For the FBR to koha analogy to work well the title column should be in the biblioitems table not the biblio table, but the value of the unititle column in the biblio table would be the title when no unititle was otherwise present.  That would be a little more involved to program and not have been an expedient pragmatic choice.
02:07 rach yup - so you could presumably make an fbr version of koha if you felt moved
02:20 thd Unititle is not linked correctly in the default Koha MARC21 mapping.  It should be 240 $a not 246 $a, which is variant or short title
02:22 rach: may all your junk be quality junk :-)
04:27 hdl paul_away : would it be useful to distinguish suprelibrarian from others in 1-B: that is :
04:27 paul_away : If user is superlibrarian, he may access all branches, if not, he only has grant access to HIS own branch.
04:27 paul_away : Anyway, independantBranches switch, the problem may be turned.
04:27 paul_away : Should IndependantBranches Switch be used for 1-A ?
04:27 paul_away right. adopted
04:27 paul (on phon)
04:40 hdl paul : when you have time, pls tell me what you like to adopt :
04:40 Is this :
04:40 a) IndependantBranches Switch used for 1-A ?
04:40 or
04:40 b) If user is superlibrarian, he may access all branches, if not, he only has grant access to HIS own branch ?
04:40 or both ?
05:30 paul OK for 1-B
05:31 1-A is different from IndependantBranches, as a given library may want to have "common" & "local" budgets for branches
06:25 shaun paul or hdl: how do you label koha in french? i.e. "Open Source Integrated Library System"
08:27 hdl shaun : Système Intégré de Gestion de Bibliothèque "Libre" (Libre stands for Open-Source)....
08:27 shaun : rebooting is quite long.... ;)
08:28 paul thd : in french, we are lucky : libre = free "as speech", and free "as beer" is "gratuit".
08:29 so, nobody is confused by 2 meanings of the same words, as in english.
08:29 However, hdl is right : ILS = SIGB (Système Intégré de Gestion de Bibliothèque)
08:30 & I usually speak of "Koha, SIGB sous licence libre"
10:04 thd paul: good afternoon
10:04 paul thx
10:05 thd paul: I was meant to write a message to koha-dev explaining the answer I found for you price question
10:06 paul: I posted the anser on IRC after went to sea
10:06 paul (did not read it. Could you repeat pls ?)
10:07 thd copy number $t is used as a key to holding fields
10:07 in MARC21
10:08 paul so, something like $3 for UNIMARC
10:08 for instance, it's unsupported by Koha
10:08 & no plans to change this atm
10:09 thd 876 $c is cost and 852 etc has other information
10:10 no need to change anything as everything works now I presume
10:11 paul: In the great future of MARC compatablility it would be nice to amongst other things make migration to Koha and record exchange a little easier
10:12 paul: by having Koha holdings support more than one field
10:15 paul: Also, at some point libraries may want to hold more holdings information than fit in the alphabet plus numbers for the possible subfields of only one field.
10:16 paul: chris and rach were explaining the old Koha data structure model to me last night after I had become confused about something.
10:17 paul: I finally understand now and am very happy.
10:18 paul: where is edition in the Koha tables?
10:19 paul ???
10:19 thd 2nd ed. or 3rd revised ed. of a biblio
10:23 paul: édition , why is there no biblioitems.edition in Koha?
10:23 paul you should ask katipans (chris or rach), as i have added nothing to those tables that were created in 1.0
10:24 imho, we should add some values to them. like language.
10:24 what is "edition" ? isn't is volume ?
10:24 (in french "édition" has many meanings)
10:25 thd paul: édition combines two English meanings
10:26 edition in English is for revision where the text changes as opposed to the English 'printing' where the text is not usually sopposed to change
10:29 thd: For different editions, the author or editor makes changes.  For different printing it is usually only the printer making minor corrections if any.
10:34 Paul: How would the French distinction be given?  édition révision and impression?
10:35 paul just depends on the context.
10:35 or can't be distinguished.
10:35 like "free" in english (libre/gratuit)
10:36 thd Paul: No one woul ever use  édition révision and impression?
10:36 paul impression is used when you use a printer. But not when you speak of a printed book.
10:36 thd :)
10:37 paul (even if a printed book has been printed on a printer, I agree ;-) )
10:41 thd My former business associate in my bookshop was a Brazilian fluent in French more than English (he studied in France for years), but he is back in Brazil.  I never asked him this question and do not remember how the distinction may be given on French books.
10:53 paul: Is a MARC bibliographic record keyed to biblioitemnumber or biblionumber in actual usage within Koha?
10:54 paul ???
10:54 thd >>- biblionumber (biblio PK)
10:54 >>- bibid (marc PK. It's a design mistake I made, for sure)
10:56 paul: This is from your migration email message.
10:57 paul the MARC record has biblionumber in it (usually in 090$9, but can be somewhere else)
10:57 internally, Koha uses a bibid to store the "MARC record number".
10:57 it's a design mistake, as bibid could have be biblionumber as well.
10:57 that's all I meaned here
10:58 thd paul: What table is bibid in?
10:58 paul bibis is the primary key of marc_biblio
10:59 thd paul: What table is bibid in on the old Koha side of the DB?
10:59 paul does not exist
10:59 (it's biblionumber)
10:59 marc_biblio having bibid AND biblionumber to keep trace of the link
11:00 (should have been drunk probably. But that's strange, I never drink alcohol...)
11:01 thd Does bibid hold the same value as biblionumber?
11:04 paul no.
11:04 as i'm definetly stupid, I make bibid "auto_increment", so the value is calculated by mysql & different from biblionumber !!!
11:05 thd Very creative :)
11:05 paul lol
11:08 thd Well, bibid could always be keyed to biblioitemnumber in marc_biblio as well.
11:09 paul mmm... complex question.
11:09 in Koha 1.2, we could have :
11:10 1 biblio => 2 biblioitems => 1 biblioitem with 3 items, the other with 1
11:10 (so 4 items at all)
11:10 in MARc, there are only 2 levels.
11:10 (biblio & items)
11:11 so, when MARC=ON, 1 biblio = 1 biblioitems
11:11 but when MARC=OFF (ask katipans for details), you can have 1 biblio = X biblioitems
11:11 thd Last night I had been considering how closed the match is or not between Koha and the FRBR model.
11:12 paul and as you have 1 biblio = 1 bibid, you can't key biblioitems
11:12 FRBR ?
11:12 thd I was getting a lesson in those details last night.
11:13 Functional Requriements for Bibliographic Records
11:16 http://www.oclc.org/research/p[…]/frbr/default.htm
11:17 http://www.oclc.org/research/p[…]eill/frbrddb2.ppt
11:18 The PowerPoint link above is very good: O'Neill, Edward T. "Functional Requirements for Bibliographic Records: OCLC's Experience Identifying and Using Works" (PowerPoint:26MB/35 slides) Given at FRBR Workshop, 8-9 July 2004, Frankfurt (Germany).
11:27 analogy between FRBR and original Koha model is work (all variants on a particular author's creative work including subsequent transformations, revisions, translations) = biblio in Koha : expression (variant revisions, translations, etc.) = group (biblioitems) in Koha : manifestation (a single form of an expression, hardcover, softcover, etc.) = ? in Koha : copies = items in Koha
11:28 paul right.
11:28 except that MARC=ON does not really support this scheme
11:32 thd MARC21 bibliographic records usually match expression and often hold multiple ISBNs for multiple manifestations (harcover and sofcover).  Also, hold multiple copy information in holdings fields.
11:33 Paul: Do UNIMARC bibliographic records often hold hardcover and softcover information in the same record?
11:33 paul hardcover & softcover ???
11:33 thd Oops
11:37 In France it is usually broché and éditions poche.  The publisher generally changes as well.
11:38 paul I don't think so.
11:38 any changes means a new MARC record.
11:39 thd If the publisher changes the MARC record would be different.
11:39 paul Even a new edition without any change, as it has a new ISBN if i don't mind.
11:40 It' time to leave.
11:40 my 3 sons are waiting for me (as well as my wife ;-) )
11:41 have a nice week end & read you on monday thd
11:41 thd paul: good weekend

← Previous day | Today | Next day → | Search | Index

koha1