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

Call for news: April 2017 Newsletter
by kohanews 14 Apr '17

14 Apr '17

I'm collecting news for the April newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: - Please include dates for past events. If I can't find dates I may not add it. - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon - For past events , **** one month back is the cut-off ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. -- Chad Roseburg Editor, Koha Community Newsletter

1 0

RDF Dereferencing/tracing/following links
by David Cook 13 Apr '17

13 Apr '17

Hi all, The key to Linked Data is obviously the links, but I dont think any of us quite know how the links actually work. In theory, I imagine having a record (ie a set of triples), in a local triplestore, which links to records available on the Internet. Periodically, those records are downloaded, and stored in a local triplestore as a cache. Then we somehow follow the links as they are stored in our local triplestore and have a set of string literals which we can show to users on a web page. In practice, I dont know how that would work. I can see us getting a list of record subjects in our local triplestore, and then iterating through each one to download the links in its objects. But I dont know where wed put that content. I also dont know if wed recurse into that content to follow more links or not. Lets say that we store that content in named graph called cache. When it comes time to re-trace the links for our list of record subjects, how do we know what local content to delete? In theory, we could use the URI from the object, but many records contain many subjects, so even if we did delete that subject from cache, we havent deleted the other subjects that it links to internally in the triplestore. Im going to ask around to see if anyone can enlighten me. Im hoping Petter might be able to shed light on how Oslo Public Library makes it work, especially in the context of ls.ext interfacing with Koha! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595

1 0

Roles for Koha 17.10
by Kyle Hall 12 Apr '17

12 Apr '17

Hey all, it's about that time of year again! I've created a skeleton wiki page for the Koha 17.10 roles! I've left it nearly all TBD so if you want to continue your role, please update this page! https://wiki.koha-community.org/wiki/Roles_for_17.11 Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org )

4 5

Linked Data Discussion from Hackfest
by Joy Nelson 11 Apr '17

11 Apr '17

Here's a quick recap of the linked data discussion we had at Hackfest in Marseille. It's a two part email: a little linked data background by me and technical discussion by Nick Clemens. Thanks! joy & nick Joy Nelson I gave a brief presentation on linked data and the benefits and potential challenges inherent in moving towards a linked data system. It was based loosely on the presentation given at KohaCon 2016 which can be viewed here: https://www.slideshare.net/talljoy/kohacon2016 We discussed some of the challenges in linked data. One of those is "Choice of Linked Data Vocabulary". In the U.S. the Library of Congress is developing BibFrame as a MARC replacement. Ideally, the system created would be 'vocabulary agnostic'. The Koha linked data system should allow users the ability to utilize one of many vocabularies or *any* vocabulary they wish. (bibframe, bf:lite, schema.org, dublin core, etc) Identifying the purpose of Linked Data is another area that needs discussion and some consensus. How do libraries envision themselves using this kind of data/system? -Do we create triplestores converted from MARC to store and allow those stores to be crawled? Thereby making a collection visible on the web in search results. -Do we concentrate on creating a system that allows for libraries to connect their data to other libraries, data stores external or internally? For example, Is the goal to link our authors and subject tags to URIs on the web that we can pull in to Koha and display more information to the user? -Do we create linked data URIs for special libraries (museums, academic institutions) to provide to other institutions and allow others to link into their system to gather data to display to their users? Linked Data is a fundamental shift in how we think about our data and how we will use that data. It is a much more cooperative venture in cataloging that will provide benefits to both staff and patrons. Nick Clemens I presented the basic work I have done on implementing a triplestore backend for Koha which can be found on github here: https://github.com/bywatersolutions/bywater-koha-devel/tree/RDF The code is very basic so far and does a few things: 1 - Implements Koha::RDF::Store as a base for which all individual backend implementations will be built 2 - Adds a beginning implementation of RDF::Trine to allow storage and retrieval of RDF triples 3 - A very basic form on the intranet details page to enter a predicate and subject (assuming the URL of the details page) as the object The code is a start and begins to raise a few of concerns which I see and what we need to do to continue. I am very interested in developing Koha/RDF in a way that is backend agnostic and allows for differing front end implementations. The next steps I see are: 1 - We must agree on a common set of subroutines that any backend will support. They will require basic CRUD and options for retrieving in various formats 2 - We will need to develop endpoints: A SPARQL endpoint, and REST endpoints for CRUD, and OAI endpoints 3 - We need to decide on how we will mint and serve URIs - we could continue to use the current details URLs and add parameters for format to supply triples or xml, however, for things like works and authors we will need some method of linking. Links with parameters are not as 'cool' as named or numbered URIs but provides the ability for linking our data out to other resources, making it crawlable, and internally linking. Once we can agree on building a base together, than we can all proceed to develop in different directions as we see fit and provide various options that can all be pursued without conflict or duplicated effort. -- Joy Nelson Director of Migrations ByWater Solutions <http://bywatersolutions.com> Support and Consulting for Open Source Software Office: Fort Worth, TX Phone/Fax (888)900-8944 What is Koha? <http://bywatersolutions.com/what-is-koha/>

1 0

Koha Development Meeting Reminder
by Nick Clemens 11 Apr '17

11 Apr '17

Hi All, Just a friendly reminder that the next Koha Development IRC meeting is tomorrow, 12 April 2017, at 19UTC And a reminder that April is quickly followed by May so now is a good time to come and mention anything of import for 17.05. Here is a converter for local date and time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Koha+Developers+I… The agenda is on the wiki, please add any topics you wish to discuss https://wiki.koha-community.org/wiki/Development_IRC_meeting_12_April_2017#… I will try to send an ES update before or after the meeting, hope to see you all there :-) -Nick

1 0

Plack and CGI : where to put initialization code ?
by Julian Maurice 10 Apr '17

10 Apr '17

Hello developers, I need to execute code at the beginning of every request. For now it's in a BEGIN block. It works well in CGI mode, but not at all with plack (it's only executed once). I tried moving the BEGIN block into a sub init(), calling this sub in the BEGIN block and in the PSGI file (in CGI::new wrapper). It works but it doesn't feel "right". Is there a common place to put this kind of code ? Should I use the L1 cache (which is flushed at every request) to store some state (initialized or no) and call init() in every method of the module or something like that ? -- Julian Maurice <julian.maurice(a)biblibre.com> BibLibre

2 2

What's on in koha-devel #11
by Jonathan Druart 04 Apr '17

04 Apr '17

Hello librarians and developers, Not much has happened this month in terms of development. Things are going very slowly at the moment, despite the hackfest in Marseille. We see a lot of new people on the mailing list and the IRC channel asking for questions, but we need more people to be involved in the discussions and the signoff process. There are hundreds of people on this list, you need to know that the Koha community needs you to make the project moving forward. I know that nobody has enough time, but you know one hour per week of even per month can help a lot. It is very easy, fun and interesting :) = How to get involved? = The first action would be to join us on the #koha IRC channel and the koha-devel mailing list. Start by presenting yourself, where do you come from, what do you do? For how long have you been using Koha? How do you think you can help? Attend meetings! We have two kinds of monthly meeting. There is a general one to talk about koha-related stuffs, and the development meeting to talk about technical stuffs. It is important for the community to have a place to be all together and try to make things move. If you are a librarian, we need you to tell developers the directions they need to go. Open bug reports It is important to know that everybody can open new bug reports on our bug tracker (https://bugs.koha-community.org) It is useful for the development team to know the new bugs. And it is also important for you to search for known bugs. A lot of bugs are known from developers but we do not know how to fix them because we are waiting for feedbacks from users. The dashboard (http://dashboard.koha-community.org) is very helpful to know the "hot" bugs that need to be fixed/tested/QAed. The "Overall bug traker health status" section displays the number of new bugs that are important to follow, make moving. If a developer submits a patch for the bug you opened, try and test it! Test bugs Here is how you can really makes things move for the community. You become involved in the development process and make the Koha project better. Sandboxes (https://wiki.koha-community.org/wiki/Sandboxes) are available to test patch easily. You do not need to install anything on your computer and do not need any technical skills. If you are a Koha user, you can test patches! Write patches If you are a developer or have a minimum of technical skills you can write your own patches and fixes bugs or develop new feature. Our dedicated wiki page (wiki.koha-community.org/wiki/Submitting_A_Patch) will guide you over the different steps. It is very easy to get a development environment using KohaDevBox ( https://github.com/digibib/kohadevbox) Start with small patches :) = Refactoring = If you have read my previous "what's on in koha-devel" emails, you may have noticed I talked a lot of "refactoring" bugs. And maybe you do not know what it is and what it brings. The Koha codebase is aged/old, and has grown very quickly since 2006. Since the last few years the development team decided to make the code more robust and slow the integration of patches, getting a stronger integration process. That's why we need to have at least one tester validating the patches, then one QAer to review the patch technically and finally the Release Manager to push it. That's mean 4 independent persons for a single patch. That made our codebase stronger and less regression prone. Some part of the code now needs to be rewritten, and it is why I have focussed on the "refactoring" work over the last year. The goal is to rewrite modules of Koha, step by step. It cleans the code, makes it more readable, reduces the number of lines, centralise the responsibilities, homogenise the code, fixes bugs, adds test coverage, etc. On the mid-long term it means a modern application, easy to maintain, robust, flexible. The bugs will be easier to fix, the enhancements will be quicker to develop and so less expensive. Do you start to understand how it is useful? So yes, it's boring to test because it does not bring anything new to the interface, but the project needs it. If you have been using Koha for months or years, it made you save money, it makes you happy to use it and you love it. If you already got answer from people on the mailing lists or the IRC channel, it's time to say thank you, by getting involved! If you have any specific questions on how to get involved, you can join me on the IRC channel or by email. I can help and guide you if necessary. A developer that loves Koha but needs help, Jonathan

2 1

KohaDevBox refatoring
by Tomas Cohen Arazi 03 Apr '17

03 Apr '17

Hi everyone, this wekend I took the time to reorganize the tasks that are ran to get KohaDevBox up and running. The main task was splitting some steps (like koha-common install, instance creation and gitifying) This makes it easier to spot potential order issues. As usual, I hope you can have some time to test it and file bugs if needed. I'll try to fix them ASAP. Thanks! -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

1 0

Documenting notices and scripts
by Barton Chittenden 31 Mar '17

31 Mar '17

I've been working on documenting all of the possible notices in the letter table, in terms of letter_code, available markup, and which tables we can pull data from. this is collected here: https://wiki.koha-community.org/wiki/Customising_Notices_and_Slips#Notice_S… I updated the wiki page this morning, everything is up-to-date with master... but there's one thing I don't understand: SendAlerts. It looks like the letter code is passed in via cgi param, and I don't know what letter_codes are available for the calls in C4/Serials.pm, acqui/ lateorders.pl and serials/claims.pl Searching for enlightenment, --Barton

1 0

Koha Community Newsletter: March 2017
by kohanews 31 Mar '17

31 Mar '17

Fellow Koha users: The Koha Community Newsletter for March 2017 is here: https://koha-community.org/koha-community-newsletter-march-2017/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter

1 0