<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<blockquote type="cite"
 cite="mid200204151155.g3FBtnJ21806@alma.athenscounty.lib.oh.us">
  <pre wrap=""><br></pre>
</blockquote>
Stephen Hedges wrote: <br>
 <br>
<blockquote type="cite">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you're a little tired of looking
for errors in scripts, how about a  philosophical question -- how many different
kohas should there be? <br>
 <br>
</blockquote>
One, and only one <img src="chrome://editor/content/images/wink_n.gif"
 alt=";-)" class="moz-txt-smily" height="19" width="19" align="middle">
 <br>
 <br>
<blockquote type="cite">I've noticed that there are some significant differences
in what libraries from  different areas of the world expect their software
to do.&nbsp; For instance, while  ten-digit barcodes seem to work well in the
South Pacific, in the US (and  Canada?) the fourteen-digit barcode for both
book ID and 'member' ID seems to  be becoming a de facto standard.&nbsp; And then
there's the whole MARC record  discussion -- just whose MARC format are we
discussing?&nbsp; There's Paul's MARC  standard in France, there's USMARC, and
I get the feeling MARC may not really  be all that important Down Under.&nbsp;
And while tracking and storing information  about ethnicity is necessary
in New Zealand, most libraries in the States would  find that idea disturbing. 
  <br>
 <br>
</blockquote>
Note the "Paul's MARC standard" is UNIMARC. It means unified MARC. There
 are only a few differences with USMARC. In fact, USMARC is UNIMARC  compliant,
but UNIMARC is not USMARC compliant. (note I may be wrong  here, as I'm not
fully aware) <br>
 <br>
&lt;SNIP&gt; <br>
<br>
<blockquote type="cite">Let's use our library (Nelsonville Public Library,
Nelsonville, Ohio, USA) to  illustrate my point.&nbsp; We have been investigating
the possibility of using koha  to replace our current Sanderson system.&nbsp;
In listing the things we would need  to change to make koha work for us,
we so far have identified: <br>
- lengthen the barcode fields <br>
- accomodate batch imports and exports of bibliographic records in USMARC
 format <br>
 <br>
</blockquote>
It's a MUST have for the next version. I think we must find a way to  import
USMARC as well as UNIMARC. I've a few UNIMARC files,&nbsp;&nbsp; but  haven't time
to test with the current MARC support. Note I'll be back on  koha (half to
full time) in around 10 days <img
 src="chrome://editor/content/images/wink_n.gif" alt=";-)"
 class="moz-txt-smily" height="19" width="19" align="middle">
 <br>
 <br>
<blockquote type="cite">&nbsp;- do away with the ethnicity fields <br>
 <br>
</blockquote>
Not important I think. If you don't mind this field, ignore it <img
 src="chrome://editor/content/images/wink_n.gif" alt=";-)"
 class="moz-txt-smily" height="19" width="19" align="middle">
 In  france, it's strictly forbidden to store such a value (as such a file
 gave some help to nazis during 2nd world war)... <br>
 <br>
<blockquote type="cite">&nbsp;- add support for the Z39.50 protocol to allow us
to share catalog records  with other libraries in the state of Ohio <br>
 <br>
</blockquote>
OK with you. Z39.50 is the same all around the world <img
 src="chrome://editor/content/images/wink_n.gif" alt=";-)"
 class="moz-txt-smily" height="19" width="19" align="middle">
 <br>
<blockquote type="cite">&nbsp;- and add support for the NISO Circulation Interchange
Protocol (NCIP) to  allow us to share user records with other libraries (and
thus participate in  the statewide resource sharing system). <br>
 <br>
</blockquote>
We need a plug-in system for sharing more than biblioitems I think,  because
sharing is VERY important for libraries all around the world. <br>
I've no idea if there is such a standard in France. I will search. <br>
 <br>
<blockquote type="cite">While these modifications are necessary to make koha
a viable alternative for  our library, they would be useless for Paul Poulain's
library (or Roger Buck's  library, or Steve Tonnessen's library, etc., etc.)&nbsp;
So let's put my original  question a little differently -- is one version
of koha enough?&nbsp; Maybe there  should be groups in different areas of the
world working to develop regional  versions of koha.&nbsp; Or has that happened
already and we just aren't hearing  anything about it? <br>
 <br>
</blockquote>
In some cases, we could have a parameter to decide if yes or no  something
is used. It's harder to code, but HIGHLY easier to maintain... <br>
In other cases, we must explain the users that we can't modify everything. 
<br>
 <br>
It's a BIG problem in open-source : every modification can be done. but  some
modifications causes my version to be no more upgrabale with the  "standard"
one, so any evolutions in the "standard" version must be  checked and corrected
to fit my own modifications. That's why I think we  must have only 1 version,
even if it causes some dis-agreements (not  sure of this word in&nbsp; english
?) <br>
In the long time, it REALLY BETTER. <br>
-- <br>
Paul <br>
<br>
</body>
</html>