| Time |
S |
Nick |
Message |
| 15:50 |
|
owen |
wb logbot! |
| 15:52 |
|
chris |
heya owen |
| 15:53 |
|
owen |
Hi chris. Network problems over there today? |
| 15:53 |
|
chris |
worse |
| 15:53 |
|
chris |
We had power problems at AT/T house about 10:10pm last night (Wed Jul |
| 15:53 |
|
chris |
20), which caused a circuit breaker to blow on the UPS. I've installed |
| 15:53 |
|
chris |
another UPS to spread the load, and started everything up. |
| 15:54 |
|
owen |
Drag. |
| 15:54 |
|
chris |
that was from si last night .. sounds like he had a crappy night |
| 15:55 |
|
chris |
i slept through it all |
| 16:04 |
|
tim |
Does anyone know if it's ok to change the tab that tags show in by just updating the tab field in marc_subfield_structure? |
| 16:05 |
|
owen |
Anything except for item fields, I think |
| 16:21 |
|
thd |
owen: why are the item fields a special problem? |
| 16:22 |
|
owen |
Because they have to be handled by additem.pl, I think. |
| 16:22 |
|
owen |
Instead of addbiblio.pl |
| 16:22 |
|
kados |
chris: morning chris |
| 16:22 |
|
kados |
chris: rough morning eh? ;-) |
| 16:23 |
|
chris |
not so much for me, rough night for si tho .. few issues left this morning |
| 16:26 |
|
chris |
http://www.lilrc.org/newsletter/v23n4.pdf take a look at page 3 |
| 16:27 |
|
thd |
owen: I noticed that if I link something in the items table to an 852 field, for example, I get an error in MARC Check. |
| 16:31 |
|
thd |
chris: Was it HLT or Katipo that first suggested releasing Koha under GPL? |
| 16:31 |
|
chris |
i think it was katipo who suggested it |
| 16:31 |
|
chris |
but that was well before it was written |
| 16:32 |
|
chris |
if that makes sense |
| 16:32 |
|
chris |
ie we didnt write something, then decide to gpl it |
| 16:32 |
|
thd |
owen: why would additem.pl need to be less flexible than addbiblio.pl ? |
| 16:33 |
|
chris |
so we recommended and HLT agreed that we would write koha with the idea that we would release it under the gpl |
| 16:33 |
|
owen |
paul could probably answer that question, thd |
| 16:34 |
|
owen |
paul did the bulk of the work on Koha's MARC capabilities, so he's the one to answer that kind of question |
| 16:36 |
|
thd |
chris: Were they easily persuaded about the software being written under the GPL as opposed to some other license, or even closed source like far to many other library projects? |
| 16:36 |
|
chris |
http://koha.org/about/story.html |
| 16:37 |
|
chris |
they are smart ppl |
| 16:37 |
|
chris |
they werent hard to persuade |
| 16:40 |
|
owen |
They also came at a different point in the process than most libraries. Most libraries look to buy something pre-written. They were already asking for something to be written from scratch |
| 16:41 |
|
thd |
chris: thank you for the exact link, I had not noticed the story link on the about page. The internet archive was also much too slow while koha.org was down. |
| 16:41 |
|
rach |
they looked to buy something pre-written first - but there wasn't anything that fit their circumstances |
| 16:41 |
|
chris |
welll they werent really owen |
| 16:41 |
|
chris |
yeah what rach said |
| 16:42 |
|
chris |
they did the full rfp process |
| 16:42 |
|
rach |
and only when none of those packages were any good (or in their budget - particularly in the long term) did we discuss writing something |
| 16:43 |
|
chris |
but it appears the big vendors dont actually read the libraries requirements :) |
| 16:43 |
|
chris |
we also looked for something that was already written |
| 16:43 |
|
owen |
They probably think you'll just be wowed by the promo materials |
| 16:43 |
|
chris |
(im lazy .. if i could have just taken an existing project and added to it, i would have) |
| 16:44 |
|
rach |
I think we looked at like the avanti project and got all excited, before finding out he hadn't actually written it yet |
| 16:44 |
|
rach |
it was just a spec |
| 16:45 |
|
thd |
chris: Most libraries contracting software to be written keep the code to themselves, if it becomes theirs, and charge other libraries to use it so they can recover their development investment. Which, seems to me a backwards idea for libraries serving the public good. |
| 16:45 |
|
rach |
we did talk about that - but "got rea" that neither we nor HLT had what you might call a marketing budget to do that |
| 16:46 |
|
owen |
thd, do you know any examples of that? |
| 16:46 |
|
rach |
- got real |
| 16:46 |
|
rach |
that is |
| 16:46 |
|
rach |
so they didn't have anyone with pretensions to become a library system vendor |
| 16:46 |
|
thd |
owen: most examples are that |
| 16:47 |
|
thd |
owen: OpenILL is just one I had looked at most recently. |
| 16:48 |
|
rach |
we decided that the key indicator of success for Koha for the library, and perhaps key predicator of disaster in the longer term, was other people using it |
| 16:48 |
|
owen |
So thd, OpenILL was something a library developed for themselves and now they're selling it to other people? |
| 16:48 |
|
rach |
so if no one else used it, it would be unlikely to last 10 years |
| 16:49 |
|
thd |
rach: there are still not enough other people using it :) |
| 16:49 |
|
thd |
rach: but there will be |
| 16:50 |
|
rach |
yep I think there will be |
| 16:50 |
|
chris |
all depends or your definition of enough :) |
| 16:51 |
|
thd |
chris: enough will be when every library at least seriously considers it |
| 16:51 |
|
rach |
:-) that's what I like - big dreams |
| 16:52 |
|
thd |
owen: OpenILL was developed with the GPL in mind, but has been run as a service to recover costs without code distribution |
| 16:53 |
|
owen |
Were any of the top ILS's developed by libraries and later spun off as a business? |
| 16:53 |
|
thd |
owen: at least OpenILL has the intention of releasing code |
| 16:53 |
|
rach |
yep I think so |
| 16:53 |
|
rach |
is open ILL the pines project? |
| 16:53 |
|
rach |
or something else? |
| 16:54 |
|
thd |
rach: something else |
| 16:54 |
|
thd |
rach: http://www.openill.org/ |
| 16:55 |
|
thd |
rach: What were you answering with "yes I think so"? |
| 16:56 |
|
thd |
s/yes/yep |
| 16:56 |
|
rach |
oh that other libraries have built systems |
| 16:56 |
|
rach |
and sold them |
| 16:56 |
|
rach |
but they tend to form a company to do it |
| 16:56 |
|
thd |
rach: full ILS systems? |
| 16:57 |
|
thd |
:) |
| 16:57 |
|
thd |
rach: let me know if you do remember |
| 16:57 |
|
owen |
thd, were you thinking of other examples as well? |
| 16:57 |
|
rach |
that was my understanding - it may have beena company that approached a number of libraries and got the funding from them to do it - |
| 16:58 |
|
rach |
rosalie might know |
| 16:58 |
|
rach |
certainly libraries in NZ have built bespoke systems in the past with varying degrees of success |
| 16:59 |
|
thd |
owen: most software developed by libraries is not distributed. Another example I recently came across was an OpenURL resolver service. |
| 17:05 |
|
thd |
rach: I was particularly interested in the possibility that a major ILS company may be the offshoot of a development project funded by a library receiving public funds to create the software in the first place. It goes on all the time really when companies contract with tax supported entities but I would be curious about the founding of any of the major ILS companies. |
| 17:11 |
|
thd |
rach: The world is grateful that neither HLT nor Katipo had anyone with pretencions to become a library systems vendor at the time you were creating Koha :) |
| 17:15 |
|
rach |
:-) |
| 17:15 |
|
rach |
well it paid off for us certainly |
| 17:23 |
|
rach |
thd - I think most library companies would have grown up like that - I know that they "pre sell" sort of shares in new features to raise the funds to do the development |
| 17:24 |
|
rach |
so I suspect that you would find that most library systems have something like that in their past |
| 17:24 |
|
thd |
rach: The momentum for FOSS is still too recent for other libraries to appreciate the FOSS model as they should. Actually, the closed source model is the brief interruption in the historic use of software. Closed source is just the brief interruption that most people grew up with and understand better. |
| 17:25 |
|
rach |
yep - but I think it's why libraries seem to have some difficulty understanding why OS is different - because they already fund new developments etc |
| 17:25 |
|
rach |
or they have done in the past |
| 17:25 |
|
thd |
rach: I wish I knew how to identify the actual source of how library companies grew up to use in a presentation. |
| 17:26 |
|
rach |
if you can get hold of him, try talking to Pat Eyler (maybe send him a personal mail) he has worked in and around library vendors in the past, and I think would have a good general knowledge |
| 17:27 |
|
thd |
rach: Was he at Katipo when Koha was first developed? |
| 17:31 |
|
thd |
rach: Is Pat Eyler pate-away? |
| 17:32 |
|
rach |
yes he is |
| 17:32 |
|
rach |
and no pat's in the states, he hasn't worked for us |
| 17:33 |
|
thd |
rach: Is he ever pate or always pate-away? :) |
| 17:33 |
|
rach |
:-) |
| 17:33 |
|
rach |
very occasionally he's pate |
| 20:54 |
|
pate-away |
rach, thanks for the vote of confidence |
| 21:29 |
|
pate |
hmm, i decide to make an appearance, and everyone is off doing other stuff. i see how it is. |
| 21:42 |
|
thd |
pate: I am here doing other stuff :) |
| 21:44 |
|
thd |
pate: you should announce your appearance with a thunderclap to get everyones attention |
| 21:53 |
|
thd |
pate: "1983 | Based on BYU-created library programming, a team of former BYU staff and grads James Wilson, Paul Sybrowski, Keith Wilson, and Ralph Egan create DYNIX, now the world?s largest library-automation company." http://magazine.byu.edu/article.tpl?num=46-Win04 |
| 21:55 |
|
chris |
and one of the hardest to migrate from |
| 21:55 |
|
chris |
perhaps thats by design |
| 21:59 |
|
thd |
chris: what especially complicates the migration process? |
| 22:00 |
|
chris |
having no way to export the data is a good start :) |
| 22:00 |
|
chris |
we got there in the end, buy installing uniVerse shifting the binaries of the data to the machine |
| 22:01 |
|
rach |
hey pat |
| 22:01 |
|
thd |
chris: you mean the system will not even dump the records in MARC communications format? |
| 22:02 |
|
thd |
chris: What is uniVerse? |
| 22:03 |
|
chris |
nope it wont, uniVerse is the database its built on |
| 22:03 |
|
chris |
this is an old version of dynix .. at least 10 years old |
| 22:03 |
|
chris |
ibm own uniVerse now |
| 22:03 |
|
chris |
and have a free version luckily |
| 22:04 |
|
pate |
hiya rach |
| 22:04 |
|
pate |
uniVerse is a PICK like system |
| 22:04 |
|
chris |
it sure is :) heya pate |
| 22:05 |
|
pate |
actually, I think you could write a PICK-Basic program to dump the data out in any format you wanted to ... finding someone with the expertise to do so is another matter |
| 22:05 |
|
chris |
luckily we found someone who was familair with dynix and we starting poking at things in the uniVerse shell, and got the data out |
| 22:05 |
|
pate |
not to mention that i think you'd be violating your license with dynix |
| 22:05 |
|
chris |
probably |
| 22:06 |
|
thd |
chris: I would never enter data into a progarm without a standards compliant export feature, but I guess not everyone beards that in mind when choosing a system :) |
| 22:06 |
|
pate |
thd, i'm not sure i merit thunderclaps ... |
| 22:06 |
|
chris |
often you dont have a lot of choice |
| 22:06 |
|
chris |
well small libraries in nz sure didnt |
| 22:06 |
|
chris |
you get what the vendor deigns to give you .. and you be happy about it |
| 22:06 |
|
chris |
:) |
| 22:07 |
|
pate |
and if that doesn't steer you towards free software, I don't know what will ;) |
| 22:07 |
|
thd |
chris: you mean none of the competition would have a standards based export feature either? |
| 22:08 |
|
chris |
10 years ago ... i doubt one that they could afford |
| 22:08 |
|
thd |
pate: just clapping then |
| 22:09 |
|
chris |
:) |
| 22:10 |
|
pate |
so chris, have you had a chance to play with Rails at all? |
| 22:11 |
|
thd |
chris: 10 years ago more software had a greater degree of vendor lock in than 5 years ago. I am eternally surprised to see what vendors still try to get away with in terms of that though. |
| 22:12 |
|
chris |
nope not yet pat |
| 22:13 |
|
chris |
thd: oh yeah |
| 22:13 |
|
thd |
Sirsi has acquiring Dynix is not likely to promote competition |
| 22:13 |
|
thd |
s/has// |
| 22:18 |
|
chris |
the ILS vendor market is almost as confusing as hte media one .. everyone keeps buying everyone else, or changing their names |
| 22:21 |
|
thd |
chris: If you change your name often enough, you can sell everyone the same thing three times and they think they will be getting something new each time. |
| 22:21 |
|
chris |
good point :) |
| 22:30 |
|
pate |
well, /me needs to go back into lurk mode ... I've got an article to finish tonight and I'm getting tired |
| 22:31 |
|
chris |
cya pate |
| 22:31 |
|
pate-lurk |
i'll be around (though email is always the best way to get me) |
| 08:12 |
|
kados |
afternoon paul |
| 08:12 |
|
paul |
morning joshua |
| 08:13 |
|
hdl |
hi joshua. |
| 08:14 |
|
kados |
afternoon hdl |
| 08:14 |
|
kados |
paul: did you get the forwarded messages from Mike Rylander about multi-branch support in PINES? |
| 08:15 |
|
kados |
paul: there's some interesting stuff in there about how PINES is handling the 'arbitrary tree' for relationships between libraries |
| 08:16 |
|
kados |
paul: I don't think it's exactly right for Koha though as it goes too deep (into biblios) |
| 08:16 |
|
paul |
i have the mails, but some very urgent things to do before. |
| 08:17 |
|
kados |
paul: ok ... well whenever you can ... |
| 10:11 |
|
owen |
paul, are you around? |
| 10:11 |
|
paul |
yes |
| 10:11 |
|
owen |
I'm curious about your response to thd's question about mapping item information |
| 10:12 |
|
owen |
He was curious why item info has to be mapped to the same tag |
| 10:12 |
|
owen |
I said it probably has to do with keeping it in additems.pl |
| 10:12 |
|
paul |
yes & no. |
| 10:13 |
|
paul |
if you map 2 fields to items that would be highly tricker to manage 2 items for a biblio. |
| 10:13 |
|
paul |
as you would have (for example, with 995 & 996 being items tab) : |
| 10:13 |
|
paul |
200$atitle $f author |
| 10:13 |
|
paul |
995 $a item1 info |
| 10:14 |
|
paul |
996 $a item other info |
| 10:14 |
|
paul |
995 $a another item info |
| 10:14 |
|
paul |
996 $a another item other info |
| 10:14 |
|
paul |
how to be sure that the 1st 995 goes with the 1st 996 & not with the 2nd ? |
| 10:15 |
|
paul |
in SUDOC (UNIMARC for french universities) they use 906/907/908 for items. |
| 10:15 |
|
paul |
and a $3 to be sure to merge them correctly |
| 10:15 |
|
paul |
but most ILS, in fact, when importing sudoc, merge the 3 in a single marc tag. |
| 10:15 |
|
paul |
does this make sense ? |
| 10:16 |
|
owen |
Yeah it does. I'm not sure why thd considers that a bad way of doing things. Maybe he just doesn't like the fact that it's not possible. |
| 10:18 |
|
kados |
well it's a real pain if you've got item information in 852 and you have to move it to 952 |
| 10:18 |
|
paul |
??? |
| 10:18 |
|
kados |
with MARC21 we have to move all item info from 852 to 952 |
| 10:18 |
|
paul |
why ? |
| 10:18 |
|
kados |
when we're migrating |
| 10:19 |
|
paul |
because there is information not related to items in 852 ? |
| 10:19 |
|
kados |
probably yes |
| 10:19 |
|
paul |
(that you have to keep) |
| 10:19 |
|
kados |
I don't remember the specifics though |
| 10:19 |
|
kados |
I think biblioitem stuff is also in 952 |
| 10:21 |
|
kados |
hmmm ... I don't see it in the default MARC21 |
| 10:22 |
|
kados |
hmm m... not seeing anything in NPL's MARC mappings either |
| 10:22 |
|
kados |
so that must not be the reason |
| 10:23 |
|
kados |
I'll have to ask Stephen |
| 10:23 |
|
kados |
owen: do you remember? |
| 10:23 |
|
owen |
No |
| 10:28 |
|
kados |
just spoke to stephen |
| 10:28 |
|
kados |
he said the main reason was that NPL already had stuff in 952 |
| 10:28 |
|
kados |
and a secondary reason was that 952 is more flexible |
| 10:28 |
|
kados |
since it's locally defined |
| 10:29 |
|
kados |
whereas 852 is limited by the standard definitions |
| 10:36 |
|
owen |
thd, any comments on all that? |
| 10:38 |
|
kados |
paul: is there a way to seperate call number in Koha? |
| 10:38 |
|
kados |
for example, in Sagebrush installations you've got: |
| 10:38 |
|
kados |
852$k is call number prefix |
| 10:38 |
|
kados |
852$k is call number main |
| 10:38 |
|
kados |
852$i is call number cutter |
| 10:38 |
|
kados |
852$m is call number suffix |
| 10:38 |
|
thd |
kados: 852 would be the standard place to store much of the items information in MARC21, but not all. In the Koha Diary there is an email from paul recommending the use of unassigned 852 subfields. |
| 10:40 |
|
paul |
there is none in non-MARC part of the DB. |
| 10:41 |
|
thd |
At some point items were switched to 952 for NPL. Certainly a better choice than using an unassigned subfields that might be assigned for a different purpose in future. |
| 10:42 |
|
thd |
kados: does Sagebrush use 852 $p ? |
| 10:42 |
|
kados |
thd: yes |
| 10:42 |
|
kados |
852$6 is format |
| 10:42 |
|
kados |
852$p is barcode |
| 10:42 |
|
kados |
852$9 is cost |
| 10:42 |
|
kados |
852$8 is accession date |
| 10:42 |
|
kados |
852$k is call number prefix |
| 10:42 |
|
kados |
852$k is call number main |
| 10:42 |
|
kados |
852$i is call number cutter |
| 10:42 |
|
kados |
852$m is call number suffix |
| 10:48 |
|
kados |
thd: Koha lists 852p as 'Piece designation (NR) |
| 10:48 |
|
kados |
thd: is that the standard place to store barcodes in MARC21? |
| 10:48 |
|
thd |
kados: You need a script to concatenate 852 $k$i$m |
| 10:48 |
|
kados |
thd: already got one ;-) |
| 10:49 |
|
thd |
Linking any one of 852 $p to items.barcode; 850 $a, 852 $a, or 852$b to items.homebranch; 541 $b to items.price; 365 $b to items.replacementprice; 852 $b to items.holdingsbranch; 852 $c, 852 $j, 852 $x, or $852 $z to items.stack results in the following error message from MARC Check. |
| 10:49 |
|
thd |
"item fields |
| 10:49 |
|
thd |
ALL items fields MUST : |
| 10:49 |
|
thd |
* be mapped to the same tag, |
| 10:49 |
|
thd |
* and they must all be in the 10 (items) tab" |
| 10:50 |
|
thd |
kados: above would be a MARC21 standards mapping |
| 10:50 |
|
owen |
thd, did you read paul's explanation above? |
| 10:51 |
|
thd |
owen: yes, the explanation is based on UNIMARC practice. I am not sure I understood it entirely. |
| 10:51 |
|
paul |
let me explain in a few words : |
| 10:51 |
|
paul |
if you have 2 items. |
| 10:52 |
|
paul |
you bought the 1st USD10 and the 2nd USD8 |
| 10:52 |
|
paul |
one has barcode 1, one barcode 432 |
| 10:52 |
|
paul |
how do you know which one you bought USD10 ? |
| 10:52 |
|
thd |
paul: by the linking subfield |
| 10:54 |
|
thd |
thd hope he is correct about this because he has just guessed now that he understands the problem :) |
| 10:54 |
|
thd |
s/hope/hopes |
| 10:55 |
|
thd |
I have just guessed :-) |
| 10:56 |
|
kados |
paul: there must be a way since all other MARC21 implementations I know of use 852 ... |
| 10:56 |
|
kados |
paul: erp ... I don't mean use 852 |
| 10:57 |
|
paul |
but you can use 852 in Koha ! |
| 10:57 |
|
kados |
paul: right ;-) |
| 10:57 |
|
kados |
paul: it was a mistake ... I mean other MARC21 implementations don't have the limitation of having all item info in a single tag |
| 10:57 |
|
kados |
paul: unless I am wrong ;-) |
| 11:31 |
|
thd |
paul: One cannot use 852 and other fields also in Koha. I would like to use 852 for what 852 provides in the standard and 952 or another local use field together, instead of using unassigned 852 subfields to try to fit everything into 852. |
| 11:31 |
|
thd |
paul: I am going to ask your price question on the autocat list. The list is moderated so the question may not appear today. |
| 11:32 |
|
thd |
paul: I have never understood how $8 field link and sequence number in MARC21 is supposed to work well enough. The explanatory examples I have seen are very short on explanation, having none. $8 usage is just not covered well if at all in any reference I have. |
| 11:32 |
|
paul |
it's time to leave. The mediteranean see is waiting impatiently for my arrival ;-) |
| 11:57 |
|
thd |
Oops, in my example mappng above, s/541 $b/541 $h/ |
