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@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 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.
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@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@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
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
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@gmail.com On 9/7/05, Thomas D <koha@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@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@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@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@indiana.edu pager: (812) 335-7403
I second this idea too. MARC data is for bibliography purpose only. The status data should keep on another database. 2005/9/7, Spencer Anspach <sanspach@gmail.com>:
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@gmail.com
On 9/7/05, Thomas D <koha@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@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@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
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@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@indiana.edu pager: (812) 335-7403
-- Best regards ë�c��, Anthony Mao, mao at lins dot fju dot edu dot tw ICQ 30941847 Department of Library and Information Science http://www.lins.fju.edu.tw/mao/index.htm TEL +886 2 29052334, FAX +886 2 29017405 Fu-jen Catholic University, Taipei, Taiwan, R.O.C.
Is there a way of separating out a "true" MARC record and keeping up to date it as an XML object, sort of an XML mirror of the tables and fields where the work is actually happening? Would that be useful or practical? -Lars Quoting Thomas D <koha@alinto.com>:
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
---------------------------------------------------------------- This mail sent through L-secure: http://www.l-secure.net/
lars@rovaniemelainen.com wrote:
Is there a way of separating out a "true" MARC record and keeping up to date it as an XML object, sort of an XML mirror of the tables and fields where the work is actually happening? Would that be useful or practical?
Thats pretty much exactly what we have in mind for 3.0 Well something pretty close anyway. I think its by far the most efficient way to do it. And with zebra we can search those marc records incredibly efficiently also. Chris -- Chris Cormack Katipo Communications Programmer www.katipo.co.nz 027 4500 789
participants (6)
-
Chris Cormack -
COURYHOUSE＠aol.com -
lars＠rovaniemelainen.com -
Spencer Anspach -
Thomas D -
毛�c��