IRC log for #koha, 2007-06-15

All times shown according to UTC.

Time S Nick Message
13:15 slef kados or paul alive?
13:19 kados slef: yo
13:23 slef 1mo, phone
13:23 slef sorry
13:24 lloyd ;)
13:34 lloyd kados - check your mail :)
13:35 lloyd its not very exciting
13:35 kados looking
13:36 slef still phoone
13:38 kados lloyd: looks like we're behind schedule :-)
13:38 slef kados: have you looked at bookseller EDI?  onix etc
13:39 kados slef: only casually
13:39 kados but I'm meeting with Ebsco at ALA next week
13:39 kados to discuss it
13:39 kados hi thd
13:39 lloyd kados - yeah very lol
13:40 kados thd:[…]-06/msg00024.html
13:40 kados thd: you can see some of the fruits of our labor last night in that email response
13:41 kados thd: feel free to join that list and add your comments to the mix :-)
13:41 kados slef: why do you ask?
13:42 slef kados: customer enquiry.  Am I right in thinking it's a case of altering acquisitions to send/receive the EDI messages?
13:42 kados yea
13:42 kados it's a pretty simple process actually
13:42 kados most implementations use FTP
13:42 kados AFAIK
13:42 kados the EDI messages are gonna be different for every vendor
13:43 kados like all library standards
13:43 slef only thing I think is really new there is to feed the MARC record from
13:43 slef the supplier into the reservoir so it's ready for acquisitions
13:43 slef kados: really?  ONIX looked like something half-standard.  I guess we can XSLT them into a koha-common-EDI-import form?  <eg>
13:43 kados well, not the reservoir
13:43 kados you want to attach it to the bib record
13:43 kados when you acquisition something in Koha, it creates a minimal bib
13:44 kados ONIX is just one of the edi standards
13:44 slef do we trust the supplier's bib that much, though?
13:44 kados EDIFAX is another I think
13:44 kados yea
13:44 kados we sorta have to
13:44 kados at least that's how it's supposed to work
13:45 kados edi does more than just grab the marc though
13:45 slef In God We Trust. All Others Bring Data.
13:45 kados hehe
13:45 kados what I want to be able to do
13:45 slef tracks the order, balances the budgets
13:45 slef what else
13:45 kados is initiate the order from koha, use a web service on the vendor's site to find books, add them to a basket, and place an order, then get back expected delivery times, etc.
13:46 kados update the budget
13:46 kados then  track the order
13:46 kados allow claims automatically
13:46 kados (more than just a report)
13:46 thd the problem with EDI in Perl is that the supporting libraries are underdeveloped even if they work for the level present
13:46 kados we need a visionary library to take on the expense of developing that
13:46 kados thd: right, we would need to expand on those
13:48 slef I'm expecting to write some EDI interface modules.
13:48 thd kados: I would advise hiring the developer of them to finish that work when it becomes a valuable feature to have
13:48 kados thd: which modules?
13:48 slef I think I've got a bookseller who is willing to help me test.
13:48 kados thd: that depends on the developer
13:48 kados thd: and how well written the code is
13:48 kados thd: if it's poor code, I'd rather start from scratch
13:49 thd kados: the problem is that you cannot get all the information for all the standards easily
13:49 kados thd: *nod*
13:50 thd the developer already had dealt with some of those issues for the old UK standard which is probably still used extensively and proprietary
13:54 slef which developer?
14:03 kados
14:03 kados thd: this one?
14:04 kados XML::Edifact - an approach towards XML/EDI as a prototype in perl
14:04 kados UN/EDIFACT is sometimes called nightmare of paperless office. About 3000 pages define the UN/EDIFACT standard to provide a rich semantic for electronic data interchange for trade commerce and transport. A semantic that is difficult to understand and to implement for the average programmer.
14:04 kados typical library standard :-)
14:08 thd I was looking but I did not find my old notes easily for this
14:09 slef But we're no average programmers, right? :)
14:10 thd there was one Perl module which included support for X12, X11, TRADOS, and EDIFACT all in one
14:10 kados slef: heh
14:11 thd TRADOS being the proprietary standard used in the UK
14:13 thd use of EDIFACT is largely confined to major business outside the US and Canada
14:13 slef UK Book Industry Communication seems to be pushing ONIX today
14:14 thd ONIX is designed more for bibliographic metadata than orders
14:14 slef I can find the EDIFACT details, but it doesn't seem promoted
14:14 slef ONIX seemed to cover QUOTES and INVOICES and so on when I read it
14:15 thd ONIX was developed by the Book Industry Study Group in the US for bibliographic data
14:15 slef[…]ementation.html#2
14:17 slef oh yeah, it hooks to EDIFACT for the INVOICES stuff
14:17 slef sorry
14:17 slef I'm in a maze of twisty standards, all different.
14:18 kados slef: yea, welcome to libraries
14:18 thd slef: TRADOS may be from my poor memory perhaps the proprietary standard is Tradicoms
14:18 thd which is in the page that you posted
14:19 slef TRADOS looked like someting for translations
14:19 thd I have not looked at this in detail for about a year and a half
14:20 slef It doesn't look like it has changed since 2002 at latest
14:21 thd the PERL modules which I had were sufficient for doing something but they worked a much lower message level than most people expected
14:23 thd there was no high level abstraction for the common tasks people wanted to perform because that level of the work on the modules was unfinished
14:31 slef I don't mind a bit of heavy lifting.
14:34 thd I found it
14:34 thd
14:35 thd that is the most complete set of modules for EDI in Perl
14:36 thd I could not remember MEDICI in association with EDI
14:37 slef thanks
14:38 thd kados: are you still here?
14:38 slef approach sounds sane (driving expat)
14:39 kados thd: just in theory :-)
14:40 thd kados: I found MEDICI for EDI in Perl, which I had forgotten; but I wanted to ask you about the list to which you pointed me
14:40 thd kados: what is that list?
14:41 kados thd: that's the opencataloger list
14:41 kados thd: for the opencataloger project
14:41 thd the classroom part?
14:42 thd or is that list also being used for the Koha development as well
14:42 thd ?
14:43 thd what is the structure of the classroom work if it is no longer competitive teams starting from nothing but some direction to the standards?
14:44 thd kados: and also where do I subscribe?
14:44 slef vrooooooooooooom
14:45 slef
14:46 slef as an aside, please ask opencataloguer to "use but not rely on" javascript ;-)
14:46 kados slef: ha!
14:46 kados slef: that's not the purpose of opencataloger
14:47 kados slef: the existing MARC record editor in KOha fulfills that goal
14:47 kados we're creating something else with opencataloger
14:47 slef fiddling with each college's browser to allow koha's admin interface to run scripts is getting very boring
14:47 kados heh
14:48 slef This project has not yet submitted a short description. You can submit it now.
14:48 slef That's not informative!
14:48 slef
14:48 slef so what is opencataloguer?
14:48 slef
14:49 slef and are you worried by the spelling error? ;-)
14:49 thd kados: I thought the purpose of open cataloguer was cataloguing, not necessarily cataloguing in JavaScript
14:49 kados slef: that's the american spelling
14:49 slef No gg?
14:49 lloyd bloody americans
14:49 slef lloyd: knickers to them.
14:50 kados a name change may be in order
14:50 kados[…]dfield_editor.png
14:50 lloyd opencatlog :)
14:50 kados
14:50 kados
14:50 slef I really don't know how US spells it.  I do well to remember that they don't use ue on the end ;-)
14:50 kados some screenshots if you want to know what it is
14:51 kados[…]catalogingproject
14:51 kados historical info on the origins ofthe project and the goals
14:51 slef heh, tabs... anyone want a
14:52 thd kados: what is the structure of the classroom work if it is no longer competitive teams starting from nothing but some direction to the standards?
14:52 owen slef, do you really exist in a world completely free of javascript?
14:53 owen It's ridiculous to expect a modern web application to fully function completely free of javascript
14:53 owen ...unless the audience *specifically* requires no javascript for some technical reason.
14:53 slef owen: no.  I exist in a world where Javascript is used sparingly,
14:53 slef because of its accessibility, energy and abuse problems.
14:53 slef hang on, some tike is banging on the building vents again
14:54 owen And you believe that a cataloging client would need to adhere to those standards, assuming that "abuse" is not relevant here?
14:54 kados thd: now it's just one student working, the google summer of code guy
14:54 kados and toins / paul did much of the interface work in XUL
14:54 slef too slow :-/
14:55 thd owen: I hope to live in a world where either every device supports JavaScript perfectly or JavaScript is not required to accomplish any task
14:55 slef owen: lots of college machines have javascript blockers by standard these days.
14:56 owen So they don't use /any/ current web application
14:56 slef It's completely stupid to prevent non-javascript clients from accessing basic services.  Even google is slowly tracking back on that, opening maps up to non-javascript browsers and so on.
14:56 thd owen: unfortunately the real world meets neither of those conditions so we either have to change the world or change the applications and changing the applications is easier
14:57 kados slef: a cataloging application is not a basic service
14:57 slef a cataloguing application has basic services
14:57 kados slef: if I were rich, I would agree with you
14:57 kados but I'm poor and I need to make something that works for my customer
14:58 owen slef, have you evaluated commercially-available cataloging clients for accessibility?
14:58 thd kados: it should be though as long as your libraries' records cannot be overwritten by the patrons
14:58 kados slef: and they require javascript to perform what they want to perform
14:58 slef part of the motive for web applications is "the Martini approach" - any time, any place, any where
14:58 thd slef: what does Martini mean in that context?
15:00 slef kados: I've found javascript to be a huge resource drain unless you lock down to only support one browser.  I hear the ajax compatibility libraries are improving it, but use much CPU
15:00 slef thd:[…]5&in_page_id=1879
15:03 slef kados: use it if you want, but please leave a basic version usable without it (or at least have some idea how one could be made, leave the door open) if you want the widest possible audience.
15:03 kados slef: we're locking down to firefox
15:03 kados slef: there is no budget for this, it's being done on a shoestring
15:03 kados slef: if you want to contribute code, that woudl be welcome
15:06 slef Maybe some time, but it looks like a html version is prevented by the XUL tech requirement.
15:14 slef owen: I've not evaluated the commercial cataloguers.  One of my FE colleges did a while back and I think they had one Windows one which was OK.
15:15 owen And it qualified as "accessible?"
15:16 slef I think it got grade 3 on their 5-point scale.  So not brilliant, but usable with adaptations that they already had.
15:18 thd owen: I think that ensuring that every function can be performed quickly with the keyboard alone using the tab key or whatever is much more important than ensuring it works without JavaScript
15:18 thd slef: I think that ensuring that every function can be performed quickly with the keyboard alone using the tab key or whatever is much more important than ensuring it works without JavaScript
15:20 slef thd: the keyboard can move the pointer at a push, so I'd put them the other way around, but both is best.
15:21 slef hrm, I can't remember how to do that in X though :)
15:21 thd slef: I only use mouse keys as well
15:22 thd slef: shift-numlock starts the mouse keys function
15:22 thd in X-windows
15:22 slef oh yeah, and tap shift while pointing to go faster
15:23 slef I tried ctrl-alt-numlock, which was close but no cookie
15:23 slef and 5 to left-click
15:23 slef where are the other mouse buttons?
15:24 thd sets the left button
15:24 thd slef: / sets the left button
15:24 thd slef: * sets the middle button or both
15:24 slef and - the right, gotcha
15:25 thd slef: - sets the right button
15:25 slef I think that's changed since I last used it.
15:25 thd slef: - 0 holds the button down
15:26 slef and 5 to release again... mmm
15:26 thd slef: - . releases the button
15:26 slef heh
15:26 thd slef: . releases the button
15:26 thd slef: + gives a double click
15:27 thd slef: all the numbers around 5 point in their relative direction of course
15:28 [K] *** part FreeNode!#koha: _lloyd_
15:29 thd slef: the only problem I have with the built in X-windows function is that the feauture turns itself off after some minute and then I type a number unexpectedly
15:29 slef 9
15:30 thd slef: 9?
15:30 slef I type a number unexpectedly
15:30 thd s/minute/period of minutes/
15:32 thd there is are programs for better control of the feature but none are packaged for Debian unless you use Gnome or KDE
15:32 thd s/is//
17:52 kados hey foxnorth
17:52 foxnorth hey kados: great email this morning. took me a while to digest. :)
17:52 kados took a while to write :-)
17:52 foxnorth i'm just about to send some use cases as i see them right now to the list
17:52 foxnorth i bet!
17:52 kados but it's important I think
17:53 kados it's easy to get caught up in the thrill of fast development
17:53 foxnorth very- dunno if you saw my reply from a short while ago yet?
17:53 kados yea, I did
17:53 foxnorth yeah, i think we need to pause and figure out what we want from this thing :)
17:53 kados yea
17:53 foxnorth ok, just sent my list of workflows/uses to opencat-dev
17:55 kados oooh, yes
17:55 kados thought of that last night: open file of MARC records
17:55 foxnorth yeah, need that
17:55 kados and saving too
17:55 kados definite must
17:57 kados cool
17:57 kados we do own the opencataloger domain
17:57 foxnorth so, i wanted to get down what's working, what isn't and what we want to work...ultimately
17:57 kados but for now I'd prefer to use the liblime wiki:
17:57 foxnorth sure, whatever's easiest/best.
17:57 kados we may end up changing names
17:58 foxnorth right, hadn't thought of htat
17:58 kados because of the spelling differences of catalog and catalogue
17:58 foxnorth good point
17:58 kados short sighted ofme
17:58 foxnorth so, on the whole, how does this list jive with what you're envisioning (if that' s not too much to ask in chat??!)
17:59 slef no, I just wondered whether it should be cataloger or catalogger - I don't know how it conjugates
17:59 foxnorth i havne't included everything, of course...
17:59 kados slef: :-)
17:59 kados foxnorth: Save changes in opencataloger (xml dom...eventually sqlite?)
17:59 slef oh wait, do you write referer?
17:59 kados foxnorth: Google has a tool for this
17:59 foxnorth a tool for which?
18:00 kados foxnorth: Google Gears
18:00 foxnorth ah, i've seen but haven't played with
18:00 foxnorth yet
18:00 kados there's also the Dojo Offline Toolkit
18:00 kados which might be better than an extension
18:00 slef oh yeah, strange US English
18:01 foxnorth you mean better than making opencat an extension, or using google gears?
18:01 kados I'd prefer to avoid making a firefox extension unless there are strong reasons too
18:01 foxnorth yeah, it seems counterintuitive.  i guess there's xulrunner, but i really don't know what the status of it is...
18:01 kados but I'm in favor of using available toolkits like dojo, jquery, yui
18:01 slef referer - A misspelling of "referrer" which somehow made it into the
18:01 slef HTTP standard. (foldoc)
18:02 kados xulrunner is really nice actually
18:02 kados that's what EG's staff client is packaged in
18:02 kados I think there's only an installer for windows though
18:02 foxnorth yeah, i thought i saw that.  it works pretty well for eg?
18:02 kados yea, very well
18:03 kados slef: yea, isn't that nuts
18:03 kados slef: I've actually been thrown by that a few times
18:04 foxnorth kados: you had said a while back you preferred sticking to xul as opposed to a js toolkit like ext/yui-- do you feel like the main benefits to xul are separation of ui and js scripts? Is it also stability you're concerned with in the other js toolkits?
18:05 kados I think xul is really fantastic interface technology
18:05 kados that's my main interest there
18:05 foxnorth cos to be perfectly honest, (in my limited experience) i've been finding xul a bit cumbersome and rigid. but that may very well be my limited exp. w/ xul compared to ext/yui/jquery etc
18:05 kados if you think you could do better in ext/yui/jquery ...
18:05 foxnorth i'm not sure!
18:05 kados I'm not gonna hold you back ;-)
18:06 foxnorth but the xul has been interesting, and i also would hate to lose the work that's been put into opencat's xul interface
18:07 foxnorth which comprises much of opencataloger at this point...
18:07 kados slef would probbaly agree with you
18:08 kados about re-designing it without XUL
18:08 foxnorth anyway, as we think about bigger goals and new features, i'm just wondering how it will be to implement in xul. but again, i'm not extremely familiar w/ xul or any other toolkit in particular, so i'm not the best judge.
18:08 kados I guess where is the future?
18:08 foxnorth hhm.
18:08 foxnorth right, where is the future???  
18:08 foxnorth i love the idea of xul.  
18:08 kados are people building xul or ext/yui/jquery apps these days?
18:08 foxnorth yeah, xulrunner seems to have a certain amount of popularity
18:08 foxnorth although the ajax/js toolkits have their fans as well
18:09 kados yup
18:09 kados well I guess Firefox is a XUL application
18:09 foxnorth good point :)
18:10 foxnorth and thunderbird
18:10 slef the future is oranges
18:10 kados and is it developed in xulrunner now?
18:10 foxnorth those are the main two i guess, plus songbird??
18:11 kados there's something sexy about a browser-based MARC editor that works really well
18:11 foxnorth for sure
18:11 slef kados: I wonder about your romantic abnormalities.
18:11 kados I guess the pain of the current implementation in Koha caused me to swing the other way and look for something radical
18:11 kados like XUL
18:11 foxnorth i could definately see that
18:12 kados but if we can acomplish the same goals using ajax toolkits I'd be happy
18:12 foxnorth well i also don't know about the divisino of labor betw. front and backend in terms of the marc editing....
18:13 kados such as?
18:13 kados not sure I understand
18:13 foxnorth like, using perl on the backend to manipulate marc would be a lot easier than dom manipulations in js
18:13 foxnorth then return the record to display
18:13 foxnorth but that's getting close to what koha is now, no?
18:13 kados well
18:13 kados not quite
18:14 kados koha now converts a form submission into a MARCXML string
18:14 foxnorth and then converts marcxml string into marc::record and puts into db?
18:14 kados well 3.0 stores natively as MARCXML
18:15 foxnorth ah right, in zebra?
18:15 kados storage is in mysql
18:15 kados indexing is in zebra
18:15 foxnorth gotcha
18:15 foxnorth got to get 3.0 setup here
18:16 foxnorth anyway, perhaps this is too far afield for opencat
18:16 kados foxnorth: the docs in that package I sent should help out so long as you have a debian etch box
18:16 foxnorth i'm running ubuntu but i could always put debian etch in vmware
18:16 kados I'd recommend it
18:16 foxnorth will do
18:17 kados installation is a bear
18:17 kados ROAR
18:17 kados :-)
18:17 kados anyway
18:17 foxnorth right,
18:47 thd kados: look at the message which I just posted to the opencataloger-dev list
18:47 kados thd: looking now
18:53 thd kados: if what I describe is not available in open cataloger, you will lose the value of a major differentiator for Koha.  I image that will be very expensive loss for marketing Koha support
18:54 thd kados: you will not of course lose anything which you have already but only a significant part of the potential
18:59 foxnorth thd: do you mean an autocomplete-type list populated w/ values such as: a - Language material | c - Notated music that a short description is included along with the value to use?
19:01 thd foxnorth: yes, but also dynamic so that choosing a value for one part/position constrains values for another part/position
19:02 foxnorth yeah, i think both of these would be extremely useful and well received
19:03 foxnorth whatever repetition is necessary in a record (e.g. date in fixed fields and date in publication date area) should be handled by the editor
19:03 foxnorth and eventually validated by the editor where possible (e.g. with dates)
19:06 thd foxforth: however, it is important that the user can avoid being forced to use the additional view by using some preference about what happens upon entering the relevant field/subfield/indicators.  But it should always be available contextually with some command or tabbing to a point where it can be actuated and pressing space or enter to actuate.
19:06 foxnorth yeah, i agree
19:06 foxnorth no need to burden someone when they don't need it.
19:06 foxnorth but the option should be available
19:07 thd yes: cataloguers hate repetition which is why often only the textual value subfields are completed for some data elements
19:10 thd foxforth: I did not understand what was intended by a preference to not have popups except that something like what I described which exists as part of the JavaScript forms based Koha editor would not be possible
19:12 foxnorth thd: what i was thinking was that a popup window slows the cataloging down (have to wait for window to open, read, then close), whereas a dropdown or autocomplete appears w/o obscuring the rest of the record, and yet could give the same semantic information (a - Language material ...)
19:13 foxnorth well, it obscures part, but not as much as popup window perhaps?
19:13 thd foxnorth: yes I agree
19:16 thd foxnorth: although it should be possible to have a view which shows all at once the semantic values recorded for an entire field rather than one position or position group at a time
19:18 thd foxnorth: also some position values must constrain the values for other positions and some positions are only filled collectively with others as a group
19:22 foxnorth yeah, a help pane or dialog box or something should be available to provide help for a particular field, with all positions shown
19:23 foxnorth yeah, the fixed fields are complicated!  
19:24 thd foxnorth: no feature should unnecessarily constrain the speed of the record editor but the speed of completing a fully completed record is what is important and referring to documentation is much slower than selecting a value directly from a self documenting form
19:24 foxnorth we need a good way to define them and their interactions within the fixed fields and within the larger record as a whole
19:24 foxnorth that's right
19:24 foxnorth as you said, referring to documentation is a deterrent
19:24 foxnorth external documentation, that is
19:27 thd foxnorth it is not only the fixed fields which have his problem but also some indicators work together; many subfields have coded values; and some subfields especially in UNIMARC have fixed length positions just like fixed fields
19:27 foxnorth yes that's true
19:27 foxnorth and i need to get familiar w/ unimarc
19:29 thd UNIMARC 1XX are the equivalents of MARC 21 006-008
19:29 foxnorth that's about as far as i've gotten in my understanding so far :)
19:30 foxnorth i wonder i there's a tutorial somewhere comparing marc21 and unimarc for catalogers
19:31 foxnorth bbl
19:31 thd there is a UNIMARC to MARC 21 conversion program at LC
20:01 thd kados: are you still there?
00:28 thd kados: ping
08:37 lloyd morning slef
08:50 slef hi
08:50 dewey hello, slef
08:51 slef I started at 8am with a server crash :-/
08:54 lloyd ahhh nice
08:54 lloyd crappy h/w? :)
08:55 slef No, software needs upgrade, but machine too loaded ATM
08:56 lloyd ahh
08:56 lloyd i started the day at 7:45 with a coffee and 15mins of big brother before getting ready for work :)
09:01 lloyd sad I know

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