← 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_p0nat.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