Time  Nick   Message
12:38 kyle_  hey all
13:55 hdl    hi kyle
14:48 Brooke Howdy
15:32 thd    ryan: ping
15:53 ryan   hi thd
15:53 thd    hello ryan
15:55 thd    ryan: have you had the opportunity to test misc/marc21_standard_auth_frameworks.sql on Koha 2.2.X?
15:58 ryan   thd: no, i haven't had a chance to
15:58 ryan   they were tested on a head install?
16:00 thd    ryan: yes, and I fixed the major problem for the HEAD install, although, chris has not committed the full set of frameworks files yet.
16:00 thd    ryan: kados said that only you had rel_2_2 running for testing
16:05 thd    ryan: I want to see if you have the same issue as I do for the authorities editor where Default, Personal Name, and Corporate Name all have the same set of fields and subfields in the editor, that is they all have all the fields and subfields as default.
16:06 thd    ryan: on my installation the rest of the authority types appear as specified
16:07 ryan   this is fixed in head?  but you still see it on rel2_2?
16:07 ryan   and just for pname, cname, not for tterm, etc ?
16:07 thd    ryan: well I do not have a local copy of head for testing
16:08 thd    ryan: that is correct
16:10 thd    ryan: if you have a running test version installed for rel_2_2 we can show paul and ask what may be causing the issue.  However, it may function as intended for you.  A test is needed.
16:13 thd    ryan: mysql [-h YourMySQLServername] -uYourKohaMySQLUsername -p YourKohaDatabasename < /path/to/marc21_standard_auth_frameworks.sql
16:24 ryan   ok, i'll find a suitable test instance
16:35 ryan   thd: marc q:
16:36 ryan   is it the case that 09X are no longer part of the MARC21 standard ?
16:37 thd    ryan: well they are specified for local classification information in the MARC 21 authorities format
16:40 ryan   but they should no longer be used in cataloging?
16:40 thd    ryan: I did not identify a MARC 21 authority format field/subfield which paul was using to track authority ID similar to 090 $c and $d in MARC 21 bibliographic format
16:41 thd    ryan: they are used in cataloguing but not by LC
16:41 ryan   (i'm asking generally here, not re: your authorities defs)
16:42 ryan   i have been using 999 for biblionumber since several catalogers have complained about 090.
16:43 ryan   i am just curious to know what the proper handling is now for a locally-defined classification
16:43 thd    ryan: 090 is an extremely common location for currently storing local LC call numbers and it was once the official location in standard MARC 21.
16:43 ryan   was there a recent change?
16:43 ryan   and is there a new official location?
16:45 thd    ryan: OCLC currently and many non0member libraries currently`use 090 for library assigned LC call numbers and the other 09X for other call numbers
16:47 thd    ryan: the change in the official standard was several years ago in USMARC when an indicator value was added to 050 etc. for call numbers not assigned by LC.
16:49 thd    ryan: however, most practise has never changed.  I suggested changing the location for storing the Koha record keys but kados did not want to complicate things for himself.
16:51 thd    ryan: eventually Koha has to stop using 090 for reserved functions or the use will cost you important customers.
16:53 thd    ryan: 999 is simply an available remapping for which I found no major pre-existing use..
16:55 ryan   yes, we're using 999 now, not 090
16:56 thd    ryan: when you find an OCLC library using LC classification for a customer that may become a problem.
17:00 ryan   oclc is using 999 ?
17:03 thd    ryan: no both Koha and OCLC are using 090 so I switched Koha to 999 for the common use because kados did not want to use any reserved field differently in koha from the way Nelsonville had used the reserved fields
17:12 thd    ryan: you have exactly what I have except that your list of authority frameworks sorts alphabetically correctly unlike my CVS rel_2_2 and HEAD which sort them in reverse alphabetic order
17:13 ryan   ah, i understand the confusion now
17:13 ryan   i mean that we are using 999 for koha biblionumber and biblioitemnumber
17:14 ryan   and have reverted our standard framework's 090 to local lc call num
17:14 thd    ryan: you have?
17:15 ryan   this is a recent change for clients, after having a few catalogers complain about 090.
17:15 ryan   my feeling is that we should make this change in head
17:16 thd    ryan: it would be nice to do it for everyone by altering 090 and swapping it with 999 in all existing installations
17:18 ryan   we've only been using this for new installs
17:19 ryan   but i do think that the v3 release should use 999
17:19 thd    ryan: I will make that change but there is already a library in France using MARC 21 Koha.
17:19 ryan   bah
17:19 ryan   we'll have to consult then
17:20 ryan   shouldn't be too much for them to change
17:20 ryan   thd: yes, the install you're looking at is a cvs rel_2_2 that's a couple months old (back to authorities issue)
17:21 thd    ryan: while you are at it 952 has other uses which conflict with the Koha reserved use.
17:23 ryan   thd: chris, joshua and i investigated implementing marc holdings (i.e. separate holdings records)
17:23 ryan   i think it will be done, with a syspref to use embedded holdings
17:24 ryan   should we be using 852 for embedded holdings?
17:24 thd    ryan: well we need to raise paul to answer why default, personal name, and corporate name, do not appear distinct as specified in the SQL file.
17:25 thd    ryan: yes if you have holdings based on standard MARC 21 holdings then 852 would be used.
17:26 ryan   | PERS0_NAME   | Personal Name      | 100                | Personal Names     |
17:26 ryan   | CORP0_NAME   | Corporate Name     | 110                | Corporate Names    |
17:26 ryan   thd:  i notice that we have zeroes here
17:26 ryan   in auth_type def
17:27 thd    ryan: I have a mapping of existing Koha holdings subfields in 952 to their standard locations.
17:27 thd    zeros?
17:27 thd    what zeros?
17:28 ryan   yes, so the auth_types are not the same as the codes in auth_ structures
17:28 ryan   PERS0_NAME != PERS0_NAME
17:28 thd    ohh :)
17:28 ryan   er... PERSO_NAME
17:29 ryan   thd: but we require some subfields that aren't defined in 852 in order to store all we want to at the item level
17:31 ryan   mysql> update auth_types set authtypecode='PERSO_NAME' where authtypecode='PERS0_NAME';
17:31 ryan   Query OK, 1 row affected (0.00 sec)
17:31 ryan   Rows matched: 1  Changed: 1  Warnings: 0
17:31 ryan   ok, should fix it there
17:32 thd    ryan: well the standard actually links together several holdings fields to the same item providing many subfields.
17:33 thd    ryan: Koha still needs a few non-standard subfields but that is no problem.