IRC log for #koha, 2006-05-26

← 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,bibli​onumber,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,bibli​onumber,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

koha1