IRC log for #koha, 2007-08-22

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

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 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 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 ryan: kados said that only you had rel_2_2 running for testing
16:05 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 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 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 ryan: that is correct
16:10 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 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 thd: marc q:
16:36 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 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 i have been using 999 for biblionumber since several catalogers have complained about 090.
16:43 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 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 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 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 ryan: eventually Koha has to stop using 090 for reserved functions or the use will cost you important customers.
16:53 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 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 i mean that we are using 999 for koha biblionumber and biblioitemnumber
17:14 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 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 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 we'll have to consult then
17:20 shouldn't be too much for them to change
17:20 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 i think it will be done, with a syspref to use embedded holdings
17:24 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 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 | CORP0_NAME   | Corporate Name     | 110                | Corporate Names    |
17:26 thd:  i notice that we have zeroes here
17:26 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 zeros?
17:27 what zeros?
17:28 ryan yes, so the auth_types are not the same as the codes in auth_ structures
17:28 PERS0_NAME != PERS0_NAME
17:28 thd ohh :)
17:28 ryan er... PERSO_NAME
17:29 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 mysql> update auth_types set authtypecode='PERSO_NAME' where authtypecode='PERS0_NAME';
17:31 Query OK, 1 row affected (0.00 sec)
17:31 Rows matched: 1  Changed: 1  Warnings: 0
17:31 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 ryan: Koha still needs a few non-standard subfields but that is no problem.

← Previous day | Today | Next day → | Search | Index

koha1