- Koha-devel - lists.koha-community.org

missing time
by David Strainchamps 15 Dec '02

15 Dec '02

Hi all, I want just to say us that in the future months i have to work for an exam so that i can't follow my very little contribution to Koha developpment. I will just read the lists cvs and devel. I think that your work is a great thing. Good wind and win for us David

1 0

Serials and Koha
by Pat Eyler 13 Dec '02

13 Dec '02

We've long known that Koha[1] needs solid support for serials[2], but up to this point haven't been willing to commit the resources to work on it for fear of gettin it wrong. We're ready to change that. Koha now sports a group of nearly 30 developers, many of whom are quite active. There's also a large group of libraries around the world who are using Koha, along with many others who are looking seriously at it. We'd like to combine the strengths of these groups to develop between two and five serials modules for Koha. These modules should provide serials support ranging from very simple for small libraries (public schools and the like) up to very complete solutions for large libraries. My plan at this point is as follows: through 31 Jan 2003 -- hold an open discussion at koha2010(a)kohalabs.com[3] about the functional needs of a serials module. This discussion can (should) include dividing functionality among the various modules, but should not be a technical discussion about how to implement the functionality 1 Feb 2003 through 28 Feb 2003 -- create a series of design specs for the modules. This discussion will occur (mostly) on the koha-devel(a)lists.sourceforge.net[4] mailing list. Periodic drafts will be posted to the koha(a)mail.katipo.co.nz[5] and koha2010(a)kohalabs.com mailing list for feedback. 1 Mar 2003 on -- work on developing the modules. The simplest module will be the first target, with others folowing based on interest from the developer and user communities. If one or more libraries would like to sponsor the development of a specific module out of sequence, or a developer or company would like to develop one of the modules, that would be fine -- we'd ask that any development be done 'in the open' with CVS access provided to the other Koha developers. -pate ps Please feel free to redistribute this ... I'd like to get as broad a discussion as possible. If you're not interested in Koha, but are interested in serials, please feel free to join the discussion and implement the ideas in your own ILS of choice. Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org [1] Koha is a free ILS produced by the Koha project. For more information, please visit http://www.koha.org [2] Serials are items published periodically (in serial), like magazines, newspapers, etc. [3] To subscribe, send an email to koha2010-subscribe(a)kohalabs.com and follow the directions in the response you recieve. [4] To subscribe, please go to http://lists.sourceforge.net/lists/listinfo/koha-devel and fill out the form. [5] To subscribe, please go to http://koha.org/mailing/ and fill out the form provided.

1 0

he panui Koha (13 Dec 2002)
by Pat Eyler 13 Dec '02

13 Dec '02

he panui Koha 13 Dec 2002

1 0

interesting note
by Pat Eyler 12 Dec '02

12 Dec '02

As we ponder cleaning up (thanks finlay and chris), here's a note that might be of some interest: http://use.perl.org/~Ovid/journal/ Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

1 0

1.3.2 => major bugfixes
by paul POULAIN 12 Dec '02

12 Dec '02

Thanks to Dombes beta test, i've found a little bug that hidded 2 majors bugs in koha 1,3,2. This bugs appears when you try to modify a biblio or an item in a biblio and was due to errors in biblio/item adding. It appears not on every biblio, so was quite hard to hunt. PLEASE : * if you installed a 1.3.2 version, please consider your datas as broken : the upgrade to 1.3.3 won't be recommended, so a fresh install will be necessary (or install from 1.2.x) * if you play with CVS, please empty your catalog tables asap (biblio, biblioitems, items, marc_biblio, marc_subfield_table and marc_word) and play again with the well-named *koha-unstable*. And report any broken stuff here or in bugs.koha.org Thanks -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://fr.koha.org)

1 0

templates translating
by paul POULAIN 12 Dec '02

12 Dec '02

Hi, when a developper modifies a template (which happends yesterday from me), i think translators should be informed. As translators are not necessary following the koha-cvs ml, i think we should create a koha-translate ml, for translators. It could be open to non-subsribers to enable developpers to post a little summary of their modifications and tell which templates have been modified. If the ml is created, we could subscribe traduction(a)koha-fr.org note : i'm happy to announce creation of traduction(a)koha-fr.org for french translators and technique(a)koha-fr.org for french developpers. <for pate> this could be a news for weekly news </for pate> -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://fr.koha.org)

2 1

Re: translation questions
by Pat Eyler 12 Dec '02

12 Dec '02

On Thu, 12 Dec 2002, Dorian Meid wrote: > Pat Eyler schrieb: > > On Wed, 11 Dec 2002, Rachel Hamilton-Williams wrote: > >>Hi Ambrose, > >>>I discovered that there is de.koha.org. It has "free" translated > >>>as "kostenlos", but fr.koha.org has "libre". Which is closer to > >>>the intended meaning of "free" as used in www.koha.org? (I suppose > >>>the French?) > > libre is a much better term ... the German probably ought to be 'freie' > > instead. Koha may be 'kostenlos'/'gratis', but the more important aspect > > is the freedom which it carries. > When i made this translation i thought of that. > But in germany with 'frei' you associate mostly freedom of individuals > or living at your own will. > You don't associate free of charge. > At least nobody will understand why a library software should have > freedom and why this is an advantage. This is interesting, and ties into another conversation I've been involved in lately ... Many people are looking at Koha because it is free (gratis), and not because it's free (libre). While I hope that the latter becomes more important as time goes along, playing to the crowd is certainly a better way of drawing eyeballs. Perhaps using Kostenlos but maintaining some information about the importance of the software being frei as well. thanks, -pate > > Dorian >

1 0

RE: [oss4lib-discuss] MARC -> RDBMS
by Pat Eyler 12 Dec '02

12 Dec '02

On Wed, 11 Dec 2002, Brian Cassidy wrote: > Hello again, > > Thanks to everyone for their quick replies! Here's what I've done since > yesterday: > > I looked into the 'Koha' library software. It looks interesting, but the > line "It is currently possible to import MARC records, one at a time." > turned me off of it, due to the fact that I have several repositories > with thousands of records each. It sounds like we need to do a better job of documenting something then. THere are a couple of flavors of bulk-importing scripts at this point. Other flavors can be derived from the existing scripts at need. (It's all a smop, right?) -pate > > I looked into Michael Doran's concerns, but the powers that be want me > to steer away from a Z39.50 interface. So, that's as far as I got with > that. :/ > > After looking at the document > (http://www.openisis.org/openisis/doc/RdbConv) provided by Ferran Jorba, > I created a simple DB structure (pardon my ASCII :) > > .---------. .-----------. > | item | | marc_data | > ----------- ---- ------------- > | item_id | | item_id | > ----------- | data | > | ------------- > | > /|\ > .-------------. > | tag_data | > --------------- > | item_id | > | tag_order | > | tag | > | indicator_1 | > | indicator_2 | > | subfield | > | data | > --------------- > > Note: marc_data.data is just a 'blob' of the MARC record. > > I then used MARC::Record (Hi Ed.) to quickly write a couple perl scripts > to generate some SQL and run the queries. My database now has 2002 > (MARC) records in a somewhat useable structure. For instance, I can now > say > > SELECT > item_id > FROM > tag_data > WHERE > tag = '008' AND > data LIKE '%fre__' > > to get all of the IDs of the French records. > > I'm now at the point where I need to create a data crosswalk (as Art > mentioned) so I can display the data in a human readable way, as well as > facilitate easy searching. The Dublin Core crosswalk > (http://www.loc.gov/marc/marc2dc.html) on the loc.gov website (hat tip: > Art) seems like a great standard to follow. The problem that I'm now > facing is that frequently, data in a tag is split up into many > subfields. For instance: > > SELECT > item_id, > subfield, > data > FROM > ust_tag_data > WHERE > tag = '245' -- Title > ORDER BY > item_id > > One of my results is: > > item_id | subfield | data > ------------------------------------------------------------- > ... > 2 | a | Keeping Alberta competitive : > 2 | b | success through workplace learning. -- > ... > > Now, it's totally doable to loop through the results (in perl, ASP, etc) > and concatenate the data together. This COULD, however, get tedious > depending on the number of fields I need to look at. This is probably > the wrong forum to ask, but would anyone have any suggestions on how to > proceed (or perhaps takes some steps back and attack it differently)? > > Thanks again for all your help! > > -Brian Cassidy (brian at nald dot ca) > > > http://www.gordano.com - Messaging for educators. > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > > oss4lib-discuss(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss > see also http://www.oss4lib.org/ >

3 2

RE: [oss4lib-discuss] MARC -> RDBMS (fwd)
by Pat Eyler 11 Dec '02

11 Dec '02

The section on Koha is particularily interesting to us going forward I think. -pate ---------- Forwarded message ---------- Date: Wed, 11 Dec 2002 16:02:26 -0400 From: Brian Cassidy <brian(a)nald.ca> To: oss4lib-discuss(a)lists.sourceforge.net Subject: RE: [oss4lib-discuss] MARC -> RDBMS Hello again, Thanks to everyone for their quick replies! Here's what I've done since yesterday: I looked into the 'Koha' library software. It looks interesting, but the line "It is currently possible to import MARC records, one at a time." turned me off of it, due to the fact that I have several repositories with thousands of records each. I looked into Michael Doran's concerns, but the powers that be want me to steer away from a Z39.50 interface. So, that's as far as I got with that. :/ After looking at the document (http://www.openisis.org/openisis/doc/RdbConv) provided by Ferran Jorba, I created a simple DB structure (pardon my ASCII :) .---------. .-----------. | item | | marc_data | ----------- ---- ------------- | item_id | | item_id | ----------- | data | | ------------- | /|\ .-------------. | tag_data | --------------- | item_id | | tag_order | | tag | | indicator_1 | | indicator_2 | | subfield | | data | --------------- Note: marc_data.data is just a 'blob' of the MARC record. I then used MARC::Record (Hi Ed.) to quickly write a couple perl scripts to generate some SQL and run the queries. My database now has 2002 (MARC) records in a somewhat useable structure. For instance, I can now say SELECT item_id FROM tag_data WHERE tag = '008' AND data LIKE '%fre__' to get all of the IDs of the French records. I'm now at the point where I need to create a data crosswalk (as Art mentioned) so I can display the data in a human readable way, as well as facilitate easy searching. The Dublin Core crosswalk (http://www.loc.gov/marc/marc2dc.html) on the loc.gov website (hat tip: Art) seems like a great standard to follow. The problem that I'm now facing is that frequently, data in a tag is split up into many subfields. For instance: SELECT item_id, subfield, data FROM ust_tag_data WHERE tag = '245' -- Title ORDER BY item_id One of my results is: item_id | subfield | data ------------------------------------------------------------- ... 2 | a | Keeping Alberta competitive : 2 | b | success through workplace learning. -- ... Now, it's totally doable to loop through the results (in perl, ASP, etc) and concatenate the data together. This COULD, however, get tedious depending on the number of fields I need to look at. This is probably the wrong forum to ask, but would anyone have any suggestions on how to proceed (or perhaps takes some steps back and attack it differently)? Thanks again for all your help! -Brian Cassidy (brian at nald dot ca) http://www.gordano.com - Messaging for educators. ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ oss4lib-discuss(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss see also http://www.oss4lib.org/

1 0

Auth.pm
by Finlay Thompson 10 Dec '02

10 Dec '02

Hi Everyone, I have just commited into the main branch the substantially rewritten Auth.pm authentification module from the rel-1-2 branch (as in use at HLT). The biggest change is the get_template_and_user () sub. This combines a whole lot of code that I had at the top of every script. It gets the correct template, and authenticates the user, loading the users details into the template (in a loop variable USER_INFO). This means that you dont need to "use C4::Output;" in the scripts, just "use C4::Auth;" In addition I have put in some code that checks the systempreferences for a "timeout" time in seconds, otherwise it defaults to 120 sec (2 mins). The login prompt is now templated as well (important for new opac). This is found at opac-auth.tmpl for the opac and auth.tmpl for the intranet. It uses Context as all good main branch modules and scripts should. It also uses Output to get the template objects. It uses Circulation::Circ2 to get the borrower information which is a little weird. It would be good to have a Users.pm module that Circ and everything else could use that accessed all the users information and returned it in a uniform way. Maybe even OO? Anyway, thats the new Auth.pm Finlay

3 3