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