IRC log for #koha, 2005-09-18

← 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

koha1