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

RE: KOHA Questions (fwd)
by Pat Eyler 09 Oct '02

09 Oct '02

Here are the answers I've sent back. I thought you'd all like to see them. I appreciate everyone who stepped up to answering the bits that I had no clue about. -pate ---------- Forwarded message ---------- Date: Wed, 9 Oct 2002 19:20:28 -0400 (EDT) From: Pat Eyler <pate(a)eylerfamily.org> Subject: RE: KOHA Questions Glen, because Koha is an Open Source project and not a vendor, some of the answers below are a bit vague. There are a number of vendors who are selling support and development for Koha (or who are planning to), and I can point you at some of them if you'd like. I understand that you may want to do some or all of the development work yourselves, that would be fine as well. The Koha development community would certainly be happy to help in any way that we can. If you have any further questions, or need clarification, please feel free to contact me. thanks, -pate 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 -- Which operating system, or choice of systems, does the proposed library automation system run on? Koha runs best on linux, but has been installed on (at least) FreeBSD and NT2000. It should be able to run on other POSIX OSes that have Perl5, MySQL, and Apache running on them. 2 -- Is system administration done with command lines or a graphical module? We should see it. Systems Administration happens at two levels. The library system is mostly exposed via a web interface (or commandline or Perl/Tk interfaces if you prefer). Administration of the underlying system and components is traditionally performed via the command line. There exist commandline options to manage the library system and graphical options to manage the lower layer pieces as well. 3 -- What is the backup utility? Does it use tapes? Koha relies on the OS level tools to handle back ups. backups could be done to tape, DLT, CD-ROM, or (via replication) to one or more other systems. 4 -- Does the system have its own file and disk maintenance procedures? If so, how are they performed? No, Koha relies on typical Linux/Unix tools, processes, and procedures. 5 -- What administrative functions or upgrades require the system to be off-line, and for how long? Upgrading the system could be done by taking the system off-line and performing the upgrade, or by swapping installed servers. In the first case, the upgrade would require up to an hour of downtime, in the second, you should be able to swap the systems in under 15 minutes. Patches and similar, minor upgrades do not require any system downtime. 6 -- Is there a backup module for circulation in case the system is down? Koha can be run in stand-alone mode (a server running on the local system), this has been done to create 'bookmobile' systems. 7 -- Describe the way customer support works, what it covers, and hours of service. Koha is an open source project. As such, unpaid volunteers provide support via email or irc. There are a number of vendors who would be willing to provide higher levels of service. You would need to contact those vendors for specifics. If you are interested, there is a list of such vendors at http://www.koha.org/installation/support.html or by email to the kohabiz(a)eylerfamily.org mailinglist. 8 -- What is the indexing capability for the catalog? How many indexes can we have? Can they be customized? Because the system is open source, you can customize it to whatever degree you desire. 9 -- Describe the capacity for integrating selfcheck machines with the system. Is it SIP1/SIP2/NCIP compliant? We don't currently have a self check system in place. Nelsonville Public Library has expressed interest in sponsoring NCIP development work. We've also heard interest from 3M in developing the support for their self-checkout system for Koha if there were libraries interested using the hardware on Koha. 10 -- What report writing capability does the system have? Koha does not ship with a report writer. Reports could be written with any tool that can interact with MySQL. Perl and DBI are know to work well. 11 -- What "canned" reports are available? There are curretnly very few canned reports that come with Koha. Because the code is open, and the DB is exposed to the standard Perl-DBI interface, writing new reports would be an easy extension. 12 -- Is there an API available? Can we develop applications that can directly access the database? Yes, there is an API available. We encourage you to develop new feature within Koha, or as adjuncts to it. If you choose to do so, the license allows you to redistribute your work (and we encourage you to do so). 13 -- Is there a function for electronic ordering, such as from Baker and Taylor? Does B&T support your ordering module? This is not a part of our current acquisitions system. It would be a relatively easy feature to add though. 14 -- What flexibility is there for customizing the catalog? Can the catalog engine search external databases? The catalog is completely customizable. As written, it is built around the MARC standard(s) (starting with the development version, currently at version 1.3.0). It is already capable of supporting both MARC21 and UNIMARC. 15 -- Is the system client-server or web based? Koha is a web based application. (There is still a text based front-end though.) 16 -- What is the capacity for e-mail functions, including e-mail notices? This functionality is currently being added, and should be present in the 1.2.3 release. 17 -- Can the system integrate library fines with external payment interfaces (library cards, etc.)? This function doesn't currently exist, but could be added. 18 -- Which RFID vendors have successfully integrated with your system? There are no libraries using Koha with RFID devices currently. If the RFID device can be made to work with Linux (or your chosen OS) it should be possible to integrate it into Koha. 19 -- Can receipt printers work with the system? Yes. 20 -- Have you converted DRA Classic sites in the past? Describe your conversion process. What data can you *not* convert? Again, this is a question to ask a Vendor working with Koha. In general, if the data can be extracted from your DRA system, it can be loaded into Koha's DB. Particularily esoteric data might require the addition of new tables. 21 -- Can your system work with Epixtech's URSA module for inter-library loan? Koha does not currently do this. 22 -- Do you provide an integrated point of sale module? There is a system for managing fine payments and a till. 23 -- What functions can our public do from home via our catalog -- pay fines? renew items? place requests? renew cards? This is very customizable. We'd recommend that you not do things that would require authentication (renewing cards and the like), but there are many services that carry low risk and would be ideal for home based users. Paying fines from home would require an interface to PayPal or a merchant account, as well as some development work. 24 -- Does the catalog have multi-lingual support? This is currently being developed. The French and German development groups are particularily involved in this effort. 25 -- What are the options, or lack of, regarding database privacy (reading records of the public, retrospective history, etc.)? This is an area that would be open to development. Some thoughts we've had are: keeping full histories (popular outside the US), keeping anonymized records, or keeping only records that patrons specifically request. 26 -- Is there support for access via hand-helds? Handlhelds providing 802.11b support and a web browser would be able o interface with the system as is. Other forms of access would require some development effort. 27 -- What is the database platform? Proprietary? Oracle? Informix? SQL? Something else? Koha normally runs on MySQL, an open source SQL RDBMS. There is work underway to add support for PostgreSQL as well. 28 -- Can customized fields be added to either item or patron records? Yes, the DB Schema is completely open. You can make any changes or additions that you want. 29 -- What flexibility is there for searching item and patron records? Can additional item and patron fields be made searchable? Yes, any fields could be made searchable. Because the code is open, you can amek any changes you desire. 30 -- Can the system store content (not just indexing) for digital materials, photographs, e-books, digital audio? This functionality could be added to Koha. 31 -- Can staff get real-time statistics on demand? Reports would need to be written and exposed to the staff via cgi. 32 -- Is there any way for users to get automatic bibliographies on request? Reports would need to be written and exposed to the staff via cgi. 33 -- Is there any capacity for debit interfaces with functions such as printing? A module would need to be developed to do this. 34 -- What kind of hardware do you recommend? Does your configuration include RAID? Koha runs quite well on off the shelf PC grade hardware. For added stability, it would be worth investing in Server Class systems featuring redundant power supplies and RAID. For truly redundant systems, a cluster of Server class systems could be used with the offline boxes providing Searching and related OLAP work, while the online system does circulation and other OLTP work. 35 -- What database redundancy is built into the system, in case a disk is lost or corrupted? Koha depends on the features of Linux and MySQL which include: RAID, journaling files systems, and Database replication. 36 -- What kind of support do you have for bookmobile operation, eg. a cache of the whole database changed every day? See Question 6, above. 37 -- Is there support for cover pages, excerpts, etc., such as we can purchase from Syndetic? This functionality could be added. 38 -- Can the public place requests for titles which are on order? This functionality could be added. 39 -- Is there integrated selector management -- that is, when you select a title from a database such as OCLC, can it be loaded into the system and ordered? This functionality could be added. 40 -- How is access managed to OCLC? We don't currently provide access to OCLC. 41 -- How are long overdue items managed -- patron notices, credit bureau reports, masking from the database, etc.? Does the capacity exist to transfer these items into an auxiliary database? Patrons are given notices and a hold is put on their account so that if they come in in the meantime it flags. A report is run and the statement can be sent to a credit bureau. Items show up in the OPAC if they are not "given up on" with a last seen date, or they are marked Lost. If they are lost they don't show up in the OPAC, but do show up in the Librarians intranet. I think that they are "purged" from time to time at library request, and they get shifted to a "deleted" table, in case they need to be recovered later. Additional reports could be written to manage long overdue items. These reports and others could be run from a replicated copy of the online database for performance reasons, or could be scheduled to run as batch jobs during low-traffic periods. 42 -- Explain the hierarchical nature of database locations (system, agencies, departments, or whatever). Our Virtual Bookshelf should allow items to be categorized into a flexible heirarchy. 43 -- How are item statuses used? Can they be converted from DRA Classic to the new system? Item status can be used to control the display of an item. Data pulled from DRA classic could be imported and used within Koha. 44 -- What is the procedure for processing lost items? This is a manual process at present, but it could be automated. 45 -- What kind of transaction statistics are kept for items? For patrons? Koha can keep all of them. Alternatively, the data could be discarded, or anonymized in whole or in part. 46 -- How does licensing work? How are fees determined? Koha is available under the Gnu General Public License. There are no fees to license or use Koha. 47 -- Can the system handle consortia? How does this affect licensing fees? Yes, Koha can be used for consortia. As there are no licensing fees, there is no effect. 48 -- What can be controlled by the systems calendar (eg. days when items are not due, fines not charged, etc.)? Currently this is controlled manually, but could be automated if desired. 49 -- What kind of patron delinquency statuses are available? Can patron statuses be converted from DRA Classic? Koha can place a temporary bar on borrowing if people owe more than a pre determined amount in fines, and can permanently disqualify a patron. There are also Child and guarantor relationships (children must "belong" to an adult), and other categories of user who have different fine privliges . Again, additional or different statuses could be used. 50 -- Does the catalog allow searching by item (not bibliographic) call numbers? This functionality could be added. 51 -- What is the hierarchy of the bibliographic database (bibliographic records, call number records, item records)? Koha uses three levels of records: biblios - everything with the same content has the same biblio (i.e. ignores what media, publisher, etc.) biblioitem - everything with the same media, publisher, etc. has the same biblioitem (ignores different copies of the same book etc.) item - what actually gets loaned out (so, e.g., has a barcode, can be put on a shelf, etc) 52 -- What is the system of classifications for materials (material codes)? Can selfcheck checkouts be limited to specified item classifications? Koha supports different lending policies depending on item classification. This could be broadened to encompass patron classification as well. Assuming selfcheck checkouts were added to Koha, these could be controlled in the same manner. 53 -- Can the system allow automatic charges to patron records as certain classes of items are checked out? Can this feature be used with the selfcheck? This functionality could be added. (Our Virtual Bookshelf feature would be a good way to support it.) 54 -- Is it possible to set up multiple databases within the system? Yes, with our Virtual Bookshelf feature. 55 -- Is there a text catalog that can be used for modem access (for people who are not yet on the Internet)? Yes. 56 -- Does the system allow tracking between patron categories and item categories for circulation statistics? This functionality could be added. The data is already in the system, so it would be a matter of writing a report. 57 -- Can fine records for patrons be converted to your system from DRA Classic? If the data can be extracted, it can be converted.

3 2

last couple of niggling questions
by Pat Eyler 09 Oct '02

09 Oct '02

Thanks to Rachel, it's down to two questions: 43 -- How are item statuses used? Can they be converted from DRA Classic to the new system? (I assume that this refers to 'lost', 'shelved', 'on hold', 'checked in', or 'on loan'. I really have no idea how these would be used in practice though. Any thoughts?) 51 -- What is the hierarchy of the bibliographic database (bibliographic records, call number records, item records)? (Paul, ?!?!?!?HELP!?!?!?!) thanks, -pate

2 1

questions for Kha
by Pat Eyler 09 Oct '02

09 Oct '02

Okay, I've gotten most of the questions answered ... I'm looking for some help though. If anyone could step up and handle 43-45, 48-49, and/or 51, I'd really appreciate it. Responses to the wiki: http://www.saas.nsw.edu.au/wiki/index.php?page=QuestionsPosed or in private email (please paste in just the question you're answering) would both be appreciated. (the wiki is probably the better way.) thanks, -pate --------------------Q&A-------------------- 1 -- Which operating system, or choice of systems, does the proposed library automation system run on? Koha runs best on linux, but has been installed on (at least) FreeBSD and NT2000. It should be able to run on other POSIX OSes that have Perl5, MySQL, and Apache running on them. 2 -- Is system administration done with command lines or a graphical module? We should see it. Systems Administration happens at two levels. The library system is mostly exposed via a web interface (or commandline or Perl/Tk interfaces if you prefer). Administration of the underlying system and components is traditionally performed via the command line. There exist commandline options to manage the library system and graphical options to manage the lower layer pieces as well. 3 -- What is the backup utility? Does it use tapes? Koha relies on the OS level tools to handle back ups. backups could be done to tape, DLT, CD-ROM, or (via replication) to one or more other systems. 4 -- Does the system have its own file and disk maintenance procedures? If so, how are they performed? No, Koha relies on typical Linux/Unix tools, processes, and procedures. 5 -- What administrative functions or upgrades require the system to be off-line, and for how long? Upgrading the system could be done by taking the system off-line and performing the upgrade, or by swapping installed servers. In the first case, the upgrade would require up to an hour of downtime, in the second, you should be able to swap the systems in under 15 minutes. Patches and similar, minor upgrades do not require any system downtime. 6 -- Is there a backup module for circulation in case the system is down? Koha can be run in stand-alone mode (a server running on the local system), this has been done to create 'bookmobile' systems. 7 -- Describe the way customer support works, what it covers, and hours of service. Koha is an open source project. As such, unpaid volunteers provide support via email or irc. There are a number of vendors who would be willing to provide higher levels of service. You would need to contact those vendors for specifics. If you are interested, there is a list of such vendors at http://www.koha.org/installation/support.html or by email to the kohabiz(a)eylerfamily.org mailinglist. 8 -- What is the indexing capability for the catalog? How many indexes can we have? Can they be customized? Because the system is open source, you can customize it to whatever degree you desire. 9 -- Describe the capacity for integrating selfcheck machines with the system. Is it SIP1/SIP2/NCIP compliant? We don't currently have a self check system in place. Nelsonville Public Library has expressed interest in sponsoring NCIP development work. We've also heard interest from 3M in developing the support for their self-checkout system for Koha if there were libraries interested using the hardware on Koha. 10 -- What report writing capability does the system have? 11 -- What "canned" reports are available? There are curretnly very few canned reports that come with Koha. Because the code is open, and the DB is exposed to the standard Perl-DBI interface, writing new reports would be an easy extension. 12 -- Is there an API available? Can we develop applications that can directly access the database? Yes, there is an API available. We encourage you to develop new feature within Koha, or as adjuncts to it. If you choose to do so, the license allows you to redistribute your work (and we encourage you to do so). 13 -- Is there a function for electronic ordering, such as from Baker and Taylor? Does B&T support your ordering module? This is not a part of our current acquisitions system. It would be a relatively easy feature to add though. 14 -- What flexibility is there for customizing the catalog? Can the catalog engine search external databases? The catalog is completely customizable. As written, it is built around the MARC standard(s) (starting with the development version, currently at version 1.3.0). It is already capable of supporting both MARC21 and UNIMARC. 15 -- Is the system client-server or web based? Koha is a web based application. (There is still a text based front-end though.) 16 -- What is the capacity for e-mail functions, including e-mail notices? This functionality is currently being added, and should be present in the 1.2.3 release. 17 -- Can the system integrate library fines with external payment interfaces (library cards, etc.)? This function doesn't currently exist, but could be added. 18 -- Which RFID vendors have successfully integrated with your system? There are no libraries using Koha with RFID devices currently. If the RFID device can be made to work with Linux (or your chosen OS) it should be possible to integrate it into Koha. 19 -- Can receipt printers work with the system? Yes. 20 -- Have you converted DRA Classic sites in the past? Describe your conversion process. What data can you *not* convert? Again, this is a question to ask a Vendor working with Koha. In general, if the data can be extracted from your DRA system, it can be loaded into Koha's DB. Particularily esoteric data might require the addition of new tables. 21 -- Can your system work with Epixtech's URSA module for inter-library loan? Koha does not currently do this. 22 -- Do you provide an integrated point of sale module? There 23 -- What functions can our public do from home via our catalog -- pay fines? renew items? place requests? renew cards? This is very customizable. We'd recommend that you not do things that would require authentication (renewing cards and the like), but there are many services that carry low risk and would be ideal for home based users. Paying fines from home would require an interface to PayPal or a merchant account, as well as some development work. 24 -- Does the catalog have multi-lingual support? This is currently being developed. The French and German development groups are particularily involved in this effort. 25 -- What are the options, or lack of, regarding database privacy (reading records of the public, retrospective history, etc.)? This is an area that would be open to development. Some thoughts we've had are: keeping full histories (popular outside the US), keeping anonymized records, or keeping only records that patrons specifically request. 26 -- Is there support for access via hand-helds? Handlhelds providing 802.11b support and a web browser would be able o interface with the system as is. Other forms of access would require some development effort. 27 -- What is the database platform? Proprietary? Oracle? Informix? SQL? Something else? Koha normally runs on MySQL, an open source SQL RDBMS. There is work underway to add support for PostgreSQL as well. 28 -- Can customized fields be added to either item or patron records? Yes, the DB Schema is completely open. You can make any changes or additions that you want. 29 -- What flexibility is there for searching item and patron records? Can additional item and patron fields be made searchable? Yes, any fields could be made searchable. Because the code is open, you can amek any changes you desire. 30 -- Can the system store content (not just indexing) for digital materials, photographs, e-books, digital audio? This functionality could be added to Koha. 31 -- Can staff get real-time statistics on demand? Reports would need to be written and exposed to the staff via cgi. 32 -- Is there any way for users to get automatic bibliographies on request? Reports would need to be written and exposed to the staff via cgi. 33 -- Is there any capacity for debit interfaces with functions such as printing? A module would need to be developed to do this. 34 -- What kind of hardware do you recommend? Does your configuration include RAID? Koha runs quite well on off the shelf PC grade hardware. For added stability, it would be worth investing in Server Class systems featuring redundant power supplies and RAID. For truly redundant systems, a cluster of Server class systems could be used with the offline boxes providing Searching and related OLAP work, while the online system does circulation and other OLTP work. 35 -- What database redundancy is built into the system, in case a disk is lost or corrupted? Koha depends on the features of Linux and MySQL which include: RAID, journaling files systems, and Database replication. 36 -- What kind of support do you have for bookmobile operation, eg. a cache of the whole database changed every day? See Question 6, above. 37 -- Is there support for cover pages, excerpts, etc., such as we can purchase from Syndetic? This functionality could be added. 38 -- Can the public place requests for titles which are on order? This functionality could be added 39 -- Is there integrated selector management -- that is, when you select a title from a database such as OCLC, can it be loaded into the system and ordered? This functionality could be added 40 -- How is access managed to OCLC? We don't currently provide access to OCLC. 41 -- How are long overdue items managed -- patron notices, credit bureau reports, masking from the database, etc.? Does the capacity exist to transfer these items into an auxiliary database? Reports could be written to manage long overdue items. These reports and others could be run from a replicated copy of the online database for performance reasons, or could be scheduled to run as batch jobs druing low-traffic periods. 42 -- Explain the hierarchical nature of database locations (system, agencies, departments, or whatever). Our Virtual Bookshelf should allow items to be categorized into a flexible heirarchy. 43 -- How are item statuses used? Can they be converted from DRA Classic to the new system? 44 -- What is the procedure for processing lost items? 45 -- What kind of transaction statistics are kept for items? For patrons? 46 -- How does licensing work? How are fees determined? Koha is available under the Gnu General Public License. There are no fees to license or use Koha. 47 -- Can the system handle consortia? How does this affect licensing fees? Yes, Koha can be used for consortia. As there are no licensing fees, there is no effect. 48 -- What can be controlled by the systems calendar (eg. days when items are not due, fines not charged, etc.)? 49 -- What kind of patron delinquency statuses are available? Can patron statuses be converted from DRA Classic? 50 -- Does the catalog allow searching by item (not bibliographic) call numbers? This functionality could be added. 51 -- What is the hierarchy of the bibliographic database (bibliographic records, call number records, item records)? 52 -- What is the system of classifications for materials (material codes)? Can selfcheck checkouts be limited to specified item classifications? This functionality could be added. (Our Virtual Bookshelf feature would be a good way to support it.) 53 -- Can the system allow automatic charges to patron records as certain classes of items are checked out? Can this feature be used with the selfcheck? This functionality could be added. (Our Virtual Bookshelf feature would be a good way to support it.) 54 -- Is it possible to set up multiple databases within the system? Yes, with our Virtual Bookshelf feature. 55 -- Is there a text catalog that can be used for modem access (for people who are not yet on the Internet)? Yes. 56 -- Does the system allow tracking between patron categories and item categories for circulation statistics? This functionality could be added. 57 -- Can fine records for patrons be converted to your system from DRA Classic? If the data can be extracted, it can be converted.

1 0

Re: [Koha-devel] koha 1,4, templating and css
by paul POULAIN 09 Oct '02

09 Oct '02

Dorian Meid wrote: >We don't need a <theme>/<lang>/ structure in the cgi-tree. >The scripts in the cgi-tree are the same for all themes and languages. >We allready have a <theme>/<lang>/ structure in the >htdocs(serverroot)-tree. > ??? we said a few days ago that it was a bad idea to put templates in html path, they should be in cgi-bin path for security reasons. But i can't find the mail where we spoke of this, so maybe another opinion ? finlay when he comes back ? I don't see any theme/lang structure in the serverroot tree neither in 1.2 nor in main branch. -- Paul

2 2

50 questions
by Pat Eyler 09 Oct '02

09 Oct '02

I didn't get around to answering the questions at: http://www.saas.nsw.edu.au/wiki/index.php?page=QuestionsPosed I'll be answering them today and sending them off at about 3PM PDT my time (-0700). If you've had any last minute bursts of insight, I'd encourage you to put them up there. thanks, -pate

1 0

Templating design
by Finlay Thompson 08 Oct '02

08 Oct '02

Hi Everyone, It seems that everyone had a email conversation about the way templating is being done in koha. I have been working on templating the opac. Let me explain what I have done, which is not to say that it is the right way :-) Firstly I should point out that I have been developing on the rel-1-2 branch, but will probably merge this into the 1.3 release. If you want to go and check it out go to http://opacdev.katipo.co.nz you can login using user:pword = frank:frank or finlay:finlay CVS: All the templates are going into the koha-tmpl tree of cvs. under this root we have two sub-branches intranet-tmpl/ and opac-tmpl/ eveything onder there should be installed in koha/intra/htdocs/ and koha/opac/htdocs/ respectivly. And then we have the structure: <theme>/<lang>/<scriptname>.tmpl I suggest that we try hard to keep the templates and scripts with the same names..... includes and images go under the <theme>/<lang>/ directory..... An example: The opac-search.pl script presents the search form in the opac. see: http://opacdev.katipo.co.nz/cgi-bin/koha/opac-search.pl it calls the opac-search.tmpl template which in this instance is found in the default/en/ theme and language. There is an include at the top: cat-top.inc and this is found in default/en/includes/cat-top.inc all the images in the templates are prefixed by the HTML::Template tag: <TMPL_VAR NAME="themelang"> eg. src="<TMPL_VAR NAME='themelang'>/images/search-button.gif" This template variable is automatically passed to includes and is automatically loaded into the template by the template loading subroutine..... Template loading: The relevant code in opac-search.pl is: use C$::Output; my $template = gettemplate("opac-search.tmpl", "opac"); The method gettemplate handles eveything about choosing theme and lang settings and finding a template etc. It then loads the "themelang" variable and returns the template. The "opac" string is simply to switch to the opac tree. however in the future this gettemplate method could perhaps be made to take a hash of options? Note: there is another candidate for the gettemplate code that Dorian wrote. His subroutine is called "pathtotemplate" and does many of the same things, except it doesnt actually intialise the template. I think that keeping the template intialising code to one line is a good idea, and I dont think there is any loss of flexibility if I allow gettemplate to pass a hash of options to the HTML::Template module. I like what andrew said with regard to something else the other day: "This way, simple scripts remain simple, and complex scripts become possible." That is a very good principle. As most of the time the scripts have one template associated, and no extra options on the template, the above one-liner will be enough. Anyway, I hope this has clarified what I have been up to. I will update the reading material on: http://koha.org/contribute/templating/ Finlay

9 18

[oss4lib-discuss] course/control - Reserves Management System (fwd)
by Pat Eyler 07 Oct '02

07 Oct '02

an interesting bit for academic libraries ... would it be better to work with a project like this or to build our own interface using the virtual bookshelf concept? -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org ---------- Forwarded message ---------- Date: Mon, 07 Oct 2002 17:12:08 -0400 From: Ross Singer <rfsinge(a)emory.edu> To: oss4lib-discuss(a)lists.sourceforge.net, web4lib(a)sunsite.berkeley.edu Subject: [oss4lib-discuss] course/control - Reserves Management System [Pardon the crossposting] course/control, a PHP and PostgreSQL based reserves management system, is available for download at http://coursecontrol.sourceforge.net. Created by Emory University General Libraries, course/control is designed to give instructors as much control over their class reserves as they or the reserves department want. It allows instructors to: Create classes Place reserves in any order Set Activation Dates to hide items until specific dates Add files to their course reserves Reactivate reserves from previously taught classes Request items from the catalog via z39.50 Add comments/annotations to particular reserve items In combination with Hylafax, fax items to the server and automatically convert the document to pdf Library staff also have the ability to do this, plus process requests for new reserve items. Through the public interface, Reserves Direct, students set up profiles of their current schedule, which allows them to see only what they're supposed to see. Reserves Direct also allows the user to hide items from their class listing to reduce visual clutter for courses with many items on reserves. Handling both electronic and "traditional" (physical) reserves, course/control is intended to be a free, opensource alternative to the myriad commercial reserves management offerings on the market. Ross Singer Application Developer Emory University General Libraries ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ oss4lib-discuss(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oss4lib-discuss see also http://www.oss4lib.org/

1 0

questions about koha (from a library)
by Nicholas S. Rosasco 07 Oct '02

07 Oct '02

Pat and I exchanged emails on this, and for the sake of everyone's sanity I'll be putting the questions up on the Wiki ... rather than trying to keep track of versions passed around etc etc. http://www.saas.nsw.edu.au/wiki/index.php?page=KohaProject Look at QuestionsPosed Nick

1 0

questions about koha (from a library)
by Pat Eyler 07 Oct '02

07 Oct '02

There's a largish library that is thinking about using Koha. They've come up with a long list of questions that they'd like answered, and I'd like to get some other peoples feedback before I start answering. Please have a look at these, and reply to those that you feel comfortable talking about. thanks, -pate ----------------------Questions---------------------------- 1 -- Which operating system, or choice of systems, does the proposed library automation system run on? 2 -- Is system administration done with command lines or a graphical module? We should see it. 3 -- What is the backup utility? Does it use tapes? 4 -- Does the system have its own file and disk maintenance procedures? If so, how are they performed? 5 -- What administrative functions or upgrades require the system to be off-line, and for how long? 6 -- Is there a backup module for circulation in case the system is down? 7 -- Describe the way customer support works, what it covers, and hours of service. 8 -- What is the indexing capability for the catalog? How many indexes can we have? Can they be customized? 9 -- Describe the capacity for integrating selfcheck machines with the system. Is it SIP1/SIP2/NCIP compliant? 10 -- What report writing capability does the system have? 11 -- What "canned" reports are available? 12 -- Is there an API available? Can we develop applications that can directly access the database? 13 -- Is there a function for electronic ordering, such as from Baker and Taylor? Does B&T support your ordering module? 14 -- What flexibility is there for customizing the catalog? Can the catalog engine search external databases? 15 -- Is the system client-server or web based? 16 -- What is the capacity for e-mail functions, including e-mail notices? 17 -- Can the system integrate library fines with external payment interfaces (library cards, etc.)? 18 -- Which RFID vendors have successfully integrated with your system? 19 -- Can receipt printers work with the system? 20 -- Have you converted DRA Classic sites in the past? Describe your conversion process. What data can you *not* convert? 21 -- Can your system work with Epixtech's URSA module for inter-library loan? 22 -- Do you provide an integrated point of sale module? 23 -- What functions can our public do from home via our catalog -- pay fines? renew items? place requests? renew cards? 24 -- Does the catalog have multi-lingual support? 25 -- What are the options, or lack of, regarding database privacy (reading records of the public, retrospective history, etc.)? 26 -- Is there support for access via hand-helds? 27 -- What is the database platform? Proprietary? Oracle? Informix? SQL? Something else? 28 -- Can customized fields be added to either item or patron records? 29 -- What flexibility is there for searching item and patron records? Can additional item and patron fields be made searchable? 30 -- Can the system store content (not just indexing) for digital materials, photographs, e-books, digital audio? 31 -- Can staff get real-time statistics on demand? 32 -- Is there any way for users to get automatic bibliographies on request? 33 -- Is there any capacity for debit interfaces with functions such as printing? 34 -- What kind of hardware do you recommend? Does your configuration include RAID? 35 -- What database redundancy is built into the system, in case a disk is lost or corrupted? 36 -- What kind of support do you have for bookmobile operation, eg. a cache of the whole database changed every day? 37 -- Is there support for cover pages, excerpts, etc., such as we can purchase from Syndetic? 38 -- Can the public place requests for titles which are on order? 39 -- Is there integrated selector management -- that is, when you select a title from a database such as OCLC, can it be loaded into the system and ordered? 40 -- How is access managed to OCLC? 41 -- How are long overdue items managed -- patron notices, credit bureau reports, masking from the database, etc.? Does the capacity exist to transfer these items into an auxiliary database? 42 -- Explain the hierarchical nature of database locations (system, agencies, departments, or whatever). 43 -- How are item statuses used? Can they be converted from DRA Classic to the new system? 44 -- What is the procedure for processing lost items? 45 -- What kind of transaction statistics are kept for items? For patrons? 46 -- How does licensing work? How are fees determined? 47 -- Can the system handle consortia? How does this affect licensing fees? 48 -- What can be controlled by the systems calendar (eg. days when items are not due, fines not charged, etc.)? 49 -- What kind of patron delinquency statuses are available? Can patron statuses be converted from DRA Classic? 50 -- Does the catalog allow searching by item (not bibliographic) call numbers? 51 -- What is the hierarchy of the bibliographic database (bibliographic records, call number records, item records)? 52 -- What is the system of classifications for materials (material codes)? Can selfcheck checkouts be limited to specified item classifications? 53 -- Can the system allow automatic charges to patron records as certain classes of items are checked out? Can this feature be used with the selfcheck? 54 -- Is it possible to set up multiple databases within the system? 55 -- Is there a text catalog that can be used for modem access (for people who are not yet on the Internet)? 56 -- Does the system allow tracking between patron categories and item categories for circulation statistics? 57 -- Can fine records for patrons be converted to your system from DRA Classic? Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org

4 3

Re: [Koha] Installation questions from another Linux/Koha newbie (fwd)
by Pat Eyler 07 Oct '02

07 Oct '02

heh, it works better to spell the name of the mailinglist correctly when forwarding an email to it ... ---------- Forwarded message ---------- Date: Mon, 7 Oct 2002 12:18:27 -0400 (EDT) From: Pat Eyler <pate(a)eylerfamily.org> To: Owen Leonard <oleonard(a)athenscounty.lib.oh.us> Cc: koha(a)lists.katipo.co.nz, koh-devel(a)eylerfamily.org Subject: Re: [Koha] Installation questions from another Linux/Koha newbie On Mon, 7 Oct 2002, Owen Leonard wrote: > In preparation for our move to Koha, I've got a brand new installation of > RedHat 7.3 on my desktop. I installed 1.3.0 using the install-script, and got > Apache set up fine. Something's not working right, though--several of the > pages come up 'Internal Server Error' (book and member searches, for > instance). > > What's the best way to diagnose problems like this? Did I skip some > configuration somewhere along the way? Or am I asking for trouble trying to > get 1.3.0 to work? > Hi Owen, The best way to look into problems like this is to start out in the error_log for apache to see what apache thinks is wrong. It sounds like you may have missed a step along the way, but that's hard to tell. You may want to avoid the 1.3.0 series for a bit longer yet (wait for 1.3.2 I'd guess -- Paul?). It's really geared at developers at this point. The good news is that the user visible (and installer bits) are going to be substantially the same as the 1.2.X versions, so the experience you gain in setting up and demoing things will carry over. Also, I've CC:d the koha-devel list on this. When troubleshooting problems, it often a good idea to try involving them. Another good approach is to jump onto the #koha channel at irc.katipo.co.nz and see if anyone is there who can help. thanks, -pate > -- Owen > > ---- > Web Site Developer > Athens County Library Services > http://www.athenscounty.lib.oh.us > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

2 1