← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
12:19 | Sylvain | paul je viens de mettre un fix pour le bug #1013 dont je t'avais parler l'autre jour. Si tu peux vérifier que ça ne casse rien et que ça fonctionne aussi chez toi |
12:31 | bon, j'y vais, si y a un problème, dis le moi | |
12:31 | ciao | |
18:13 | russ | kados: you about? |
18:28 | hi thd | |
18:28 | thd: have you made any more progress with the features section for the website? | |
19:40 | thd | russ: yes I have about three weeks work into it so far and practically put myself on NZ time with sleep loss. |
19:40 | russ | crikey |
19:41 | thd | russ: As I said it is more than just a features list. |
19:42 | russ | have you got anything we can take a look at? |
19:43 | thd | russ: Yes, but I would be afraid to give the wrong impression from just one whole document. |
19:49 | russ | i'd really like to have a look if at all possible |
19:52 | thd | russ: It is currently one large document that needs division by module and development level if not more than that to be readable. |
19:55 | russ: I would have posted something and kept adding to it, however, the design as a large document to be divided has meant that posting it by degrees would be double work for each dividing process. | |
19:55 | russ | right |
19:56 | thd | russ: even suitably divided it might need to be trimmed back to serve as a feature list. |
19:57 | russ | right |
19:57 | any idea how much more you have to do? | |
19:57 | thd | russ: I was grepping for some descriptive text I had written in a paragraph from yesterday but I may not have save that document. |
19:59 | russ: That is the consequence of sleep loss. Forgetting to save ones work :) That was not of great importance. | |
20:00 | russ: I have a tendency to work until I cannot stay awake. That only works for a few days without good rest then productivity falls to almost nothing until the sleep deficit is restored. | |
20:00 | russ | oh well take care, i don't think it is so important that you need to jepordise your sleep |
20:02 | thd | russ: As a feature list it is not overly important however I am trying to do other things with it. |
20:03 | russ: Koha Analytical Feature List and Documentation Index with Demonstration and Example Implementation Links is a title that I have attached to the comprehensive draft file. | |
20:05 | russ | that is a mouthful :-) |
20:05 | thd | russ: So there is the feature list purpose to show not just the obvious and superficial but also the features that cannot be seen without close examination. |
20:05 | russ: Feature list is good for koha.org | |
20:06 | russ | yep |
20:07 | thd | russ: It is easy to come away with a poor impression of Koha by only seeing what is obvious in the demonstration and a cursory examination of documents. |
20:07 | russ: This is especially true with MARC Koha. | |
20:07 | russ | well i dont think poor is the right word, maybe incomplete is a better description |
20:09 | if you could keep us posted on your progress that would be great | |
20:09 | thd | russ: The default configuration gives the impression that MARC support is extremely incomplete instead of modestly incomplete in some ways. |
20:10 | russ-lunch: I will explain some other utility after lunch | |
20:10 | rach | :-) you really are on nz time |
20:11 | thd | :-) |
20:11 | rach: actually I have not had breakfast yet today | |
20:12 | rach | maybe you should do that so you're in sync with each other :-) |
20:15 | thd | kados: are you around |
20:15 | kados: I have some information and a question about adding MARC serials support to Koha | |
20:30 | russ, rach: I found the missing paragraph, for when you get back from lunch. It is good to know that I can save documents while sleepwalking. | |
20:43 | russ: From my lost and now found paragraph... | |
20:44 | This is meant to show prospective adopters of Koha the full range of hidden features that are not obvious from superficial examination. It is hoped to guide prospective feature funders and supporters otherwise to know what features may need support to initiate or accelerate development. Developers are also reminded of what is needed for the roadmap and possible future directions for Koha. | |
20:46 | russ | ok cool - that gives me a better idea of what you are trying to do - thanks |
20:46 | thd | russ: The point where it becomes complex is that is an analytical features list. |
20:47 | russ: Features are not merely listed in a flat sequence. | |
20:48 | russ: Many important features are broken down into there constituent elements. | |
20:48 | russ: The organisation is a large indented outline. | |
20:50 | russ: In HTML, it requires ordered list and dictionary list tags. | |
20:51 | russ: Even suitably broken down, it needs appropriate stylesheet elements for the ordered list and dictionary list tags for readability. | |
20:53 | russ: I have written a stylesheet for those tags and tested it. | |
20:54 | russ | ah right |
20:54 | thd | russ: Without such a stylesheet, gazing upon it is uniewably painful :) |
20:55 | russ | ok well we will just have to see how we get on with that when populating the content into koha.org |
20:55 | a seperate style sheet for that section may be a problem, may not | |
20:55 | but I wouldnt worry about that for the moment | |
20:56 | the most important thing is getting that content together. | |
20:56 | we can sort out how it gets displayed and organised on koha.org later | |
20:56 | gotta go - client is after a report i am writing | |
20:57 | thd | russ: It is only the list, ordered list, and dictionary tags that need special stylesheet treatment |
21:01 | russ: I have been translating some roadmap content from French. The babelfish had reduced some posted 3.0 roadmap features to gibberish. | |
22:50 | rach | thd do you know about inventory reports? |
01:42 | thd | rach: what about inventory reports? |
04:23 | good morning paul | |
04:23 | paul | (on phone) |
04:23 | thd | paul: I have a question when you are off phone |
05:01 | paul: are you still on phone? | |
05:02 | paul | 58mn on phone... |
05:02 | hdl | s/thiks/thinks/ |
05:02 | paul | i'm here now ! |
05:03 | (on phone again...) | |
05:03 | (unilim) | |
05:03 | thd | paul: I have seen your expert MARC editor diagram. It looks very nice. |
05:05 | paul: It is designed as I expected it to be with an exception which I will explain when you are off phone again. | |
05:14 | Sylvain | ho |
05:14 | hi | |
05:15 | thd | ho Sylvain |
05:48 | paul | thd, i'm back |
05:50 | thd | paul: I had not expected that the authorised value pop-up would have been part of you expert MARC editor implementation. |
05:51 | paul | why ? |
05:51 | thd | paul: However, I think a proper implementation of the full guided editor forms tool should be the best for every user including experts. |
05:52 | paul | ??? |
05:53 | thd | paul: I think the guided forms with value lists and plugins for everything possible should be ideal for every user ultimately. |
05:55 | paul: However, I just thought the experts would be typing the authorised forms for authorities expertly without a tool to aid them. | |
05:56 | paul: I prefer the pop-up for authorised values in the expert editor as you have represented it. | |
05:57 | paul: However, there is a problem with the way the frameworks represent authorised values from authority records. | |
05:59 | paul: Yes, I am saying that the help is good but there is a design defect in the help. | |
06:00 | paul: The frameworks have no provision for designating field groupings for authorised values. | |
06:00 | paul: consider the case of authorised personal names. | |
06:02 | paul: I have noticed that implementations of UNIMARC Koha seem to use personal names in a manner that is a little closer to MARC 21 than UNIMARC. | |
06:03 | paul: After lunch I will explain with an example. | |
06:09 | s/field groupings/subfield groupings/ | |
08:15 | paul: consider the case of the personal names | |
08:17 | paul: Examples I have seen in UNIMARC Koha look like MARC 21 | |
08:17 | paul: Sorry, do you mean that you are busy reading now? | |
08:17 | paul | no, I mean I'm reading you ;-) |
08:19 | thd | paul: I find 700##$aSmith, John in UNIMARC Koha just as would expect to see it in MARC 21 Koha |
08:19 | paul | except that you also should have a $3 with the authority number |
08:21 | thd | paul: Yes there would be an authority number that is true but to an improper authority form. The equivalent for MARC 21 Koha would be 100#1$aSmith, John. |
08:22 | paul: UNIMARC divides forenames from surnames by different subfields, not merely punctuation. | |
08:23 | paul | right. |
08:23 | smith => $a | |
08:23 | john => $b | |
08:23 | thd | paul: exactly |
08:23 | paul | + title (king, Sir, Lord...) in $dontrememberwhich |
08:23 | + birth/death dates in $f | |
08:23 | thd | paul: $c |
08:23 | paul | + number in $d |
08:24 | (like King Louis XIV) | |
08:24 | thd | paul: exactly and the cumulation of all those parts is the authorised form of the name |
08:27 | paul: This allows the direct distinction of $700#1$aSmith$bJohn$f1840-1900 from $700#1$aSmith$bJohn$f1950- | |
08:28 | paul: for the user visually as well as the system in $3 | |
08:31 | paul: The frameworks should support treating subfields as groups or whole fields collectively and filling the authorised form as a whole with the standard authorised form from BnF or wherever.. | |
08:33 | paul: frameworks should fill with 700 #0$aAlexandra,$cEmpress,$cConsort of Nicholas II, Emperor of Russia ; note the repeated $c and not merely 700 $aAlexandra | |
08:35 | s/frameworks should fill/plugin pop-up should fill/ | |
08:41 | paul: do you have comment? | |
08:41 | paul | (on phone, sorry ;-) ) |
08:47 | thd | s/$aSmith$bJohn/$aSmith,$bJohn/g # I had omitted the comma after Smith |
08:58 | hdl | thd: comma automatically added after $cEmpress ? |
09:01 | thd: Is this much troublesome to link with the appropriate authority but fill with only a summary of informations ? | |
09:04 | thd: I don't understand your change in Indicator 700#1 becomes 700#0 | |
09:09 | thd | hdl: UNIMARC 700#1 for designates $a as a surname |
09:09 | hdl: UNIMARC 700#0 designates $a as a forename | |
09:10 | hdl | wow smileglasses |
09:10 | thd | hdl: Alexandra is a forename |
09:11 | hdl | thd: you really are a MARC professionnal are you not ? |
09:13 | thd | hdl: The comma depends on your bibliographic cataloguing rules. Remember I asked what is the name of the cataloguing rules used in France. |
09:14 | hdl: I am an amateur at everything :) | |
09:15 | hdl: Although, I wish I had as much experience programming as I have cataloguing. | |
09:17 | hdl: I have never worked as a cataloguer in a library only in books businesses where the important cataloguing issues are more usually descriptions of condition after copy cataloguing the rest of the information. | |
09:18 | hdl: I learnt to care about the fine details of MARC while writing my own copy cataloguing system before Koha existed. | |
09:24 | hdl: I do not understand this question. " Is this much troublesome to link with the appropriate authority but fill with only a summary of informations ?" | |
09:26 | hdl | thd: Indeed, as you said, MARC21 uses a kind of summary field to display authority derived information, and UNIMARC does it differently. |
09:27 | thd: if we follow MARC21 practise in UNIMARC, is this THAT horrible ? | |
09:27 | thd | hdl: Do you mean MARC 21 has no linkage to the authority record number as UNIMARC $3 provides? |
09:29 | hdl | Errr... |
09:29 | thd | hdl: Or do you mean putting the forename and the surname in $a as is the UNIMARC practise. |
09:29 | ? | |
09:29 | hdl | thd: yes, that latest assert |
09:30 | thd | hdl: Then you do not have UNIMARC and your authorised names will not match the BnF authority file at the encoding level. |
09:30 | hdl | thd: that's the spirit, except that you seemed to talk about MARC21 as putting the forename and the surname in $a ... Or I mix up |
09:31 | ok. | |
09:31 | thd | hdl: Yes MARC 21 puts the both the forename and surname in $a however UNIMARC does not. |
09:32 | hdl: This aspect may be minor since would be easy to add a $b with a script. | |
09:33 | hdl: The issue that is important is that multiple subfields work together for the authorised form of the name. | |
09:35 | hdl: Dates, etc. if present in the authorised form are important distinguishes so the user can use the same full name with dates to search another system for the exact same author. | |
09:35 | s/distinguishes/distinguishers/ | |
09:37 | hdl: consider a MARC 21 example 100 1#$aChurchill, Winston,$cSir,$d1874-1965. | |
09:38 | hdl: There are other Winston Churchill's who are less famous but wrote books. Without the dates it is impossible to distinguish them from the bibliographic record. | |
09:40 | hdl: MARC 21 has no $3 for authority record linking and even in UNIMARC the user searching another system has no meaningful access to $3. | |
09:40 | hdl | thd: are the other Winston also Sir ? |
09:41 | ;) | |
09:41 | ok. | |
09:41 | I understand your point of view. | |
09:42 | thd | hdl: I do not remember. Quite possibly. Knighthoods are common but even still it is from another subfield. |
09:44 | hdl: There are actually quite a few Winston Churchills, more than one of which has published books. Some are direct descendents or also ancestors of the best known Winston Churchill. | |
09:45 | hdl: Another good example just for fun is 100 0#$aJohn Paul$bII,$cPope,$d1920-2004 | |
09:49 | hdl: There are certainly some John Pauls in the world where Paul is a surname. And a previous Pope John Paul. His given Polish name is not the authorised form in the NACO names database. | |
09:50 | paul: My reference showed 1920- with no death date and I could not remember when he died. | |
09:50 | paul | 2005, april 2 |
09:50 | (was the day my last son was baptised) | |
09:51 | thd | paul: I was feverish at the time with influenza. |
09:51 | paul: All my memories then are muddled. | |
09:54 | paul: So what about the issue of treating groups of subfields with indicators for filling with authorised forms. | |
09:55 | paul: UNIMARC 700 $4 could not be filled from an authority record but I think everything else could in 700. | |
09:56 | paul: Should there not be some way to define such behaviour in an authority framework? | |
09:59 | paul: If you copy catalogue from BnF you will at least have 700 $a and $b for most every case unless you concatenate them. | |
10:04 | paul: The issues for subject subdivisions are a little different because subject headings usually have the subfields filled individually from the authorised heading in a subject authority record when cataloguing except when copying the subdivision usage from another bibliographic record as a whole. | |
10:05 | paul: comments, or are you still on telephone? | |
10:06 | hdl | paul away at the doctor. |
10:06 | thd | hdl: Have I made him ill? |
10:07 | hdl | No. :D had an appointment. and remembered late.;) |
10:08 | thd | hdl: Koha will be very difficult to market in the US without addressing these issues. |
10:09 | hdl | but sure, when we speak with you, it is both interesting but not very productive time for our own developpments. |
10:10 | thd | hdl: I realise that but would not most important libraries in France have the same need? |
10:11 | hdl | First, let's have Koha Safe and sound even with some lacks. |
10:11 | Then let's fill in the gaps. | |
10:11 | Don't you agree ? | |
10:12 | But It IS interesting to speak with you. | |
10:13 | thd | hdl: Yes of course and these issues will certainly be easier for the OPAC in 3.0 but I had assumed they would also be addressed for the authority record at the same time. |
10:15 | hdl: I have a librarian in Illinois who had told me two weeks ago that she was willing to write a grant application for two full time programmers for a year to address these issues in Koha. | |
10:19 | hdl: What do you do now about 700 $a and $b when copy cataloguing from BnF? | |
10:26 | hdl: Why does ENSMP only have Koha for testing and not yet for production? |
← Previous day | Today | Next day → | Search | Index