| Time |
S |
Nick |
Message |
| 20:25 |
|
thd |
kados: are you around? |
| 21:13 |
|
kados |
thd: I'm around now ... just not answering my phone ;-) |
| 21:14 |
|
russ |
request for questions? |
| 21:14 |
|
russ |
doh |
| 21:14 |
|
russ |
quotation |
| 21:14 |
|
kados |
right ;-) |
| 21:14 |
|
russ |
time for another coffee |
| 21:30 |
|
thd |
kados: look at http://www.kohadocs.org/holdings.html#d0e445 . I have been revising the mappings part of earlier sections of this document this weekend with the addition of recommended table changes, settings usage, coverage of 942, 856, etc. |
| 21:34 |
|
thd |
kados: I had not intended to put more detail into the cited standards description at this time. There is a small error in the MARC 21 standards description that derived form some poor wording in LC documentation but that should not adversely affect understanding. |
| 21:39 |
|
thd |
russ, chris: how much support for serials holdings does your prospective serials customer have already, need, expect? |
| 21:42 |
|
russ |
thd: what do you mean by support? we are at the building a requirements document phase |
| 21:42 |
|
russ |
so very early on in this project |
| 21:43 |
|
thd |
russ: requirements for Koha is exactly what I mean. |
| 21:49 |
|
kados |
I think what's happened in Koha development thusfar |
| 21:50 |
|
kados |
is that we've only done the bare minimum to address the needs of a specific client |
| 21:50 |
|
kados |
without stepping back and looking to the future in terms of what needs to happen for bigger clients down the road |
| 21:50 |
|
kados |
actually, i think that's a probably a fair characterization of a lot of open source software |
| 21:50 |
|
chris |
i think thats true, if you add in "In some cases" |
| 21:51 |
|
kados |
yes ... MARC support being one of those cases ;-) |
| 21:51 |
|
kados |
but I agree it doesn't apply in other areas where we're actually leading the pack |
| 21:51 |
|
kados |
like interface design for instance |
| 21:51 |
|
kados |
and use of templates |
| 21:51 |
|
kados |
etc. |
| 21:51 |
|
rach |
there is going to be a tension when a specific client is asking/paying for something |
| 21:51 |
|
thd |
russ: Is the serials holdings form as it currently exists significantly insufficient for your non-MARC client? |
| 21:51 |
|
rach |
it is really hard then as we all know to not get |
| 21:52 |
|
rach |
"captured" by what that client wants |
| 21:52 |
|
kados |
unfortunately, the problem with having weak MARC support (like we have now) is that we'll never really land a solid client |
| 21:52 |
|
kados |
unless |
| 21:52 |
|
rach |
The serials yes is insufficient |
| 21:52 |
|
rach |
and inexplicable as well to a large degree |
| 21:52 |
|
kados |
they _buy_ into the whole open-source 'build it to meet your needs' idea |
| 21:52 |
|
kados |
which is a _very_ hard sell at the large-library level |
| 21:53 |
|
chris |
yep, marc support is due to be fixed though isnt it, most of the problem goes away with the use of flat files and zebra |
| 21:54 |
|
chris |
then its all interface, which is easy |
| 21:54 |
|
chris |
correct me if im wrong |
| 21:55 |
|
chris |
but the problem with current marc support is in the storage of it, the structure isnt flexible enough to handle the madness that is a marc record |
| 21:55 |
|
chris |
if we just store them as marc records, this problem largely goes away |
| 21:55 |
|
kados |
phone ... sorry :-/ |
| 21:55 |
|
chris |
and our problem becomes, showing the information to ppl |
| 21:55 |
|
thd |
rach: If you want really inexplicable serials look at some of the more complex parts of captions and patterns, and enumeration and chronology fields for MARC holdings. |
| 21:56 |
|
chris |
thd: the main insufficiency is, serials doesnt create items currently |
| 21:56 |
|
chris |
so for public libraries, which issue serials |
| 21:56 |
|
chris |
its wholly insufficient |
| 21:56 |
|
rach |
so the work that paul has done, doesn't replace our original serials workaround |
| 21:57 |
|
chris |
it would be fine for a library that has serials that are purely for reading within the library |
| 21:57 |
|
chris |
but if you want to issue them, then yes, the original workaround |
| 21:57 |
|
rach |
which presumably whoever got paul to do the work did |
| 21:57 |
|
chris |
probably an academic library |
| 21:57 |
|
rach |
yep |
| 21:58 |
|
chris |
theres no reason it cant be extended to create items |
| 21:58 |
|
rach |
yep which I'm hoping is where we are going :-) |
| 21:59 |
|
chris |
and using a system preference variable, should be able to work for both library types |
| 21:59 |
|
rach |
well at least we agree chris :-) |
| 21:59 |
|
thd |
chris: There is a problem with creating very many repeating issue fields in a single MARC record. |
| 21:59 |
|
rach |
within KOha, or in general? |
| 22:01 |
|
chris |
repeating fields within flat file representation are always problematic |
| 22:01 |
|
chris |
its just one of the many things wrong with MAR |
| 22:01 |
|
chris |
C |
| 22:01 |
|
thd |
rach: In MARC, the record can grow so large that MARC::PM can no longer manage it after it breaks the maximum size for a single record using repeated fields for every issue. |
| 22:01 |
|
chris |
but before i start ranting im gonna go do some work instead |
| 22:02 |
|
rach |
so within Koha - which is what chris has just said is looking to be quite radically changed |
| 22:02 |
|
rach |
well it's what I understood by what he said to Kados a few minutes ago |
| 22:02 |
|
rach |
YMMV |
| 22:03 |
|
thd |
rach: The workaround is to create multiple linked holdings records before the size becomes too large. |
| 22:03 |
|
thd |
rach: YMMV? |
| 22:03 |
|
rach |
your millage may vary |
| 22:04 |
|
rach |
- umm seems to mean you may have a different experience/understanding |
| 22:05 |
|
rach |
are you suggesting that as a workaround, or is that what Joshua et al are implementing? |
| 22:05 |
|
thd |
rach: I have not learnt most of the abbreviated IRC communications conventions yet. :) |
| 22:06 |
|
rach |
ah it's a mailing list one I think - well that's where I will have got it from :-) It's quite a useful one |
| 22:06 |
|
rach |
along with IANAL and IANAP |
| 22:06 |
|
rach |
I am not a lawyer, I am not a programmer - usually followed by a "but" |
| 22:07 |
|
thd |
rach: Those are more common. I learnt those a few years ago :) |
| 22:09 |
|
thd |
rach: I have probably[D[D[a[C[C[C deciphered YMMV before when preceded by a 'but'. |
| 22:11 |
|
thd |
rach: Multiple linked records was a suggestion. I have not answered on the list yet to the recent question about serials. |
| 22:17 |
|
thd |
rach: Maybe, if every issue was a linked record it could work around the field and subfield ordering problem that exists in MARC Koha currently. Otherwise MARC serials work cannot be started until 3.0 has fixed field and subfield ordering and subfield repeatability. |
| 22:19 |
|
chris |
well it wont be done before 3.0 anyway |
| 22:19 |
|
chris |
there are no more features planned for 2.2.x |
| 22:19 |
|
chris |
it would be kinda pointless to do marc serials then completely change the way koha handles marc |
| 22:20 |
|
rach |
well yes it would |
| 22:23 |
|
rach |
our (Katipo's) strength is not MARC - I suspect that our best contribution is in working out from the users perspectives what is wanted - so that's what we're concentrating on |
| 22:30 |
|
thd |
rach: The confusing part of the serials patterns that is there now in Koha is the same as would be for MARC serials. A friendly interface is needed for controlling the coded information that uses drop down value lists for creating the publication pattern and automatically creates an item for attaching a barcode when an issue is received. |
| 22:34 |
|
rach |
it does seem to be quite a minefield |
| 22:38 |
|
thd |
rach: I told kados that the full work that could be involved for adding MARC holdings standards support is comparable to the work for adding MARC bibliographic standards support to date, although, something significantly short of that could be functional at a minimal level and more affordable :) |
| 22:40 |
|
thd |
rach: minefields just need to be well mapped so that you can walk around them until you can afford to clear them completely :) |
| 22:44 |
|
rach |
the way that "stuff" has been added to Koha in the past is in a "staged" way - so first up someone does the proof of concept - then other libraries see enough to comit to doing the next stage |
| 22:45 |
|
rach |
we are unlikely without someone dieing and leaving the project a fortune to be able to do it any other way - which for the idealists among us I susepct is pretty frustrating |
| 22:45 |
|
chris |
if we did it any other way, we still wouldnt have a koha |
| 22:45 |
|
chris |
we'd still be speccing it |
| 22:46 |
|
rach |
we'd be Avanti :-) |
| 22:48 |
|
rosa |
and we'd be desperate |
| 22:49 |
|
thd |
rach: Except that you would have had the prudence to not start an implementation of an OSS library system in Java without enough supporting modules to make it work. |
| 22:49 |
|
rach |
well yes |
| 22:50 |
|
rach |
but the point being that our more pragmatic development style has got us a library system that libraries can acutally use :-) |
| 22:50 |
|
rach |
but we're unlikely to be able to do the "complete soloution" to any one problem using this model, it will be a process of continued gradual improvement |
| 22:50 |
|
rach |
as various itches are scratched |
| 22:58 |
|
thd |
rach: It is difficult to find libraries in the US sufficiently satisfied with the current level of MARC support that they are even willing to invest in an incremental improvement. I expect that will change modestly with 3.0. I just wish 3.0 were the starting point already. |
| 23:00 |
|
rach |
patience is a virtue :-) |
| 23:04 |
|
chris |
its just a shame there arent more libraries are brave as hlt and npl |
| 23:04 |
|
thd |
rach: eating may not be a virtue, but it is a necessary condition for filling the patience virtue |
| 23:08 |
|
thd |
chris: It is unusual in the world generally, for a customer to pay for something that does not exist yet. |
| 23:08 |
|
chris |
not really |
| 23:08 |
|
chris |
99% of our work is doing just that |
| 23:09 |
|
rach |
surely that's what all library vendors seem to do |
| 23:09 |
|
rach |
it's a v common way to do software development |
| 23:09 |
|
chris |
its what you do with a builder or an electrician or a plumber |
| 23:09 |
|
chris |
they quote, and then they do the work, and you pay them for it |
| 23:09 |
|
rach |
they don't pay for it until it's proven/done, but certainly you undertake to do it |
| 23:09 |
|
rach |
and often pay a deposit |
| 23:10 |
|
chris |
i paid for my lounge suite before it existed |
| 23:12 |
|
chris |
and there is nothing unusual at all about commiting to pay for something when it does exist |
| 23:12 |
|
chris |
it happens all the time |
| 23:13 |
|
chris |
just maybe not in libraries |
| 23:13 |
|
thd |
chris, rach: The difference is that to win those contracts you have to persuade the customer that you have done something sufficiently comparable. While Koha without some major set of features seldom seems comparable to the alternatives with large license fees. |
| 23:16 |
|
rach |
and this would be why when we wrote Koha we didn't chuck in the day jobs |
| 23:16 |
|
rach |
it's a long slow haul to prove yourselves etc |
| 23:16 |
|
rach |
our competitors have been around for a long time |
| 23:17 |
|
thd |
chris rach: you hire a house builder after seeing other houses the builder has done. Most libraries think of Koha as just the roof perhaps and are afraid to hire roofers to build the walls and foundation. |
| 23:20 |
|
chris |
ah well, we were lucky to find a few not that shortsighted and can only hope as koha improves more, it will be a nicer target |
| 23:23 |
|
thd |
rach: I think the proprietary companies that still exist started with much more complete systems relative to the maturity of the market with one exception. |
| 23:25 |
|
thd |
rach: I can think of a major proprietary systems vendor that may have started with support services at which they excelled long ago. |
| 23:27 |
|
thd |
rach: I am supposing that if one module were able to compete with the best comparable module from any other system that Koha would be better noticed. |
| 23:28 |
|
chris |
thats entirely subjective, but id put up a well skinned koha opac against any of the proprietary systems web opacs |
| 23:29 |
|
thd |
rach: The task of making the whole system comparable with systems that have been around for decades is too large. |
| 23:30 |
|
thd |
chis: It is difficult to separate the OPAC from the rest of the system. |
| 23:32 |
|
rach |
From what we've seen of other systems, just making it look nicer would be a big leap forward |
| 23:32 |
|
rach |
over other systems |
| 23:33 |
|
chris |
yep, thats why i said well skinned |
| 23:33 |
|
thd |
chris: Although if it could be separated, anything that can be separated and interoperable with another system would be a good candidate for using as a means for other libraries to become familiar with Koha without a full commitment. |
| 23:33 |
|
rach |
people are very swayed by what things look like - if we wanted to get more credible the easiest/cheapest way would be to make it more beautifuly IMO |
| 23:35 |
|
kados |
rach: I agree that that works for smaller libraries but based on the conversations I've had with some of the larger systems what they are most concerned is support of standards |
| 23:36 |
|
kados |
and unfortunately, we haven't had enough investment in Koha yet to do a good job of that |
| 23:36 |
|
chris |
we could just lie like the other vendors do |
| 23:36 |
|
kados |
hehe |
| 23:36 |
|
kados |
ha! |
| 23:37 |
|
thd |
rach: yes that can be quite true. I tried to demonstrate a partly working unattractive mockup against an attractive but functionally deficient system and the person was only exclaiming the virtues of the appearance of the other functionally deficient system |
| 23:40 |
|
thd |
chris: some people have suggested to me privately that Koha already is lying with claiming to support MARC where that claim is not qualified. |
| 23:40 |
|
chris |
ah well |
| 23:42 |
|
rach |
so clearly the big libraries still have lots of funding - because they can afford to stand on their principles, whereas smaller libraries who are getting squeezed perhaps appreciate the pragmitism a bit more. |
| 23:42 |
|
rach |
I'm guessing that chipping away at the big libraies is all we can do - continue to improve, continue not to go away |
| 23:42 |
|
rach |
that's been our approach anyway |
| 23:42 |
|
rach |
but it's not a get rich quick scheme I will admint |
| 23:44 |
|
thd |
chris: Other vendors pursue significant independent capital beyond what comes from their customers in license fees and maintenance. They all seemed to have had much more working capitol of their own when starting. |
| 23:45 |
|
rach |
and this would contribute to why they aren't open source :-) |
| 23:46 |
|
chris |
yep, if one of those vendors with a fully functioning, compliant system released it under the gpl id start working with that |
| 23:47 |
|
thd |
rach: It could still be done for open source. However, convincing a banker or another investor that open source is a better investment is difficult. |
| 23:50 |
|
rach |
has someone tried? |
| 23:51 |
|
thd |
Investors usually want to acquire an interest in the assets for security. The source code and contracts are the only significant securable assets in proprietary software companies. |
| 23:51 |
|
kados |
um ... so there's always Evergreen ;-) |
| 23:52 |
|
rach |
maybe the marc hangups are just an american thing |
| 23:52 |
|
rach |
sorry guys |
| 23:52 |
|
rach |
paul seems to be run off his feet |
| 23:52 |
|
thd |
kados: Evergreen has made some of the same mistakes about standards as Koha has. |
| 23:52 |
|
rach |
have you considered moving :-) |
| 23:56 |
|
thd |
rach: investors in GPL software companies cannot acquire any greater interest in the source code than the rest of the world leaving only the limited contracts as security. |
| 23:58 |
|
thd |
rach: significant investment in OSS companies for code development has mostly come from other companies wanting to use the software themselves. |
| 00:00 |
|
thd |
rach: So you just need to find some big businesses that want a library system that can be as easily customised as Koha. |
| 00:01 |
|
rach |
yep that's pretty much who we look for |
| 00:02 |
|
rach |
and we do a lot of non library work as well - which adds to our general credibility as contractors |
| 00:03 |
|
thd |
rach: Do you have more business library customers than non-business libraries for Koha? |
| 00:03 |
|
rach |
in round numbers yes |
| 00:03 |
|
rach |
as in - more actual people |
| 00:04 |
|
rach |
more clients - in $ terms probably about the same |
| 00:05 |
|
rach |
certainly more business/private libraries than public libraries by a lot |
| 00:07 |
|
rach |
but we often do less for them |
| 00:07 |
|
rach |
or bundle koha with other services more |
| 00:14 |
|
thd |
rach: In the US, the business libraries are focussed on serials first and MARC second. Bridging the gap to appeal to businesses, as the most likely customers to consider investing in Koha, would mean a lot of development work first for the very features that Koha has the least sufficient development now to appeal to the US business library market. |
| 00:15 |
|
rach |
serials is what most businesses are interested in - which is why we're really happy to get a business client who wants us to work on them with them |
| 00:22 |
|
thd |
rach: Maybe between your customer and the two that kados has, part of that minefield can be cleared. It would be unfortunate if the minefield were merely mapped around or only cleared in the centre, without leaving a through path. |
| 00:23 |
|
rach |
hopefully, we're certainly going to try and marry up our work and make it as widely useful as poss |
| 00:29 |
|
thd |
rach: Koha needs to demap some of those minefields in a joint operation so that everyone can frolic with building improvements that other systems do not have rather than apologising for, "well, not yet, someday; but look over here this feature is nifty". |
| 00:30 |
|
rach |
that's part of what you've been doing isn't it? |
| 00:30 |
|
rach |
or did I get that wrong? |
| 00:30 |
|
thd |
rach: I have been mapping the minefields not demapping them yet :) |
| 00:31 |
|
thd |
rach: It is dangerous to demap them before they have been cleared :) |
| 03:02 |
|
osmoze |
hello |
| 03:36 |
|
thd |
hello osmoze |
| 04:08 |
|
thd |
good morning paul |
| 04:08 |
|
paul |
hi thomas |
| 04:10 |
|
thd |
paul: what do libraries do for their UNIMARC copy catalogued records from BnF which have both 700 $a $b? I know that is easily concatenated to just $a if it needs to be. |
| 04:12 |
|
thd |
paul: I am just asking if you have written a script to do that concatenation and hidden it somewhere in Koha. |
| 04:13 |
|
thd |
paul: also, is there an SQL update script for 2.2.4? |
| 04:22 |
|
thd |
paul: sorry, I see the that the SQL files are identical between 2.2.3 and 2.2.4. I had thought there would be minor changes. |
| 04:32 |
|
paul |
thd : when you upgrade your version, koha runs updater/updatedatabase |
| 04:32 |
|
paul |
same thing when you install, it installs 2.2.0 official DB, and update it |
| 04:33 |
|
paul |
that's why the koha.mysql doesn't change. |
| 04:33 |
|
paul |
(in 2.2 branch, will be different in 3.0) |
| 04:35 |
|
thd |
paul: does 2.2.x have no provision for adding a column to a table for koha.update? |
| 04:35 |
|
paul |
??? |
| 04:37 |
|
thd |
paul: Where would the SQL for new columns or new tables go for 2.2.3 -> 2.2.4 if there had been any? |
| 04:37 |
|
paul |
there are. |
| 04:38 |
|
paul |
everything is in updater/updatedatabasE. but it's not SQL. it's perl script (& an intelligent one : checks what it has to create and do only what's needed) |
| 04:39 |
|
thd |
paul: I was just about to do a diff on that file as I had noticed that the file size had changed. |
| 05:03 |
|
thd |
paul: I see what you mean now by not SQL. You do not consider intelligent generation of SQL statements from a Perl script to be SQL. For you, an SQL file with nothing but blind SQL statements would be SQL. Intelligent SQL does work better than trying to accomplish the same task in an SQL file blindly with brute force by dumping the data, dropping the tables, creating new tables, and reinserting the data. |
| 06:40 |
|
thd |
So the default OPAC template is now only good for non-MARC Koha. |
| 07:34 |
|
osmoze |
paul, as tu un petit moment ? J ai un probleme avec le fichier de retour bdp, dans la 2.2.3 et la 2.0 ...Je comprend plus :(, en attendant, vais installer la 2.2.4 en remplacement de la 2.2.3 |
| 07:49 |
|
paul |
osmoze, je suis là |
| 08:02 |
|
osmoze |
coucou paul |
| 08:02 |
|
osmoze |
je comprend pas, le script (nettoi_bdp) trouve pas les codes barre |
| 08:02 |
|
osmoze |
:( |
| 08:03 |
|
paul |
envoie le script ET le fichier BDP par mail stp. |
| 08:05 |
|
osmoze |
ok :) je fini l install de la 2.2.4 avant ^^ |
| 09:50 |
|
thd |
paul: why is the itemcallnumber preference missing from demo.koha-fr.org ? |
| 09:56 |
|
thd |
paul: it is not there at the moment. I was hoping to check whether it worked there. |
| 10:01 |
|
thd |
paul: the value does not appear for me unless I do something wicked such as swapping the mapping of items.itemnumber for items.callnumber. Then the subfield is using a special reserved name called by the template. |
| 10:03 |
|
thd |
paul: do you have any libraries that use this feature? |
| 10:04 |
|
paul |
f |
| 10:05 |
|
timing |
Hello we are a public school district with 7 elementary libraries, 2 middle school libraries and 1 high school library |
| 10:05 |
|
timing |
and we are looking at koha |
| 10:06 |
|
paul |
good idea. where are you located ? |
| 10:06 |
|
paul |
(country at least) |
| 10:06 |
|
timing |
does any one have this same setup and would like to answer some questions |
| 10:06 |
|
timing |
USA, burleson, texas |
| 10:07 |
|
paul |
maybe, probably. I'm Paul Poulain, Release MAnager for 2.x branch. And joshua / kados, the release manager for 3.0 is never far. |
| 10:07 |
|
paul |
i'm french & joshua is from Nelsonville, Ohio. |
| 10:08 |
|
timing |
just the guys i need |
| 10:08 |
|
paul |
throw your question. |
| 10:09 |
|
timing |
we currently use Follet and each library has its own database and marc records |
| 10:09 |
|
kados |
hi timing |
| 10:09 |
|
paul |
hehe... joshua never sleeps. 24/7 on this channel ;-) |
| 10:09 |
|
timing |
hello kados |
| 10:10 |
|
kados |
one of the libraries I manage used Follet many years ago |
| 10:10 |
|
kados |
what are your questions? |
| 10:11 |
|
timing |
I really want to use koha and we have 10 libraries with seperate databases and marc records |
| 10:11 |
|
kados |
right |
| 10:11 |
|
timing |
we want a system that will allow us to seperate the campus libraries but allow for additional searches |
| 10:12 |
|
timing |
to borrow |
| 10:12 |
|
kados |
so a consortium of sorts eh? |
| 10:13 |
|
timing |
like if a student looks for harry potter he will see if it is on his campus if not search for other campus |
| 10:13 |
|
kados |
right ... |
| 10:13 |
|
kados |
do any of your libraries have branches? |
| 10:14 |
|
timing |
each school is its own branch |
| 10:14 |
|
timing |
7 elem 2 middle and 1 high shcool |
| 10:14 |
|
timing |
school oops |
| 10:15 |
|
timing |
I see where to set up the braches but not really sure how to set up database and import marc records for each branch |
| 10:15 |
|
kados |
ahh ... |
| 10:16 |
|
kados |
well, the catalog is central to all branches |
| 10:16 |
|
kados |
though it would be very easy to specify which branch a set of records belongs to |
| 10:17 |
|
kados |
as far as bulk import, there is a command-line tool called 'bulkmarcimport' |
| 10:17 |
|
kados |
it takes MARC records and imports them into Koha |
| 10:17 |
|
timing |
but if student searches for a book and the book is not at his branch does it show all other branches that have it |
| 10:17 |
|
thd |
kados: can he not have a simple modification that is set to only search other branches if the results are empty for the local branch? |
| 10:18 |
|
kados |
yes |
| 10:18 |
|
kados |
to both ;-) |
| 10:18 |
|
kados |
timing: what we'd like to have, is full support for 'consortiums' |
| 10:18 |
|
kados |
timing: but so far no libraries using Koha 'need' that feature so we haven't had a sponsor |
| 10:19 |
|
thd |
kados: has not hdl been creating that? |
| 10:19 |
|
kados |
thd: no ... slightly different ... hdl is working on 'independent branches' AFAIK |
| 10:19 |
|
paul |
thd : no, hdl added feature for independantbranches, that makes each branch independant from a cataloguing point of view. |
| 10:20 |
|
paul |
not really what is requested. |
| 10:20 |
|
thd |
and that is in 2.2.4 |
| 10:20 |
|
kados |
timing: so if you're interested in contributing a major feature to Koha that'd be one option ;-) |
| 10:20 |
|
timing |
so what are we looking at |
| 10:20 |
|
kados |
timing: if that's not possible, you may be able to get away with using the current 'branches' |
| 10:22 |
|
kados |
it's hard to say how much it would cost without taking some time to spec it out |
| 10:23 |
|
kados |
but we're not talking hundreds of thousands or anything ;-) |
| 10:23 |
|
timing |
well if we get something together I might have a large number of schools that would move to koha |
| 10:24 |
|
thd |
Is there a my branch conception for the OPAC currently? |
| 10:24 |
|
timing |
I have started a small company called open4education and we are working on open source solutions for education for Texas |
| 10:25 |
|
kados |
cool! |
| 10:26 |
|
timing |
I really like koha and would like to get something rolling towards a Follet replacement |
| 10:26 |
|
timing |
lots of schools use it in Texas |
| 10:26 |
|
kados |
yep |
| 10:27 |
|
timing |
love liblime by the way I have visited your site several times |
| 10:27 |
|
kados |
thx |
| 10:28 |
|
thd |
timing: are you http://open4education.com/ 404 error? |
| 10:29 |
|
JYL57 |
paul : Salut Paul, t'as une minute ?! |
| 10:29 |
|
thd |
s/404/403 and 404/ |
| 10:30 |
|
paul |
zyva (en private) |
| 10:30 |
|
kados |
heh |
| 10:32 |
|
timing |
yeh we are working on it and have since changed servers |
| 10:32 |
|
thd |
timing: Is http://www.open4education.com/ your website? |
| 10:32 |
|
timing |
thd: yes |
| 10:32 |
|
timing |
We just got started |
| 10:33 |
|
timing |
only three of us and not enough time in the day |
| 10:33 |
|
thd |
timing: understood |
| 10:33 |
|
kados |
timing: how's business in Texas? |
| 10:33 |
|
timing |
trying to find the best solutions to fit our needs |
| 10:35 |
|
timing |
kados:not good since the government has locked up paying teachers until late October |
| 10:35 |
|
kados |
yikes! |
| 10:36 |
|
timing |
no budget releases or anything |
| 10:36 |
|
timing |
yeh |
| 10:36 |
|
paul |
yikes ! if someone tries this in France, there will be a revolution !!! |
| 10:37 |
|
thd |
timing: Is the Texas state treasury short of money just now or is there no contract with the teachers union? |
| 10:37 |
|
timing |
Judge says if no answer by late Oct all public school must shut down |
| 10:37 |
|
kados |
ha! |
| 10:37 |
|
timing |
then i would really have time for open4education |
| 10:37 |
|
kados |
that's simply barbaric! |
| 10:38 |
|
timing |
yeh tell me |
| 10:38 |
|
thd |
timing: What is the precipitating cause? |
| 10:39 |
|
JYL57 |
kados: Sorry to disturb you but I was wondering if progress has been made on the Fines topic lately ?! |
| 10:39 |
|
timing |
terrible legislator's not worried about our children i guess |
| 10:40 |
|
kados |
JYL57: chris committed a fix but it didn't completely fix the problem I'm having |
| 10:40 |
|
kados |
JYL57: it's on my 'todo' list ;-) |
| 10:40 |
|
timing |
well i have to have at least one school up as a test bed by end of month |
| 10:40 |
|
paul |
(on top or bottom of the list ? :-D ) |
| 10:40 |
|
JYL57 |
I'm now on this topic too, because people want to start using fines here also !:-! |
| 10:41 |
|
kados |
paul: top because a client needs it ;-) |
| 10:41 |
|
thd |
timing: Funding is available for the rest of the government, just not teachers? |
| 10:41 |
|
kados |
but this week I won't have much time to work on it |
| 10:41 |
|
timing |
correct just not public school |
| 10:42 |
|
JYL57 |
kados: if tests are required I can help |
| 10:42 |
|
timing |
they got raises to all the other govermental agencies but not schools |
| 10:43 |
|
JYL57 |
kados : I've looked at fines2.pl a few months ago... |
| 10:43 |
|
timing |
does anyone have the exact break down of what the 14 digit barcode is about vs the 10 digit |
| 10:44 |
|
timing |
we are currently using both and by my understading we need to merge to the 14 A.S.A.P |
| 10:44 |
|
thd |
timing: that is an EAN barcode |
| 10:45 |
|
kados |
JYL57: great! let's talk again about this early next week |
| 10:45 |
|
timing |
I will be meeting with our test librarian today to discuss what koha will do or what follet is doing vs what we can or cannot do with koha |
| 10:46 |
|
JYL57 |
kados : Ok, just time for me to upgrade to 2.2.4 and update my Debian Sarge a little...;-) See you |
| 10:46 |
|
thd |
timing: 2 or 3 character country country code, product code plus id, and check digit. |
| 10:46 |
|
kados |
JYL57: sounds good ;-) |
| 10:47 |
|
timing |
thd: can I find this online some place |
| 10:47 |
|
timing |
to show the librarian the break down |
| 10:48 |
|
thd |
timing: yes there is a good reference I posted to koha-devel |
| 10:49 |
|
timing |
thd: thnks |
| 10:50 |
|
thd |
timing: The barcode generator most accessible in Koha was changed from EAN to 128 symbology |
| 10:50 |
|
timing |
I am completely new to this library stuff so bare with me |
| 10:51 |
|
timing |
the difference is what from EAN to 128 symbology |
| 10:51 |
|
timing |
if we have 14 digit barcodes will this work |
| 10:54 |
|
thd |
timing: code 128 is free form and EAN is structured fur use with UPC labelling but they are essentially both the same symbology |
| 10:55 |
|
timing |
thd: i see, so we would be able to segregate schools based on the barcode |
| 10:56 |
|
thd |
timing: There is no library standard barcode unless you mean the ISBN code which is moving from ten digit code 128 to EAN-13 |
| 10:56 |
|
timing |
I guess |
| 10:57 |
|
timing |
we have mostly the ten digit and where told that we needed to move to a 14 digit barcode |
| 10:58 |
|
indradg |
timing, we are using the code 128 to segregate the different types of users in our library (based on programs - as we are an Univ.) in our member mgmt... guess it will work seamlessly for lib items too |
| 10:58 |
|
thd |
timing: for using barcodes in a library system you simply assign the code to the item holdings in the book record along with the school or library to which it relates |
| 10:58 |
|
timing |
the marc records that follet uses will have the barcode info in that record correct |
| 10:59 |
|
timing |
I think our problem is that we used the same barcode at 8 differnt campus libraries |
| 10:59 |
|
thd |
indrag: do you use a sequence expressed in the code itself for a distinction similar to a manufacturer code? |
