Time  Nick           Message
11:20 pierrick       I'm trying to understand how authorities work in Koha, I have a question
11:22 pierrick       In Koha database (branch 2.2), for a given author name, where do I find rejected and official value ?
11:22 pierrick       For instance, I want to see all rejected value of a given author name
11:22 paul           you just have to see authority detail.
11:23 paul           in biblio, only the "accepted form" is stored.
11:23 paul           everything else is in the authority itself.
11:23 paul           it's quite strange for a developper, as it's not really correct
11:24 paul           we would store only the # of authority in the biblio.
11:24 paul           to create the relationship.
11:24 paul           but librarians decided to store the # + the main entry field (name+surname+dob+title...)
11:24 pierrick       OK... so the join is not made with authority id...
11:25 pierrick       thus duplicating information...
11:25 paul           yes but no.
11:25 paul           the join is made with authority id.
11:25 paul           + information duplicated.
11:25 paul           in unimarc, the join is in $3 in biblio
11:25 paul           in marc21, it's "where the local system want to put it" => not in the standard
11:26 paul           (thus you're right for marc21, but wrong for unimarc in fact)
11:26 pierrick       OK, I'm searching in the database where are the informations you just gav me :-)
11:27 paul           auth_*_tables for authorities.
11:29 pierrick       thank you paul, I'm querying my local EMP database :-)
11:50 pierrick       :-/ browsing MARCdetail.pl, some field are linked to an authority. Say authority 3537 (ENVIRONNEMENT). How do I see rejected forms of the authority ? In fact, I'm confused because I thought an authority was a list of forms with one accepted form and N rejected forms. It's not so simple :-/
11:51 paul           in opac or librarian interface ?
11:51 paul           in librarian you should have an "authority" button
11:51 paul           that reaches the authority
11:51 paul           for EMN, you DON'T have complete authorities.
11:51 paul           you just have accepted form !
11:51 pierrick       librarian
11:52 paul           so don't look for rejected form, there is no !
11:52 pierrick       OK... I could search long time...
12:07 pierrick       in any tag, $3 subfield is always internal Koha related?
12:15 pierrick       (in unimarc)
12:16 paul           no, it's unimarc standard
14:01 paul           what is the channel on freenode for perl4lib ?
14:03 pierrick       irc.freenode.net
14:03 paul           yep, my problem was the chanel : it's ok, i just had forgotten the # : #code4lib
14:04 pierrick       paul: sorry, I had read the question too quickly
14:06 paul           lol
14:06 pierrick_dummy when modifying an authority type, the help label next to field "Report tag" is "Enter here the number of the tag that will be reported in the biblio (subfield by subfield). For example, in UNIMARC, enter 200 to report every 200 subfield in the 70x biblio". I'm sorry, but where is the logic? :-/
14:06 hdl            test
14:06 kados          morning fellas
14:06 pierrick_dummy alpha tango charlie
14:07 pierrick_dummy 'morning kados
14:08 pierrick_dummy can I make a proposition to modify database update script? (based on the work I've made on another projct)
14:08 hdl            morning Big Man.
14:08 kados          pierrick_dummy: sure
14:10 pierrick_dummy summarize before proposing on koha-devel : instead of a big updatedatabase script, having N scripts that can be execute only once. We store in db the upgrades already executed. When a new upgrade script is available (after a cvs update), you're notified in intranet screen that N upgrade are missing.
14:13 pierrick_dummy this kind of simple scripts : http://svn.gna.org/viewcvs/phpwebgallery/trunk/install/db/
14:15 pierrick       paul: what do you think of my proposal? (you can think it's useless, that won't hurt me ;-)
14:15 paul           nope. I think it's a good idea.
14:16 paul           everything that makes install/upgrade more friendly is good !
14:18 pierrick       the drawback of my proposal is that you can't execute upgrades twice (but it's a wanted behaviour, to simplify things a lot, and sometimes executing more than once is dangerous)
14:21 paul           some years ago I wrote such a script.
14:21 paul           the DB version was embeeded in the database itself (as unmodifiable systempref for example)
14:21 paul           when you want to upgrade, the script checks what is already done, what is to be done.
14:22 pierrick       exactly what I did elsewher
14:22 pierrick       It works great I must admit
14:24 pierrick       kados: what's the difference between "upgrade" and "update" ?
14:27 owen           update is usually smaller, more incremental
14:32 pierrick       OK, thank you owen
17:51 thd            kados: I sent you an improved bibliographic framework