IRC log for #koha, 2007-12-18

All times shown according to UTC.

Time S Nick Message
12:44 fbcit g'morning koha
14:55 hdl hi
14:55 hdl kados around ?
14:55 kados hdl: yep
14:55 kados g'morning
14:55 hdl hi.
14:56 hdl I already asked you. But problem is not solved here.
14:56 hdl on advsearch,
14:56 hdl search on kw are doing expression search and not wordlist search.
14:56 hdl Is there something we can doo about it ?
14:57 hdl We use the same ccl.properties.
14:57 kados yep, and I have verified it
14:57 kados it happens when QueryStemming is turned off
14:58 hdl We cannot turn it on since french stemming is not the same as American Stemming.
14:59 hdl Is there an other solution ?
14:59 kados I have it on my list
14:59 kados there may be a simple solution
15:00 kados are you sure you want 'word list' instead of 'word'  as the default?
15:00 hdl why should I say no ?
15:01 hdl We have expr if we want exact search.
15:01 kados The structure attribute values Word list (6)  is supported, and maps to the boolean AND  combination of words supplied. The word list is useful when google-like bag-of-word queries need to be translated from a GUI query language to PQF. For example, the following queries are equivalent:
15:01 kados      Z> find @attr 1=Title @attr 4=6 "mozart amadeus"
15:01 kados      Z> find @attr 1=Title  @and mozart amadeus
15:02 hdl This is why I added wrdl attribute to all the attributes in advsearch.
15:03 kados *nod* but it shouldn't be a user-facing attribute
15:03 hdl user-facing ?
15:03 hdl thing tha user sees ?
15:03 kados yes
15:03 kados I'm investigating where to set the default
15:05 hdl maybe we could strip out all the attributes modifiers from humansearchdesc ?
15:06 hdl Would Querystemming use french if locale is french ?
15:06 kados yep
15:06 kados it could
15:06 paul (hi kados)
15:07 paul I once tried and got complete failure. but I haven't investigated deeply what happends
15:07 hdl Could or does ?
15:07 kados hdl: see _build_stemmed_operand
15:07 kados hdl: minor modif (maybe a syspref) to make that work
15:07 kados Lingua::Stem supports FR-FR AFAIK
15:09 hdl Yes, but this is told to be only basic stemming problems.
15:09 kados yep, I agree we need to work on word list separate from stemming
15:09 kados I'm investigating now
15:09 kados it shouldn't be a difficult problem
15:09 paul + the proble that hdl reports is the same for NoZebra & NZ don't support stemming
15:10 paul (or i'm a genius, as I do things without knowing :o) )
15:10 kados :)
15:10 kados it could support stemming quite easily as well
15:10 kados as the stemming is handled by an external library
15:16 kados ok, I've founda  good place for it
15:16 kados lemme test for a few minutes
15:27 kados hdl,paul: ok, I've got a patch, do you want me to push it up mainline or email to you for testing?
15:28 kados hdl: let me know what email you prefer
15:29 hdl henridamien at koha hyphen fr dot org
15:29 kados hdl: sent
15:31 kados date, year, word, keyword, etc
15:32 kados I'll investigate all of the 4= attributes, I've just noticed some redundencies
15:32 kados in our ccl.properties
15:35 kados hdl: working?
15:38 hdl cannot test right now.
15:38 hdl will test it tonight.
15:44 fbcit g'morning again koha
15:44 hdl kados : I saw your patch.
15:44 kados hiya fbcit
15:45 gmcharlt hi fbcit
15:45 hdl It is adding wrdl to any index without modifier.
15:45 hdl Could be a problem with dates.
15:45 hdl Have to test it deeper.
15:46 kados hdl: yes, just noticed that
15:46 kados hdl: I'm fixing it now
15:47 kados hdl: I am altering the ccl.properties to remove all structure attributes
15:47 kados hdl: (just multi-parameter ones)
15:48 kados and we'll do:
15:48 kados unless (!$index || $index =/(st-|phr|ext|wrdl)/) {
15:48 kados $structure = ",wrdl";
15:48 kados to set the default
15:53 kados hdl: we have 'Date' and Date-of-publication' and 'Date-of-Acquisition' set to 'numeric string' rather than a date index
15:53 kados hdl: any reason for that?
15:53 kados why aren't we using 'Date (normalized)' ?
15:53 kados (4=5)
15:55 kados some of the 'Date' fields are clearly type 'year'
15:56 kados like in the 008 def for marc21
15:56 kados others, like 033 I'm not sure about
15:57 kados gmcharlt: do you have any impressions about the best method for indexing dates like pubdate and copydate ?
15:57 kados should it be based on the year, or a full date? and if a full date, what's the best method for getting a normalized date string out of the MARC?
15:58 gmcharlt for monographs, year is sufficient
15:59 gmcharlt 033 is not commonly used for monos; may be for other formats
15:59 gmcharlt my impression is that there should be two types of date indexes: year and full timestamp
15:59 kados ok, so stick with date1 in 001?
15:59 kados 008 I mean
16:00 gmcharlt date1 in 008 is OK for now
16:00 kados there is 'year of pub' not the same as 'year of copyright' right?
16:00 gmcharlt but main issue is dealing with incompletely entered dates
16:00 gmcharlt 198u, 20uu, etc.
16:00 kados ahh
16:01 kados yea, now that you mention it, there are a few conventiosn for partial entry of dates IIRC
16:01 gmcharlt and right, year of pub not necessarily equal to copyright date
16:01 gmcharlt right: convention in 033 appears to be hyphens
16:01 kados so acqdate is easy, since we control that field
16:01 kados pubdate will be a year and I'll use date1 from 008
16:02 gmcharlt yep; indexing 005 timestamp should also be easy
16:02 kados copydate I'm not sure about
16:02 kados yea, but 005 is updated every time the record is edited, so it's not strictly an acqdate
16:02 kados /is/shouldbe/
16:02 kados also IIRC :-)
16:02 gmcharlt true: so 005 is not necessarily of interest in OPAC index (might be for a staff index, though)
16:03 kados *nod*
16:03 gmcharlt fuller indexing of 008 dates will take more work, but can be deferred IMO
16:03 kados shoudl I bother with date2 ?
16:03 gmcharlt e.g, if 008/06 = 'e', Date1 contains year and Date2 contains month and day
16:04 gmcharlt Date2 can be of interest to serials
16:04 kados ok, so we'll defer that until 3.2
16:04 gmcharlt yep
16:04 kados dom filtering will make that a lot easier anyway
16:05 gmcharlt yep: make it easy to point all of the errors that catalogers have made in filling out those fields ;-)
16:05 kados hehe
16:14 kados gmcharlt: so no good way to get copyright date?
16:15 kados 260c maybe?
16:15 gmcharlt it's transcribed in 260$c
16:15 kados should we normalize 260c?
16:15 kados or do a normalized version in 260$9 or sth?
16:15 gmcharlt yep -- generally approach is to grab whatever matches something like /\d[u0-9]{3}/
16:16 kados I can do a regex match with zebra
16:16 gmcharlt normalized version should exist somewhere, but I'm a leary of putting in in the MARC record itself -- at least the version that is displayed and that cataloger edits
16:16 kados but that won't work for sorting
16:16 kados *nod*
16:17 kados it can be system-generated and maintained ... ie, marked 'hidden' from the catalog client
16:17 gmcharlt yep -- and I'm wondering if we shouldn't see if we can set up a convention of using alphabetic tags for stuff that is generated or maintained solely for the benefit of indexing
16:18 gmcharlt e.g., 'itm' instead of 952, 'dat' for normalized dates, etc.
16:18 kados that makes sense
16:18 kados not sure MARC:: will allow it
16:19 kados but we can certainly patch it to allow that :-)
16:20 gmcharlt somebody already requested that (because ALEPH uses a lot of alphabetic tags), so we'd be adding on to the pile
16:20 gmcharlt that or else make an XML schema that does two things:
16:20 gmcharlt [1] warps MARC XML
16:20 gmcharlt (or any metadata type Koha supports)
16:21 gmcharlt s/warp/wrap/ -- MARC is warped enough
16:21 gmcharlt [2] contains additional indexing and administration data
16:22 gmcharlt lead Koha to the path of munching on all metadata (yum, yum)
16:25 kados *nod*
16:27 gmcharlt thinking about it, I like that more than stuffing custom tags in the bib records
16:28 aklibrarian Good morning all.
16:28 paul kados : I once have sent you a patch to fix <span class="term"> inside author link. You've rejected it because it was too simple & said that you planned to work on a more complete fix.
16:29 paul atm, there is no more complete fix if I don't mind !
16:30 kados paul: yes, also on my list
16:30 paul ok, so i don't file a new bug ;-)
16:31 kados no, you can file a bug, but I thought there was already one there
16:31 kados if not it should be filed
16:32 paul filed. (1658à
16:32 paul )
16:32 kados hdl around?
16:33 kados hdl: in your record.abs you have a tpubdate and a pubdate
16:33 kados hdl: is that a typo?
16:33 paul kados : you seem to have removed the bulkmodif feature. was it by mistake or voluntary ?
16:34 paul (I mean the feature to bulkedit the result of a search. A feature that our libraries find very interesting)
16:34 kados I agree it's very interesting
16:34 kados but it's too imature IMO for 3.0 ... I didn't remove it, just commented it out IIRC
16:34 kados it makes the results page on the staff client very slow
16:35 paul it's because of the marc list, right ?
16:35 kados yep
16:35 kados and also, IMO it shouldn't appear for every search anyway
16:35 paul what about just removing the list & let the user enter the marc field/subfield name ?
16:35 kados that could work ... but still, it should be in tools/
16:36 kados and should be called 'global update' or something
16:45 fbcit gmcharlt: I'm going to send you a patch for the work I've done so far adding Win32 support to installer...
16:45 gmcharlt fbcit: great
16:46 fbcit its a work in progress, but installer still works fine with the patch applied AFAIK
16:52 fbcit gmcharlt: sorry... the first is a git-diff, the second is the patch...
16:55 kados gmcharlt: in summary of our dates discussion
16:55 kados date indexing in Koha 3.0 for MARC21:
16:55 kados Index                   Expected format         Notes
16:55 kados date-entered-on-file    [yymmdd]        (008/0-5, indexed in word and sort indexes)
16:55 kados copydate                [yyyy]          (260$c, indexed in word and sort indexes)
16:55 kados acqdate                 [yyyy-mm-dd]    (952$d, indexed in date,word,sort indexes)
16:55 kados pubdate                 [yyyy]          (008/7-10, indexed in year,word,sort indexes)
16:56 gmcharlt kados: looks ok
16:59 gmcharlt fbcit: looking at the patch, it looks fixshebang is defined but not currently invoked -- am I reading that right?
17:00 fbcit gmcharlt: right, I have to decide how/where to invoke it
17:01 fbcit it needs porting for other platforms and some dressing up too, but works in its current state
17:02 fbcit I wonder if it could be run against blib to avoid changing the original package files....
17:02 gmcharlt fbcit: I'm thinking that it should be put into a separate script, e.g., fix-perl-path.PL and invoked in blib similar to rewrite-config.PL
17:02 fbcit gmcharlt: excellent idea!
17:03 gmcharlt to be automatically invoked in single and standard mode
17:03 fbcit ++
17:04 gmcharlt the recursion could either be done in Makefile.PL (to build up the list of files to be fixed), or just give it a dummy argument in PL_FILES and have it do the recursion
17:08 fbcit the latter probably represents the least changes to Makefile.PL
17:08 gmcharlt yep
17:08 gmcharlt will you have to time to work that out?
17:08 fbcit sure
18:17 [K] *** join #koha@FreeNode: ru55el n=russel@203-118-134-114.netspace.net.nz
18:59 kados heads up koha devs, some patches just pushed up with bugfixes
19:21 atz cool, just rebased
19:21 atz minor patches submitted
19:23 chris got them atz
19:23 chris signing off now and sending them on
19:34 [K] *** join #koha@FreeNode: maktrix n=mak@59.152.90.138
19:34 [K] <maktrix@FreeNode> hello all
19:35 chris hi matrix
19:38 [K] <maktrix@FreeNode> [K]: I'm from Bangladesh
19:40 chris sorry in a meeting at the moment, i can talk later though
19:40 [K] <maktrix@FreeNode> :) no prob. will talk later
19:57 hdl kados : In ccl.properties, you do Date-Of-Publication 1=pubdate r=r
19:57 hdl rather than 1=31 4=4 r=r.
19:57 hdl Is there a reason ?
20:00 [K] *** part FreeNode!#koha: ru55el n=russel@203-118-134-114.netspace.net.nz
21:24 [K] *** part FreeNode!#koha: maktrix n=mak@59.152.90.138
22:37 chris back
23:19 [K] *** join #koha@FreeNode: ru55el n=russel@203-118-134-114.netspace.net.nz
23:45 [K] *** join #koha@FreeNode: DrDogwelder n=DrDogwel@mail.wlpl.org
23:45 [K] *** part FreeNode!#koha: DrDogwelder n=DrDogwel@mail.wlpl.org
23:59 slef gmcharlt: are you there?
23:59 slef hi all
00:00 kados hey slef
00:00 gmcharlt hi slef
00:00 gmcharlt how goes it?
00:00 slef odd... just tried to pull your tree and it hit conflicts
00:01 slef have you done anything odd with your master, like rebase it?
00:01 gmcharlt slef: yes, I've been rebasing it to keep in sync -- is there a better way?
00:01 slef yes, merge from master, else you cause conflicts for everyone pulling your branch
00:02 slef rebase is for local topic branches, really, that you'll merge into your main tree
00:02 slef not for long-term branches
00:03 gmcharlt slef: ok (although I do intend for this to be merged into git.koha.org sooner rather than later)
00:04 kados pending slef's approval :-)
00:05 slef I'd like to merge it across into mjr-installer and debianised and see what happens
00:06 gmcharlt fbcit's done some work to get installer to work on cygwin and Strawberry Perl; after he does a bit more, I'll merge in his stuff tomorrow
01:45 gmcharlt hi fbcit
01:56 fbcit hi gmcharlt
01:57 gmcharlt fbcit: great
01:57 gmcharlt awaiting your patches :)
01:57 fbcit I think I found a way to pass MAXLINELENGTH to dmake via Makefile.PL
01:57 gmcharlt env var?
01:58 fbcit macro =>
01:58 kados huh
01:58 fbcit inside WriteMakefile()
01:58 kados so did we just completely lose biblio.subtitle?
01:59 kados when did that happen?
01:59 fbcit gmcharlt: {ANY_MACRO => ANY_VALUE, ...}
01:59 fbcit per MM docs...
01:59 chris did we ever have biblio.subtitle?
01:59 chris we had a subtitles table
02:00 fbcit gmcharlt: check out the section "Additional lowercase attributes"
02:00 gmcharlt fbcit: ok, wasn't expecting that dmake would take that parameter as a macro, but if it works, it works
02:00 kados chris: bibliosubtitle.subtitle
02:00 chris yeah thats the one
02:00 kados chris: so that mapping has been lost
02:00 kados and that field no longer displays
02:00 kados in results, etc.
02:00 kados :(
02:01 chris has someone killed that whole table?
02:01 gmcharlt fbcit: I see
02:01 chris yep, so they have
02:01 chris somewhere between 2.2 and 3
02:01 fbcit gmcharlt: it appears dmake considers it a macro:
02:01 fbcit dmake [-P#] [-{f|C|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value ...]
02:03 fbcit gmcharlt: currently it passes in like >dmake -x MAXLINELENGTH=300000
02:04 fbcit so I'm about to give it a whirl...
02:04 chris hard to find when it went to, as the file has been moved and so we dont have its full commit history
02:04 fbcit took the words out of my mouth... err fingers... :)
02:05 gmcharlt chris: you can use gitweb to follow history, even through moves
02:05 gmcharlt go to commit that has move
02:05 gmcharlt click on lnk to original file
02:05 chris ahh cool ta
02:05 gmcharlt then click on history link
02:07 gmcharlt although it looks like bibliosubtitle preceeds earliest history in git
02:09 chris yep, its in 2.2.x but looks like both it and bibliosubject
02:09 chris never made it to 3
02:09 chris bibliosubject isnt a worry, we dont need it
02:09 kados yea, it's the mappings we're really hurting from
02:09 gmcharlt mappings as in OPAC display?
02:09 kados yea
02:09 chris as we get the subjects from marc
02:09 chris so we can do the same for the subtitle
02:10 chris or get bibliosubtitle back
02:11 gmcharlt is the idea to have these separate tables to avoid the hit of parsing the MARC XML every time?
02:12 kados ideally it'd be called subtitle :-)
02:12 kados $b is not repeatable
02:12 kados so a direct mapping shoudln't hurt
02:12 kados we may want to just add biblio.subtitle?
02:13 gmcharlt that or tack on to biblo.title -- can't think of any time where you would want to display 245$a but not $b
02:14 chris good point
02:14 russel you might want to do different formatting though
02:14 kados unfortunately our frameworks don't allow that atm, do they
02:15 russel have the title in large print - subtitle smaller or not bold  etc
02:19 chris kados: in opac-detail.pl we have
02:19 chris my $record           = GetMarcBiblio($biblionumber);                                                                                                  
02:19 chris    my $marcnotesarray   = GetMarcNotes( $record, $marcflavour );                                                                                          
02:19 chris    my $marcauthorsarray = GetMarcAuthors( $record, $marcflavour );                                                                                        
02:19 chris    my $marcsubjctsarray = GetMarcSubjects( $record, $marcflavour );
02:19 chris etc
02:19 kados yea
02:20 chris might be easiest just to add my $subtitle = GetSubtitle($record, $marcflavour);
02:20 kados yea
02:20 kados pain in the butt though
02:20 chris yep
02:21 kados well I just sent you a patch that has a decent workaround for the specific case
02:21 chris k
02:21 kados that I noticed this issue from
02:21 kados but we do need a solution to subtitle in general
02:21 kados I believe it comes through in the BIBLIO_RESULTS ... or I mean is expected
02:22 kados in the template
02:22 kados yep, it is
02:31 fbcit gmcharlt: passing it in as a macro did not work... 'pears dmake parses Makefile prior to execution...
02:31 fbcit I'll look at the ENV option
02:32 fbcit s/ENV/ENV VAR/g
02:33 fbcit I'm testing the pl_file shebang fix now
02:41 fbcit gmcharlt: man page for dmake reads:
02:41 fbcit MAXLINELENGTH
02:41 fbcit This macro defines the maximum size of a single line of makefile input text. The size is specified as a number, the default value is defined internally
02:41 fbcit which I read as meaning we cannot pass it in as an env var...
02:42 fbcit and which makes me wonder why I can't pass it in as a macro...
02:46 fbcit ahh, it appears that control macros cannot be used inside of "recipes"...
09:31 [K] *** join #koha@FreeNode: aleix n=aleix@194.158.78.231
09:31 [K] *** part FreeNode!#koha: aleix n=aleix@194.158.78.231
10:03 lea hi there
10:06 lea I've got a bit of a situation. About this time last year I was assessing Koha to replace our current proprietary system, but it wasn't quite ready yet. A lot of features were coming in V3. As a result, the boss decided to go with the proprietary vendors "online" product. It just doesn't work. He's now considering forking out £5K to a company called Talis. This sucks. So, given that scenario, what would you guys do? (Remember, our data is not fully Marc21, so there
10:47 kados hdl about?
10:48 hdl yes
10:48 kados hdl: I just pushed up the last few patches from my bugfixing of searches yesterday
10:48 kados hdl: can you verify that on the staff client all the bugs are resolved?
10:48 kados I still need to walk through the opac side and make sure all of the patches have been applied there as well
10:49 kados and ... can you confirm that the changes to the display in results for 'location' and 'callnum' conform to what your customers need?
10:49 kados (I remember you said there were some changes that they didn't like but I haven't gotten any specifics, so I'm flying blind :-))
10:50 hdl changes in result page are quite OK.
10:51 hdl They would rather have the issued item pointed at result list than simply having a count
10:51 hdl When you have 20 libraries, France wide.
10:52 hdl And your user wants to know if he can check out one book at his library.
10:52 hdl Knowing there are 10 items with one checked out is helpless.
10:53 kados *nod*
10:54 kados and now it shows copies available at 'library 1 (count), library 2 (count), etc.', right?
10:54 kados instead of just statuses
10:54 kados is that what you mean?
10:58 kados paul_: around?

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary