| Time |
S |
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/php[…]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 |
