![http://photos.bigballofwax.co.[…]imageViewsIndex=1](http://photos.bigballofwax.co.nz/gallery2/v/kohaphotos/reserve.png.html?g2_imageViewsIndex=1){kind=link}
![http://photos.bigballofwax.co.[…]oha/acq3.png.html](http://photos.bigballofwax.co.nz/gallery2/v/kohaphotos/koha/acq3.png.html){kind=link}
![http://photos.bigballofwax.co.[…]imageViewsIndex=1](http://photos.bigballofwax.co.nz/gallery2/v/kohaphotos/moving+items.png.html?g2_imageViewsIndex=1){kind=link}
← 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?type=&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