[OPEN-ILS-GENERAL] Upcoming Documentation Interest Group Meeting: Thursday May 1st, 2014

[Yamil Suarez]

Hello everyone,

The Evergreen Documentation Interest Group has its next meeting
scheduled for Thursday, May 1st, 2014 at 2:00 PM EST on the
#EvergreenIRC channel (http://evergreen-ils.org/irc.php).

Anyone interested in documentation is welcome to attend. An agenda has
been posted at 
http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meetings

Changes and additions to the agenda are welcome.


Here are the links to access the Meetbot formatted minutes of the
previous meeting.

(Meetbot) Minutes:
http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-10-14.00.html

IRC Log:
http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-04-10-14.00.log.html


Thanks,
Yamil

Re: [OPEN-ILS-GENERAL] Non-unique Dewey call numbers with spaces rather than periods

[Linda Jansova]

Thank you, Dan! Your hint with the bib record with two versions of the 
same call number has helped us find the right way to proceed (four 
remaining troublesome records will be dealt with manually :-):


evergreen=# UPDATE asset.call_number SET label = replace(label, '.', '-');
UPDATE 10355
evergreen=# UPDATE asset.call_number SET label = replace(label, ' ', '.');
UPDATE 10355
evergreen=# UPDATE asset.call_number SET label = replace(label, '-', '.');
ERROR:  duplicate key value violates unique constraint 
"asset_call_number_label_once_per_lib"
DETAIL:  Key (record, owning_lib, label, prefix, suffix)=(5651, 4, 
248.84, -1, -1) already exists.


Linda

On 04/28/2014 03:26 PM, Dan Wells wrote:

Hello Linda,

I don't fully understand how you built your holdings, but it looks like you 
found something that worked for you.

Your update is failing on a record which already has both versions of the call 
number (correct with '.' and incorrect with 'space').  See here:

http://lib.etspraha.cz/eg/opac/record/4465?query=evangelical;qtype=keyword

If you manually merge those copies onto either call number, there is a chance 
your listed SQL query can succeed.  If not, you will need to determine how many 
records you have which already have a correct call number listed:

SELECT record,label FROM asset.call_number WHERE label LIKE '%.%';

That doesn't tell the whole story (i.e whether you have *both* types of call 
numbers on that record), but it's a quick way to see what you are up against.  
If it's just a few, I'd merge them manually.  Otherwise, I'd next do a JOIN to 
see how many actually have both types of call number.  If it is still a lot, 
working up a little script or even a more complex query to do the merging would 
be your best bet.

Sincerely,
Dan


Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133

-Original Message-
From: open-ils-general-boun...@list.georgialibraries.org 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Linda 
Jansova
Sent: Monday, April 28, 2014 1:56 AM
To: Evergreen Discussion Group
Subject: [OPEN-ILS-GENERAL] Non-unique Dewey call numbers with spaces rather 
than periods

Hi all,

We have imported bibliographic and holdings data of the Evangelical Theological 
Seminary library to Evergreen 2.5.3!

Yet, we have encountered the following problem (maybe a bit related to a recent 
discussion on Dewey normalization:
http://comments.gmane.org/gmane.education.libraries.open-ils.general/9661):

The library uses Dewey decimals as call numbers but these call numbers are not unique (no 
cutters are applied). In the OPAC, these data can be found as correctly imported in 
subfield "a" of the the 082 field (which means the data in MARCXML have been 
well preserved). But during the import, they were normalized in metabib.full_rec and call 
numbers are created from these data. There is no problem with padding zeroes as these 
have not been added but periods within the Dewey number have been overrided by spaces, 
e.g., http://lib.etspraha.cz/eg/opac/results?query=evangelical;qtype=keyword.

Therefore we have - unsuccessfully - tried to add the periods back but then the 
call numbers are expected to be unique which is not our case.
So an error has occured:

evergreen=# UPDATE asset.call_number SET label = replace(label, ' ', '.');
ERROR:  duplicate key value violates unique constraint 
"asset_call_number_label_once_per_lib"
DETAIL:  Key (record, owning_lib, label, prefix, suffix)=(4465, 4, 274.3708, 
-1, -1) already exists.

Is there anything we can do about it (get the periods back to call numbers and 
have the call numbers that are not unique)?

Any ideas are very welcome :-)!

Linda and Vaclav Jansovi

Re: [OPEN-ILS-GENERAL] error in new queue with record match

[Kathy Lussier]

Hi  Erick,

I just tried uploading your MARC file on a 2.5 system (not sure which 
point release) with two different match sets:


(item_lang AND (240 ‡a OR 245 ‡a))
(020 ‡a)

In both cases, I had no trouble loading records into the queue. I'm not 
sure why you would be seeing something different locally.


Maybe there is something you can dig out from your system logs that 
might point you in the right direction.


Kathy

Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier

On 4/28/2014 11:02 AM, Erick Emir Alonso Roman wrote:

To whom it may concern
Hello My name is Erick
I'm emailing in reference to a problem that I have with Evergreen.
I'm from Mexico and I am  using Evergreen at the Library in my job but 
I have this problem When I'm trying to import some records in the MARC 
batch import,  when I use a record match set none record it's 
imported,but if I don't use any record match set the import it's 
normal, someone knows what can cause this problem?

I hope that somebody can help me.
I' m using Evergreen staff client 2.5.3
I 'm trying to import 3500 records, but only for testing I'm using 10 
and doesn't work either,
I've already used the match set of the official documentation the 
expression looks like this /Your Expression:/(item_lang AND (240 ‡a OR 
245 ‡a))

or this /Your Expression:/(NOT 020 ‡a)
but none of this works
Thanks for the attention
I look forward to hearing from you
let me know any questions about my problem.
I attached two files, one with screenshots of my problem, and the test 
file

so if someone could replicate my problem and tell me if works
in your system it would be very helpful
Regards Erick Emir Alonso Roman

--
Atentamente.
*I.T.I. Erick Emir Alonso Román*
Programmer/developer
erickemir1...@gmail.com 

Re: [OPEN-ILS-GENERAL] 2.6 Wrap Up and Awards [RM2.6]

[Mike Rylander]

I echo Dan's thanks to everyone who pitched in on 2.6.

Dan, I'm particularly honored by the HAAS medal ... I'm always happy
to fight a clog, and the plungers are perfect. ;)

--miker

On Fri, Apr 25, 2014 at 4:07 PM, Dan Wells  wrote:
> Hello all,
>
> With 2.6.0 cut 10 days ago, it is high time for me to give one final update
> before I pass the torch.  I haven’t given a formal email progress summary
> since the beta (though a verbal update was given at the conference), so
> we’ll be looking back at both the RC and the 2.6 “final” contribution
> periods.
>
> With 23 tickets committed for the RC and 15 for 2.6.0, the grand total for
> the 2.6 cycle comes to exactly 100 improvements committed.  You can see the
> latest two rounds of fixes here:
>
> https://launchpad.net/evergreen/2.6/2.6.0-rc1
>
> and here:
>
> https://launchpad.net/evergreen/2.6/2.6.0
>
> While Launchpad gives us a nuts and bolts view of things, with a final
> release comes a better way to look more broadly at the changes: release
> notes!  You can read the release notes for 2.6 here:
>
> http://evergreen-ils.org/documentation/release/RELEASE_NOTES_2_6.html
>
> Of course, the beat goes on, and a few important fixes have already been
> committed for what will be 2.6.1.  I encourage anyone looking at 2.6.0 to
> read up on these recent commits and decide whether they might affect your
> local use:
>
> https://bugs.launchpad.net/evergreen/+milestone/2.6.1
>
> My expectation is still that 2.6.1 will be cut relatively early (within the
> next week or two), and that normal monthly updates will begin with 2.6.2.
>
>
> Overall, I am proud of all that we have been able to accomplish these past
> two cycles.  With that in mind, I’d like to take another moment to recognize
> those who put forth the necessary effort to make 2.6 a reality.  Of course
> this means medals, and for this round, you will notice that the medals are
> now rimmed in maroon.  This is meant not only to distinguish these final
> medals from the rest, but also as a modest gesture to my employer Calvin
> College, without whom I would not be involved with Evergreen, and without
> whose support I could not have managed these last two releases.
>
> Here are the recipients of the final Evergreen Medals of Honour for the 2.6
> release (RC and 2.6.0 combined):
>
> A. HANCOCK Medal of Fortitude (for reviewing and signing off on another
> community member's code)
>   1. GOLD Recipients (granted for signing off on at least 6 branches)
>
> http://www.calvin.edu/library/images/eg_medals/Hancock_Medal_2_6_Final_Gold.png
> Ben Shum
> Galen Charlton
> Remington Steed
>   2. SILVER Recipients (at least 2 signoffs)
>
> http://www.calvin.edu/library/images/eg_medals/Hancock_Medal_2_6_Final_Silver.png
> Bill Erickson
> 3. BRONZE Recipients (at least 1 signoff)
>
> http://www.calvin.edu/library/images/eg_medals/Hancock_Medal_2_6_Final_Bronze.png
> Doug Kyle
> Jason Stephenson
> Jeff Godin
> Kathy Lussier
> Mike Rylander
>
> B. BARTON Medal of Steadfastness (for contributing in general to the code
> review process)
>   1. GOLD Recipients (granted for contributing to at least 7 bug reviews)
>
> http://www.calvin.edu/library/images/eg_medals/Barton_Medal_2_6_Final_Gold.png
> Ben Shum
> Bill Erickson
> Galen Charlton
> Mike Rylander
>   2. SILVER Recipients (at least 3 bugs)
>
> http://www.calvin.edu/library/images/eg_medals/Barton_Medal_2_6_Final_Silver.png
> Chris Sharp
> Dan Scott
> Grace Dunbar
> Jason Etheridge
> Jason Stephenson
> Kathy Lussier
> Lebbeous Fogle-Weekley
> Remington Steed
>   3. BRONZE Recipients (at least 1 bug)
>
> http://www.calvin.edu/library/images/eg_medals/Barton_Medal_2_6_Final_Bronze.png
> Christine Morgan
> Doug Kyle
> Elaine Hardy
> Elliot Voris
> Erica Rohlfs
> Holly Brennan
> Jeff Godin
> Jennifer Pringle
> Mark Cooper
> Michael Peters
> Michele Morgan
> Pasi Kallinen
> Rogan Hamby
> Sarah Childs
> Srey Seng
> Steve Callender
> Tim Spindler
> Tina Ji
> Tony Bandy
> Warren Layton
> Yamil Suarez
>
> C. ARMSTRONG Medal of Courage (for installing and testing a release tarball,
> and reporting back)
>   1. GOLD Recipients (granted for simply doing this!)
>
> http://www.calvin.edu/library/images/eg_medals/Armstrong_Medal_2_6_Final_Gold.png
> Remington Steed
>
> As always, please contact me if I made any mistakes, as I want everyone to
> get the recognition they deserve!
>
> Along those lines, and in addition to the recognition given above, I’d like
> to give one more medal under the banner of “ask and you shall receive.”
> Mike Rylander single-handedly wrote code to fix a majority of the release
> blockers for 2.6, and mentioned in IRC the 

Re: [OPEN-ILS-GENERAL] error in new queue with record match

[Kathy Lussier]

Hi Erick,

I'll try to take some time to try an upload with the records you 
attached to see if I can get it to work on a 2.5ish system. However, one 
small thing jumped out at me from your e-mail.


I would avoid using the (NOT 020a) expression you identified in your 
e-mail. I'm not sure how the system would interpret that expression, but 
what you want at least one piece of your expression to tell the system 
which fields should be used for matching. That expression only tells the 
system which field NOT to use.


Of course, this doesn't explain why the other expression isn't working. 
Have you tried one that is (AND 020a)?


Kathy

Kathy Lussier Project Coordinator Massachusetts Library Network 
Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: 
http://www.twitter.com/kmlussier On 4/28/2014 11:02 AM, Erick Emir 
Alonso Roman wrote:

To whom it may concern
Hello My name is Erick
I'm emailing in reference to a problem that I have with Evergreen.
I'm from Mexico and I am  using Evergreen at the Library in my job but 
I have this problem When I'm trying to import some records in the MARC 
batch import,  when I use a record match set none record it's 
imported,but if I don't use any record match set the import it's 
normal, someone knows what can cause this problem?

I hope that somebody can help me.
I' m using Evergreen staff client 2.5.3
I 'm trying to import 3500 records, but only for testing I'm using 10 
and doesn't work either,
I've already used the match set of the official documentation the 
expression looks like this /Your Expression:/(item_lang AND (240 ‡a OR 
245 ‡a))

or this /Your Expression:/(NOT 020 ‡a)
but none of this works
Thanks for the attention
I look forward to hearing from you
let me know any questions about my problem.
I attached two files, one with screenshots of my problem, and the test 
file

so if someone could replicate my problem and tell me if works
in your system it would be very helpful
Regards Erick Emir Alonso Roman

--
Atentamente.
*I.T.I. Erick Emir Alonso Román*
Programmer/developer
erickemir1...@gmail.com 

Re: [OPEN-ILS-GENERAL] Non-unique Dewey call numbers with spaces rather than periods

[Dan Wells]

Hello Linda,

I don't fully understand how you built your holdings, but it looks like you 
found something that worked for you.

Your update is failing on a record which already has both versions of the call 
number (correct with '.' and incorrect with 'space').  See here:

http://lib.etspraha.cz/eg/opac/record/4465?query=evangelical;qtype=keyword

If you manually merge those copies onto either call number, there is a chance 
your listed SQL query can succeed.  If not, you will need to determine how many 
records you have which already have a correct call number listed:

SELECT record,label FROM asset.call_number WHERE label LIKE '%.%';

That doesn't tell the whole story (i.e whether you have *both* types of call 
numbers on that record), but it's a quick way to see what you are up against.  
If it's just a few, I'd merge them manually.  Otherwise, I'd next do a JOIN to 
see how many actually have both types of call number.  If it is still a lot, 
working up a little script or even a more complex query to do the merging would 
be your best bet.

Sincerely,
Dan


Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133

-Original Message-
From: open-ils-general-boun...@list.georgialibraries.org 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Linda 
Jansova
Sent: Monday, April 28, 2014 1:56 AM
To: Evergreen Discussion Group
Subject: [OPEN-ILS-GENERAL] Non-unique Dewey call numbers with spaces rather 
than periods

Hi all,

We have imported bibliographic and holdings data of the Evangelical Theological 
Seminary library to Evergreen 2.5.3!

Yet, we have encountered the following problem (maybe a bit related to a recent 
discussion on Dewey normalization: 
http://comments.gmane.org/gmane.education.libraries.open-ils.general/9661):

The library uses Dewey decimals as call numbers but these call numbers are not 
unique (no cutters are applied). In the OPAC, these data can be found as 
correctly imported in subfield "a" of the the 082 field (which means the data 
in MARCXML have been well preserved). But during the import, they were 
normalized in metabib.full_rec and call numbers are created from these data. 
There is no problem with padding zeroes as these have not been added but 
periods within the Dewey number have been overrided by spaces, e.g., 
http://lib.etspraha.cz/eg/opac/results?query=evangelical;qtype=keyword.

Therefore we have - unsuccessfully - tried to add the periods back but then the 
call numbers are expected to be unique which is not our case. 
So an error has occured:

evergreen=# UPDATE asset.call_number SET label = replace(label, ' ', '.');
ERROR:  duplicate key value violates unique constraint 
"asset_call_number_label_once_per_lib"
DETAIL:  Key (record, owning_lib, label, prefix, suffix)=(4465, 4, 274.3708, 
-1, -1) already exists.

Is there anything we can do about it (get the periods back to call numbers and 
have the call numbers that are not unique)?

Any ideas are very welcome :-)!

Linda and Vaclav Jansovi