The future of Koha (some ideas and thoughts) [IMPORTANT] (I hope) and [LONG] (not so)
Hello all, I was in Paris yesterday (what does not justify a mail on koha-devel, I agree ;-) ), and was thinking to the future of Koha in the TGV (3hours to do 850km !) I suddenly realized that, with the architecture we are working on for Koha 3.0, we were on the way to develop what I call "Koha-Suite". I mean in Koha 3.0, we will have : * a web portal. (Our actual OPAC) * a tool to store large datas (Zebra) * all ILS features. We spoke once to have RSS feeds in OPAC, I'm sure that's a great idea that could be implemented quite easily in Koha and highly improve OPAC use & utility. Once rss feeds will be availabe in OPAC, we could consider Koha interfaced with any CMS, as most actual CMS are providing rss feeds. We could imagine "rss boxes" in main page as well as in opac-user page. Just a suggestion for instance, it's not done (except in some argentinian code, iirc) So we have a software in 4 parts. All of them can be modularized to consider we have 4 differents bricks that can be foundation of a complete document-oriented-suite. What we could add later is : * a brick to manage electronic document (like thesis & internal production of the user-company) Internal docs as well as OpenArchive harvester. * a brick to index external sources, that could be sorted & analyzed to do a knowledge DB (in french, it's "veille technologique", that I don't know how to translate. I mean : a tool that automatically check some databases daily, compute summaries on accurate documents, and send them to users) Of course, the 2 later bricks won't be written in a day or 2. Not even in this month. And probably not for 3.0 But I'm sure (& hope you will confirm) that it's the way to go. If confirmed, then Koha developpers will have to write all 3.0 stuff with this goal in mind, on the long term. It means having a code structure modular enough to be able to install a brick without all the others. Just one technical proposal, about code organization : We could have, under koha-cvs, one directory for each brick : * /opac/ for web portal (yes, we already have it !!!) * /core/ for the common and core scripts (I think actual modules : parameters, reports and members) * /ils/ for ils part of Koha suite (I think actual acquisition, cataloguing, circulation, authorities) * /XXX/ for electronic docs management (new brick, does not exist yet) * /YYY/ for external source (KB) (new brick too) * The /C4/ directory contains every core Perl packages and will be a common tool, used by every brick, so it can stay on top level of CVS org. With such an architecture it would be easy to release specific packages, for "Koha ILS-only", "Koha KB-only", "Koha ILS and electronic doc management" ... I have created a little scheme to explain my idea (maybe a basis for a future marketing document ;-) ) You can find it on : http://___www___.paulpoulain.com/Koha_futur.pdf (remove the trailing ___ before and after www, I just want this link not to be indexed by google) Don't distribute this doc outside from this list for instance pls, it's my idea, not the Koha team decision ;-) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On Fri, Sep 02, 2005 at 03:44:03PM +0200, Paul POULAIN wrote:
It means having a code structure modular enough to be able to install a brick without all the others.
Just one technical proposal, about code organization : We could have, under koha-cvs, one directory for each brick : * /opac/ for web portal (yes, we already have it !!!) * /core/ for the common and core scripts (I think actual modules : parameters, reports and members) * /ils/ for ils part of Koha suite (I think actual acquisition, cataloguing, circulation, authorities) * /XXX/ for electronic docs management (new brick, does not exist yet) * /YYY/ for external source (KB) (new brick too) * The /C4/ directory contains every core Perl packages and will be a common tool, used by every brick, so it can stay on top level of CVS org.
I've recently been investigating Catalyst (http://catalyst.perl.org) for work and personal projects. It is a very nice framework, with separation of application flow, data management, and layout. It is very flexible, and does not constrain a project to certain sets of CPAN modules, though there are plugins to help with some of the more common tools. It is also architected so that an application may run under CGI, mod_perl 1, or mod_perl 2, which I find nice for development. -kolibrie
Nathan Gray <kolibrie@southernvirginia.edu> wrote:
I've recently been investigating Catalyst (http://catalyst.perl.org) for work and personal projects. [...] It is very flexible, and does not constrain a project to certain sets of CPAN modules [...]
I quite like Rails-like systems, but I'm still exploring them. I investigated Catalyst a while ago and the very long list of required modules put me off. http://dev.catalyst.perl.org/wiki/HowToGet suggests that it's still the same (see the debs required). Has it changed? Regards, -- MJ Ray (slef), K. Lynn, England, email see http://mjr.towers.org.uk/
On Fri, Sep 02, 2005 at 04:52:56PM +0100, MJ Ray wrote:
Nathan Gray <kolibrie@southernvirginia.edu> wrote:
I've recently been investigating Catalyst (http://catalyst.perl.org) for work and personal projects. [...] It is very flexible, and does not constrain a project to certain sets of CPAN modules [...]
I quite like Rails-like systems, but I'm still exploring them. I investigated Catalyst a while ago and the very long list of required modules put me off. http://dev.catalyst.perl.org/wiki/HowToGet suggests that it's still the same (see the debs required). Has it changed?
Well, that list of debs seems a bit longer than necessary. I only have nine of those 25 installed, and I think it would be less if I were not using Template Toolkit. -kolibrie
Fantastic ideas Paul! I think you're absolutely right, we need to start thinking in terms of a 'koha suite' with the ILS as just one component in a larger framework. Some of my ideas for things that could be included: Inventory management Scheduling management Full-text document storage and retrieval (Zebra makes this easy) Computer scheduling (so patrons can sign up for computers, etc.) These kinds of value-added features will make Koha really stand out compared to other ILS products. More modularization of the code base will make it easier to incorporate new modules. I think we should go for it! -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
I agree. Furthermore, there are some significant advocates for disintegrating integrated library systems. An integrated library system seems to discourage adding features and interoperating well with other systems. Modules and major components should be fully modularised so that they can play as well as possible with others. Some ILS vendors already market favoured modules from their ILS systems for using as an add on to another company's ILS. Koha is much more likely to succeed at being installed in libraries if the ILS is not an all or nothing installation. It is not already all or nothing at the largest library using Koha. NPL uses ITS MARC for Windows for cataloguing. Koha needs to be able to do the same for using any module or major component with another ILS. That may go well beyond a direction for 3.0 but should be developed for some future version. Libraries should be free to choose the best modules from many systems to create their ILS or Library Application Suite. Even if modules work best together with other modules from the same integrated system, they should also work independently perfectly well. As long as common standards to exchange data are used mixing and matching modules between systems should be fine. Non-proprietary Unix, such as GN/Linux, did not succeed in corporate ILS departments by wholy replacing all computer systems at a corporation. It started by allowing the corporate IT department to fulfil one niche at a time with print servers, webservers, etc. Gradually the confidence developed for non- proprietary Unix to have wider adoption. Non-proprietary Unix has still not been comparably successful in the desktop systems market but that only reinforces the point about the advantages of not having an all or nothing approach to adopting Koha. Thomas D Quoting Joshua Ferraro <jmf@liblime.com> :
---------------- Beginning of the original message ------------------
Fantastic ideas Paul! I think you're absolutely right, we need to start thinking in terms of a 'koha suite' with the ILS as just one component in a larger framework. Some of my ideas for things that could be included:
Inventory management Scheduling management Full-text document storage and retrieval (Zebra makes this easy) Computer scheduling (so patrons can sign up for computers, etc.)
These kinds of value-added features will make Koha really stand out compared to other ILS products. More modularization of the code base will make it easier to incorporate new modules. I think we should go for it!
-- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
------------------- End of the original message ---------------------
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com
I'd like to reinforce Thomas' point about "disintegrating integrated library systems" (and also correct a small error). NPL now uses BookWhere instead of ITS MARC for cataloging materials -- which actually reinforces Thomas' point, because NPL was able to switch from one cataloging application to another without making changes to Koha. This was possible because both cataloging applications generate MARC records in a standard format (iso2709), and Koha can import those standardized records. However, Koha is only able to do the import after the records have been altered by a customized version of bulkmarcimport.pl. I believe I remember that Paul has already discussed the notion of rewriting the Koha cataloging code so that it generates files of records for import in batches, instead of adding each record as it is created (which is very slow). I think it would be wise to aim for doing this rewrite in such a way that it also makes it easy for a library to use their own cataloging utility. In other words, I suggest that we start the disintegration process with the cataloging module, making it a "stand-alone" application that _can_ be used with Koha, but may also be replaced with another cataloging application of the library's choosing. Stephen Thomas D said:
I agree. Furthermore, there are some significant advocates for disintegrating integrated library systems. An integrated library system seems to discourage adding features and interoperating well with other systems. Modules and major components should be fully modularised so that they can play as well as possible with others. Some ILS vendors already market favoured modules from their ILS systems for using as an add on to another company's ILS. Koha is much more likely to succeed at being installed in libraries if the ILS is not an all or nothing installation. It is not already all or nothing at the largest library using Koha. NPL uses ITS MARC for Windows for cataloguing. Koha needs to be able to do the same for using any module or major component with another ILS. That may go well beyond a direction for 3.0 but should be developed for some future version.
Libraries should be free to choose the best modules from many systems to create their ILS or Library Application Suite. Even if modules work best together with other modules from the same integrated system, they should also work independently perfectly well. As long as common standards to exchange data are used mixing and matching modules between systems should be fine.
Non-proprietary Unix, such as GN/Linux, did not succeed in corporate ILS departments by wholy replacing all computer systems at a corporation. It started by allowing the corporate IT department to fulfil one niche at a time with print servers, webservers, etc. Gradually the confidence developed for non- proprietary Unix to have wider adoption. Non-proprietary Unix has still not been comparably successful in the desktop systems market but that only reinforces the point about the advantages of not having an all or nothing approach to adopting Koha.
Thomas D
Quoting Joshua Ferraro <jmf@liblime.com> :
---------------- Beginning of the original message ------------------
Fantastic ideas Paul! I think you're absolutely right, we need to start thinking in terms of a 'koha suite' with the ILS as just one component in a larger framework. Some of my ideas for things that could be included:
Inventory management Scheduling management Full-text document storage and retrieval (Zebra makes this easy) Computer scheduling (so patrons can sign up for computers, etc.)
These kinds of value-added features will make Koha really stand out compared to other ILS products. More modularization of the code base will make it easier to incorporate new modules. I think we should go for it!
-- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
What alterations were done for the customised version of bulkmarcimport.pl at NPL? Thomas D Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message ------------------
I'd like to reinforce Thomas' point about "disintegrating integrated library systems" (and also correct a small error).
NPL now uses BookWhere instead of ITS MARC for cataloging materials -- which actually reinforces Thomas' point, because NPL was able to switch from one cataloging application to another without making changes to Koha. This was possible because both cataloging applications generate MARC records in a standard format (iso2709), and Koha can import those standardized records. However, Koha is only able to do the import after the records have been altered by a customized version of bulkmarcimport.pl.
I believe I remember that Paul has already discussed the notion of rewriting the Koha cataloging code so that it generates files of records for import in batches, instead of adding each record as it is created (which is very slow). I think it would be wise to aim for doing this rewrite in such a way that it also makes it easy for a library to use their own cataloging utility. In other words, I suggest that we start the disintegration process with the cataloging module, making it a "stand-alone" application that _can_ be used with Koha, but may also be replaced with another cataloging application of the library's choosing.
Stephen
I agree. Furthermore, there are some significant advocates for disintegrating integrated library systems. An integrated library system seems to discourage adding features and interoperating well with other systems. Modules and major components should be fully modularised so that they can play as well as possible with others. Some ILS vendors already market favoured modules from their ILS systems for using as an add on to another company's ILS. Koha is much more likely to succeed at being installed in
is not an all or nothing installation. It is not already all or nothing at the largest library using Koha. NPL uses ITS MARC for Windows for cataloguing. Koha needs to be able to do the same for using any module or major component with another ILS. That may go well beyond a direction for 3.0 but should be developed for some future version.
Libraries should be free to choose the best modules from many systems to create their ILS or Library Application Suite. Even if modules work best together with other modules from the same integrated system,
also work independently perfectly well. As long as common standards to exchange data are used mixing and matching modules between systems should be fine.
Non-proprietary Unix, such as GN/Linux, did not succeed in corporate ILS departments by wholy replacing all computer systems at a corporation. It started by allowing the corporate IT department to fulfil one niche at a time with print servers, webservers, etc. Gradually the confidence developed for non- proprietary Unix to have wider adoption. Non-proprietary Unix has still not been comparably successful in the desktop systems market but
Thomas D said: libraries if the ILS they should that only
reinforces the point about the advantages of not having an all or nothing approach to adopting Koha.
Thomas D
Quoting Joshua Ferraro <jmf@liblime.com> :
---------------- Beginning of the original message
Fantastic ideas Paul! I think you're absolutely right, we need to start thinking in terms of a 'koha suite' with the ILS as just one component in a larger framework. Some of my ideas for things that could be included:
Inventory management Scheduling management Full-text document storage and retrieval (Zebra makes this easy) Computer scheduling (so patrons can sign up for computers, etc.)
These kinds of value-added features will make Koha really stand out compared to other ILS products. More modularization of
code base will make it easier to incorporate new modules. I think we should go for it!
-- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training,
the maintenance,
support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------- End of the original message ---------------------
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com
Thomas D said:
What alterations were done for the customised version of bulkmarcimport.pl at NPL?
Some code was added to the beginning to re-write the MARC records (using MARC::Record) to split holdings information into two MARC tags instead of the normal single tag, so that some of the holdings data could be mapped to biblioitems and the rest to items. Stephen
Thomas D
Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message ------------------
I'd like to reinforce Thomas' point about "disintegrating integrated library systems" (and also correct a small error).
NPL now uses BookWhere instead of ITS MARC for cataloging materials -- which actually reinforces Thomas' point, because NPL was able to switch from one cataloging application to another without making changes to Koha. This was possible because both cataloging applications generate MARC records in a standard format (iso2709), and Koha can import those standardized records. However, Koha is only able to do the import after the records have been altered by a customized version of bulkmarcimport.pl.
I believe I remember that Paul has already discussed the notion of rewriting the Koha cataloging code so that it generates files of records for import in batches, instead of adding each record as it is created (which is very slow). I think it would be wise to aim for doing this rewrite in such a way that it also makes it easy for a library to use their own cataloging utility. In other words, I suggest that we start the disintegration process with the cataloging module, making it a "stand-alone" application that _can_ be used with Koha, but may also be replaced with another cataloging application of the library's choosing.
Stephen
I agree. Furthermore, there are some significant advocates for disintegrating integrated library systems. An integrated library system seems to discourage adding features and interoperating well with other systems. Modules and major components should be fully modularised so that they can play as well as possible with others. Some ILS vendors already market favoured modules from their ILS systems for using as an add on to another company's ILS. Koha is much more likely to succeed at being installed in
is not an all or nothing installation. It is not already all or nothing at the largest library using Koha. NPL uses ITS MARC for Windows for cataloguing. Koha needs to be able to do the same for using any module or major component with another ILS. That may go well beyond a direction for 3.0 but should be developed for some future version.
Libraries should be free to choose the best modules from many systems to create their ILS or Library Application Suite. Even if modules work best together with other modules from the same integrated system,
also work independently perfectly well. As long as common standards to exchange data are used mixing and matching modules between systems should be fine.
Non-proprietary Unix, such as GN/Linux, did not succeed in corporate ILS departments by wholy replacing all computer systems at a corporation. It started by allowing the corporate IT department to fulfil one niche at a time with print servers, webservers, etc. Gradually the confidence developed for non- proprietary Unix to have wider adoption. Non-proprietary Unix has still not been comparably successful in the desktop systems market but
Thomas D said: libraries if the ILS they should that only
reinforces the point about the advantages of not having an all or nothing approach to adopting Koha.
Thomas D
Quoting Joshua Ferraro <jmf@liblime.com> :
---------------- Beginning of the original message
Fantastic ideas Paul! I think you're absolutely right, we need to start thinking in terms of a 'koha suite' with the ILS as just one component in a larger framework. Some of my ideas for things that could be included:
Inventory management Scheduling management Full-text document storage and retrieval (Zebra makes this easy) Computer scheduling (so patrons can sign up for computers, etc.)
These kinds of value-added features will make Koha really stand out compared to other ILS products. More modularization of
code base will make it easier to incorporate new modules. I think we should go for it!
-- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training,
the maintenance,
support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------- End of the original message ---------------------
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
What holdings data does NPL map to the biblioitems table? Thomas D Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message ------------------
Thomas D said:
What alterations were done for the customised version of bulkmarcimport.pl at NPL?
Some code was added to the beginning to re-write the MARC records (using MARC::Record) to split holdings information into two MARC tags instead of the normal single tag, so that some of the holdings data could be mapped to biblioitems and the rest to items.
Stephen
Thomas D
Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message
I'd like to reinforce Thomas' point about "disintegrating integrated library systems" (and also correct a small error).
NPL now uses BookWhere instead of ITS MARC for cataloging materials -- which actually reinforces Thomas' point, because NPL was
able
to switch from one cataloging application to another without making changes to Koha. This was possible because both cataloging applications generate MARC records in a standard format (iso2709), and Koha can import those standardized records. However, Koha is only able to do the import after the records have been altered by a customized version of bulkmarcimport.pl.
I believe I remember that Paul has already discussed the notion of rewriting the Koha cataloging code so that it generates files of records for import in batches, instead of adding each record as it is created (which is very slow). I think it would be wise to aim for doing this rewrite in such a way that it also makes it easy for a
to use their own cataloging utility. In other words, I suggest
we start the disintegration process with the cataloging module, making it a "stand-alone" application that _can_ be used with Koha, but may also be replaced with another cataloging application of the
------------------ library that library's
choosing.
Stephen
[snip]
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------- End of the original message ---------------------
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com
Thomas D said:
What holdings data does NPL map to the biblioitems table?
Thomas D
942 $c (item type) and 942 $k (dewey) -- here's the complete biblioitems mapping: biblioitemnumber --> 090 $d (Koha biblioitemnumber) biblionumber volume --> 440 $v (Volume number/sequential designation) number --> 440 $n (Number of part/section of a work) classification --> 942 $k (dewey) itemtype --> 942 $c (item type) isbn --> 020 $a (International Standard Book Number) issn --> 022 $a (International Standard Serial Number) dewey subclass publicationyear publishercode --> 260 $b (Name of publisher, distributor, etc) volumedate volumeddesc timestamp illus --> 300 $b (Other physical details) pages --> 300 $a (Extent) notes size --> 300 $c (Dimensions) place --> 260 $a (Place of publication, distribution, etc) url --> 856 $u (Uniform Resource Identifier) lccn --> 010 $a (LC control number) marc
Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message ------------------
Thomas D said:
What alterations were done for the customised version of bulkmarcimport.pl at NPL?
Some code was added to the beginning to re-write the MARC records (using MARC::Record) to split holdings information into two MARC tags instead of the normal single tag, so that some of the holdings data could be mapped to biblioitems and the rest to items.
Stephen
Thomas D
Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message
I'd like to reinforce Thomas' point about "disintegrating integrated library systems" (and also correct a small error).
NPL now uses BookWhere instead of ITS MARC for cataloging materials -- which actually reinforces Thomas' point, because NPL was
able
to switch from one cataloging application to another without making changes to Koha. This was possible because both cataloging applications generate MARC records in a standard format (iso2709), and Koha can import those standardized records. However, Koha is only able to do the import after the records have been altered by a customized version of bulkmarcimport.pl.
I believe I remember that Paul has already discussed the notion of rewriting the Koha cataloging code so that it generates files of records for import in batches, instead of adding each record as it is created (which is very slow). I think it would be wise to aim for doing this rewrite in such a way that it also makes it easy for a
to use their own cataloging utility. In other words, I suggest
we start the disintegration process with the cataloging module, making it a "stand-alone" application that _can_ be used with Koha, but may also be replaced with another cataloging application of the
------------------ library that library's
choosing.
Stephen
[snip]
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------- End of the original message ---------------------
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
The call number related columns from the biblioitems table, such as biblioitems.dewey, would not be needed in Koha provided that the templates are changed to use items.itemcallnumber. Biblioitems.itemtype is a flexible field with multiple uses in non-MARC Koha. Unfortunately, the one to one relationship between the biblio, biblioitems, and items tables required for MARC Koha has undermined that flexible utility for biblioitems.itemtype. Circulatioon rules are usually tied to a media format and binding based itemtype. Non-MARC Koha, allows multiple biblioitems for each item. Items can switch itemtypes for an item as needed. MARC Koha provides no interface for changing the itemtype to accommodate a need to change the circulation rules for that item only without changing the circulation rules for every other item common to that itemtype as well. Both MARC and non-MARC Koha need a more flexible approach to these issues. Circulation rules need to be set for the item in the items table. Separate columns are needed to specify format, binding, audience and whatever else for which biblioitems.itemtype has been used in Koha. A means of grouping this information by assigning defaults based on other items for that biblio could preserve the advantage of grouping by biblioitems.itemtype. There should be no need to tie a circulation rule to a media format or binding. Tying circulation rules in that way is a decetpive convenience that leads to an unnecessarily inflexible data model. Thomas D Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message ------------------
Thomas D said:
What holdings data does NPL map to the biblioitems table?
Thomas D
942 $c (item type) and 942 $k (dewey) -- here's the complete biblioitems mapping:
biblioitemnumber --> 090 $d (Koha biblioitemnumber) biblionumber volume --> 440 $v (Volume number/sequential designation) number --> 440 $n (Number of part/section of a work) classification --> 942 $k (dewey) itemtype --> 942 $c (item type) isbn --> 020 $a (International Standard Book Number) issn --> 022 $a (International Standard Serial Number) dewey subclass publicationyear publishercode --> 260 $b (Name of publisher, distributor, etc) volumedate volumeddesc timestamp illus --> 300 $b (Other physical details) pages --> 300 $a (Extent) notes size --> 300 $c (Dimensions) place --> 260 $a (Place of publication, distribution, etc) url --> 856 $u (Uniform Resource Identifier) lccn --> 010 $a (LC control number) marc
Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message
Thomas D said:
What alterations were done for the customised version of bulkmarcimport.pl at NPL?
Some code was added to the beginning to re-write the MARC records (using MARC::Record) to split holdings information into two MARC
tags
instead of the normal single tag, so that some of the holdings data could be mapped to biblioitems and the rest to items.
Stephen
Thomas D
Quoting Stephen Hedges <shedges@skemotah.com> :
---------------- Beginning of the original message
------------------
I'd like to reinforce Thomas' point about
"disintegrating
integrated library systems" (and also correct a small error).
NPL now uses BookWhere instead of ITS MARC for cataloging materials -- which actually reinforces Thomas' point, because NPL was able to switch from one cataloging application to another without making changes to Koha. This was possible because both cataloging applications generate MARC records in a standard format (iso2709), and Koha can import those standardized records. However, Koha is only able to do
------------------ the
import after the records have been altered by a customized version of bulkmarcimport.pl.
I believe I remember that Paul has already discussed the notion of rewriting the Koha cataloging code so that it generates files of records for import in batches, instead of adding each record as it is created (which is very slow). I think it would be wise to aim for doing this rewrite in such a way that it also makes it easy for a library to use their own cataloging utility. In other words, I suggest that we start the disintegration process with the cataloging module, making it a "stand-alone" application that _can_ be used with Koha, but may also be replaced with another cataloging application of the library's choosing.
Stephen
[snip]
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------- End of the original message
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium
services
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
------------------- End of the original message ---------------------
--------------------------------------------- Protect your mails from viruses thanks to Alinto Premium services http://www.alinto.com
Thomas D a écrit :
The call number related columns from the biblioitems table, such as biblioitems.dewey, would not be needed in Koha provided that the templates are changed to use items.itemcallnumber.
You're 100% right here. I needed a long time to understand how. Let me explain : to define a "book", you have 2 differents things : - it's classification => meaning what the book is related to. Many libraries uses dewey, but not all. Many uses lccn (not in France), or another classification (for example : ams for mathematical libraries) - it's physical location in shelves => the "callnumber". The difficulty here is that most libraries, and they are right, have callnumbered theirs "books" like they have classified them. So, classification = callnumber. But that's not the same concept : * a single book (= 1 callnumber) can have X classifications in some cases (= some subjects) * X books can have the same callnumber, or differents callnumbers, even if they have a single classification (=when the library has a callnumber not 100% related to classification) That's why I introduced itemcallnumber in Koha 2.2 branch. We need a CLASSIFICATION at the biblio level and a CALLNUMBER at the item level ! Usually they contain the same information, that's why there is a systempref where you can say "ok, computer, automatically report subfield XXXy from biblio into item when adding an item". And, imho, in the opac pages we should not mix classification & callnumber informations. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
participants (6)
-
Joshua Ferraro -
MJ Ray -
Nathan Gray -
Paul POULAIN -
Stephen Hedges -
Thomas D