← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:13 | hdl | kados around . |
| 12:13 | indradg around ? | |
| 12:24 | kados | hdl: I'm here |
| 12:24 | hdl: just spoke to my Law Library (potential) client | |
| 12:24 | hdl: he is satisfied with Koha's serials functionality | |
| 12:25 | hdl: but has one question | |
| 12:25 | hdl: is there a way to 'link' a serial record and a MARC record? | |
| 12:25 | hdl: I think the answer is no | |
| 12:25 | hdl: or ... not yet ;-) | |
| 12:26 | hdl | Your guess is right. :) |
| 12:26 | Have you ever tried to set a subfield with both an auth_value and a plugin ? | |
| 12:27 | kados | hdl: I don't think so |
| 12:27 | hdl: what happens? ;-) | |
| 12:27 | hdl: I'm not sure I remember what a plugin is | |
| 12:28 | hdl | It is meant to fill subfields automatically. |
| 12:28 | kados | ahh |
| 12:28 | hdl: so could I use it to put 'today's date' in a field? | |
| 12:29 | hdl: for cataloging purposes (for 'date accessioned')? | |
| 12:29 | hdl | For instance, 100$a which contains coded values can be filled with a plugin |
| 12:30 | kados, this would be too simple, maybe we could make a Default Value input... But then we should build functions... | |
| 12:31 | kados | so 100$a contains coded values? |
| 12:31 | I thought it contained 'author'? | |
| 12:31 | or is it different in UNIMARC | |
| 12:31 | hdl | UNIMARC :) |
| 12:31 | kados | ahh ;-) |
| 12:32 | hdl | http://www.ifla.org/VI/3/p1996-1/uni1.htm#100 |
| 12:32 | I don't know US-MARC equivalent. | |
| 12:32 | If there is one. | |
| 12:33 | kados | looks similar to leader |
| 12:33 | thd would know ;-) | |
| 12:34 | hdl: in subfield_structure, 'thesaurus' is for MARC Authorities? | |
| 12:35 | hdl | yes. |
| 12:38 | kados : auhtorized_values preceds on plugin. | |
| 12:39 | that is : when you define both auth_value and a plugin, authvalue list will be displayed and not plugin. | |
| 12:42 | kados | interesting |
| 12:42 | I'll remember that ;-) | |
| 13:15 | tim | You there kados? |
| 13:27 | owen | I'm not getting anything from the "full" serial view in either the opac /or/ the intranet |
| 13:27 | I remember that this was working at some point | |
| 13:37 | Hmm.... Am I missing a system preference? | |
| 13:51 | No, I've got that. It just determines which summary I see, the full or compact. Either way, I get an empty full view | |
| 14:14 | Hi thd | |
| 14:15 | thd | hello owen |
| 14:15 | Is kados about? | |
| 14:15 | owen | He's been in and out...mostly out |
| 14:17 | thd | owen: he needs to have his status recorded in the DB :) |
| 14:18 | owen | Maybe we should all have switches put in our seats to detect when we're sitting in front of our computers |
| 14:19 | thd | owen: :) sitting does not mean paying any attention to #koha |
| 14:22 | kados | thd: I'm here now |
| 14:22 | thd | hello kados |
| 14:23 | I have been hoping to find you on #koha during the past few days | |
| 14:23 | kados | thd: but I have a few minutes at the moment |
| 14:25 | thd | kados: sorry about your hard failure, I always get a little scared that something will not go right about correcting that when it has happened to me :) |
| 14:25 | kados | thd: so far everything's been ok ;-) |
| 14:25 | thd | kados: For the question that you had to hdl this morning about the MARC 21 equivalent of UNIMARC 100 |
| 14:26 | kados | yea |
| 14:26 | thd: I'd also like to get your opinion on doing serials in MARC ... is it a good thing ? | |
| 14:27 | thd: or should we stick with a separate db | |
| 14:27 | thd | kados: MARC 21 has 008 and 006 fixed fields with no subfields as equivalent. UNIMARC 100 uses fixed fields within subfields. Leader is almost identical between MARC 21 and UNIMARC. |
| 14:28 | kados: Do you mean doing serial holdings within MARC? | |
| 14:29 | kados | thd: yep |
| 14:30 | thd: so 008 and 006 (MARC21) serve a similar function as 100a (UNIMARC) | |
| 14:31 | thd: I'm still not clear on what the purpose of the fixed fields is | |
| 14:32 | thd | kados: It is poorly written, but http://www.kohadocs.org/holdings.html document describes what is involved in complex holdings for serials. Implementing it would involve a lot of work. |
| 14:33 | kados | thd: seen gapines.org catalog? |
| 14:35 | thd: also, I hacked together a temporary fix for the holdings display problem at NBBC | |
| 14:35 | thd: for PERI item types | |
| 14:35 | thd | kados: The advantage of fixed fields is described in the finished section of my two month old email that I have worked on completing the last section of during the last couple of days :) |
| 14:35 | owen | the pines interface is neat |
| 14:36 | ...though unfinished | |
| 14:36 | kados | yea :-) |
| 14:37 | owen | Is this purely a test setup? |
| 14:37 | kados | owen: yea ... afaik it's a development system |
| 14:38 | owen | I like their MARC view |
| 14:38 | Although it's not interactive like Koha's. Visually it's nice and concise | |
| 14:38 | kados | yea |
| 14:39 | thd | kados, owen: I have a development site where parts look exactly like the advanced search. |
| 14:39 | kados | owen: we've got to get a 3.0 demo running so we can start hacking on the OPAC |
| 14:39 | owen: sorry I've been so remiss | |
| 14:40 | thd | owen: were you able to bring up a record on the PINES demo? |
| 14:41 | owen | yes |
| 14:42 | Tons of great ideas in that interface. They've obviously got some muscle behind their development | |
| 14:44 | thd | kados: fixed fields store coded information in a concise machine readable form. They can be a wealth of information but OPACs ignore almost everything in the fixed fields because it requires special parsing for a human display and indexing. |
| 14:45 | owen: was that a yes to your having a successful query that returned a record on the PINES demo? | |
| 14:48 | owen | thd: yes, that was a yes |
| 14:48 | thd | kados: My suspicion seemed confirmed in the log that you have not seen how plugins or authority records work in Koha cataloguing. |
| 14:48 | owen | I tried a keyword search for 'something' |
| 14:49 | kados | thd: correct |
| 14:49 | thd: no libraries I manage use it | |
| 14:54 | thd | kados: Well of course merely adding holdings to a record in the current Koha MARC editor can break the proper sequencing of the subfields for the MARC bibliographic record but there is a significant amount of value in the existing cataloguing module even though it is not currently implemented in a standards compliant manner. |
| 14:55 | kados | thd: right ... well the cataloging project I'm working on is a bit different |
| 14:55 | thd: I'm mainly interested in display issues | |
| 14:55 | thd | kados: You should try installing UNIMARC Koha with the default templates. |
| 14:55 | kados | thd: usability and productivity of the interface |
| 14:56 | thd: so the project will use a minimal Z3950 query script and a bit of MARC::Record to pull out fields in the resulting records and heavy javascript usage to do all of that without a page reload | |
| 14:57 | thd: the goal is to make it as record agnostic as possible | |
| 14:58 | thd: but very heavy on the client-side scripting to make it look and act like a desktop rather than a web application, a la google and amazon | |
| 14:58 | thd | kados: what aspects of usability concern you? Do you mean agnostic between MARC 21 and UNIMARC? |
| 14:58 | kados | thd: yep ... and between MARC and XML as well |
| 14:58 | thd: so you've got a application framework that sits client side, | |
| 14:58 | does a query, | |
| 14:59 | the server side decides how to grab the data, and returns it in an XML format | |
| 14:59 | client side parses the XML and displays it to the user | |
| 14:59 | thd | kados: How are Google and Amazon like desktop applications and not server applications running over a web browser? |
| 15:00 | kados | thd: have you used maps.google.com or opensearch.a9.com? |
| 15:00 | thd: mainly we're probably going to be using XML::Http client side | |
| 15:01 | thd: we'll have to see how advanced the tool becomes, I've no idea whether these students will really take it as far as it could go | |
| 15:03 | owen | One of the nice things about the Pines demo is that it looks like their javascript stuff isn't breaking the back button |
| 15:03 | I'm curious how they handle that | |
| 15:07 | thd | kados: my initial thought about the 10 week class is that, unless the students are bringing prior understanding of MARC with them, they are unlikely to develop enough familiarity with MARC in 10 weeks to produce a sufficiently well considered design for a record editor. A Z39.50 client is much simpler and the one in Koha now seems to be a very poor design. |
| 15:09 | kados | owen: not sure I know what you mean |
| 15:11 | thd | kados: Well you cannot learn enough about the hows and whys of MARC by merely reading the standard. You need a mini course in library science. |
| 15:11 | kados | thd: right ... I get that ... but that's got little to do with how to build a record format editor ;-) |
| 15:12 | thd: I've basically told the students to blackbox MARC altogether | |
| 15:12 | thd: just know that 'you've got fields, some unrepeatable and some repeatable' | |
| 15:12 | thd: 'and that you've got to make it easy to edit the fields, add new ones, and navigate through a help system' | |
| 15:14 | thd | kados: A mini course in library science adequate to design a good cataloguing application as opposed to a possible but not necessarily good application would run at least ten weeks. The students need to learn to think like librarians, something that does not seem to come naturally to programmers. |
| 15:15 | kados | thd: well ... firstly, it's not just one 10 week course ... it's a project that has a scope of three years |
| 15:15 | owen | I guess they're not using AJAX to load results like I thought they were |
| 15:15 | They're just doing some kind of delayed display thing | |
| 15:16 | kados | thd: true that most of the students will turn over after the first 10 weeks |
| 15:16 | thd: but a few will stick with it for the duration | |
| 15:18 | thd | kados: MARC is much much more complicated than a simple description is likely to attempt to reduce it to. 3 years could certainly be managed but an introduction to library science course should be a prerequisite for everyone. |
| 15:20 | kados | thd: i still don't see why they need to know anything about MARC |
| 15:20 | thd | kados: Even the existing Koha framework design has some significant defects. The worst problems are exclusive to the editor but not all of them. |
| 15:20 | kados | thd: they won't really be dealing with it at all |
| 15:22 | thd: with Zebra we'll be dealing directly with record strings | |
| 15:22 | thd: so all the cataloging component needs to do (for simple purposes) | |
| 15:23 | thd: is grab those strings, parse them into labeled XML tags/indicators/subfields, order them as is, and display to the user in an editable format | |
| 15:23 | thd: then, when they are saved, pass them back to the parsing engine to be turned back into valid MARC | |
| 15:24 | thd | kados: If the need to design for repeatability, nonrepeatablity, etc. that list of factors is very very long. They do not need to know exactly what MARC 21 XXX $x is for but they need to be able to create a design that works for any possible XXX field and that is very complex. |
| 15:25 | kados | thd: naw ... all that's handled in a conf file |
| 15:25 | thd: it's record agnostic | |
| 15:25 | thd: record-type agnostic I mean | |
| 15:26 | thd: really, the bulk of the work is on the interface | |
| 15:26 | thd | kados: The application has to be able to support the config file. I am only describing type agnostic issues. |
| 15:26 | kados | of course ... |
| 15:27 | so asside from repeatability, non-repeatablity, orderliness, what other factors do you suggest we account for? | |
| 15:30 | thd | kados: One of the difficulties is that some fields in MARC actually 'interact' so that how a field or subfield works is dependent upon external content in a structural manner. This is more than just a semantic specification that might go into a config file. |
| 15:31 | kados | could you give an example? |
| 15:31 | thd | kados: Another factor is that some subfields function as groups and not isolated subfileds as they are treated in the current Koha frameworks. |
| 15:32 | kados | thd: have you discussed this somewhere in a document? |
| 15:32 | thd: could you give me an example of the 'interaction' ? | |
| 15:33 | thd: (I assume that MARC::Record could handle all the issues you're raising?) | |
| 15:41 | thd | kados: I am finishing the analytical feature list including features needed for the next version and features that may be good to have in future versions but it is in outline form with no explanations given. |
| 15:41 | kados: I had some difficulty determining how to convert a large outline into an HTML ordered list with a script starting from an indented text file. I only found the answer last night after setting it aside for a few days. The list was too long for coding by hand and making errors. Of course, it would only appear in small sections with most users only seeing the current feature set or the 3.0 roadmap feature set. | |
| 15:45 | kados: MARC::Record does the hard work of parsing the fields, indicators, and subfields into something that an application can use. The application still has to do the work needed at the application level. | |
| 15:55 | kados | thd: could you give me some examples of what you mentioned earlier about 'interaction'? |
| 15:56 | thd | kados: One example of interaction within a single record is MARC 21 is 245 10$6880-03$aSosei to kakō$bNihon Sosei KakōGakkai shi. 880 10$6245-03/$1$a[Title in Japanese script]: $b[Subtitle in Japanese script] where $1 is a coded value for Japanese script. |
| 16:00 | kados: The application needs to know how to find and use values from other fields. Even the character order for parsing a field can depend upon the script directionality. | |
| 16:02 | kados | find and use what values from other fields? |
| 16:06 | thd | kados: $6 in MARC 21 is usually a reference to another field specifying the script used to interpret the field containing $6. |
| 16:08 | kados: Maybe not a major issue for the monolingual libraries where Koha is currently installed but something that may difficult to fix after it was not part of the design. | |
| 16:12 | kados: For an example in English we $8, field link and sequence number, for bibliographic as opposed to holdings fields. This relates parts of a work to information about those parts. | |
| 16:12 | 245 10$aBrevard Music Center$nProgram #24$h[sound recording]. | |
| 16:12 | 505 0#$aFrom my window / Siegmeister (world premiere) - Don Giovanni. Il mio tesorof [i.e. tesoro] / Mozart - Martha. M'appari / Flotow - Turandot. Nessun dorma / Puccini - Pines of Rome / Respighi. | |
| 16:12 | 650 #0$81\c$aSuites (Orchestra), Arranged. | |
| 16:12 | 650 #0$82\c$83\c$84\c$aOperas$xExcerpts. | |
| 16:12 | 650 #0$85\c$aSymphonic poems. | |
| 16:12 | 700 1#$82\c$84\c$aDi Giuseppe, Enrico,$d1938-$4prf | |
| 16:12 | 700 12$81\c$aSiegmeister, Elie$d1909-$tFrom my window;$oarr. | |
| 16:12 | 700 12$82\c$aMozart, Wolfgang Amadeus,$d1756-1791.$tDon Giovanni$pMio tesoro. | |
| 16:13 | 700 12$83\c$aFlotow, Friedrich von,$d1812-1883.$tMartha.$pAch! So fromm, ach! so traut.$lItalian | |
| 16:13 | 700 12$84\c$aPuccini, Giacomo,$d1858-1924.$tTurandot.$pNessun dorma. | |
| 16:13 | 700 12$85\c$aRespighi, Ottorino$d1879-1936.$tPini di Roma. | |
| 16:15 | kados: more interesting still is the linking of one bibliographic record to another. | |
| 16:16 | kados | sorry ... had to finish up an email |
| 16:16 | a couple of emails actually ;-) | |
| 16:17 | thd: ok ... that makes sense ... | |
| 16:17 | thd: but I don't really think any application is going to be able to make those connections automatically | |
| 16:17 | thd: (script _> type of script I mean) | |
| 16:17 | thd: (within a single record) | |
| 16:18 | thd: unless you think otherwise I think it's going to be something a real person keeps track of | |
| 16:20 | thd: you there? | |
| 16:20 | thd: I'm going to dissapear into RFP-Response-Writing-Land in a few minutes | |
| 16:22 | thd | kados: sorry I was finding this example of linking to a parent record using 772 $w: 772 0#$tWorld agricultural situation (Washington, D.C. : 1970)$x0084-1358$w(DLC)sf#81008035# |
| 16:24 | kados: Al linking fields use coded values not very useful to humans. | |
| 16:24 | kados | thd: I'm interested in parent->child record relationships ... but let's stick to inter-record relationships at first |
| 16:24 | not useful ... but still, a human has to make the connection | |
| 16:25 | the way I see it ... unless you know of a way to do it otherwise | |
| 16:25 | thd | kados: Previous examples were inter record relationships. |
| 16:25 | kados | right |
| 16:25 | thd | kados: What do you mean exactly by make the connection? |
| 16:25 | kados | maybe I'm not understanding your point |
| 16:27 | you gave this example: | |
| 16:27 | One example of interaction within a single record is MARC 21 is 245 10$6880-03$aSosei to kakō$bNihon Sosei KakōGakkai shi. 880 10$6245-03/$1$a[Title in Japanese script]: $b[Subtitle in Japanese script] where $1 is a coded value for Japanese script. | |
| 16:27 | what's the value for $1 here? | |
| 16:28 | is it $a[Title in Japanese | |
| 16:28 | script]: $b[Subtitle in Japanese script] | |
| 16:28 | ? | |
| 16:28 | or 6245-03/ | |
| 16:28 | ? | |
| 16:31 | thd | kados: $6 is the subfield containing 245 with indicators 03 and $1 for CJK. |
| 16:34 | kados | I don't get it |
| 16:35 | thd | kados: The system has to convert the CJK. Koha 3.0 should be using unicode but the system has to first convert records acquired over Z39.50 from non-unicode systems. Existing library records in unicode are very rare. That makes for a lot of complications when dealing with records using other language scripts. |
| 16:36 | kados | ahh ... so you're saying ... a non-unicode record comes in, cataloging tool converts it to unicode, it should update the subfield to say 'unicode' rather than 'not unicode'? |
| 16:36 | is that right? | |
| 16:36 | if so, seems pretty simple | |
| 16:37 | thd | kados: exactly, obviously [Title in Japanese script] is meant for human consumption. |
| 16:37 | kados | simple if statement ... if ($converted) { updateRecordEncode('unicode') } |
| 16:38 | with the appropriate stuff in the sub to handle it | |
| 16:38 | thd | kados: It is only easy if the system can identify the starting language and how it is recorded. |
| 16:38 | kados | why does it need to know the language? |
| 16:38 | it just needs to know the encoding right? | |
| 16:40 | thd | kados: These examples are for exceptions to a global character set that covers the whole record. Yes it need to know the starting encoding and identify it on a field by field or field/subfield by field/subfield basis when needed. |
| 16:41 | kados | ahh ... that makes sense now |
| 16:41 | any other examples like this? | |
| 16:42 | btw: came accross this earlier today: http://www.ourmedia.org/node/57388 | |
| 16:42 | thd | kados: global is easy but the example above is for mixed script usage. |
| 16:42 | kados | I think 'Cyril' is relevant here |
| 16:42 | "If you have Russian records Cyril will enter the Russian characters in field 880 and update the other places in the record necessary." | |
| 16:46 | thd | kados: Yes that is interesting. There is MARC::Charset from our hero Ed Summers. UNIMARC character sets get more tricky and Ed Summers does not support them all. |
| 16:46 | kados | thd: yet ... ;-) |
| 16:49 | thd | kados: Well I have found a one way conversion for ISO 5426, although, that is fairly simple. I have not looked for other UNIMARC character set conversions. |
| 16:50 | kados: the record linking is where these structural issues become much more complex and where the existing Koha framework design has a significant deficiency. | |
| 16:51 | kados | thd: right ... and I think you'd be hard-pressed to find a really solid framework for that kind of complexity |
| 16:51 | thd | kados: All the examples I gave above are in the MARC documentation. How to work with authority control is not in the MARC documentation. |
| 16:52 | kados | thd: I mean an application framework |
| 16:53 | thd | kados: Authority control sets values for groups of subfields not just one as assumed by the current Koha framework design. |
| 16:53 | kados | thd: right ... |
| 16:53 | thd: well let's see how we do with our proposed plan (cataloging tool) | |
| 16:53 | thd: just getting an interface working | |
| 16:53 | thd: the back-end stuff (like what you're talking about) | |
| 16:54 | thd: requires a level of application-layer logic that's not really related to the inteface | |
| 16:54 | thd: all the interface needs to know is 'what to display' and 'what things I can do with the display' | |
| 16:54 | thd: and I think most of that is covered with 'repeatability, unrepeatability, and orderliness' | |
| 16:55 | thd | kados: Is not the back end what the interface has to support and hook into in order to know what types of information/data entry displays it needs to support? |
| 16:56 | kados | thd: we'll talk about this more later ... |
| 16:56 | thd | OK :) |
| 18:49 | kados: are you there? I have a simple question. | |
| 01:17 | indradg | kados, around? |
| 01:51 | hi... anyone knows abt the latest updated POs uploaded by paul... the webcvs interface is still showing the old version | |
| 02:29 | paul_away, are you there? | |
| 04:56 | Malin | hi |
| 04:56 | anybody here? :-) |
← Previous day | Today | Next day → | Search | Index