← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:44 | fbcit | g'morning koha |
| 14:55 | hdl | hi |
| 14:55 | kados around ? | |
| 14:55 | kados | hdl: yep |
| 14:55 | g'morning | |
| 14:55 | hdl | hi. |
| 14:56 | I already asked you. But problem is not solved here. | |
| 14:56 | on advsearch, | |
| 14:56 | search on kw are doing expression search and not wordlist search. | |
| 14:56 | Is there something we can doo about it ? | |
| 14:57 | We use the same ccl.properties. | |
| 14:57 | kados | yep, and I have verified it |
| 14:57 | 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 | Is there an other solution ? | |
| 14:59 | kados | I have it on my list |
| 14:59 | there may be a simple solution | |
| 15:00 | are you sure you want 'word list' instead of 'word' as the default? | |
| 15:00 | hdl | why should I say no ? |
| 15:01 | 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 | Z> find @attr 1=Title @attr 4=6 "mozart amadeus" | |
| 15:01 | 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 | thing tha user sees ? | |
| 15:03 | kados | yes |
| 15:03 | I'm investigating where to set the default | |
| 15:05 | hdl | maybe we could strip out all the attributes modifiers from humansearchdesc ? |
| 15:06 | Would Querystemming use french if locale is french ? | |
| 15:06 | kados | yep |
| 15:06 | it could | |
| 15:06 | paul | (hi kados) |
| 15:07 | 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 | hdl: minor modif (maybe a syspref) to make that work | |
| 15:07 | 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 | I'm investigating now | |
| 15:09 | 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 | (or i'm a genius, as I do things without knowing :o) ) | |
| 15:10 | kados | :) |
| 15:10 | it could support stemming quite easily as well | |
| 15:10 | as the stemming is handled by an external library | |
| 15:16 | ok, I've founda good place for it | |
| 15:16 | lemme test for a few minutes | |
| 15:27 | 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 | 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 | date, year, word, keyword, etc | |
| 15:32 | I'll investigate all of the 4= attributes, I've just noticed some redundencies | |
| 15:32 | in our ccl.properties | |
| 15:35 | hdl: working? | |
| 15:38 | hdl | cannot test right now. |
| 15:38 | 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 | Could be a problem with dates. | |
| 15:45 | Have to test it deeper. | |
| 15:46 | kados | hdl: yes, just noticed that |
| 15:46 | hdl: I'm fixing it now | |
| 15:47 | hdl: I am altering the ccl.properties to remove all structure attributes | |
| 15:47 | hdl: (just multi-parameter ones) | |
| 15:48 | and we'll do: | |
| 15:48 | unless (!$index || $index =/(st-|phr|ext|wrdl)/) { | |
| 15:48 | $structure = ",wrdl"; | |
| 15:48 | to set the default | |
| 15:53 | hdl: we have 'Date' and Date-of-publication' and 'Date-of-Acquisition' set to 'numeric string' rather than a date index | |
| 15:53 | hdl: any reason for that? | |
| 15:53 | why aren't we using 'Date (normalized)' ? | |
| 15:53 | (4=5) | |
| 15:55 | some of the 'Date' fields are clearly type 'year' | |
| 15:56 | like in the 008 def for marc21 | |
| 15:56 | others, like 033 I'm not sure about | |
| 15:57 | gmcharlt: do you have any impressions about the best method for indexing dates like pubdate and copydate ? | |
| 15:57 | 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 | 033 is not commonly used for monos; may be for other formats | |
| 15:59 | 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 | 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 | 198u, 20uu, etc. | |
| 16:00 | kados | ahh |
| 16:01 | 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 | right: convention in 033 appears to be hyphens | |
| 16:01 | kados | so acqdate is easy, since we control that field |
| 16:01 | 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 | yea, but 005 is updated every time the record is edited, so it's not strictly an acqdate | |
| 16:02 | /is/shouldbe/ | |
| 16:02 | 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 | 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 | gmcharlt: so no good way to get copyright date? | |
| 16:15 | 260c maybe? | |
| 16:15 | gmcharlt | it's transcribed in 260$c |
| 16:15 | kados | should we normalize 260c? |
| 16:15 | 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 | *nod* | |
| 16:17 | 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 | e.g., 'itm' instead of 952, 'dat' for normalized dates, etc. | |
| 16:18 | kados | that makes sense |
| 16:18 | not sure MARC:: will allow it | |
| 16:19 | 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 | that or else make an XML schema that does two things: | |
| 16:20 | [1] warps MARC XML | |
| 16:20 | (or any metadata type Koha supports) | |
| 16:21 | s/warp/wrap/ -- MARC is warped enough | |
| 16:21 | [2] contains additional indexing and administration data | |
| 16:22 | 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 | 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 | if not it should be filed | |
| 16:32 | paul | filed. (1658à |
| 16:32 | ) | |
| 16:32 | kados | hdl around? |
| 16:33 | hdl: in your record.abs you have a tpubdate and a pubdate | |
| 16:33 | 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 | (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 | but it's too imature IMO for 3.0 ... I didn't remove it, just commented it out IIRC | |
| 16:34 | 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 | 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 | 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 | 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 | date indexing in Koha 3.0 for MARC21: | |
| 16:55 | Index Expected format Notes | |
| 16:55 | date-entered-on-file [yymmdd] (008/0-5, indexed in word and sort indexes) | |
| 16:55 | copydate [yyyy] (260$c, indexed in word and sort indexes) | |
| 16:55 | acqdate [yyyy-mm-dd] (952$d, indexed in date,word,sort indexes) | |
| 16:55 | pubdate [yyyy] (008/7-10, indexed in year,word,sort indexes) | |
| 16:56 | gmcharlt | kados: looks ok |
| 16:59 | 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 | it needs porting for other platforms and some dressing up too, but works in its current state | |
| 17:02 | 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 | will you have to time to work that out? | |
| 17:08 | fbcit | sure |
| 18:17 | [K] | *** join #koha FreeNode: ru55el n=russel203-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 | minor patches submitted | |
| 19:23 | chris | got them atz |
| 19:23 | signing off now and sending them on | |
| 19:34 | [K] | *** join #kohaFreeNode: maktrix n=mak59.152.90.138 |
| 19:34 | <maktrixFreeNode> hello all |
|
| 19:35 | chris | hi matrix |
| 19:38 | [K] | <maktrixFreeNode> [K]: I'm from Bangladesh |
| 19:40 | chris | sorry in a meeting at the moment, i can talk later though |
| 19:40 | [K] | <maktrixFreeNode> :) no prob. will talk later |
| 19:57 | hdl | kados : In ccl.properties, you do Date-Of-Publication 1=pubdate r=r |
| 19:57 | rather than 1=31 4=4 r=r. | |
| 19:57 | Is there a reason ? | |
| 20:00 | [K] | *** part FreeNode!#koha: ru55el n=russel203-118-134-114.netspace.net.nz |
| 21:24 | *** part FreeNode!#koha: maktrix n=mak59.152.90.138 |
|
| 22:37 | chris | back |
| 23:19 | [K] | *** join #kohaFreeNode: ru55el n=russel203-118-134-114.netspace.net.nz |
| 23:45 | *** join #kohaFreeNode: DrDogwelder n=DrDogwelmail.wlpl.org |
|
| 23:45 | *** part FreeNode!#koha: DrDogwelder n=DrDogwelmail.wlpl.org |
|
| 23:59 | slef | gmcharlt: are you there? |
| 23:59 | hi all | |
| 00:00 | kados | hey slef |
| 00:00 | gmcharlt | hi slef |
| 00:00 | how goes it? | |
| 00:00 | slef | odd... just tried to pull your tree and it hit conflicts |
| 00:01 | 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 | rebase is for local topic branches, really, that you'll merge into your main tree | |
| 00:02 | 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 | hi fbcit | |
| 01:56 | fbcit | hi gmcharlt |
| 01:57 | gmcharlt | fbcit: great |
| 01:57 | 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 | when did that happen? | |
| 01:59 | fbcit | gmcharlt: {ANY_MACRO => ANY_VALUE, ...} |
| 01:59 | per MM docs... | |
| 01:59 | chris | did we ever have biblio.subtitle? |
| 01:59 | 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 | and that field no longer displays | |
| 02:00 | in results, etc. | |
| 02:00 | :( | |
| 02:01 | chris | has someone killed that whole table? |
| 02:01 | gmcharlt | fbcit: I see |
| 02:01 | chris | yep, so they have |
| 02:01 | somewhere between 2.2 and 3 | |
| 02:01 | fbcit | gmcharlt: it appears dmake considers it a macro: |
| 02:01 | dmake [-P#] [-{f|C|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value ...] | |
| 02:03 | gmcharlt: currently it passes in like >dmake -x MAXLINELENGTH=300000 | |
| 02:04 | 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 | go to commit that has move | |
| 02:05 | click on lnk to original file | |
| 02:05 | chris | ahh cool ta |
| 02:05 | gmcharlt | then click on history link |
| 02:07 | 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 | never made it to 3 | |
| 02:09 | 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 | so we can do the same for the subtitle | |
| 02:10 | 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 | $b is not repeatable | |
| 02:12 | so a direct mapping shoudln't hurt | |
| 02:12 | 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 | my $record = GetMarcBiblio($biblionumber); | |
| 02:19 | my $marcnotesarray = GetMarcNotes( $record, $marcflavour ); | |
| 02:19 | my $marcauthorsarray = GetMarcAuthors( $record, $marcflavour ); | |
| 02:19 | my $marcsubjctsarray = GetMarcSubjects( $record, $marcflavour ); | |
| 02:19 | 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 | 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 | but we do need a solution to subtitle in general | |
| 02:21 | I believe it comes through in the BIBLIO_RESULTS ... or I mean is expected | |
| 02:22 | in the template | |
| 02:22 | 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 | I'll look at the ENV option | |
| 02:32 | s/ENV/ENV VAR/g | |
| 02:33 | I'm testing the pl_file shebang fix now | |
| 02:41 | gmcharlt: man page for dmake reads: | |
| 02:41 | MAXLINELENGTH | |
| 02:41 | 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 | which I read as meaning we cannot pass it in as an env var... | |
| 02:42 | and which makes me wonder why I can't pass it in as a macro... | |
| 02:46 | ahh, it appears that control macros cannot be used inside of "recipes"... | |
| 09:31 | [K] | *** join #kohaFreeNode: aleix n=aleix194.158.78.231 |
| 09:31 | *** part FreeNode!#koha: aleix n=aleix194.158.78.231 |
|
| 10:03 | lea | hi there |
| 10:06 | 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 | hdl: can you verify that on the staff client all the bugs are resolved? | |
| 10:48 | I still need to walk through the opac side and make sure all of the patches have been applied there as well | |
| 10:49 | and ... can you confirm that the changes to the display in results for 'location' and 'callnum' conform to what your customers need? | |
| 10:49 | (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 | They would rather have the issued item pointed at result list than simply having a count | |
| 10:51 | When you have 20 libraries, France wide. | |
| 10:52 | And your user wants to know if he can check out one book at his library. | |
| 10:52 | Knowing there are 10 items with one checked out is helpless. | |
| 10:53 | kados | *nod* |
| 10:54 | and now it shows copies available at 'library 1 (count), library 2 (count), etc.', right? | |
| 10:54 | instead of just statuses | |
| 10:54 | is that what you mean? | |
| 10:58 | paul_: around? |
← Previous day | Today | Next day → | Search | Index
