← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:03 | veki | I have put link to your site on our site http://www.gnucentar.org.yu in Links/access to knwoledge and information category. I hope tha this will increase number of users of KOHA. |
| 12:19 | kados | veki: thanks! |
| 12:19 | veki | ok, great, no problem. It is my pleasure to do so |
| 12:20 | it may be good to work on increase of accessibility of library sites | |
| 12:20 | when I say accessiility I think on W3C recommendations | |
| 12:25 | there is tool Hera that you can find on www.sidar.org/hera which may help in increasing level of accessibility | |
| 12:32 | bbl | |
| 14:50 | kados | chris: you around? |
| 14:50 | chris: I need to ask you about the 1.x Koha design, specifically about grouping biblioitems into a single biblio | |
| 14:50 | hey owen | |
| 14:50 | chris: was it for circulation rules and for reserves ... and just that? | |
| 15:08 | chris | no |
| 15:08 | acquisitions too | |
| 15:08 | and database normalisation | |
| 15:08 | there were technical reasons, and functionality reasons | |
| 15:13 | kados | I'm trying to figure out whether we could represent the three-tier model in MARC21 and UNIMARC |
| 15:13 | chris | no |
| 15:14 | you cant | |
| 15:14 | but you can abstract over that to make it appear like you are | |
| 15:14 | kados | yea, that's what I was thinking |
| 15:14 | my latest idea is to store bibliographic and holdings data separately ... | |
| 15:14 | and to have a grouping table | |
| 15:15 | to group holdings data (items) | |
| 15:15 | would that work for HLT? | |
| 15:15 | chris | maybe |
| 15:15 | only if it appeared to them if nothing had changed | |
| 15:15 | kados | right |
| 15:16 | well from what I can tell, the only thing that biblioitems gives them is the ability to group items together and manage circulation rules and reserves and acquisitions based on those groups rather than just the Biblio or item | |
| 15:17 | owen | I'd love to be able to link directly to other formats from the details screen. "This title also available as..." |
| 15:19 | chris | yes it does |
| 15:19 | it also gives you a three tiered approach to cataloguing | |
| 15:20 | when adding a new item you can choose which group to add it to, or make a new group, or if needs be make a new biblio and group | |
| 15:20 | take that away, and all our users will go mental | |
| 15:20 | kados | of course |
| 15:21 | chris | you can of course shift items between groups too |
| 15:21 | kados | so the question is, can we emulate the concept of a group with a biblioitem table that had biblionumber,itemnumber columns |
| 15:21 | ie, not map it to the MARC fields | |
| 15:21 | just maintain it as a separate table | |
| 15:21 | chris | right, yep we probably cooul |
| 15:22 | could | |
| 15:23 | its all interface really | |
| 15:24 | kados | the one thing that needs to be there is the itemtype |
| 15:24 | chris | yep |
| 15:24 | kados | because that's how you do circ rules and reserves |
| 15:24 | chris | yep |
| 15:25 | kados | so if we had biblionumber,itemnumber,itemtype in biblioitems |
| 15:25 | that might do it | |
| 15:25 | chris | should do |
| 15:25 | kados | it would be pretty simple to build that table too |
| 15:26 | chris | then a chunk of work on acquisitions, reserves, and the detail.pl and more-detail.pl scripts |
| 15:26 | kados | so the question is, are there times when they'd want more than one MARC record to be grouped in a single biblio? |
| 15:26 | chris | so that they know to use that table |
| 15:26 | perhaps | |
| 15:26 | kados | so before we do anything, we need to understand when they'd want that and whether we could acomodate it |
| 15:27 | with this idea | |
| 15:27 | I've been working on a new API for Koha 3.0 | |
| 15:27 | chris | http://www.library.org.nz/cgi-[…]tail.pl?bib=12180 |
| 15:27 | kados | and have written several hundred lines of code so far working on it |
| 15:27 | chris | id expect this one be more than one marc record |
| 15:28 | kados | yea |
| 15:28 | so maybe we keep the MARC at the biblioitem level | |
| 15:28 | and the group stuff is biblio level | |
| 15:29 | chris | the main thing they dont want |
| 15:29 | is when you search on return of the king | |
| 15:29 | you get 9 lines in your search results | |
| 15:29 | instead of 1 line, with nine items | |
| 15:29 | kados | yea ... 9 lines with the same title |
| 15:30 | chris | yep |
| 15:30 | kados | so that actually complicates things quite a bit |
| 15:30 | one way we could acomplish this | |
| 15:30 | is to apply the FRBR working set to the set of MARC records | |
| 15:31 | chris | hmm |
| 15:31 | yep that might work | |
| 15:31 | kados | derive a set of 'works' |
| 15:31 | those become the biblios | |
| 15:31 | chris | yeah |
| 15:31 | kados | the problem with that approach |
| 15:31 | is that we lose all of the search options that Zebra gives us for working with MARC records | |
| 15:31 | we'd basically have to reinvent the wheel | |
| 15:32 | i think | |
| 15:32 | chris | k |
| 15:32 | u know what would probably work just fine | |
| 15:33 | just a grouping of results when u get them back from zebra | |
| 15:33 | it could be a system preference | |
| 15:33 | so only libraries that want it have it | |
| 15:33 | kados | how would you group them? |
| 15:34 | chris | title + author |
| 15:34 | kados | well ... |
| 15:34 | maybe my original idea ... | |
| 15:35 | I think we'd need to store the group information beforehand | |
| 15:35 | otherwise searching'll be mad slow | |
| 15:35 | chris | yep |
| 15:35 | kados | hmmm |
| 15:35 | chris | you could have |
| 15:36 | groupnumber,biblionumber,itemnumber,itemtype | |
| 15:36 | hmm no ignore that | |
| 15:36 | ud want | |
| 15:37 | worknumber,groupnumber,biblionumber,itemnumber,itemtype | |
| 15:37 | for eg | |
| 15:37 | http://www.library.org.nz/cgi-[…]tail.pl?bib=35551 | |
| 15:37 | there would be 9 rows | |
| 15:38 | all with worknumber the same | |
| 15:38 | kados | right |
| 15:38 | that makes sense | |
| 15:38 | chris | i think 5 different groupnumbers |
| 15:38 | etc | |
| 15:38 | kados | what's the groupnumber? |
| 15:39 | now we have 4 levels? | |
| 15:39 | chris | its a number unique within a worknumber |
| 15:39 | kados | ahh |
| 15:39 | so you do a search | |
| 15:39 | and if it's turned on | |
| 15:40 | chris | it groups biblios together as works |
| 15:40 | kados | it groups all the records |
| 15:40 | chris | yep |
| 15:40 | kados | yea ... and gives the user just title and author |
| 15:40 | it'd have to store some of that stuff too I suppose | |
| 15:40 | which makes it problematic | |
| 15:40 | because of course, in MARC that stuff is all over the place | |
| 15:40 | chris | right |
| 15:40 | kados | and there are multiple authors and multiple subjects and stuff |
| 15:40 | its' messy | |
| 15:40 | hmmm | |
| 15:40 | chris | yep |
| 15:41 | kados | maybe rather than map those fields to a single MARC field, they should be mapped to multiple fields |
| 15:41 | the same way we do when searching with bib1 | |
| 15:41 | chris | could be |
| 15:42 | kados | it |
| 15:42 | it's still not gonnabe FRBR | |
| 15:42 | chris | they dont want frbr |
| 15:42 | they just dont want 5 lines of the same title showing | |
| 15:42 | kados | because FRBR actually doesn't map a 1-1 between MARC and any of the levels they define |
| 15:42 | yea, that part seems easy | |
| 15:43 | chris | our clients are more pragmatic than dogmatic :) |
| 15:43 | kados | yep :-) |
| 15:43 | it makes perfect sense | |
| 15:43 | chris | they want a search that allows their patrons to find books easy |
| 15:43 | kados | in fact, it's how evergreen works |
| 15:43 | chris | as that is in fact the entire point of being a library ;) |
| 15:43 | kados | they create a metarecord that basically just groups marc records |
| 15:43 | yea | |
| 15:43 | chris | right thats essentially all we want to do too |
| 15:44 | kados | I gues s my question was were to do the grouping, do we group MARC records or items |
| 15:44 | it looks like MARC items | |
| 15:44 | unless we want to do both for some reason :-) | |
| 15:44 | but I think grouping MARC records will do it | |
| 15:45 | chris | yeah i think so too |
| 15:47 | kados | so in Zebra we store: |
| 15:47 | erp | |
| 15:47 | so we have the following Zebra databases: | |
| 15:47 | biblios | |
| 15:47 | holdings | |
| 15:47 | authorities | |
| 15:47 | reservoir | |
| 15:48 | biblios is the bibliographic data | |
| 15:48 | holdings is the items data | |
| 15:48 | authorities is authority records | |
| 15:48 | reservoir is identical to biblios but not the actual catalog | |
| 15:48 | then in SQL | |
| 15:48 | chris | right |
| 15:48 | kados | we have bibliogroup |
| 15:49 | biblio | |
| 15:49 | items | |
| 15:49 | ? | |
| 15:49 | I guess our problem is that we don't trust Zebra 100% yet | |
| 15:49 | and we need a way to rebuild it if it dies | |
| 15:51 | chris | yes |
| 15:51 | i quite like the fact the raw marc is being stored | |
| 15:51 | plus we lose the failover stuff tumer has done if we gut the db | |
| 15:51 | kados | right |
| 15:51 | this is starting to come together | |
| 15:52 | chris | maybe we should leave gutting the db for 3.2? |
| 15:52 | when zebra/zoom is mature-er | |
| 15:52 | kados | yea |
| 15:52 | yep, when we trust it | |
| 15:52 | chris | yeah |
| 15:52 | kados | ok, I'm gonna summarize this stuff on the wiki |
| 15:52 | bbiab | |
| 16:11 | chris: so ... | |
| 16:11 | I spent about 4 hours today working on a new module | |
| 16:11 | called Record.pm | |
| 16:11 | chris | cool |
| 16:11 | whats it do? | |
| 16:11 | kados | it's for managing records of all types |
| 16:11 | chris | sweet |
| 16:11 | kados | it does this: |
| 16:11 | * marc2marcxml - convert from MARC to MARCXML | |
| 16:11 | * marcxml2marc - convert from MARCXML to MARC | |
| 16:11 | * html2marcxml convert from HTML to MARCXML (used in addbiblio and additem) | |
| 16:11 | * html2marc - old routine to take HTML and convert directly to MARC (broken now, but might be useful someday) | |
| 16:12 | * changeEncoding - the mother of all encoding routines, convert from and to any encoding (MARC-8, UTF-8, etc.) in any record format (MARC, MARCXML, XML, etc.) for any flavour of MARC (MARC21, UNIMARC, etc.) | |
| 16:12 | chris | sweet |
| 16:12 | kados | and I've begun working on: |
| 16:12 | Biblios.pm | |
| 16:13 | Holdings.pm | |
| 16:13 | chris | right |
| 16:13 | kados | and now I'm thiking Bibliogroup.pm |
| 16:13 | it's not too bad actually ... | |
| 16:13 | we've got most of the code written already | |
| 16:14 | it's just a matter of putting it in the right places | |
| 16:14 | russ | morning kados |
| 16:14 | kados | morning russ |
| 16:14 | chris | yep |
| 16:18 | kados | chris: before I commit Record.pm ... could you explain how to add the VERSION stuff? |
| 16:18 | i'd like to have a log on this just like for Biblio.pm | |
| 16:19 | chris | righto |
| 16:19 | just put this line in | |
| 16:19 | $VERSION = do { my @v = '$Revision: 1.171 $' =~ /\d+/g; | |
| 16:19 | shift(@v) . "." . join("_", map {sprintf "%03d", $_ } @v); }; | |
| 16:19 | kados | what do I set 1.71 to? |
| 16:19 | chris | just leave it as that |
| 16:19 | when u cvs commit | |
| 16:20 | cvs will fix it to the right value | |
| 16:20 | kados | nice |
| 16:20 | chris | its cool like that |
| 16:20 | kados | and the log bit? |
| 16:20 | chris | # $Log: $ |
| 16:20 | easy eh | |
| 16:20 | kados | heh, yea :-) |
| 16:20 | chris | also i like to put this |
| 16:20 | kados | thanks |
| 16:20 | chris | just below the copyright |
| 16:21 | # $Id: $ | |
| 16:21 | so when u open the module you can see the version and who last committed easy | |
| 16:21 | kados | ahh, cool |
| 16:21 | chris | eg, take a look at C4/Date.pm |
| 16:22 | kados | thanks |
| 16:49 | chris: could you explain the groupnumber,biblionumber,itemnumber,itemtype a bit more in our new bibliogroup table? | |
| 16:50 | woops | |
| 16:50 | worknumber,groupnumber,biblionumber,itemnumber,itemtype | |
| 16:50 | what's the diff between worknumber and groupnumber? | |
| 16:50 | chris | group is a lower level |
| 16:50 | group is a group of items | |
| 16:50 | work is a group of biblios | |
| 16:51 | kados | I thought biblio was a group of items |
| 16:51 | chris | not really |
| 16:51 | think of biblionumber as marcrecord id | |
| 16:52 | kados | right |
| 16:52 | (and why XXXnumber instead of XXXid?) | |
| 16:52 | chris | i like number |
| 16:52 | cos its a number | |
| 16:52 | kados | :-) |
| 16:52 | chris | thats the reason i use itemnumber, biblionumber etc |
| 16:52 | kados | right, that's fine ... |
| 16:53 | so we have: | |
| 16:53 | chris | just a naming convention i have |
| 16:53 | kados | sure |
| 16:53 | chris | but im fine with id too |
| 16:53 | kados | so we're grouping MARC records into works |
| 16:53 | and items into groups? | |
| 16:53 | chris | yep |
| 16:53 | yep | |
| 16:53 | that gives us works->groups->items | |
| 16:53 | which is | |
| 16:54 | kados | where does the record fit in? |
| 16:54 | chris | biblio->biblioitems->items in koha 1.0 |
| 16:54 | sorry? | |
| 16:54 | kados | ok ... |
| 16:54 | we've got a MARC record | |
| 16:54 | chris | yep |
| 16:54 | kados | lets call that biblio |
| 16:54 | chris | yep |
| 16:54 | kados | then we've got an item ... called item |
| 16:54 | chris | and that belongs to a work |
| 16:55 | kados | the biblio belongs to a work |
| 16:55 | so now we need three ids | |
| 16:55 | workid | |
| 16:55 | biblioid | |
| 16:55 | itemid | |
| 16:55 | chris | yes |
| 16:55 | kados | where does the fourth id come in? |
| 16:55 | chris | and groupid |
| 16:55 | kados | ahh! |
| 16:55 | what the heck is groupid? | |
| 16:55 | hehe | |
| 16:55 | isn't that the same as workid? | |
| 16:55 | chris | no no no |
| 16:55 | workid is much higher | |
| 16:56 | here we go | |
| 16:56 | works own biblios, biblios own groups, groups on items | |
| 16:56 | kados | ok |
| 16:56 | lets call them | |
| 16:56 | bibliogroup | |
| 16:57 | biblios | |
| 16:57 | itemgroup | |
| 16:57 | items | |
| 16:57 | make sense? | |
| 16:57 | chris | that;ll work |
| 16:57 | im using groups because thats how hlt think of them | |
| 16:57 | kados | and so a biblio is just the MARC record |
| 16:57 | chris | a biblio has groups, groups have items |
| 16:57 | in koha 1 | |
| 16:57 | kados | right |
| 16:58 | and bibliogroup is for searching only | |
| 16:58 | chris | yes |
| 16:58 | itemgroup is for issuing/reserves | |
| 16:58 | kados | so this is a bit different than 1.0 |
| 16:58 | cause in 1.0 we only had three levels right? | |
| 16:59 | chris | yeah |
| 16:59 | kados | we need to be able to define circulation rules on all three of the bottom levels I think |
| 16:59 | chris | but bibliogroup is what biblio was in koha 1 |
| 16:59 | really | |
| 16:59 | kados | yea ... |
| 17:00 | chris | we are using 4 levels |
| 17:00 | to recreate the 3 that we had | |
| 17:00 | kados | hmmm |
| 17:00 | hehe | |
| 17:00 | so we need 4 because of the searching thing | |
| 17:00 | chris | but we have to becuase marc is not normalised |
| 17:00 | kados | ok, I think I get it |
| 17:00 | sheesh | |
| 17:00 | :-) | |
| 17:00 | chris | ie it contains bunches of redundant (replicated) data |
| 17:01 | kados | yea |
| 17:01 | chris | so we need to abstract over that, to make it look like it doesnt :) |
| 17:02 | its not really even for the searching, we still just search the same way | |
| 17:02 | its just for displaying the results | |
| 17:02 | kados | yea |
| 17:02 | how about sorting? | |
| 17:03 | chris | should be doable, just will need some thought |
| 17:03 | kados | also, we need two tables |
| 17:03 | bibliogroup | |
| 17:03 | dewey | it has been said that bibliogroup is for searching only |
| 17:04 | kados | itemgroup |
| 17:04 | dewey | itemgroup is for issuing/reserves |
| 17:04 | kados | hehe |
| 17:04 | chris | we do? |
| 17:04 | couldnt we just have | |
| 17:04 | one table | |
| 17:04 | bibliogroupid,biblioid,itemgroupid,itemid | |
| 17:05 | 1,1,1,1 | |
| 17:05 | kados | hmmm |
| 17:05 | chris | 1,2,1,2 |
| 17:05 | kados | right, |
| 17:05 | chris | 1,3,2,3 |
| 17:05 | etc | |
| 17:05 | kados | this complicates cataloging :-) |
| 17:05 | and searching :-) | |
| 17:06 | chris | from the programming side yes |
| 17:06 | for the user side, it simplifies both | |
| 17:06 | kados | well I'm just thinking of how to add new records with an external cataloger like we do now |
| 17:07 | chris | right i think ppl using an external cataloger wont have this switched on |
| 17:07 | kados | hmmm |
| 17:07 | chris | this is for people who want to catalog in the biblio,group,item style of koha 1 |
| 17:07 | kados | right ... |
| 17:08 | and HLT isn't the only one | |
| 17:08 | I've got clients who don't want to use MARC | |
| 17:08 | so I'm invested in making this work well | |
| 17:08 | chris | nope all the corporate libraries |
| 17:08 | kados | yea |
| 17:08 | corporate and tiny libraries | |
| 17:08 | chris | yep |
| 17:08 | and libraries that get no value from marc | |
| 17:08 | kados | right |
| 17:08 | chris | like most nz public libraries |
| 17:09 | kados | I wonder if we could store the bibliogroupid and itemgroupid in the record |
| 17:09 | chris | reckon so |
| 17:09 | kados | seems like we shouhld be able to |
| 17:09 | chris | yeah |
| 17:09 | cant see why not | |
| 17:09 | kados | they're record-level and item-level |
| 17:09 | chris | yep |
| 17:09 | kados | that way we could still use an external cataloger |
| 17:10 | chris | yep |
| 17:10 | kados | though it would be tough to tie it into the db |
| 17:10 | hmmmm ... maybe not with Z3950 | |
| 17:10 | chris | if we stored it in the record, do we need it in the db? |
| 17:10 | kados | maybe not |
| 17:11 | and if it's in the record, can we use Zebra to find it? :-) | |
| 17:11 | maybe with xpath? | |
| 17:11 | chris | yeah |
| 17:11 | kados | constructing that query in sql would be tough ... |
| 17:11 | chris | yeah |
| 17:11 | if it was in the record | |
| 17:11 | kados | I'm not sure how to do it in xpath (or if it's even possible) |
| 17:11 | chris | u could rank on it |
| 17:12 | kados | hmmm, interesting |
| 17:12 | chris | or sort by it |
| 17:12 | kados | well ... but you end up with a problem then |
| 17:12 | chris | will allow clumping together easily too |
| 17:12 | kados | because you're stuck with a sort based on group only |
| 17:12 | rather than by title author etc. | |
| 17:13 | this is a very challanging problem :-) | |
| 17:13 | chris | i think its soluble tho |
| 17:13 | kados | we're getting there :-) |
| 17:13 | chris | basically u want to drop duplicates from ur results |
| 17:13 | ie, if you have 2 with the same bibliogroup | |
| 17:13 | you only need to return one | |
| 17:13 | kados | not quite I think ... because you want to show the items too I think |
| 17:14 | you return one bibliogroup ... with the biblios , itemgroups and items attached | |
| 17:14 | chris | right |
| 17:15 | kados | so I say we use 001 for the biblionumber |
| 17:15 | and 090 for the bibliogroupnumber | |
| 17:15 | hmmm | |
| 17:16 | you don't need two tables to keep the ids and membership outside of the records? | |
| 17:16 | I'm confused about that point | |
| 17:16 | I guess we don't have that now | |
| 17:17 | chris | nope |
| 17:17 | its 1->many 1->many | |
| 17:17 | you only need a joining type table | |
| 17:17 | when you have a many to many relationship | |
| 17:18 | kados | so to create a new bibliogroup or itemgroup you basically just use an existing biblio to do it |
| 17:18 | or item | |
| 17:18 | chris | that you need to break into 2 1 to many relationships |
| 17:18 | kados | and it generates a new id ...? |
| 17:18 | chris | yep |
| 17:18 | we may want to store the highest value somewhere | |
| 17:19 | kados | yea, that's what I'm thinking |
| 17:19 | chris | so we dont have to scan zebra |
| 17:19 | kados | especially with an external cataloging client |
| 17:20 | chris | ill have to think about it more, but now i better actually do some work :) |
| 17:20 | kados | yep, sorry for taking up so much time |
| 17:20 | chris | no worries its interesting |
| 17:20 | kados | thanks for brainstorming with me |
| 17:21 | chris | oh oh oh |
| 17:21 | kados | got it? :-) |
| 17:21 | chris | why dont we store some xml |
| 17:21 | that has the bibliogroups etc in it | |
| 17:22 | kados | hmmm ... |
| 17:22 | chris | we could use zebra to interface with it |
| 17:23 | or that might just make it more complicated | |
| 17:23 | anyway ill have a think about it | |
| 17:23 | kados | k |
| 17:24 | something like: | |
| 17:24 | <bibliogroup> | |
| 17:24 | <bibliogroupnumber>1</bibliogroupnumber> | |
| 17:24 | <biblionumber>1</biblionumber> | |
| 17:24 | <itemgroupnumber>1</itemgroupnumber> | |
| 17:24 | <itemnumber>1</itemnumber> | |
| 17:24 | </bibliogroup> | |
| 17:25 | chris | yeah something like that |
| 17:26 | kados | right ... I'm gonna grab some dinner |
| 17:26 | bbiab | |
| 18:13 | the more I think about it, the more I like the idea of releasing 2.4 with a Zebra plugin option | |
| 18:14 | all we'd need to do is wrap tumer's stuff in a systempref | |
| 18:14 | and revise the zebra plugin documentation | |
| 18:14 | chris | yeah |
| 18:14 | kados | and folks could get started using zebra |
| 18:14 | chris | i think thats a great step |
| 18:14 | kados | that would let us play some more with head |
| 18:14 | chris | yep |
| 18:14 | ziggactly | |
| 18:14 | kados | and play with zebra |
| 18:14 | I'm gonna run that by paul tomorrow | |
| 18:15 | chris | k |
| 18:44 | kados | I didn't realize that MARC=OFF actually did something to the back end |
| 18:44 | I thought it was just a way to hind MARC | |
| 18:45 | but in reality, it's still running Koha 1.x back there | |
| 18:45 | maybe we should just keep that up and running | |
| 18:45 | exactly the way it is | |
| 18:45 | they won't get the new search features ... and that kinda sucks ... | |
| 19:19 | now I'm thinking we leave the old koha 1.x stuff alone | |
| 19:19 | rename all the routines | |
| 19:19 | kohaXXX | |
| 19:19 | and update all the scripts | |
| 19:19 | and just build the zebra stuff next to that | |
| 19:20 | chris | hmm |
| 19:20 | thatd be a shame | |
| 19:20 | so they dont get any of th benefits of zebra? | |
| 19:20 | kados | yea ... |
| 19:20 | chris | im not sure im mad keen about that idea |
| 19:20 | kados | I can't think of a way to implement this hierarchy with zebra without really losing the benefits of zebra |
| 19:21 | chris | well its early days yet |
| 19:21 | kados | ?? :-) |
| 19:21 | chris | i wouldnt commit to any decision |
| 19:21 | kados | maybe it's early for you :-) |
| 19:21 | chris | we have only just started to think about how to do it |
| 19:21 | kados | I've got to roll this out asap :-) |
| 19:21 | chris | no its early .. this discussion started what last night? |
| 19:21 | kados | hehe |
| 19:21 | yea, that part is early | |
| 19:22 | i guess I'm in a coding mood | |
| 19:22 | and I happen to have some time because all our big projects are done for a bit | |
| 19:22 | so i was hoping to get a whole week of coding in | |
| 19:22 | chris | i think that there must be a way to do it |
| 19:22 | kados | and if we had a plan I think I could get pretty far ... |
| 19:23 | but it's making the plan that's tough | |
| 19:23 | chris | yeah but pretty far down the wrong road potentially |
| 19:23 | kados | yea, suppose so |
| 19:23 | chris | its a fairly crucial decision |
| 19:23 | that will affect the project for years to come | |
| 19:23 | so itd be nice to get it right(ish) | |
| 19:23 | kados | well ... |
| 19:23 | here's a question | |
| 19:24 | does Koha 1.x search on anything but biblio table? | |
| 19:24 | chris | yes it does |
| 19:24 | so does koha 2.2 | |
| 19:24 | with marc=off | |
| 19:24 | it still searches the marc tables | |
| 19:24 | kados | hmmm |
| 19:24 | ahh ... | |
| 19:25 | so in fact, they would get the benefit of zebra | |
| 19:25 | chris | koha 1.0 searched biblio and biblioitems and items |
| 19:25 | koha 2.2 searches the marc tables | |
| 19:25 | yep | |
| 19:25 | kados | so if I'm understanding correctly HLT doesn't like the way that Koha 2.2 searches because it probably brings up 7 records instead of 1, right? |
| 19:26 | chris | no i fixed that |
| 19:26 | kados | !! |
| 19:26 | how the heck did you do that? :-) | |
| 19:26 | chris | they already had the structure |
| 19:26 | http://www.library.org.nz/cgi-[…]ter&Go.x=0&Go.y=0 | |
| 19:27 | for eg | |
| 19:27 | so it wasnt that hard | |
| 19:27 | koha2marc.pl does most of it | |
| 19:28 | pretty much everything barring searching by itemtype works pretty well | |
| 19:28 | for searching by itemtype we have to drop back to looking at the biblioitem table | |
| 19:29 | cos the 2.2 marc set up assumes a marc record will only have 1 itemtype in it | |
| 19:29 | kados | right |
| 19:29 | hmmm | |
| 19:30 | chris | with a bit of work i could export all the records as marc records |
| 19:30 | and include the bibliogroup number | |
| 19:31 | kados | so but what I'm not clear on is how you implemented the marc record at the biblio level but still managed to maintain itemtype at the biblioitem level |
| 19:31 | chris | it searches on the marc_word |
| 19:32 | it gets some biblionumbers from that | |
| 19:32 | then you just return the results from the biblio,biblioitems and items tables | |
| 19:33 | that make sense? | |
| 19:33 | kados | not entirely |
| 19:33 | because when marc is on | |
| 19:33 | chris | it searches the marc and displays the marc |
| 19:33 | kados | there's a mapping in place between fields in biblio, biblioitems and items |
| 19:33 | to specific marc subfields | |
| 19:33 | chris | that mapping is there whether its on or off |
| 19:34 | kados | right |
| 19:34 | chris | hence when i search on biblio.title, it actually searches marc_word for 245a |
| 19:34 | kados | right |
| 19:34 | chris | whether i have marc on or off |
| 19:34 | the only difference is | |
| 19:34 | kados | right |
| 19:34 | chris | if i have marc=off |
| 19:34 | it gets the biblionumber from that search | |
| 19:35 | and uses that to fetch the biblio,biblioitems and items | |
| 19:35 | kados | I see |
| 19:35 | chris | if i have marc=on |
| 19:35 | it shows me the marc stuff | |
| 19:35 | kados | the problem is, there are concessions on both sides to make this work |
| 19:35 | chris | so its not fully marc compliant in the background .. but it has enough to allow it to work they way they want |
| 19:36 | kados | yea |
| 19:36 | well we're not fully marc compliant with marc=on either :( | |
| 19:36 | chris | nope not in 2.2 |
| 19:36 | kados | I think I get it though |
| 19:36 | chris | search on one, display the other |
| 19:36 | thats all its doing really | |
| 19:36 | kados | yea |
| 19:37 | so you could do the same thing with zebra | |
| 19:37 | chris | so with a zebra plugin for 2.4 |
| 19:37 | exactly | |
| 19:37 | we can do the same thing | |
| 19:37 | kados | and tumer already does that to some extent |
| 19:37 | if zebra crashes | |
| 19:38 | chris | its its nice and fast to fetch from biblio etc when you are fetching by their primary key |
| 19:38 | kados | actually, he goes a step farther and searches using the old tables |
| 19:38 | chris | yep |
| 19:38 | kados | hmmm |
| 19:38 | chris | searching using the old tables is slower |
| 19:38 | kados | what I was thinking |
| 19:39 | for Koha 3.0 | |
| 19:39 | this may be silly | |
| 19:39 | instead of storing the koha tables stuff in the koha tables | |
| 19:39 | store it as xml | |
| 19:39 | so you have: | |
| 19:39 | <biblio> | |
| 19:39 | chris | nope thats fine |
| 19:39 | kados | <biblioitem> |
| 19:39 | chris | thats where i was heading as well i think |
| 19:39 | kados | <item> |
| 19:39 | <item> | |
| 19:39 | </biblioitem> | |
| 19:39 | <biblio> | |
| 19:39 | chris | yeah |
| 19:40 | kados | easy as pie to export like that |
| 19:40 | chris | yep |
| 19:40 | kados | then we build some zebra config files to know how to search it |
| 19:40 | the cool thing about that approach | |
| 19:40 | chris | its fully extensible |
| 19:41 | kados | is it opens up the possibility of libraries defining their own fields |
| 19:41 | chris | exactly |
| 19:41 | kados | and of moving completely away from MARC in completely new directions |
| 19:41 | chris | i like it |
| 19:41 | since a corporate library | |
| 19:41 | has quite different cataloguing needs | |
| 19:41 | kados | yup |
| 19:41 | chris | to a public library, or some small special |
| 19:42 | kados | so the question is can zebra search that three-tier hierarchy the way we want? |
| 19:42 | chris | reckon so |
| 19:42 | kados | I think so too |
| 19:42 | so behind the scenes | |
| 19:42 | we'll need a driver layer | |
| 19:42 | chris | the hardest thing is gonna be editing it |
| 19:42 | but if we make a dtd | |
| 19:42 | kados | to determine how to handle search requests, etc. |
| 19:43 | chris | that shouldnt be too bad either |
| 19:43 | kados | yea, dtd sounds good |
| 19:43 | chris | eg |
| 19:43 | title 125 varchar | |
| 19:43 | which lets us know how to build a form to edit it | |
| 19:44 | somethign like that anyway | |
| 19:44 | kados | yea |
| 19:44 | that could really rock | |
| 19:44 | chris | yep |
| 19:44 | kados | if it was well implemented |
| 19:44 | what would be neat | |
| 19:44 | chris | if you had xml and a dtd |
| 19:44 | you could build a myriad of ways to edit it | |
| 19:44 | kados | maybe the frameworks should be dtds |
| 19:45 | and this should just be a framework | |
| 19:45 | chris | ie you give something xml and a dtd, and it gives you back xml |
| 19:45 | that something could be any kinda cataloguing tool you liked | |
| 19:45 | kados | yea |
| 19:45 | if it was implemented as a framework, we could hypothetically use all the same code to manage the marc and koha editor | |
| 19:46 | then, to implement a new record format all you'd need to do is write a dtd for it | |
| 19:46 | chris | yep |
| 19:46 | kados | hmmm ... |
| 19:46 | chris | ok i gotta go eat, bbiab |
| 19:46 | kados | k :-) |
| 20:49 | chris: http://library.afognak.org/koha.dtd | |
| 20:49 | chris: hacked together the start of a dtd for koha tables | |
| 20:50 | not sure that elements biblioitem and item need biblionumber or biblioitemnumber | |
| 20:50 | I think each one just has it's own | |
| 20:55 | so what attributes do these need ... I thought maybe type and length | |
| 20:55 | anything else? | |
| 21:00 | if the dtd is going to be used as a framework we might need plugin too | |
| 21:01 | at least for the fields with character data | |
| 06:40 | morning all | |
| 06:40 | paul_away: you around? | |
| 08:50 | owen | kados: you around? |
| 09:14 | This one goes out to anyone listening: Why does my itemlost column contain three possible values? 0,1, and 2? | |
| 09:39 | kados | hey owen |
| 09:39 | is that the question you had for me? | |
| 09:39 | owen | If you know the answer :) |
| 09:39 | kados | :-) |
| 09:40 | I think I can help | |
| 09:40 | which machine are you on, 101? | |
| 09:40 | owen | Yes |
| 09:41 | kados | check the koha mappings for the itemlost column to find out where it's linked |
| 09:41 | s/linked/mapped | |
| 09:41 | then check the biblio framework and see if that subfield is set to use an authorized value | |
| 09:43 | owen | It doesn't seem to be linked to anything |
| 09:43 | kados | really? |
| 09:44 | ahh .. | |
| 09:45 | well ... I'm not sure then | |
| 09:45 | that's a question for paul | |
| 09:45 | or else we could dig in the code | |
| 09:52 | kyle | hey all |
| 09:52 | johnb | Kados: Found this site concerning multiple manifestations of the same work using MARC http://www.loc.gov/marc/marc-f[…]ple-versions.html |
| 09:52 | kyle | I finished a *ver* basic patron activity simulator. |
| 09:53 | *very*, that is. | |
| 09:53 | you can check it out at http://ccfls.org/koha/ | |
| 10:00 | kados | johnb: that _is_ interesting |
| 10:01 | chris an I had a long chat yesterday about Koha 3.0's handling of bibliograpic levels | |
| 10:02 | johnb: that site is useful because it actually has MARC tags and subfields that identify the FRBR hierarchy mappings | |
| 10:02 | johnb | yep |
| 10:03 | kados | kyle: cool ... I'll take a look asap |
| 10:03 | right now I've got to get some breakfast | |
| 10:03 | phone's been ringing off the hook this morning :) | |
| 10:03 | bbiab | |
| 10:03 | kyle | bon appetit ; ) |
← Previous day | Today | Next day → | Search | Index