← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 13:09 | kados | hdl: still around? |
| 13:09 | hdl: I have a quick authorities question | |
| 13:56 | owen: you around? | |
| 13:56 | owen | yes |
| 13:56 | kados | owen: I have a question about subjects :-) |
| 13:58 | yea ... I'm trying to figure out how to ask it | |
| 13:59 | the bottom line is that I really don't understand how MARC subjects are supposed to work | |
| 13:59 | it seems like an arbitrary and contradictory framework for a taxonomy | |
| 14:00 | owen | I can't help you much with that :) |
| 14:00 | kados | I'm trying to figure out for instance, how authorities control should work for MARC |
| 14:00 | say you've got the following: | |
| 14:00 | Geographic name: Georgia | |
| 14:00 | General subdivision: Codes | |
| 14:00 | General subdivision: Amendments and revisions | |
| 14:01 | would that be three separate authorities or just one? | |
| 14:01 | hdl: you've been working on authorities lately for subjects, right? | |
| 14:01 | hdl: how does it work in unimarc? | |
| 14:02 | owen | The trouble with asking me is that I've never worked with authorities |
| 14:03 | kados | hehe |
| 15:20 | owen | Any luck kados? |
| 16:13 | kados | well ... i actually asked one of our consultants, he's gonna pass it on to a MARC expert :-) |
| 16:14 | I'm gonna head out for the day | |
| 16:14 | night all | |
| 16:48 | hdl | kados ? |
| 18:53 | hi chris | |
| 18:54 | chris | hi hdl |
| 18:54 | what are you doing awake? | |
| 18:55 | ahhh, i hope it is going well | |
| 18:59 | anything i can help with? | |
| 19:15 | wb hdl | |
| 19:16 | hdl | OpenOffice keeps crashing :/ |
| 19:16 | chris | :( is that what you are doing your presentation with? |
| 19:16 | hdl | yes. |
| 19:16 | chris | do you have much left to do? |
| 19:17 | hdl | Can you tell me about zebra features ? |
| 19:17 | I know | |
| 19:17 | Full text index | |
| 19:17 | Boolean search | |
| 19:17 | chris | yep |
| 19:17 | hdl | Multi format (Dublin-Core, BiblioML) |
| 19:17 | chris | proximity search |
| 19:17 | hdl | Z3950 full support |
| 19:18 | Is taht all ? | |
| 19:18 | chris | stemming |
| 19:18 | stemming and proximity searching | |
| 19:19 | Searching supports a powerful combination of boolean queries as well as relevance-ranking (free-text) queries. Truncation, masking, full regular expression matching and "approximate matching" (eg. spelling mistakes) are all handled. | |
| 19:20 | hdl | dewey translate into french stemming |
| 19:20 | dewey | hdl: excuse me? |
| 19:20 | chris | ill give you an example |
| 19:20 | if i set it up | |
| 19:20 | and i search on | |
| 19:20 | Songs | |
| 19:20 | it will search songs | |
| 19:20 | then song | |
| 19:20 | then son | |
| 19:21 | hdl | ok. |
| 19:21 | thanks | |
| 19:22 | kados | hdl: full boolean is important too |
| 19:22 | hdl: as we dont' currently have that | |
| 19:22 | chris | it doesnt do anything we cant do with perl and sql .. but it does it a hell of a lot faster than we could |
| 19:23 | thats the main compelling reason | |
| 19:23 | speed | |
| 19:23 | plus its already written :-) | |
| 19:27 | kados | yea ... in fact, I'm not sure boolean would be practical in rel22 |
| 19:27 | I took a look once but you'd have to so do many self joins | |
| 19:27 | searches would take forever | |
| 19:27 | chris | yep |
| 19:28 | speed | |
| 19:28 | kados | yup |
| 19:28 | hdl: the other thing Zebra does is greatly increase the complexity of setting up and maintaing Koha ... :-) | |
| 19:28 | not sure you'll want to mention that though :-) | |
| 19:28 | chris | heh |
| 19:29 | kados | all right guys |
| 19:29 | I'm gonna sign off | |
| 19:29 | hdl | for sure. |
| 19:29 | chris | night |
| 19:29 | hdl | night kados |
| 19:29 | kados | night |
| 20:49 | tumer | talking about complexity of zebra. Now tackling with async mode. its err difficult |
| 20:53 | hdl still awake? | |
| 01:37 | chris | morning pierrick |
| 01:39 | pierrick | hi chris |
| 01:59 | osmoze | hello |
| 01:59 | dewey | niihau, osmoze |
| 02:00 | chris | hmm when did dewey learn chinese |
| 02:13 | pierrick | hi ToinS |
| 02:13 | ToinS | hello pierrick |
| 02:13 | paul | hello pierrick |
| 02:14 | pierrick | hello paul |
| 02:26 | btoumi | hi everybody |
| 02:27 | pierrick | hi bruno |
| 02:27 | btoumi | hi pierrick |
| 02:31 | ToinS | hi bruno |
| 02:32 | btoumi | hi antoine |
| 02:32 | how are u? | |
| 02:34 | ToinS | fine |
| 02:34 | btoumi | kool |
| 02:53 | pierrick | does anybody know what a "multi language thesaurus" means? |
| 02:53 | (I know what a thesaurus is, I know what multi languagee is) | |
| 02:53 | paul | so you know what is a multi language thesaurus ! |
| 02:54 | the only caveat here is to deal with translations like : | |
| 02:54 | libre => free | |
| 02:54 | gratuit => free | |
| 02:54 | 1 word in a language, 2 in the other | |
| 02:55 | btoumi | hi paul |
| 02:55 | pierrick | is it really a problem? a thesaurus is specific to a "champ lexical", so free would mean either '"libre" or "gratuit" depending on the thesaurus |
| 02:56 | in a thesaurus, do we have specific relation "translation of" between two words ? | |
| 02:59 | in the future, is it planned to optionnaly require a logon in the OPAC? | |
| 03:55 | btoumi | i need some help somebody can help me? |
| 04:29 | if somebody can help me ? i have a error message "Missing right curly or square bracket at" dans le fichier Accounts2.pm or i look for and i find nothing | |
| 04:30 | paul | it's a problem with a missing } or ) |
| 04:30 | sometimes hard to find where it is | |
| 04:30 | btoumi | do u have the problem? it's strange that's i'm lonely |
| 04:32 | ok i find | |
| 04:34 | paul | you're probably not the only one, but nobody tried yet! |
| 04:43 | btoumi | ok i've resolved probleme |
| 04:44 | paul | don't forget to commit it ;-) |
| 04:44 | btoumi | ok |
| 06:55 | pierrick | btoumi, I've seen the last addition of paul concerning roadtypes, can you explain me the purpose of it ? |
| 06:59 | btoumi | en francais c le type de voie |
| 06:59 | par exemple avenue rue boulevard impasse ect.. | |
| 06:59 | et si tu mais rien ca ne doit pas apparaitre sur le template | |
| 07:00 | pierrick | alors en français: quel intérêt ? |
| 07:01 | (c'est une remarque naïve, je ne dis pas qu'il ne faut pas le faire) | |
| 07:05 | btoumi | ca va etre utiliser par un sig |
| 07:06 | pierrick | sig? |
| 07:08 | btoumi | systeme informatiion geographique |
| 07:22 | pierrick | btoumi, et dans un sig, le type de rue est important ? Je me demande bien la valeur ajoutée :-) |
| 07:23 | btoumi | oui |
| 07:25 | kados | morning all |
| 07:25 | pierrick | morning kados |
| 07:25 | kados | paul: got a quick question for you ... |
| 07:26 | paul | hi joshua/kados |
| 07:26 | kados | in current authorities, is it normal for an authority record to contain many tags/subfields but to only be linked to one bib subfield (the heading?) |
| 07:26 | or is it normal to have many links from biblio subfields to authority records? | |
| 07:27 | for example: | |
| 07:27 | 651 $aGeorgia $xCodes $xAmmendments and revisions | |
| 07:27 | that's a bib record | |
| 07:28 | paul | it is a graphic bug, but Koha will report $a as well as $x if you have them in your authority recore |
| 07:28 | kados | would that be three separate authority records? or just one? |
| 07:28 | paul | just 1 |
| 07:28 | kados | ahh ... too |
| 07:28 | too bad | |
| 07:28 | this must be what thd was pointing out | |
| 07:29 | in MARC21 the above example could be 3 separate I think | |
| 07:29 | paul | it seems MARC21 differs from UNIMARC here. |
| 07:29 | kados | yep ... |
| 07:29 | paul | in MARC21, 1 field in biblio means 1 authority |
| 07:29 | sorry | |
| 07:29 | in UNIMARC ... | |
| 07:29 | kados | well, in MARC21 it's still confiusing for me ... because it seems like some auth records have many fields in them |
| 07:30 | and I assume when you link auth-> bib you want to grab all of the data | |
| 07:30 | not just the heading | |
| 07:31 | but how to do this if every field has a single authority | |
| 07:44 | hmmm | |
| 07:45 | so the issue is that our links are based on a subfield within a tag | |
| 07:45 | we can't have more than one link within a tag ... right? | |
| 07:47 | I think I understand now why MARC21 does string matching :-) | |
| 07:47 | paul | kados : right for 1 link within a tag. |
| 07:48 | string matching : I think I understand too. | |
| 08:05 | kados | hey kyle |
| 08:05 | paul | hey kyle |
| 08:05 | kyle | hey kados |
| 08:05 | hey paul | |
| 08:06 | kados, I wanted to talk to you a bit about the fallback system for when an intranet terminal loses its connection to the koha server | |
| 08:07 | kados | kyle: sure ... it's called 'offline circ' |
| 08:07 | paul: has SAN West made any progress on this? | |
| 08:08 | paul | I don't think so. but btoumi is around, ask him |
| 08:08 | ;-) | |
| 08:08 | btoumi | :=) |
| 08:08 | kados | good point :-) |
| 08:08 | btoumi: hi :-) | |
| 08:09 | btoumi | hi koados |
| 08:09 | kados sorry | |
| 08:09 | kyle | you mentioned it being a firefox extension. |
| 08:09 | kados | kyle: that was one idea ... |
| 08:09 | kyle | I just wondered if there was a particular reason for that, or what. |
| 08:10 | kados | btoumi: has that project been worked on yet? |
| 08:10 | kyle | I've got a few ideas rolling about in my head, and I just don't know what would be the just course of attack. |
| 08:10 | kados | kyle: right |
| 08:10 | kyle: I haven't personally thought about it much | |
| 08:10 | kyle: I know it was a requirement for SAN West at one point | |
| 08:11 | kyle: btoumi can speak to the status better than I :-) | |
| 08:11 | btoumi | sorry i answer something when i understand all the discuss |
| 08:11 | :=) | |
| 08:12 | kyle | It would be trivial to write a firefox extension that stores checkin's and checkout's |
| 08:12 | the harder part is getting that stored information back into the database. | |
| 08:13 | this would be a much easier task if koha *were* split up into a set of services. | |
| 08:13 | I've been thinking about writing a soap interface for reports generation | |
| 08:14 | This is another application where such an interface would be useful. | |
| 08:15 | kados | btoumi: we're discussing how to implement an 'offline circulation' client for Koha |
| 08:15 | btoumi | ok |
| 08:15 | kados | btoumi: is SAN West currently working on this? |
| 08:15 | btoumi | no not at time |
| 08:16 | kados | btoumi: ok ... so kyle will do it then ;-) |
| 08:16 | kyle: ok ... so bombs away :-) | |
| 08:16 | btoumi | me i continu to bug correction of borrowers and arnaud is in holiday |
| 08:16 | kyle | indeed : ) |
| 08:16 | kados | btoumi++ |
| 08:17 | kyle: it shouldn't be difficult to get that info back into the db | |
| 08:17 | kyle: because the thing is, you still want the librarian to watch it | |
| 08:17 | kyle: for instance, there are still going to be questions the librarian should answer | |
| 08:17 | kyle | kados: how then? There is no way to access a database through firefox natively. |
| 08:18 | kados | kyle: just post the stuff the same way the browser would normally ;-) |
| 08:18 | kyle: use the same API, we may need to expand it a bit to handle new problems | |
| 08:18 | kyle: (like dealing with check-out to a debarred patron for instance) | |
| 08:19 | kyle: (make sense?) | |
| 08:19 | kyle | yes, I think I get it. |
| 08:19 | but I don't know it that's the best solution... | |
| 08:20 | I'm not sure if it's possible to POST from javascript. | |
| 08:20 | I've been unable to find any information on that. | |
| 08:20 | kados | sure it is |
| 08:20 | XMLHttpRequest supports POST | |
| 08:20 | kyle | ok. |
| 08:21 | excellent. | |
| 08:22 | so the plugin would collect all checkins and checkouts with the neccessary infomration (date, time, patron, etc.), and when the system comes back on, the librarian would click a button that would POST all the info to a CGI perl prog that would integrate it into the main database> | |
| 08:23 | does that sound about right? | |
| 08:24 | oh, and the perl CGI would first re-display everything to confirm it's correctness and stuff. | |
| 08:26 | pierrick | kados, how many biblios in NPL ? |
| 08:26 | kados | pierrick: about 150K biblios, 300K items |
| 08:27 | pierrick | kados, thx |
| 08:27 | kados | kyle: yea, it would post each one individually |
| 08:27 | kyle: and if it needed advice from the librarian it would prompt her | |
| 08:28 | kyle | I think it might be easier for the client-side end to be "stupid" and for the server-side to ask such questions, but that's no big deal. |
| 08:28 | kados | yea, server-side asks |
| 08:28 | but client-side has to know how to recieve a question | |
| 08:28 | and how to answer one | |
| 08:29 | kyle | The more I think about it, the less reason there is for this to be an extension, and more just a plain html page with javascript. |
| 08:29 | kados | unless you just interupt the process if there's a question and she has to start over ... |
| 08:29 | kyle | hmmm.... |
| 08:29 | kados | yea, it could just be js on the circ page |
| 08:30 | thing is, there is definitely more than one way to do it :-) | |
| 08:30 | kyle | I know, that's the problem ; \ |
| 08:30 | kados | heh :_) |
| 08:30 | snack time | |
| 08:30 | bbiab | |
| 08:30 | kyle | later |
| 08:47 | kados | hi johnb (john brice?) |
| 08:48 | kyle | you are correct, sir : ) |
| 08:49 | kados: I need a program that will simulate daily patron activity on a demo server, and I was wondering if anyone had written one before I go and write it myself. | |
| 08:50 | kados | kyle: I haven't written one for Koha, have for Evergreen though |
| 08:50 | kyle | kados: do you think that it would be useful for me to see it before writing my own? |
| 08:50 | kados | kyle: but PINES is expecting mad load on Evergreen ... to the tune of 1000-1500 simultanous connections |
| 08:51 | kyle: you can definitely take a look ... it might be helpful ... sec and I'll post it somewhere | |
| 08:51 | kyle | ok |
| 08:52 | kados | kyle: http://liblime.com/public/kill_evergreen.pl |
| 08:52 | kyle | kados: I like the name : ) |
| 08:53 | kados | perldoc kill_evergreen.pl will give you usage, etc. |
| 08:53 | or just go: | |
| 08:53 | ./kill_evergreen.pl | |
| 08:53 | and it should dump usage info | |
| 08:54 | kyle: it's way overkill for Koha | |
| 08:54 | hey tumer | |
| 08:54 | hehe | |
| 08:55 | kyle | kados: yeah, I plan on writing a script that will perform some random checkouts, checkins, and perhaps some reserves. |
| 08:55 | kados | sweet ... |
| 08:55 | could be the start of a testing suite | |
| 08:55 | kyle | kados: I was thinking that. |
| 08:56 | paul | kados is becoming a true Perl Monger... |
| 08:56 | kyle | kados: has any thought been put into koha 4.0? |
| 08:57 | kados | kyle: no ... we've thought about 3.2 ... but 4.0 would mean we did something major to the way the system works |
| 08:57 | kyle: we follow the linux kernel versioning model | |
| 08:58 | kyle | kados: I'm just thinking that modularizing the system is going to be very important to its health and viablility. |
| 08:58 | kados | sure, but we need not wait until 4.0 to do that |
| 08:59 | kyle | kados: I just figured an alteration that large would get a new version number. |
| 08:59 | kados: but it doesn't matter as long as it's in there. | |
| 08:59 | kados | it's on the 3.0 roadmap :-) |
| 08:59 | kyle | excellent : ) |
| 08:59 | pierrick | kyle, I agree, this is why we said "stronger API" during devweek |
| 08:59 | we've discussed about it with chris also | |
| 09:00 | kyle | pierrick: indeed. I think unless we give koha a real api, it won't be able to get buch bigger without becoming unmaintainable. |
| 09:00 | kados | yep ... it's very important ... but as always, the question is, who will do it? |
| 09:00 | http://wiki.koha.org/doku.php?[…]opment:roadmap3.0 | |
| 09:00 | current 3.0 roadmap ^ | |
| 09:00 | pierrick | kados, I think nobody will do it in a row |
| 09:00 | we have to set coding rules | |
| 09:01 | kyle | I think the best way to do it will be to have volunteers take on "modules". |
| 09:01 | kados | pierrick: we have coding rules, we need to expand them |
| 09:01 | pierrick | (I wanted to work on it last week, but... no time) |
| 09:01 | kyle | where are the coding rules on the wiki? |
| 09:01 | kados | kyle: http://www.kohadocs.org/codingguidelines.html |
| 09:01 | pierrick | kados, existing coding rules are only a start I think |
| 09:01 | kados | kyle: not on the wiki ... |
| 09:01 | pierrick: I agree | |
| 09:01 | kyle | thanks. |
| 09:02 | pierrick | and the coding rules whould be in the wiki for the moment |
| 09:02 | kados | agreed ... so we can all work on them |
| 09:02 | pierrick | (when I'll work on it, I'll put them in the wiki) |
| 09:02 | kados | pierrick++ |
| 09:02 | kyle | indeed |
| 09:03 | pierrick | I will also talk about some coding practices... |
| 09:03 | kyle | with an api in place, testing will become near trivial. writing a blackbox test suite would take only a day or two. |
| 09:03 | pierrick | such has "do not use encoded information in the database where it's useless" (I'm talking about "hidden" being a tinyint(3)) |
| 09:06 | kados | pierrick: I'm not sure I 100% agree on that specific point ... |
| 09:06 | pierrick: but I understand what you mean | |
| 09:31 | paul | tumer is here for a few seconds ;-) |
| 09:32 | btoumi | hi tumer |
| 09:32 | tumer | hi paul my server keeps throwing me out |
| 09:32 | paul | yes, we saw this |
| 09:32 | pierrick | kados, if I wanted to make my point more obvious, I would say that we only need one column per table, having fields separated by pipes in the value : 12|pierrick|le gall |
| 09:33 | kados | sure ... I can understand that ... |
| 09:33 | pierrick | kados, obviously, this is stupid :-), don't you think? |
| 09:33 | kados | but this is quite a different case |
| 09:33 | because for instance, all of these visibility options are numeric | |
| 09:34 | and we want to be able to use < > = in the scripts | |
| 09:34 | paul | kados ++ |
| 09:34 | pierrick + | |
| 09:34 | pierrick | kados, give me an exampl |
| 09:34 | e | |
| 09:34 | kados | sure ... |
| 09:35 | so for example, if we have an encoded scheme based on 3 values, just like unix permissions | |
| 09:35 | first value is opac, second is intranet, third is editor (say ... just for example) | |
| 09:35 | so given a visibility flag of: | |
| 09:35 | 011 | |
| 09:36 | we can go: | |
| 09:37 | if ($hidden < 100) { it's invisible in the OPAC } | |
| 09:37 | pierrick | if (not $visible_in_opac) |
| 09:38 | kados | well ... but there are more cases than just a simple boolean flag |
| 09:38 | tumer | kados:are you discussing what I've implemented with authorities? |
| 09:38 | kados | tumer: yes |
| 09:38 | pierrick | tumer, yes |
| 09:38 | kados | and tumer's right that there's no advantage to having three columns over one |
| 09:38 | in fact, in some ways it simplifies things | |
| 09:39 | pierrick | it makes the think darker, I'm afraid |
| 09:39 | s/think/thing | |
| 09:39 | just think of maintainability | |
| 09:39 | paul | pierrick + |
| 09:40 | (/me will count + at the end & decide who he will vote for :-D ) | |
| 09:40 | kados | but hard-coding three new columns in the db means that if we want to add another visibility option we need to create a new column rather than just add a value to an existing column |
| 09:41 | pierrick | kados, you're right, but I think it's less important than readibility |
| 09:41 | kados | imo if someone can understand unix permissions, they can easily understand this visibility flag |
| 09:42 | paul | kados + for db easier |
| 09:42 | kados + for unix perms | |
| 09:42 | kados | of course, for the user it should be completely auto-generated based on questions asked |
| 09:42 | paul | I want to add that the actual perm system inside koha works like this |
| 09:42 | kados | so whoever is editing the frameworks manually shouldn't be bothered by the encoding scheme |
| 09:42 | paul | with some binary encoding/decoding to play with them easier |
| 09:42 | kados | yep |
| 09:43 | paul | the encoder/decoder "translate" binary into $visible_in_opac |
| 09:43 | kados | a well-designed binary encoding scheme can make things really nice to script |
| 09:43 | tumer | its implemented like that (drop dowwn selections) no numbers for the user |
| 09:43 | kados | tumer++ |
| 09:43 | tumer: I'm installing HEAD btw ... | |
| 09:43 | tumer: should have it going with NPL's data today (I hope) | |
| 09:44 | pierrick | OK, let's say I agree in condition you write a function my ($visible_in_opac, $visible_in_intranet, $visible_in_editor) = decode_hidden($hidden_value); |
| 09:44 | tumer | excited (fl) |
| 09:44 | pierrick:I do not | |
| 09:45 | pierrick | (and the same kind of function for the reverse) |
| 09:45 | tumer, you do not what ? | |
| 09:45 | (agree?) | |
| 09:45 | tumer | I will implement collapsed for opac at one point as well |
| 09:45 | kados | tumer++ |
| 09:45 | pierrick | what do you mean? |
| 09:46 | kados | pierrick: that's too limiting ... and every time we implement a new encoding scheme we'll have to add a variable |
| 09:46 | pierrick: there are more than just 6 options here | |
| 09:47 | pierrick: each interface has a range of visibility options | |
| 09:47 | kyle | I'd have to throw my lot in with pierrick, I'd pick grokability over clever any day. |
| 09:47 | pierrick | kados, I understand that the encoding is a great way to avoid modifying database structure, but it produces code harder to read (at least for poor minded people like me). So if we say we're hacker, we don't mind readability, OK for encoding |
| 09:48 | kados | it's not about grokability, it's more about codeability |
| 09:48 | kyle | but lack of easy understanding puts up barriers to entry which will limit the koha community. |
| 09:48 | pierrick | kyle++++ |
| 09:48 | kados | IMO anyone who can't understand linux permissions shouldn't be coding on Koha ;-) |
| 09:49 | binary encodings schemes are not black magic | |
| 09:49 | pierrick | so I shouldn't since I always forgot and need to think about it... I never use "chmod 755", I use "chmod ug-x" |
| 09:49 | kados | hehe |
| 09:50 | IP addresses are binary encoding schemes | |
| 09:50 | kyle | But I still beleive an emphasis on easy understanding is vital to the long-term health of the system. |
| 09:50 | pierrick | kados, that's why DNS exists ;-) |
| 09:50 | kados | hehe |
| 09:51 | kyle | pierick++ |
| 09:51 | kados | but my point is, underlying db is an encoding scheme |
| 09:51 | the interface is easy to use | |
| 09:51 | so for those who are actually using the system, they don't need to know how the encoding scheme works | |
| 09:52 | but if you're going to work on the visibility options, it's much easier to work with a binary encoding scheme than bunch of independent flags | |
| 09:52 | pierrick | it's obvious for me Koha users don't have to understand the binary encoding :-) |
| 09:52 | kados | plus, the binary encoding scheme is already written |
| 09:52 | kyle | I think you mean it's quicker to work with a binary encoding scheme. |
| 09:52 | less code. | |
| 09:53 | kados | kyle: it's a cleaner solution |
| 09:53 | pierrick | kados, I don't agree about "cleaner" |
| 09:53 | kados | kyle: not just less code, less logic in the scripts ... more in the db |
| 09:53 | you store the hierarchical relationships in the positions rather than code them in the scripts | |
| 09:55 | kyle | for now I acquiesce ; ) |
| 09:56 | pierrick | another disturbing me... I think it's less readable to use negative variables |
| 09:56 | hidden = not visible | |
| 09:56 | not hidden = not not visible = visible | |
| 09:57 | kados | hehe |
| 09:57 | pierrick | I would prefer having this kind of variable "visible" instead of "hidden" |
| 09:57 | kados | yea, that makese sense |
| 09:57 | tumer | pierick + |
| 09:57 | pierrick | I've seen this everywhere in the reservation screen, it quickly becomes very confusing |
| 09:58 | if (not not ... and not ... and ...) | |
| 09:58 | kados | yep |
| 09:59 | pierrick | and also if you want to keep the binary format, rename the field to "visibility" |
| 09:59 | because "hidden" is yes/no, "visibility" can mean what you want | |
| 09:59 | it's a matter of consistency | |
| 10:00 | when I look at items.notforloan, I'm expecting yes or no, nothing else | |
| 10:00 | kados | yea, that's another one that's confusing |
| 10:00 | pierrick | ... and instead I find no, or many possibilities for yes |
| 10:01 | kados | yep |
| 10:01 | but it didn't start that way | |
| 10:01 | originally it was a flag | |
| 10:01 | but then we realized we needed more values for it | |
| 10:01 | pierrick | first it's confusing because it's a negative variable, then you don't get what you expect |
| 10:01 | kados | yep |
| 10:01 | pierrick | kados, just as for "hidden" I suppose |
| 10:01 | kados | exactly |
| 10:02 | pierrick | So you understand why I consider using binaries encoding created inconsistency? |
| 10:03 | kados | I completely understand how it has made the process of learning Koha from a development point of view, frustrating |
| 10:03 | pierrick | concerning items.notforloan, we should have added a field "notforloanreason" for example |
| 10:03 | kados | maybe ... |
| 10:03 | really what should have been done there is to rename the column :-) | |
| 10:03 | pierrick | or modify the field name to "loanability" |
| 10:03 | :-) | |
| 10:04 | kados | yea, well back when koha was just chris a paul it wasn't a big deal |
| 10:04 | because they pretty much knew the whole thing by heart | |
| 10:04 | but now that it's getting bigger we need to start doing things in a more universally accepted way | |
| 10:04 | paul | yep. |
| 10:04 | pierrick | yes, but it's not the way we want it today, am I right? |
| 10:05 | kados | pierrick: you're right |
| 10:08 | btoumi | bye everybody |
| 10:08 | paul | bye btoumi |
| 10:12 | tumer | pierric: I've implemented a field called linkid in authorities. That field will never get filled with anything. Is that ok with you or very unconventional. |
| 10:12 | pierrick | tumer, what's the purpose of a useless field ? |
| 10:13 | tumer | this gives teh opprtunity of linking authority fieds on any subfield rather than hardcoding subfield number in code |
| 10:13 | I call it convenience field | |
| 10:14 | pierrick | why do you say it won't be filled ? |
| 10:15 | tumer | In marc we use this multiple times just or adressing the subfield . So infact you may need any number of these |
| 10:15 | pierrick | if you need it more than once, you have to create a specific table |
| 10:15 | for linking authorities | |
| 10:16 | you want to link an authority with another authority or with a biblio? | |
| 10:16 | tumer, you want to link an authority with another authority or with a biblio? | |
| 10:16 | tumer | If a records links to more than one record I use this field more than once. I will not bother filling a field that I will not extract data from |
| 10:17 | It links one authority to multiple other authorities | |
| 10:18 | pierrick | so create, authority_links with fields : from, to, type |
| 10:18 | kados | tumer: have you thought any more about the advantages of switching to a marc21-style authorities scheme? |
| 10:18 | tumer | kados: yes I'm switching to that and this is part of that |
| 10:19 | this :-@ server | |
| 10:19 | kados | tumer: if I understand correctly, in MARC21 you can have multiple authority links within a single biblio field (tag) |
| 10:20 | for instance ... | |
| 10:20 | 651 $aGeorgia $xCodes $xAmmendments and revisions | |
| 10:20 | take that biblio field | |
| 10:20 | tumer | say again? |
| 10:20 | kados | in MARC21 $a, $x, and $x could all be linked to separate authority records |
| 10:20 | so you only have one authority record for 'Codes' | |
| 10:21 | and only one for 'Ammendments and revisions' | |
| 10:21 | and only one for 'Georgia' | |
| 10:21 | rather than a single authority record for $aGeorgia $xCodes $xAmmendments and revisions | |
| 10:21 | I think this is why MARC21 doesn't use ids to link authority to bib but uses string matching instead :-) | |
| 10:22 | tumer | hmm not at the moment no I do not have that |
| 10:22 | kados | (but I'm not 100% sure on this ... we'd have to ask Thomas ) |
| 10:22 | (thomas is attending his father's funeral at the moment and won't be back for a week or so) | |
| 10:30 | pierrick | is it possible to export bib from Koha? |
| 10:30 | paul | pierrick: yes |
| 10:30 | koha >> parameters >> export | |
| 10:30 | improved by hdl for 2.4.0 | |
| 10:32 | pierrick | *.mrc is for Marc record, right? |
| 10:33 | so Koha exports in iso2709? | |
| 10:33 | paul, what kind of improvement were made by hdl for 2.4.0? | |
| 10:34 | paul | filtering on export (on a branch / itemtype iirc) + possibility to export only X record, for testing purposes |
| 10:34 | pierrick | OK, that's what I have in my rel_2_2 installation |
| 10:34 | paul | yep |
| 10:34 | kados | I think there's also a command-line version that I committed |
| 10:35 | paul | mmm... I missed this. it's on rel_2_2 ? |
| 10:36 | pierrick | so export in iso2709, nothing else? |
| 10:36 | kados | paul: yew, rel_2_2 |
| 10:36 | pierrick: MARCXML too | |
| 10:37 | pierrick | kados, good for MARC XML |
| 10:37 | is that in the command line tool you coded? | |
| 10:37 | kados | pierrick: let me write that real quick and commit |
| 10:37 | it'll take two seconds :-) | |
| 10:38 | pierrick: all our MARC stuff is handled by the MARC::Record suite | |
| 10:38 | pierrick: so adding MARCXML export is just a matter of a two line change | |
| 10:39 | pierrick: to that export script | |
| 10:39 | paul | yes, & we could add it on export.pl as well. That could be a "marketing feature" : "yey, dude, Koha is XML compliant, it rocks" |
| 10:42 | kados | we've resolved all of the encoding problems for MARC21 from MARC-8 to UTF-8 and back again ... and we have a plan for handling non-MARC8 data ... |
| 10:42 | but the UNIMARC encoding stuff is still untested | |
| 10:43 | I haven't had a chance to test my newfound knowledge of XML::SAX on UNIMARC records yet | |
| 10:43 | did everyone see my mail about encoding? | |
| 10:45 | pierrick | kados, I've read it but not tested it yet |
| 10:48 | paul | kados: I saw it, as well as the discussion on perl4lib, but could not give it a try. |
| 10:48 | I plan to do it in 2 weeks | |
| 11:20 | tumer | kados are you around? |
| 11:21 | kados | tumer: yep |
| 11:21 | tumer | regarding authorities |
| 11:22 | what I think of implementing in future | |
| 11:22 | kados | yea? |
| 11:23 | tumer | an authority marc record will be filled like you suggested $x from somewher $z from countries etc. |
| 11:24 | but we still save that as one record with the correct order od fubfields | |
| 11:24 | currenctly I can link as many authoriies as I like together | |
| 11:24 | MARC21 uses 750 for that so I use 750 | |
| 11:25 | its not hardcoded so hdl can use it for 500 if he likes | |
| 11:25 | $6 $8 or whatever is not hardcoded | |
| 11:25 | all user definable | |
| 11:26 | kados | right |
| 11:26 | tumer | LC shows authorities as $aSomething$xSubsumthing$zcountry |
| 11:26 | kados | tumer: what confuses me is how to you link multiple authorities within a single MARC tag? |
| 11:27 | tumer | So I add the subfields as $a $x ato summary as well |
| 11:28 | You just use multiple 750s for multiple linking | |
| 11:29 | within the authority record its similar to biblio record. $x you say authsubfields $z countries as if they are authorities as well | |
| 11:29 | which they are | |
| 11:30 | You do not link those you just fill them from authority tables with ... appearing | |
| 11:30 | getiing you more confused? | |
| 11:32 | The filling of subfields from differnt authorities I did not commit as its still experimental | |
| 11:33 | kados | sorry ... got a phone call |
| 11:33 | I'm here now | |
| 11:34 | tumer | Ok lets strat again |
| 11:34 | kados | tumer: what confuses me is how to you link multiple authorities within a single MARC tag? |
| 11:34 | :-) | |
| 11:34 | eg: $aSomething$xSubsumthing$zcountry | |
| 11:34 | how can Something, Subsumthing and country all be linked to separate auth records? | |
| 11:35 | tumer | I have not implemented that part but plan is like filing biblios |
| 11:36 | This is not conventional but if we do not want to write lots of code | |
| 11:37 | every single subfield gets filled by another authority using the ... notation | |
| 11:37 | except that in biblios $a gets filled by $a | |
| 11:37 | but in authorities $x (calling subfield) gets filled by $a | |
| 11:38 | kados | so you're idea is to create a 'meta authority' that is linked to child auth records for certain fields? |
| 11:38 | tumer | my implemented method uses some part of this already |
| 11:39 | Meta authority is whats described at the devel week I believe | |
| 11:40 | You have an authority for each subfield . Countries, Subjects, Subheadings. I think thats wat thomas said | |
| 11:40 | kados | could be ... |
| 11:41 | though I thought there was just a direct link between the biblio subfields and the authority records | |
| 11:41 | without the intermediate meta authority | |
| 11:42 | tumer | There is a direct link with biblio and authority record. But that authority record is filled from differnt authorities at cataloguing time |
| 11:43 | That authority could be linked to other authorities | |
| 11:43 | Those get displayed on the fly as a linking authority | |
| 11:43 | in my case a differnt language version | |
| 11:44 | kados | I understand the linking authorities |
| 11:44 | but what I'm not sure of is how MARC21 treats linking between bib and auth record | |
| 11:44 | tumer | in hdls case a broaderterm authority |
| 11:44 | kados | eg can Something, Subsumthing and co |
| 11:44 | oops | |
| 11:44 | eg eg: $aSomething$xSubsumthing$zcountry | |
| 11:44 | I think in MARC21 | |
| 11:45 | $Something links to one authority | |
| 11:45 | $xSubsumthing links to another | |
| 11:45 | tumer | No |
| 11:45 | kados | $zcountry links to yet another |
| 11:45 | tumer | No |
| 11:45 | No | |
| 11:45 | kados | :-) |
| 11:45 | ok well I don't know for sure | |
| 11:46 | and in fact, I've had a hard time finding any decent overview of how it should work | |
| 11:46 | tumer | marc21 $asomething $zcountry $xsomotherthing links to one authority |
| 11:46 | which says $asomething $zcountry $xsomotherthing (notice $a$z$x order) | |
| 11:47 | that is one record of authority | |
| 11:47 | kados | ok |
| 11:48 | tumer | any authority record that says $asomething $xsomotherthing $zcountry is another authority |
| 11:48 | kados | interesting |
| 11:49 | tumer | the different authorities of countries etc is at authority creation level not at biblio level |
| 11:49 | kados | I see ... |
| 11:49 | what I think we need | |
| 11:49 | tumer | So catalogers pulls together different authorities together and creates one authority record |
| 11:50 | kados | are some real examples of unimarc and marc21 standard authorities and bibs that use them |
| 11:50 | ahhh ... so that's the key | |
| 11:50 | tumer | That is now authority. Any modifications to the order of subfields is not permitted |
| 11:50 | kados | in that case, we're very close to being fully MARC21 standard compliant |
| 11:50 | tumer | yep |
| 11:51 | kados | excelletn |
| 11:51 | excellent even | |
| 11:52 | tumer | In KOHA though we can get away with having $a$x$z as one and $a$z$x as another authority |
| 11:52 | In KOHA though we can get away with having $a$x$z as one and $a$z$x as another authority | |
| 11:53 | the cataloger may change the order of subfields as tehy wish at biblio level | |
| 11:54 | anyway more food for thought |
← Previous day | Today | Next day → | Search | Index