[Koha-devel] Koha Statuses and MARC?

Wed Sep 7 05:00:06 CEST 2005

I want to strongly support this idea. The status data need not be stored in 
MARC, as I see it, as long as there's a way to import it (as Joshua 
proposes) and a way to export it as Thomas suggests. As long as it can be 
made transparent going in and coming out, there's no real downside to not 
actually storing the status information within the MARC record.
 Spencer M. Anspach
sanspach at gmail.com

 On 9/7/05, Thomas D <koha at alinto.com> wrote: 
> 
> Koha is not ready yet for standards compliant holdings. That would hardly
> make Koha unusual for library systems.
> 
> However it is done, I do believe that all information that can be should 
> be
> recorded in MARC. If real time updates to status in the MARC would
> compromise system performance, then use a corresponding more efficiently
> updated items.status. The status should still be updated in the MARC 
> record
> as either part of a batch process, or part of a script that builds the
> complete record upon record export. Either of these procedures should 
> allow
> status information to be stored in the record at least upon export or 
> demand
> without adversely affecting system performance.
> 
> If a build upon export procedure is used, then that should include export
> for the Z39.50 server in addition to the export script.
> 
> 
> Thomas D
> 
> Quoting COURYHOUSE at aol.com :
> > ---------------- Beginning of the original message ------------------
> >
> >
> > The best thing is to keep MARC as standard as you can...
> >
> > Ed Sharpe archivist for SMECC.
> >
> >
> >
> >
> >
> > > Paul et al,
> > >
> > > In Paul's proposed scheme for item statuses, the
> > items.notforloan
> > > field is linked to MARC field 942$k and then an authorized
> > value
> > > is set for that field (defined by the library). Before we
> > invest
> > > too much development energy on this idea I'd like to
> > question
> > > whether it's even a good idea to store status information in
> > the
> > > MARC record, especially we we move toward using Zebra to
> > store our
> > > textual (MARC) database.
> > >
> > > Stephen and I spoke earlier today and he's got me thinking
> > that maybe
> > > it's not such a good idea to store statuses in MARC. MARC
> > wasn't
> > > really designed for anything but the static record
> > information. It's
> > > ill-suited for transactional based data such as statuses.
> > >
> > > I propose that for Koha 3.0 we create a new field in the
> > Koha tables
> > > called 'items.status'. items.status can be a numeric value
> > and have
> > > a set of library-defined authorized values. We can then add
> > a framework
> > > for setting those values that a library must setup when they
> > install
> > > the system. For instance, it should be possible to set Koha
> > to
> > > automatically set an items status to 'in transit' when an
> > item is
> > > on reserve to a patron in a branch other than the
> > holdingbranch (when
> > > the item is returned) and 'waiting' when it arrives and is
> > scanned.
> > > But the goal would be to make this a setting that the
> > library could
> > > define when setting Koha up, a set of 'status rules'.
> > >
> > > Comments, suggestions, volunteers?
> > >
> > > Cheers,
> > > --
> > > 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
> >
> >
> > Thanks,
> >
> > Ed Sharpe, Archivist for SMECC
> >
> > See the Museum's Web Site at www.smecc.org <http://www.smecc.org>
> >
> > We are always looking for items to add to the museum's display
> > and ref.
> > library - please advise if you have anything we can use.
> >
> > Coury House / SMECC
> > 5802 W. Palmaire Ave. Phone
> > 623-435-1522
> > Glendale Az 85301 USA
> >
> >
> >
> >
> > CONFIDENZIALE: Questo messaggio e gli eventuali allegati sono
> > confidenziali
> > e riservati. Se vi è stato recapitato per errore e non siete
> > fra i
> > destinatari elencati, siete pregati di darne immediatamente
> > avviso al
> > mittente. Le informazioni contenute non devono essere mostrate
> > ad altri, né
> > utilizzate, memorizzate o copiate in qualsiasi forma.
> >
> > CONFIDENTIAL: This e-mail and any attachments are
> > confidential and may
> > contain reserved information. If you are not one of the named
> > recipients,
> > please notify the sender immediately. Moreover, you should not
> > disclose the
> > contents to any other persons, nor should the information
> > contained be used
> > for any purpose or stored or copied in any form.
> >
> >
> > ------------------- End of the original message ---------------------
> 
> 
> 
> 
> ---------------------------------------------
> Protect your mails from viruses thanks to Alinto Premium services 
> http://www.alinto.com
> 
> 
> -------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/koha-devel
> 

-- 
Spencer M. Anspach, Library Systems Analyst/Programmer
Library Information Technology, Indiana University
Library E456 phone: (812) 856-5318
Bloomington, IN 47405 fax: (812) 856-4979
sanspach at indiana.edu pager: (812) 335-7403
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20050907/1771a535/attachment-0002.htm>