[Koha-devel] The future of Koha (some ideas and thoughts)

[Stephen Hedges]

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 at 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
>>
>> 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 at 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 at liblime.com |Full Demos at http://liblime.com/koha
>> >> |1(888)KohaILS
>> >>
>>
>> --
>> Stephen Hedges
>> Skemotah Solutions, USA
>> www.skemotah.com  --  shedges at 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 at skemotah.com