← 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