Re: [Koha] some thoughts about cataloguing and acquisition (important)
Greetings All! I'm a Librarian and a Library Automation Consultant, and have been involved in library automation for 20 years - since the earliest days of microcomputer applications for libraries. I have been monitoring the listserv for a few days, and have become interested because of my links with the supporters of Koha in my area. I am considering getting a couple of clients to install the system here in Montreal. I appreciate the comments I've seen on this list regarding the need for a good acquisitions module to make Koha strong against all competition. I agree, but not to the subordination of the cataloguing functionality. We need to improve and perfect the acquisitions function, but we must not neglect the provision of appropriate tools to create records that meet the standard. The standard for cataloguing - whether we like it or not - is MARC (whichever version we should standardize on is a question for another day) - and we need to be able to create entries in Koha that will produce good MARC records for those we can't fetch from somewhere else. I advise most librarians to use the internet and to fetch MARC records from anywhere they can instead of creating them manually, and the z39.50 searching and fetching capability that I've noticed mentioned is a great tool to have integrated in the system. Nevertheless, it does happen that there are no valid records available for certain documents, and there is a need to be able to catalogue them fully in the right structure. Also, it is necessary to be able to edit the MARC record appropriately. Sometimes a librarian may be able to take a record for a similar title and modify it so that it will be appropriate for the new item. To do that, the cataloguing module must allow for the editing of all parts of the record - not a trivial matter for a data structure with 1000 variable length fields, most of which may be repeatable, and a maximum record size of 99999 bytes. (I have an article I wrote for School Libraries in Canada called "Hitting the MARC" that discusses the use of MARC as the data structure for library automation that may help. Send me a message and I'll forward it back to you). It would be a serious mistake to produce a system that doesn't allow for full record creation and editing the MARC structure records. It is complex enough that I suspect it should be a module of its' own. Just my 2 cents worth! Looking forward to some interesting discussions in the future. Regards, Al Calame Management Consultant, Librarian-at-Large, Albert P. Calame Consulting Montreal, Québec, Canada 514-745-3424 albert.p.calame@sympatico.ca
On Thu, 16 Jan 2003, Albert P. Calame wrote:
To do that, the cataloguing module must allow for the editing of all parts of the record - not a trivial matter for a data structure with 1000 variable length fields, most of which may be repeatable, and a maximum record size of 99999 bytes. (I have an article I wrote for School Libraries in Canada called "Hitting the MARC" that discusses the use of MARC as the data structure for library automation that may help. Send me a message and I'll forward it back to you). It would be a serious mistake to produce a system that doesn't allow for full record creation and editing the MARC structure records. It is complex enough that I suspect it should be a module of its' own.
The next version of Koha will be fully capable of storing all of the data that a MARC record can hold. It will also be able to enforce the restrictions set in the chosen standard (MARC21 or UNIMARC for now) like which fields or tags are repeatable, etc. Our goal is to allow two or more "interfaces" for cataloguing. One of these will definitely be the full MARC interface, where librarians will add a 245a subfield for a title record, and a 100a subfield for an author, etc. I believe that Paul Poulain has already done some nice work on a MARC editor for Koha. There will also be a simpler non-MARC interface where the librarian will fill in a set number of fields (such as title, subtitle, author, publisher, etc.) without having to know anything about the MARC structure that the data is actually stored in. This interface will basically be the same as the existing cataloguing interface in the 1.2 version of Koha. This is much less flexible but allows Koha to be used in settings where a trained librarian is not available, or where the librarians feel that they don't need the flexibility (and the associated complexity) that MARC offers. Steve Tonnesen
First of all: a short introduction of myself. I'm a Swiss librarian, interested in different library systems, and am presently co-writing part of the Koha documentation. I've been working with different library systems in the past, both commercial and custom made, but am not currently working in a library. Following the discussion on the koha list on acquisitions and cataloguing with a lot of interest some thoughts and questions popped up for me. Historically, in libraries, acquisitions and cataloguing have been distinct processes, often employing personnel with different qualtifications. This was the case mainly in the paper age, but also in "early" automation, as often acquisitions was added onto an ILS only later. But Koha offers up till now a different approach. Koha uses a somehow linear process for entering the document data. First a document is ordered, and therefor linked to the supplier data. At receiving, the bibliographic data can be completed, and group and item information added. And the cataloguing is complete. There is no distinction of acquisitions and cataloguing in Koha, cataloguing is "modifying an acquisition's record". So for me, there are a few questions, I'd like to throw into the discussion: - what arguments are against keeping Koha "different" and have a "document treatment unity" comprehending acquisitions and cataloguing? - is it really necessary to separate cataloguing from acquisitions - provided that acquisitions allows "complete entering of the data = cataloguing" according to the format chosen (marc or non-marc)? - does a marc-record necessarily need to be complete? or is it possible to have something like a "temporary marc record" which has only a few marc field used, and still have every record in the same bibliotable? - if acquisitions and cataloguing are going to be separated - is there really a need to have a second copy of the database? As I fully agree that the user interrogating the catalogue should be shown wheter a book is on order or bought and available in the library, there should be done sth about it. But I think that this could be treated in adding a "status" to the document like "on order", "in the library - but in process", "on the shelf", "borrowed" etc. In other words: if separation is needed, shouldn't there be just separate "interfaces" for acquisitions and cataloguing - both using the one and only one database? - is it possible to differentiate by "record status"only? Personally, I'd rather have a ILS which unites acquisitions and cataloguing, keeping the system as simple as possible, for librarians and members, even if this needs some reorganisation in a library, e.g. employing personnel in acquisitions who knows how to catalogue. And concentrating all efforts in other parts of the system. Regula Sebastiao __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
On Fri, Jan 17, 2003 at 12:16:59AM +0000, Regula Sebastiao wrote:
- does a marc-record necessarily need to be complete? or is it possible to have something like a "temporary marc record" which has only a few marc field used, and still have every record in the same bibliotable?
I understand the question to be this: why should Koha preserve full MARC records when both the format of the records is archaic (sorry you MARC fans) and only some of the fields are used; can't we simply build a program to grab the standard MARC fields and stick thim into the Koha database? If this is your question I can take a stab at it. One major problem that I see with not having all the MARC fields in the Koha database arises when libraries try to move data: many libraries are used to using the extra fields in MARC to document things that MARC did not contain standard fields for. If Koha does not have the capacity to retrieve all the MARC fields from a record, libraries that use the extra fields in MARC will have difficulty transfering their data from the old system to the new one. Not storing the complete MARC record could turn out to be a severe limitation. Joshua Ferraro Nelsonville Public Library
Hi again my question was aimed to know wheter a "basic" record for acquisitions, e.g., could be in a kind-of-reduced MARC-format. ordering information is often incomplete and thus not all required fields of a MARC record can be filled in. in the systems I know, this problem is solved in various ways. either by having incomplete records (non-MARC) in a separate database or an incomplete MARC-record signalled as such with "record status". one such status could be "acquisition-incomplete" e.g. another one would be deleted notice etc. and i absolutely do agree that if MARC is used, then ALL MARC fields should be possible in the database. and the required-optional fields should be respected for a full record. but there should be possibilities for not complete records. personally, i think that there should be one and only one database where all bibliographic-"minded" records - ev. with different statuses - should be stored. Regula Sebastiao --- Joshua Ferraro <jferraro@alma.athenscounty.lib.oh.us> wrote: > On Fri, Jan 17, 2003 at 12:16:59AM +0000, Regula Sebastiao wrote:
- does a marc-record necessarily need to be complete? or is it possible to have something like a "temporary marc record" which has only a few marc field used, and still have every record in the same bibliotable?
I understand the question to be this: why should Koha preserve full MARC records when both the format of the records is archaic (sorry you MARC fans) and only some of the fields are used; can't we simply build a program to grab the standard MARC fields and stick thim into the Koha database? If this is your question I can take a stab at it.
One major problem that I see with not having all the MARC fields in the Koha database arises when libraries try to move data: many libraries are used to using the extra fields in MARC to document things that MARC did not contain standard fields for. If Koha does not have the capacity to retrieve all the MARC fields from a record, libraries that use the extra fields in MARC will have difficulty transfering their data from the old system to the new one. Not storing the complete MARC record could turn out to be a severe limitation.
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Greetings All! I'm always concerned when we start talking about using "basic" or "brief" cataloguing records, simply because so often the "quick and dirty" ends up being the final version - mostly because we have so little time to take care of fixing things up later. That said, in the systems that I've worked in we usually had templates for short records and for more complete records. I think that the system should be able to allow us to enter acquisitions data directly into the MARC database, and an "On Order" status, or an "Under Consideration" status added to the record could be applied so that users searching in OPAC would realize the items are not available. When the item is received, and the status changes, the system would then flag the record for update so that the librarian could complete the cataloguing with the item in hand (incidentally allowing you to fetch an appropriate MARC record for the item online, or to load the record that you could receive from the vendor if the service is available to you.). The system should allow the creation of records that have only a certain minimum of information: namely, Author (100#a); Title (245#a and b); Publication information (260#a,b,and c); Physical Description (300), if available; and, standard numbers such as ISBN (020), ISSN (022), and LCCN (010) when they are available. Of course, the system should allow you to make sure the Leader of the record reflects the appropriate type of material, and that the fixed field (008) field has the basic information in it. The final version of the record, after the item is received, would add the subject access and notes, and all the other pertinent local holding information like call number, price, and barcode. All this should be recorded in MARC format, and I concur with others who have written that the system should allow for the entry of all 1000 MARC fields. If records are stored in this structure, there is no reason why they can't be displayed any way the user desires. The data entry templates can use the full MARC designations for those who use them, but a more simple interface could easily be prepared that would insert the data into the appropriate MARC field or subfield, supplying appropriate punctuation automatically - or "automagically" as a fellow librarian says! I think it is wasteful to have records in two different formats - one MARC and one non-MARC. It means that if you want to move information from one to the other that you have to convert the data. Storing the information in one standard format makes much more sense to me. In this I strongly agree with Regula! Regards, Al Calame Librarian-at-Large, Montreal, Québec, Canada 514-745-3424 albert.p.calame@sympatico.ca ----- Original Message ----- From: "Regula Sebastiao" <reseba@yahoo.com> To: <koha@lists.katipo.co.nz> Cc: "Joshua Ferraro" <jferraro@alma.athenscounty.lib.oh.us> Sent: Sunday, January 19, 2003 6:20 PM Subject: Re: [Koha] some thoughts about cataloguing and acquisition (important)
Hi again
my question was aimed to know wheter a "basic" record for acquisitions, e.g., could be in a kind-of-reduced MARC-format. ordering information is often incomplete and thus not all required fields of a MARC record can be filled in.
in the systems I know, this problem is solved in various ways. either by having incomplete records (non-MARC) in a separate database or an incomplete MARC-record signalled as such with "record status". one such status could be "acquisition-incomplete" e.g. another one would be deleted notice etc.
and i absolutely do agree that if MARC is used, then ALL MARC fields should be possible in the database. and the required-optional fields should be respected for a full record. but there should be possibilities for not complete records.
personally, i think that there should be one and only one database where all bibliographic-"minded" records - ev. with different statuses - should be stored.
Regula Sebastiao
--- Joshua Ferraro <jferraro@alma.athenscounty.lib.oh.us> wrote: > On Fri, Jan 17, 2003 at 12:16:59AM +0000, Regula Sebastiao wrote:
- does a marc-record necessarily need to be complete? or is it possible to have something like a "temporary marc record" which has only a few marc field used, and still have every record in the same bibliotable?
I understand the question to be this: why should Koha preserve full MARC records when both the format of the records is archaic (sorry you MARC fans) and only some of the fields are used; can't we simply build a program to grab the standard MARC fields and stick thim into the Koha database? If this is your question I can take a stab at it.
One major problem that I see with not having all the MARC fields in the Koha database arises when libraries try to move data: many libraries are used to using the extra fields in MARC to document things that MARC did not contain standard fields for. If Koha does not have the capacity to retrieve all the MARC fields from a record, libraries that use the extra fields in MARC will have difficulty transfering their data from the old system to the new one. Not storing the complete MARC record could turn out to be a severe limitation.
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi All [Big snip] What I think the system should do is not force anyone to conform to another's method of cataloging if at all possible :-) One big reason the data is stored in marc and the non-marc koha format. Is that HLT for whom the system was originally written, have no desire to ever have to deal with MARC. I think it would be a real shame if they lost that, so what my aim as a koha developer is, is to make sure that those who want to see bibliographical data in terms of a MARC record can. And those who dont dont have to.
I think it is wasteful to have records in two different formats - one MARC and one non-MARC. It means that if you want to move information from one to the other that you have to convert the data. Storing the information in one standard format makes much more sense to me. In this I strongly agree with Regula!
The computer scientest in me agrees also. We should have a fully normalised database with no redundant data. But there are many other considerations, the main one being speed of searching. Data will undoubtedly need to be duplicated in order to achieve fast search results. The trick is making sure the routines that handle the data keep it all in sync. Disk is cheap .. users patience with slow searches isnt :-) Just some thoughts. I must say im really enjoying the discussions on the lists lately. Lots of positive input from many people. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Mandi! Chris Cormack In chel di` si favelave...
But there are many other considerations, the main one being speed of searching. Data will undoubtedly need to be duplicated in order to achieve fast search results. The trick is making sure the routines that handle the data keep it all in sync. Disk is cheap .. users patience with slow searches isnt :-)
Please, no. Referential integrity is the only warrenty of data ever correct and coherent. A correct schema, well written, are not slower as a full set of dirty tricks. Please, build koha around a well written data schema, ad the application will be easer tu build and to manage. PS: for the MARC dispute... i think that koha *MUST* speak MARC, but this dont'mean that koha have to usa marc as a internal storage format... -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) gaio(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Difendiamo PeaceLink! Campagna di solidarietà per la tutela legale di una voce scomoda. http://www.peacelink.it/emergenza/
Mandi! Chris Cormack In chel di` si favelave...
But there are many other considerations, the main one being speed of searching. Data will undoubtedly need to be duplicated in order to achieve fast search results. The trick is making sure the routines that handle
Hi again! At the risk of flogging a dead horse, and also of putting my 2 cents in where they don't belong, I don't see the wisdom or benefit of maintaining two data structures for koha bibliographic data. The internal data structures in MARC records require the ability for a database engine to be able to read and index much more than just a string of data. There are 1000 fields potentially, all of which may be repeatable, with over 30 subfields possible and most of which are variable in length. Each field may have as many as two special indicators attached to them to indicate how the data in the field must be treated. Then comes the punctuation... If the data structure that the data is stored in doesn't understand this and allow you to modify it, the system is crippled from the start.(Certainly in the North American market.) I've been working with library automation for over 20 years now in the microcomputer environment. In the early days, systems came to market using all kinds of database engines, proprietary structures designed for the system, and published ones like dbase. They were simple and easy to use and extremely inflexible in every case but one of my experience. There was no standard, and it showed - people couldn't share information from one system to another. This was a fundamental flaw that goes against the philosophy of what libraries are all about. Sharing! When I started in library automation, I had a barcode and 28 characters for the title in the "bibliographic" record. The next system expanded to give me 55 characters for the title, 20 characters for the Call Number and Author designation , a price field, one for ISBN or LCCN, and 2 codes for subject areas. I never did get all the records updated. Then came a more developed system that allowed much more complete data and eventually stored a copy of the MARC record which was the source of the other fields of data. Again, we found that the brief records we entered for later enhancement never got enhanced. The name of this game is access to information. The more data we have in a record, the more potential access we have. If you don't currently use an OPAC or don't expect to have one, and only do circulation, you can get along with a very skeletal record - like the first one I had (though 28 characters for a title is a bit restrictive). Otherwise you need to think in terms of having records that are more complete. I was a school librarian, and it is a fallacy to think that you need less information in the catalogue of school library than you need in a public or academic library. You need the same level - how can you teach children to find things if you don't give them all the tools. It's like learning to drive an automobile that doesn't have any fuel in it. I'm certainly not against having simple entry screens and simple records for those who don't think they need any more than that. I know that it is possible to have that and have the information stored in any structure you like. If you don't want to use the full power of MARC you shouldn't have to, and we should have entry screens and displays available that don't require you to know it. I do submit, however, that it will be much easier programming-wise to store all the data in MARC and then give it to the user in that simple form than to keep maintaining two versions of koha - one for MARC and one non-MARC. Since there is a standard, I believe we should use it. I know that there are simpler data structures than MARC. That's just the problem. The data we need can't be stored in any other way, that I know of, that will give us everything. MARC, in any one of its incarnations, does that. Those who want to do simple entry can do so, into a data entry screen that just asks them for simple data, and the system will automatically create the record in MARC format with the required fixed information. When they want to edit the record, they use the same simple template. When the information is displayed, it is displayed the way they want it to be. If they decide later to go the MARC route, all they need to do is bring up the MARC data entry or editing templates and they're there. No conversions required. Maybe harder to program in the beginning, but worth the trip in the long run! OK, so maybe it's more like 10 cents, but there it is. You may have figured out by now that I'm a bit of a MARC fanatic. But I've seen too many problems over the years with non-standard database structures to be able to let this one go by without comment. Have a great day! Regards, Al Calame Consultant, Librarian-at-Large, Albert P. Calame Consulting Montreal, Québec, Canada 514-745-3424 albert.p.calame@sympatico.ca I understand ----- Original Message ----- From: "Marco Gaiarin" <gaio@sv.lnf.it> To: "Chris Cormack" <chris@katipo.co.nz>; <koha@lists.katipo.co.nz> Sent: Monday, January 20, 2003 4:31 AM Subject: Re: [Koha] some thoughts about cataloguing and acquisition (important) the
data keep it all in sync. Disk is cheap .. users patience with slow searches isnt :-)
Please, no. Referential integrity is the only warrenty of data ever correct and coherent. A correct schema, well written, are not slower as a full set of dirty tricks.
Please, build koha around a well written data schema, ad the application will be easer tu build and to manage.
PS: for the MARC dispute... i think that koha *MUST* speak MARC, but this dont'mean that koha have to usa marc as a internal storage format...
-- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) gaio(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797
Difendiamo PeaceLink! Campagna di solidarietà per la tutela legale di una voce scomoda. http://www.peacelink.it/emergenza/ _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On Mon, 20 Jan 2003, Albert P. Calame wrote:
Again, we found that the brief records we entered for later enhancement never got enhanced.
Is some sort of data auditing facility available in these packages to say "these records are incomplete"? In dealing with migrating legacy data into relational databases I've had to write these sorts of auditing scripts to gradually clean up the old data. Sometimes this is before loading into the relational system, but often it happens after it's loaded. A flag that says "this record is incomplete" or simply a series of checks "if x then problem" have been effective if the users are motivated to clean up the data problems found in the audit. -- </chris> "Never offend people with style when you can offend them with substance." - Sam Brown
Hello I have to agree with Albert on this: MARC is simply so widespread that, even if you think you don't want MARC, you will later discover that you must have it. I certainly don't know the underlying data structures of koha, but the simplest thing, to me, seems to be, maintaining fundamentally MARC based info, which can have simple, or full interfaces. I have not given this a lot of thought, but would something like this work? Table of valid record number. create table records { recordid number; acquisid number; }; The marc table uses the record id as the foreign key, to pull together the field number, and the subfields. create table marc { recordid number; fieldid number; subfield varchar; idicator1 varchar; indicator2 varchar; }; Then various views can be used to construct tables of titles, and authors based on selecting the correct fieldid, and subfields from the records. Just my 2 nanocents. Rick __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
On Mon, Jan 20, 2003 at 01:31:13PM -0800, Enrico Silterra said:
Hello I have to agree with Albert on this: MARC is simply so widespread that, even if you think you don't want MARC, you will later discover that you must have it.
I certainly don't know the underlying data structures of koha, but the simplest thing, to me, seems to be, maintaining fundamentally MARC based info, which can have simple, or full interfaces.
Hi Guys We may have gone a little of track here :-) There is no suggestion that Koha should not support MARC, and in the development branch, (what will become 2.0) MARC is already supported. IE you can import from MARC, view a record as MARC and export it again as MARC, for various flavours of MARC. All im seeking to achieve is for those who dont want to see their data as MARC records, they dont have to :-) Underlying storage doesnt really worry me, as long as its 1/ Fast, and 2/ Complete. And as long as the API for dealing with the data is well defined and tested, so as to ensure integrity. I really dont mind at all how its stored. I hope that clears up where im coming from. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
On Mon, 20 Jan 2003, Marco Gaiarin wrote:
Please, no. Referential integrity is the only warrenty of data ever correct and coherent. A correct schema, well written, are not slower as a full set of dirty tricks. Please, build koha around a well written data schema, ad the application will be easer tu build and to manage.
You're mixing up a number of things here. What you're referring to as "referential integrity" I'm guessing you mean normalized. Either way, neither is a warranty for correct data. I'm a big believer in normalization and a fully normalized "ideal" model for every system should be saved as a reference for all DBA's and programmers dealing with the database directly. But in most practical systems some degree of denormalization is necessary for effeciency. I have a system which produces reports of insurance claims. We maintain a claim transaction table that has a lot of transactions in it, but also another table summarizing various things about these transactions. If we were to scan the full transaction table for each report produced, the reports would take four to five times as long to produce and the overall application would be slower because of CPU and I/O utilization on the server. The obvious difficulty is that this information must be maintained which entails programming and system overhead, but given our usage patterns this trade off is well worth it. Some people are overzealous in their optimizations and you can end up with some nasty data models because of it, but that doesn't mean that denormalization is all bad. If you're speaking of referential integrity in the sense of constraints within the database, there again you're facing a performance penalty which is usually not worth it. I encourage software developers to write code on a database which supports constraints, but the implementation is often on a database where constraints aren't available (like MySQL) or where the constraints slow things down more than they're worth (like Oracle) in production. Financial environments and other places where there's plenty of money to throw at hardware for the database often run production systems with referential integrity cut on, but that's the opposite of most libraries I'm familiar with. -- </chris> "Never offend people with style when you can offend them with substance." - Sam Brown
Mandi! Christopher Hicks In chel di` si favelave...
database directly. But in most practical systems some degree of denormalization is necessary for effeciency.
There's ever time for dirty tricks, and i'm seriously convinced that with a well written schema in normal (normalized?!) form all things can be done with no big penalties (or better, with low speed penalties compared to overral stability benefit ;).
production. Financial environments and other places where there's plenty of money to throw at hardware for the database often run production systems with referential integrity cut on, but that's the opposite of most libraries I'm familiar with.
Oh, my organization use JDE OW as a business/ERP/CRM software, and there's no referential integrity at all. Worst practice tipically doesn't need examples. ;) -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) gaio(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Difendiamo PeaceLink! Campagna di solidarietà per la tutela legale di una voce scomoda. http://www.peacelink.it/emergenza/
On Thu, 23 Jan 2003, Marco Gaiarin wrote:
database directly. But in most practical systems some degree of denormalization is necessary for effeciency.
There's ever time for dirty tricks, and i'm seriously convinced that with a well written schema in normal (normalized?!) form all things can be done with no big penalties (or better, with low speed penalties compared to overral stability benefit ;).
Then please educate me. Here's a challenge: Database: anything freely runnable on Linux ERD: Two tables in a master-slave arrangemet. The master is a "claim" table and the slave is a "transact" table. The transact table often contains hundreds and occasionally thousands of transactions per claim. Transactions include allocating funds and spending them across several categories per claim. Allocation and spending totals for each category and the overall claim are regularly needed in reports. Usage: few updates, many reports. Reports may be for a few or thousands of claims. Quandry: Either don't maintain totals in an effort to remain pure for normalization purposes or maintain the necessary totals in the claim table or a claimsumm table. So, can you use a standard benchmarking module ( http://search.cpan.org/author/JHI/perl-5.8.0/lib/Benchmark.pm ) to show that the time to produce a report in the normalized fashion is quicker than producing it in the denormalized fashion? Let's say that if you can produce the reports based on normalized data in less than twice the time they can be produced with denormalized data that would be considered "no big penalties" and you win. For fun, try it with a few test clients running concurrently and watch what happens to the results. I'm sure the librarians are bored to tears by all of this by now, but it would be extremely disappointing to them I think if the "normalization to the death" camp holds sway over Koha. Normalization is a very good idea and it doesn't cause any problems until you try to scale beyond a database size of merely academic interest. Normalization is often ignored because of premature optimization and total ignorance and I spend more of my DBA consulting time teaching people this most basic of database concepts than I do encouraging people to break the rules. But when there's a clear need to break the rules, you'll pay an increasingly large penalty as things scale. And I suspect almost every library would like to get bigger someday. -- </chris> "Never offend people with style when you can offend them with substance." - Sam Brown
On Thu, 23 Jan 2003, Christopher Hicks wrote:
I'm sure the librarians are bored to tears by all of this by now
I think that Christopher has made a very important point here. This is an excellent conversation, and will be carefully weighed and measured by folks doing active development work (mostly through benchmarking, as was done during the 1.3 schema development). I don't want to discourage anyone from discussing koha, but please let me point out that there are several lists where conversations can (should) be steered. koha (this list) - for discussion of Koha at (primarily) the library level. questions about how to get something installed or added are certainly appropriate. koha-devel - here's where the developers hang out in all their geeky glory. discussions here should be about the nuts and bolts of getting code improved, extended, fixed, etc. this is a very tactical list koha2010 - here's the strategic list. this is where we talk about functionality in Koha, what's missing, what needs to be changed, etc. kohabiz - if you're interested in running a business around koha, this is the place to exchange ideas, leads, and other such stuff. koha-win32 - if you're hoping to run koha on windows, you should be on this list. it's not for the faint of heart ... french koha list - this is a french language list, it serves the purposes of all of the above (it may get split out into multiple lists as it grows ... ) german koha list - like the french list, only in german (If you think there should be list for your own language, please let us know. We're pretty happy to set up such lists and maintain them, given a reasonable need.) you can get more information (including subscription info) about these lists at: http://koha.org/mailing/ thanks, -pate
..... french koha list - this is a french language list, it serves the purposes of all of the above (it may get split out into multiple lists as it grows ... ) german koha list - like the french list, only in german (If you think there should be list for your own language, please let us know. We're pretty happy to set up such lists and maintain them, given a reasonable need.) ---- On that note, I'm still waiting to hear from various people with requests for language related services! Email me for access to documentation translation tools, and Pat about language specific lists and CVS access for templating! Nick
just a bit of Subject: line and CC: line hygiene :) On Thu, 23 Jan 2003, Nicholas S. Rosasco wrote:
On that note, I'm still waiting to hear from various people with requests for language related services! Email me for access to documentation translation tools, and Pat about language specific lists and CVS access for templating!
On a related note, I've been asked to see if there's anyone interested in a Breton translation of Koha. THere are a couple of folks who are willing to work on it, but they'd like to see if anyone else is interested (and maybe willing to help out). thanks -pate
Nick
hello again just one clarification... and maybe i seem to contradict myself, but i feel it's important to add this precision. when i said that i thought that there should be only one database, i was thinking only of marc records and how "records for acquisitions" could fit into a marc-record based koha. thus the thing about a different status like "on order" indeed. i was not thinking of the "other" format, i.e. the original format koha offers as well, which is used in hlt at present. and i do fully agree that there should be a "complete non marc version", especially for libraries who wish to keep their data entries simple. there are libraries who have different needs, and many of them do not have the wish or need to import/exort records. especially smaller libraries will probably not gain much by importing data, but more when having a simple cataloguing procedure as it is the case at present. in my mind, a library chooses at installation of koha one or the other format (marc or non-marc) and sticks to it, and a switch to the other version would mean major changes... greetings, Regula --- "Albert P. Calame" <albert.p.calame@sympatico.ca> wrote: > Greetings All!
I'm always concerned when we start talking about using "basic" or "brief" cataloguing records, simply because so often the "quick and dirty" ends up being the final version - mostly because we have so little time to take care of fixing things up later.
That said, in the systems that I've worked in we usually had templates for short records and for more complete records. I think that the system should be able to allow us to enter acquisitions data directly into the MARC database, and an "On Order" status, or an "Under Consideration" status added to the record could be applied so that users searching in OPAC would realize the items are not available. When the item is received, and the status changes, the system would then flag the record for update so that the librarian could complete the cataloguing with the item in hand (incidentally allowing you to fetch an appropriate MARC record for the item online, or to load the record that you could receive from the vendor if the service is available to you.).
The system should allow the creation of records that have only a certain minimum of information: namely, Author (100#a); Title (245#a and b); Publication information (260#a,b,and c); Physical Description (300), if available; and, standard numbers such as ISBN (020), ISSN (022), and LCCN (010) when they are available. Of course, the system should allow you to make sure the Leader of the record reflects the appropriate type of material, and that the fixed field (008) field has the basic information in it.
The final version of the record, after the item is received, would add the subject access and notes, and all the other pertinent local holding information like call number, price, and barcode. All this should be recorded in MARC format, and I concur with others who have written that the system should allow for the entry of all 1000 MARC fields. If records are stored in this structure, there is no reason why they can't be displayed any way the user desires. The data entry templates can use the full MARC designations for those who use them, but a more simple interface could easily be prepared that would insert the data into the appropriate MARC field or subfield, supplying appropriate punctuation automatically - or "automagically" as a fellow librarian says!
I think it is wasteful to have records in two different formats - one MARC and one non-MARC. It means that if you want to move information from one to the other that you have to convert the data. Storing the information in one standard format makes much more sense to me. In this I strongly agree with Regula!
Regards, Al Calame
Librarian-at-Large, Montreal, Québec, Canada
514-745-3424 albert.p.calame@sympatico.ca
----- Original Message ----- From: "Regula Sebastiao" <reseba@yahoo.com> To: <koha@lists.katipo.co.nz> Cc: "Joshua Ferraro" <jferraro@alma.athenscounty.lib.oh.us> Sent: Sunday, January 19, 2003 6:20 PM Subject: Re: [Koha] some thoughts about cataloguing and acquisition (important)
Hi again
my question was aimed to know wheter a "basic" record for acquisitions, e.g., could be in a kind-of-reduced MARC-format. ordering information is often incomplete and thus not all required fields of a MARC record can be filled in.
in the systems I know, this problem is solved in various ways. either by having incomplete records (non-MARC) in a separate database or an incomplete MARC-record signalled as such with "record status". one such status could be "acquisition-incomplete" e.g. another one would be deleted notice etc.
and i absolutely do agree that if MARC is used, then ALL MARC fields should be possible in the database. and the required-optional fields should be respected for a full record. but there should be possibilities for not complete records.
personally, i think that there should be one and only one database where all bibliographic-"minded" records - ev. with different statuses - should be stored.
Regula Sebastiao
--- Joshua Ferraro <jferraro@alma.athenscounty.lib.oh.us> wrote: > On Fri, Jan 17, 2003 at 12:16:59AM +0000, Regula Sebastiao wrote:
- does a marc-record necessarily need to be complete? or is it possible to have something like a "temporary marc record" which has only a few marc field used, and still have every record in the same bibliotable?
I understand the question to be this: why should Koha preserve full
records when both the format of the records is archaic (sorry you MARC fans) and only some of the fields are used; can't we simply build a program to grab the standard MARC fields and stick thim into the Koha database? If this is your question I can take a stab at it.
One major problem that I see with not having all the MARC fields in
Koha database arises when libraries try to move data: many libraries are used to using the extra fields in MARC to document things that MARC did not contain standard fields for. If Koha does not have the capacity to retrieve all the MARC fields from a record, libraries that use the extra fields in MARC will have difficulty transfering their data from the
MARC the old
system to the new one. Not storing the complete MARC record could turn out to be a severe limitation.
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
__________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Hi # From a long time lurker on this site - always very interesting site. I am a librarian with very slight technical knowledge of databases. This library is a member of Kinetica (a large database of maybe 36 million MARC compatible holdings) that is run by the National Library of Australia. wwww.nla.gov.au/kinetica/connect.html to see information. IDs and passwords are needed to check the catalogue which costs around 80c to $1 approx per search. I'm pretty sure NLA would supply access to serious developpers. There is a Cataloguing Client for MARC compliant cataloguing which is being updated. Small libraries now have available a shortened on the web input form for "cataloguing". This provides an entry of basic standard which hopefully may be upgraded later if another library also acquires that title. Libraries often "add" their holdings to existing records. Large libraries frequently work on their local cataloguing systems and "upload" to the Kinetica database and matching algorithms are there to prevent duplicate entries. Please note that I am not personally familiar with these details at the NLA "end" as work in a SOLO library now. This shortened on the web form has the standard requirements including author, title, format (like book, video etc etc) publisher, place of publication, date, country of publication, ISBN etc (International Standard Book Number), ISSN (International Standard Serial Number). It really is a simple form to complete - the record is saved as a whole (not line by line as in the Client), a check of the entry appears on the screen which you click to add to the Kinetica database in MARC format (done by the system). You do not need to know the MARC tags to use this form to produce a basic MARC compatible cataloguing record. Please excuse me if any of this is inaccurate as I have only used it as an end-user and so am not aware of the exact details at the NLA "end" of the process. The point I am trying to make is that the end-user library can immediately "see" the MARC tags added to their simple cataloguing on the screen after it has been input into the Kinetica Database, and another, even smaller library could add its holdings to the MARC record 1 or 2 minutes later, or indeed upgrade the complexity of the cataloguing standard. I got the impression that Koha "simpler non-MARC interface" form would not allow the "simpler" libraries to see the record in MARC compatible format. I apologise if I have misunderstood! I feel that it is very important to have all records MARC compliant for international cooperation, even if this is rarely needed at the local leval. With NLA the records are stored in NLA servers etc, not at the local leval which obviously could not store 36 million records! I feel sure that the people at the National Library of Australia would be very happy to liaise with Koha people. The NZ National Catalogue "Te Puna" is available on the Kinetica site and originally I believe it was a joint project between the National Libraries of Australia and NZ. Just my 2 cents. Bonne chance! Jean Truebridge ADAVB Library (VDA) -----Original Message----- From: koha-admin@lists.katipo.co.nz [mailto:koha-admin@lists.katipo.co.nz]On Behalf Of Tonnesen Steve Sent: Friday, 17 January 2003 08:47 To: Albert P. Calame Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] some thoughts about cataloguing and acquisition (important) On Thu, 16 Jan 2003, Albert P. Calame wrote:
To do that, the cataloguing module must allow for the editing of all parts of the record - not a trivial matter for a data structure with 1000 variable length fields, most of which may be repeatable, and a maximum record size of 99999 bytes. (I have an article I wrote for School Libraries in Canada called "Hitting the MARC" that discusses the use of MARC as the data structure for library automation that may help. Send me a message and I'll forward it back to you). It would be a serious mistake to produce a system that doesn't allow for full record creation and editing the MARC structure records. It is complex enough that I suspect it should be a module of its' own.
The next version of Koha will be fully capable of storing all of the data that a MARC record can hold. It will also be able to enforce the restrictions set in the chosen standard (MARC21 or UNIMARC for now) like which fields or tags are repeatable, etc. Our goal is to allow two or more "interfaces" for cataloguing. One of these will definitely be the full MARC interface, where librarians will add a 245a subfield for a title record, and a 100a subfield for an author, etc. I believe that Paul Poulain has already done some nice work on a MARC editor for Koha. There will also be a simpler non-MARC interface where the librarian will fill in a set number of fields (such as title, subtitle, author, publisher, etc.) without having to know anything about the MARC structure that the data is actually stored in. This interface will basically be the same as the existing cataloguing interface in the 1.2 version of Koha. This is much less flexible but allows Koha to be used in settings where a trained librarian is not available, or where the librarians feel that they don't need the flexibility (and the associated complexity) that MARC offers. Steve Tonnesen _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On Fri, Jan 17, 2003 at 11:43:00AM +1100, Jean Truebridge said:
Hi
[snip]
I got the impression that Koha "simpler non-MARC interface" form would not allow the "simpler" libraries to see the record in MARC compatible format. I apologise if I have misunderstood! I feel that it is very important to have all records MARC compliant for international cooperation, even if this is rarely needed at the local leval. With NLA the records are stored in NLA servers etc, not at the local leval which obviously could not store 36 million records!
You are kind of right :-) The simple non-MARC interface doesnt present the data in MARC to the librarians. That is not to say though, that the data isnt viewable and/or exportable in MARC format. Its just that the librarians have chosen (by setting a system variable) not to have to see the records in MARC format. This is the beauty of storing the data in a relational database, its very easy to present the same data in numerous different ways. So librarians can interface with the data in a way they are comfortable with. Hope this helps Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Hi I should say IANAL (I am not a librarian :-)
I got the impression that Koha "simpler non-MARC interface" form would not allow the "simpler" libraries to see the record in MARC compatible format. I apologise if I have misunderstood!
I think this is a misunderstanding. Aquisitions (full) is full because it deals with Budgets and bookfunds - MONEY, nothing to do with MARC. It assumes that you order books, wait around a bit, get the books delivered, then complete the catalogueing of them and put them on the shelves. It assumes that you want to do the minimum amount of data entry necessary *before* you get the book to enable people to see that you have it on order, but that you don't want to spend a bunch of time entering in data for a book you may never receive (something not uncommon here at the end of the world :-). You don't do the full catalogue record until you have the physical book in your hand. The simple Aquisitions system assumes that you don't really order books - or at least that you account for that in another system, that you just enter them when you get them, so it does the full record in one go - more like a "standard" catalogue screen I assume (But IANAL :-). I *hope* and I haven't been involved in the MARC project, so I'm not sure, that EITHER acquisition system will do the whole MARC bit, and that all you are choosing, is the aquisitions system that best fits your libraries business process. Hope it helps Cheers Rachel _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
Hi again And if I'm talking about something completely different I appologise - but I suspect the general thing is right - that MARC is something that you can have "obvious" or not, as is your preference Cheers R
Hi
I should say IANAL (I am not a librarian :-)
I got the impression that Koha "simpler non-MARC interface" form would not allow the "simpler" libraries to see the record in MARC compatible format. I apologise if I have misunderstood!
I think this is a misunderstanding. Aquisitions (full) is full because it deals with Budgets and bookfunds - MONEY, nothing to do with MARC. It assumes that you order books, wait around a bit, get the books delivered, then complete the catalogueing of them and put them on the shelves.
It assumes that you want to do the minimum amount of data entry necessary *before* you get the book to enable people to see that you have it on order, but that you don't want to spend a bunch of time entering in data for a book you may never receive (something not uncommon here at the end of the world :-). You don't do the full catalogue record until you have the physical book in your hand.
The simple Aquisitions system assumes that you don't really order books - or at least that you account for that in another system, that you just enter them when you get them, so it does the full record in one go - more like a "standard" catalogue screen I assume (But IANAL :-).
I *hope* and I haven't been involved in the MARC project, so I'm not sure, that EITHER acquisition system will do the whole MARC bit, and that all you are choosing, is the aquisitions system that best fits your libraries business process.
Hope it helps
Cheers Rachel _____________________________________________________________
Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
I think i must explain some things about 2.0 version... The Database exists in 2 forms : * "standard db" : the DB coming from the 1.2 version * "MARC-DB" : the MARC one. A parameter tables maps marc fields and standard-db ones. The new 2.0 guarantees that both DB are always synchronised. That's why it was long to write, and to debug. But, now we have a big advantage, as the user can decide to use MARC or non-MARC interface. In both cases, the 2 databases are living. If you choose the MARC one, the parameter tables provides the following features : * support any MARC flavour : just define what 100$a, 200$a... mean * support what you want in your MARC flavour : 100$a => used 100$b => used, but less important, 100$c => ignored The manual MARC cataloguing tool is ready in 1.3.3, and used by a french library in France. My question was not about marc/non marc, my question was to have advices for a deepest separation between acquisition and cataloguing. I repeat that here, in France, there are almost no librarians that enters manually their biblios : universities have a common pool, the National Library (BNF) provides a cdrom with 4 millions of UNIMARC notices, and Electre provide a commercial one with recent books. So most ils separate acquisition and cataloguing, as librarians "spend not more than 10 mn a week on cataloguing" as mailed me a french koha-addict ! Let's continue your answers/ideas/... on this topic, i'll conclude and propose something (on the wiki) next week. you'll be informed of my proposal when ready, and get the opportunity to comment it too ! Note : i plan to do something SIMPLE (from a developping time point of vue) for the 2.0 release which should occur in a month (at least for a RC one) In 2.0.1, I expect to improve it (i WILL improve it if it's funded by someone !) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Hi everybody, Here is Paul, from the old Europe ;-) i just spended 20mn to read all those answers to my request, and I'm not happy because what i've read is NOT RELATED to my question. 1st : my question was a LIBRARIAN question. And i think almost all answers are related to DEVELOPPERS problems ! 2nd : my question was to imagine a solution to get the best possible acquisition and cataloguing process ! not to do a code -or db- revolution in koha ! and what are you speaking about ? DB normalization, and other -interesting but not in the scope- question. The most interesting thought, imho, comes from Stephen, from NPL (which funded MARC support, so, is always right :-) ) I think that a strong acquisition component would be a very valuable asset for Koha. In fact, I think acquisitions are much more important than cataloging. That means that I support your idea of separating the two, so it would be easier (to my mind) to focus development effort on acquisitions. If they are not separated, then I think cataloging should at least be handled as a sub-task of acquisitions. Incidentally, this is my opinion too :-) So, my proposal for acquisition and cataloguing is the following : *ACQUISITION* During acquisition, you define as few datas as possible. You can define less than ISBN, title, author and editor if you want. The acquisition part does NOT deals with marc (ie : from a librarian point of vue. the mySQL DB is something else !). when the book is recieved, the librarian will note this in the acquisition part of koha, then, will automatically reach the cataloguing chapter This WILL be in the 2.0, it's almost the normal acquisition of the 1.2. this acquisition process will be the same wether MARC or non-MARC. Acquisition in a future will also get : - suggestions *CATALOGUING* - The library can use MARC or non MARC cataloguing. - The cataloguing can be called after an acquisition, or as a specific and single task - The cataloguing means : entering biblio and entering items. All those will be in the 2.0. It's part from acqui.simple in MARC for MARC, and part from normal acquisition of the 1.2 cataloguing in a future version will also get : - z39.50 support - import of "commercial" MARC cdroms like "electre" or "Rameau", in France. I think that everybody agrees to say that books that will arrive soon in the library can be shown on opac or catalogue search part of koha, with a specific flag. So, that will be done too. I hope that at least every LIBRARIAN will be happy with those proposals. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Paul As someone using koha for a smallish(~30,000 volume) more or less private library I would like to belatedly add three extra low priority wish list feature requests that I haven't seen discussed: 1. A way to use koha to order from book sellers that we have a standing relationship with ( Amazon.com or Powells.com for example ) 2. the opac in xhtml so that someone contemplating an acquisition at a book store could see if the book is already in the library via internet enabled phone. Having the acquisition in xhtml would not help me, because there is no way the book will get entered in the catalog until it arrives in the library. This is probably not something that larger libraries care about, but would be nice for personal libraries. 3. The ability to add items without a barcode. so that barcodes don't have to be set aside for books that have not yet arrived. (This may already exist but I'm not aware of it. This would be of greater importance if acquisitions was in xhtml and there was a chance that someone would add a book from their cell phone. But others might find it useful. Note: A webpage has to be written in valid xhtml to be readable by cell phones that are advertised as "Internet Ready" in the USA. So people can read "accessible by cell phone" for "xhtml". Micheas On Fri, 2003-01-24 at 02:31, paul POULAIN wrote:
Hi everybody, Here is Paul, from the old Europe ;-)
i just spended 20mn to read all those answers to my request, and I'm not happy because what i've read is NOT RELATED to my question.
1st : my question was a LIBRARIAN question. And i think almost all answers are related to DEVELOPPERS problems ! 2nd : my question was to imagine a solution to get the best possible acquisition and cataloguing process ! not to do a code -or db- revolution in koha !
and what are you speaking about ? DB normalization, and other -interesting but not in the scope- question.
The most interesting thought, imho, comes from Stephen, from NPL (which funded MARC support, so, is always right :-) )
I think that a strong acquisition component would be a very valuable asset for Koha. In fact, I think acquisitions are much more important than cataloging. That means that I support your idea of separating the two, so it would be easier (to my mind) to focus development effort on acquisitions. If they are not separated, then I think cataloging should at least be handled as a sub-task of acquisitions.
Incidentally, this is my opinion too :-)
So, my proposal for acquisition and cataloguing is the following : *ACQUISITION* During acquisition, you define as few datas as possible. You can define less than ISBN, title, author and editor if you want. The acquisition part does NOT deals with marc (ie : from a librarian point of vue. the mySQL DB is something else !). when the book is recieved, the librarian will note this in the acquisition part of koha, then, will automatically reach the cataloguing chapter This WILL be in the 2.0, it's almost the normal acquisition of the 1.2. this acquisition process will be the same wether MARC or non-MARC.
Acquisition in a future will also get : - suggestions
*CATALOGUING* - The library can use MARC or non MARC cataloguing. - The cataloguing can be called after an acquisition, or as a specific and single task - The cataloguing means : entering biblio and entering items.
All those will be in the 2.0. It's part from acqui.simple in MARC for MARC, and part from normal acquisition of the 1.2
cataloguing in a future version will also get : - z39.50 support - import of "commercial" MARC cdroms like "electre" or "Rameau", in France.
I think that everybody agrees to say that books that will arrive soon in the library can be shown on opac or catalogue search part of koha, with a specific flag. So, that will be done too.
I hope that at least every LIBRARIAN will be happy with those proposals.
Micheas Herman a écrit:
Paul
As someone using koha for a smallish(~30,000 volume) more or less private library I would like to belatedly add three extra low priority wish list feature requests that I haven't seen discussed:
low priority wishes, maybe, but that's the kind of idea the managers team always take care of !
1. A way to use koha to order from book sellers that we have a standing relationship with ( Amazon.com or Powells.com for
example )
do you mean "electronic orders" here ? if yes, that's something we already spoke about some months ago. Not planned at all, anyway. If funded by a bookseller, could be quickly added :-)
2. the opac in xhtml so that someone contemplating an acquisition at a book store could see if the book is already in the library via internet enabled phone. Having the acquisition in xhtml would not help me, because there is no way the book will get entered in the catalog until it arrives in the library. This is probably not something that larger libraries care about, but would be nice for personal libraries.
The 2.0 will include a full-templated koha. This means it will be possible (and not too hard) to add as many themes as needed. Thus, anybody could develop a xhtml theme, or even a full-xml theme, or anything else. This is with templates too that we can translate koha in any language
3. The ability to add items without a barcode. so that barcodes don't have to be set aside for books that have not yet arrived. (This may already exist but I'm not aware of it. This would be of greater importance if acquisitions was in xhtml and there was a chance that someone would add a book from their cell phone. But others might find it useful.
strange thing indeed. Does someone else have something like this ? Don't you misunderstood what means : "patrons should be able to find biblios without items in the opac, to see that the book will arrive soon ", as i think it's what you ask for ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (14)
-
Albert P. Calame -
Chris Cormack -
Christopher Hicks -
Enrico Silterra -
Jean Truebridge -
Joshua Ferraro -
Marco Gaiarin -
Micheas Herman -
Nicholas S. Rosasco -
Pat Eyler -
paul POULAIN -
Rachel Hamilton-Williams -
Regula Sebastiao -
Tonnesen Steve