IRC log for #koha, 2007-06-15

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
13:15 slef kados or paul alive?
13:19 kados slef: yo
13:23 slef 1mo, phone
13:23 sorry
13:24 lloyd ;)
13:34 kados - check your mail :)
13:35 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 but I'm meeting with Ebsco at ALA next week
13:39 to discuss it
13:39 hi thd
13:39 lloyd kados - yeah very lol
13:40 kados thd: https://mail.gna.org/public/op[…]-06/msg00024.html
13:40 thd: you can see some of the fruits of our labor last night in that email response
13:41 thd: feel free to join that list and add your comments to the mix :-)
13:41 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 it's a pretty simple process actually
13:42 most implementations use FTP
13:42 AFAIK
13:42 the EDI messages are gonna be different for every vendor
13:43 like all library standards
13:43 slef only thing I think is really new there is to feed the MARC record from
13:43 the supplier into the reservoir so it's ready for acquisitions
13:43 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 you want to attach it to the bib record
13:43 when you acquisition something in Koha, it creates a minimal bib
13:44 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 yea
13:44 we sorta have to
13:44 at least that's how it's supposed to work
13:45 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 what I want to be able to do
13:45 slef tracks the order, balances the budgets
13:45 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 update the budget
13:46 then  track the order
13:46 allow claims automatically
13:46 (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 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 thd: and how well written the code is
13:48 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 http://www.xml-edifact.org/TR/XML-Edifact-3.html
14:03 thd: this one?
14:04 XML::Edifact - an approach towards XML/EDI as a prototype in perl
14:04 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 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 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 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 http://www.bic.org.uk/ecommerc[…]ementation.html#2
14:17 oh yeah, it hooks to EDIFACT for the INVOICES stuff
14:17 sorry
14:17 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 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 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 http://www.s-mart.net/medici/
14:35 that is the most complete set of modules for EDI in Perl
14:36 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 kados: what is that list?
14:41 kados thd: that's the opencataloger list
14:41 thd: for the opencataloger project
14:41 thd the classroom part?
14:42 or is that list also being used for the Koha development as well
14:42 ?
14:43 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 kados: and also where do I subscribe?
14:44 slef vrooooooooooooom
14:45 https://mail.gna.org/listinfo/opencataloger-dev
14:46 as an aside, please ask opencataloguer to "use but not rely on" javascript ;-)
14:46 kados slef: ha!
14:46 slef: that's not the purpose of opencataloger
14:47 slef: the existing MARC record editor in KOha fulfills that goal
14:47 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 That's not informative!
14:48 https://gna.org/projects/opencataloger
14:48 so what is opencataloguer?
14:48 http://home.gna.org/opencataloger/
14:49 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 http://kados.org/stuff/opencat[…]dfield_editor.png
14:50 lloyd opencatlog :)
14:50 kados http://kados.org/stuff/opencat-help.png
14:50 http://kados.org/stuff/opencat-results.png
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 http://wiki.liblime.com/doku.p[…]catalogingproject
14:51 historical info on the origins ofthe project and the goals
14:51 slef heh, tabs... anyone want a http://www.useit.com/alertbox/991114.html
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 It's ridiculous to expect a modern web application to fully function completely free of javascript
14:53 ...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 because of its accessibility, energy and abuse problems.
14:53 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 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 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 thd: http://www.dailymail.co.uk/pag[…]5&in_page_id=1879
15:03 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 slef: there is no budget for this, it's being done on a shoestring
15:03 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 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 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 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 slef: shift-numlock starts the mouse keys function
15:22 in X-windows
15:22 slef oh yeah, and tap shift while pointing to go faster
15:23 I tried ctrl-alt-numlock, which was close but no cookie
15:23 and 5 to left-click
15:23 where are the other mouse buttons?
15:24 thd sets the left button
15:24 slef: / sets the left button
15:24 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 slef: + gives a double click
15:27 slef: all the numbers around 5 point in their relative direction of course
15:28 [K] *** part FreeNode!#koha: _lloyd_ n=lloyd_p0@nat.wsufftrust.org.uk
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 there is are programs for better control of the feature but none are packaged for Debian unless you use Gnome or KDE
15:32 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 i bet!
17:52 kados but it's important I think
17:53 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 thought of that last night: open file of MARC records
17:55 foxnorth yeah, need that
17:55 kados and saving too
17:55 definite must
17:57 cool
17:57 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: wiki.liblime.com
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 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 yet
18:00 kados there's also the Dojo Offline Toolkit
18:00 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 HTTP standard. (foldoc)
18:02 kados xulrunner is really nice actually
18:02 that's what EG's staff client is packaged in
18:02 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 slef: yea, isn't that nuts
18:03 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 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 which comprises much of opencataloger at this point...
18:07 kados slef would probbaly agree with you
18:08 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 right, where is the future???  
18:08 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 although the ajax/js toolkits have their fans as well
18:09 kados yup
18:09 well I guess Firefox is a XUL application
18:09 foxnorth good point :)
18:10 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 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 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 then return the record to display
18:13 but that's getting close to what koha is now, no?
18:13 kados well
18:13 not quite
18:14 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 indexing is in zebra
18:15 foxnorth gotcha
18:15 got to get 3.0 setup here
18:16 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 ROAR
18:17 :-)
18:17 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 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 ....so 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 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 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 no need to burden someone when they don't need it.
19:06 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 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 well, it obscures part, but not as much as popup window perhaps?
19:13 thd foxnorth: yes I agree
19:16 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 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 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 that's right
19:24 as you said, referring to documentation is a deterrent
19:24 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 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 i wonder i there's a tutorial somewhere comparing marc21 and unimarc for catalogers
19:31 bbl
19:31 thd there is a UNIMARC to MARC 21 conversion program at LC
20:01 kados: are you still there?
00:28 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 crappy h/w? :)
08:55 slef No, software needs upgrade, but machine too loaded ATM
08:56 lloyd ahh
08:56 i started the day at 7:45 with a coffee and 15mins of big brother before getting ready for work :)
09:01 sad I know

← Previous day | Today | Next day → | Search | Index

koha1