February 2016 - Koha-devel - lists.koha-community.org

RFC for a really new stuff : sharing data worldwide
by Paul Poulain 01 Feb '16

01 Feb '16

Ladies & gentlemen, We're competing more and more against providers that promote a "cloud multi-tenant LMS". Koha is a cloud application (and it is since 2000, long before cloud is born). What does "multi-tenant" mean ? It mean that you'll get access to many resources that are shared worldwide. I think that the "multi-tenancy" is a way for proprietary vendors to lock-in their customers [1]. But the idea of having a worldwide database for some informations is interesting and relevant. Proprietary vendors take care of updating this database. Open Source projects are not working centrally, so we must find another way of creating and maintaining such a database. With this thing in mind, BibLibre has decided to sponsor an intern + some internal resources for next summer dedicated to a project dedicated to sharing data between koha instances worldwide. I wrote a 1st draft of RFC and I'd like to have your feedback: http://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc If this project is successful, in the automn version of Koha, we may see a way to share worlwide data between all Koha libraries ! [1] if you're a proprietary vendor and are reading this: I don't mean it's the only reason for multi-tenancy. -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

5 8

Jenkins (we want to move the server)
by Paul Poulain 01 Feb '16

01 Feb '16

Hi koha-devel (and especially chris I think) The jenkins server is now pretty old, we (BibLibre) have new (fancy) platforms where we would like to move it. First question: do we agree that jenkins.koha-community.org is now only collecting data from other servers as "master", and no integration is made on BibLibre server anymore ? If I'm wrong we need some explanations ! Migration plan: what do we need to move ? the .war only ? a mysql db we have [koha, koha_univ_lyon3, koha_biblibre_master] ? Another question: it seems I don't have an account anymore on jenkins http. thx to answer by including laurent, our sysop (he's not on koha-devel) -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

4 11

Staff Client Normal View details
by akafortes 01 Feb '16

01 Feb '16

Hello everyone, I'd like to ask if it is possible to add the value of a MARC field as a label in one of the Normal view fields. I use the "UNIMARCslim2intranetDetail.xsl". And I have something like this: <xsl:call-template name="tag_7xx"> <xsl:with-param name="tag">700</xsl:with-param> <xsl:with-param name="label">Main Author</xsl:with-param> </xsl:call-template> Which in the Normal View, on the Staff Client would Display: Main Author: Author's Name from 700 I use the 700$4 to store a code that Identifies, in a way, what that person is. I use a list of authorized value of this form: Value Description 005 Actor 070 Author . . . What I'd like to do is something like this: <xsl:call-template name="tag_7xx"> <xsl:with-param name="tag">700</xsl:with-param> <xsl:with-param name="label">700$4 Description</xsl:with-param> </xsl:call-template> So for example if record has "Author" in the 700$4 then I'd want the normal view to display that as a label Can anyone please tell me if: 1) is this possible to be done? 2) if it is possible, how would I go about doing it? Thank you very much -- View this message in context: http://koha.1045719.n5.nabble.com/Staff-Client-Normal-View-details-tp587228… Sent from the Koha-devel mailing list archive at Nabble.com.

1 1

Re: [Koha-devel] [Koha] Koha and OAI-PMH [and digital materials]
by David Cook 01 Feb '16

01 Feb '16

Hi Joel, Thanks for your email. I think I’ve sorted things out with Flo, but I wanted to come back to your email, which I’m going to cross-post to the developer listserv as well. I originally started working on an OAI-PMH harvester to create an automatic import of records from DSpace into Koha, so that Koha could show electronic resources in the catalogue. While having good item types, frameworks, and templates are good, I found the main problem to be the metadata quality. Dublin Core doesn’t translate very well to MARC. Although now that I’m re-reading your email… are you talking about making MARC records in Koha and then using DSpace’s OAI-PMH harvester to import metadata from Koha? Then attaching digital materials in DSpace while using Koha to maintain the metadata? That could be interesting… I agree that Koha needs to evolve to have better support for digital materials. However, I’m not sure what you mean by “a first-class framework for URL-only item types” though. Could you elaborate on that? Better integration into systems like DSpace may be achieved using their evolving REST APIs, although again I’m not sure what you mean by “a user might end up checking-out some digital content stored there [DSpace? Koha?] (a record is created in the issues table) that doesn’t need to check back in”. Why would you need to check out digital content in DSpace? In my experience, content is either open to the public or limited to logged in users (as part of licensing/rights restrictions). Are you thinking of something more like hosting your own ebooks in DSpace and complying with concurrent user restrictions? That could be interesting as well, although I think the majority of that work would be done in DSpace with Koha just hooking into a DSpace API to determine if there are any “available” copies for the material that they found in the Koha catalogue. I admit I’m not super familiar with ebook DRM either, so I’m not certain how much intervention would be required for expiring “on loan” DRM protected library ebooks. Personally, I find most of our Koha client libraries are interested in allowing their users to find “only electronic resources” and to provide seamless access to third-party sites like EBSCO, Proquest, and other publishers that host the actual content. EBSCO have been putting work into that with the Koha-EDS plugin, although I’d like to see more done in that area, although that’s actually more a matter of digital material publishers providing authentication and API options. If they provide the hooks, we can provide the services. I’m curious to hear your thoughts. If you have ideas for things you’d like to see, feel free to share them. If you have a budget for sponsoring development, feel free to mention that as well. It’s actually quite an exciting time to be working on Koha as large organizations like EBSCO and the National Library of Sweden are sponsoring developments in areas like OAI-PMH harvesting (which I’m working on now), moving to ElasticSearch for search and retrieval, a new REST API, etc. Even if you don’t have the money yourself, you might propose ideas on the koha-devel listserv and see if anyone is interested in sponsoring that work. Cheers, David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Coehoorn, Joel [mailto:jcoehoorn@york.edu] Sent: Wednesday, 27 January 2016 10:25 AM To: David Cook <dcook(a)prosentient.com.au> Cc: koha(a)lists.katipo.co.nz; flo.pouyenne(a)gmail.com Subject: Re: [Koha] Koha and OAI-PMH It sounds like she's talking about using a program that acts kind of like a web search crawler, similar to how Googlebot operates, to push information into Koha. If that's the case, I don't think Koha would be a good solution for this right now, though you might get something working via a z39.50 connection. It may be that she's asking if Koha can store and serve/circulate harvested digital content directly. Again, I don't believe Koha in it's current form would be good at this. Koha does not currently provide any place to store binary files for circulation. It may also be that she's asking if she can use Koha as a front end into something like DSpace <http://www.dspace.org/> or Greenstone <http://www.greenstone.org/> . If that's the case, I believe Koha can do this right now, but the setup is not yet easy or straightforward. In a nutshell, you would want to enter marc records for each item in the repository, just like you do for current materials, but you would want to use item types and a custom framework so that the material is presented well. I would welcome improvements in Koha to support any of those scenarios. Ultimately, I think Koha needs to evolve to have better support for digital materials. At a minimum, this means a first-class framework for URL-only item types along with first-class integration into systems like DSpace, where a user might end up checking-out some digital content stored there (a record is created in the issues table) that doesn't need to check back in. As distasteful as it may be, this probably needs to also include some kind of copyright enforcement mechanism, to allow libraries to easily comply with external licensing requirements. <http://www.york.edu/Portals/0/Images/Logo/YorkCollegeLogoSmall.jpg> Joel Coehoorn Director of Information Technology 402.363.5603 jcoehoorn(a)york.edu <mailto:jcoehoorn@york.edu> The mission of York College is to transform lives through Christ-centered education and to equip students for lifelong service to God, family, and society On Tue, Jan 26, 2016 at 5:04 PM, David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Hi Florence, I'm afraid that I don't understand your question. What do you mean by "Can Koha be used to manage a digital library"? Are you asking if Koha can show metadata records from a digital library? Or are you asking if Koha can add/update/delete records in a digital library? Or both? Or something else? I'm currently working on an OAI-PMH harvester for Koha, but the sole intent at the moment is to harvest metadata records from other systems and import them into Koha. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 > -----Original Message----- > Date: Tue, 26 Jan 2016 15:08:31 +0000 (UTC) > From: Florence <flo.pouyenne(a)gmail.com <mailto:flo.pouyenne@gmail.com> > > To: koha(a)lists.katipo.co.nz <mailto:koha@lists.katipo.co.nz> > Subject: [Koha] Koha and OAI-PMH > Message-ID: <loom.20160126T160510-456(a)post.gmane.org <mailto:loom.20160126T160510-456@post.gmane.org> > > Content-Type: text/plain; charset=us-ascii > > Hello, > > Can Koha be used to manage a digital library ? With a OAI-PMH harvester ? > > > > ------------------------------ _______________________________________________ Koha mailing list http://koha-community.org Koha(a)lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> https://lists.katipo.co.nz/mailman/listinfo/koha

1 0

New Zebra Version 2.0.62 (Relevance plus st-numeric && CHR documentation fix)
by David Cook 01 Feb '16

01 Feb '16

Hi Barton and all, Just noticed that Zebra 2.0.62 came out on the weekend: <http://lists.indexdata.dk/pipermail/zebralist/2016-January/002642.html> http://lists.indexdata.dk/pipermail/zebralist/2016-January/002642.html You’ll see “Allow @attr 2=102 for numeric index” near the bottom of the announcement. That should allow the use of “rk=()” around a query that contains a st-numeric qualifier. I haven’t tested it yet, but just a head’s up. Barton, you may find that fixes the problem you were experiencing in November. They’ve also updated the documentation for the charmap files for “equivalent” ( <https://github.com/indexdata/idzebra/commit/0e8272b3d5a18a0695f8c7a58617caa…> https://github.com/indexdata/idzebra/commit/0e8272b3d5a18a0695f8c7a58617caa…) ( <http://www.indexdata.com/zebra/doc/character-map-files.html> http://www.indexdata.com/zebra/doc/character-map-files.html) It mentions that “equivalent” is actually for searching and not for sorting. It also mentions that the equivalent directive takes place before the map directive. I think we might want to update some of our CHR files in light of this clarification. At the moment, in Koha, I think if you search for “carers” you’ll also get hits for “careers” because of the following directives: equivalent ëē(ee) map ë e map ē e I think it’s because the term “careers” would be equivalent to “carērs” and “carërs”, according to the equivalent directive. And “carērs” and “carërs” would both map to “carers” with the map directive, which means that “carers” would get hits for a “careers” value. I’ve seen the same thing with “Siemon” and “Simon”: equivalent ï(ie) map ï i equivalents: Siemon = Sïmon map: Sïmon = Simon So a search for “Siemon” would equal “Simon”. Conclusion: I think we could actually go without the “equivalent” directive and just use “map”, since “map” is for indexing, searching, and sorting. We get everything we need from “map”. I don’t think the equivalent is even 100% correct. For Scandinavian languages, this line would be incorrect: equivalent aáàãåâăąȧǎȁȃ å should actually be equivalent to “aa”. If you look at the system Zebra file scan.chr, you’ll see “equivalent å(aa)”. Anyway, just a FYI to everyone… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Barton Chittenden [mailto:barton@bywatersolutions.com] Sent: Monday, 9 November 2015 11:14 PM To: David Cook <dcook(a)prosentient.com.au> Subject: Re: Searching numeric ranges On Mon, Nov 9, 2015 at 1:33 AM, David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Hi Barton: I’d have to explore some more and I’ve already overstayed my day by 30 minutes. Quite understandable :-) I’d suggest adding the “SetEnv DEBUG 1” to your Apache configuration. That should output the final Search.pm query to your logs, and then you can explore from there. Yeah, I just hard coded DEBUG=1 in search.pm <http://search.pm> on my development instance. All the search debugging spam, with none of the other spam. We determined that the ranking operator/zebra construct rk( ... ) is incompatible with st_numeric :-P ... or at least that was Jesse Weaver's assessment... I was log-blind (you see too much snow, you go snowblind, you see to many logs, you go log-blind). I'll dig up more details in a bit. Thanks, --Barton I might have some time to look tomorrow though :) David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Barton Chittenden [mailto:barton@bywatersolutions.com <mailto:barton@bywatersolutions.com> ] Sent: Friday, 6 November 2015 8:04 AM To: David Cook <dcook(a)prosentient.com.au <mailto:dcook@prosentient.com.au> > Subject: Fwd: Searching numeric ranges Hey, I thought this might be in your area of expertise. The CCL part is working but once it gets inside C4/Search.pm ... god knows.... Cheers, --Barton ---------- Forwarded message ---------- From: Barton Chittenden <barton(a)bywatersolutions.com <mailto:barton@bywatersolutions.com> > Date: Thu, Nov 5, 2015 at 11:47 AM Subject: Searching numeric ranges To: Koha-devel <koha-devel(a)lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > I am working on searching lexile number ranges. ccl.properties shows lex 1=9903 r=r The 'r=r' bit means that I should be able to search using a numeric range separated by a dash, e.g. 500-600 Should return any numeric results from 500 to 600. The following query works: cgi-bin/koha/catalogue/search.pl?q=ccl%3Dlex%2Cst-numeric%3D500-600 <http://search.pl?q=ccl%3Dlex%2Cst-numeric%3D500-600> However, when I try adding that as an item in the search menu, as follows: $(document).ready(function(){ //add lexile to search pull downs $("select[name='idx']").append("<option value='lex,st-numeric'>Lexile (e.g. 600 or 550-650 )</option>"); }); That gets munged... the url reads cgi-bin/koha/catalogue/search.pl?idx=lex%2Cst-numeric <http://search.pl?idx=lex%2Cst-numeric&q=500-600> &q=500-600 And I get the following message: No results found No results match your search for 'lex,st-numeric: 500-600'. --Barton

1 0