Dear Community! My devious little plan for 3.16 is to start getting some RDF/Linked Data/Semantic Web stuff into Koha.
There are two sides to this, both of which should of course be completely opt-in and without side-effects for the MARC-based functionality in Koha: * MARC2RDF conversion MARC records should be converted to RDF and stored in a triplestore, whenever they are added to Koha or edited in Koha. Chris Cormack already made a start on this, but I think we agree now that the actual conversion should be re-written to use Catmandu::RDF. My plan is to either nag Chris into doing this or to fork what he already did and re-write it myself. ;-) * Browsing RDF data in the triplestore should be browsable in the OPAC. I have code for this that is almost ready to be submitted, but I will do some more tweaking before I unleash it. Even if I fail miserably at all of this, it sounds like 3.16 is going to be pretty great! :-) Best regards, Magnus Enger libriotech.no On 10 December 2013 01:59, Galen Charlton <g...@esilibrary.com> wrote: > Hi, > > For discussion, here is a list of some of some things I would like to see in > 3.16. This is not meant to be complete; please feel free to use this thread > both to comment on my goals and to suggest goals that you're personally > willing to advocate for -- and by advocate for, I mean that you and/or the > institutions who support your Koha activity are ready and willing to take > concrete steps to help implement it. I ask that if all you have is an idea > -- no matter how good! -- but not any concrete code or plans to have it be > ready in the next few months -- please start a different thread. > > [1] Deprecation of the GRS-1 mode for Zebra. > > Reason: the DOM index filter allows greater flexibility for setting up > indexing definitions. The DOM filter also offers a path (among other > options) towards indexing non-MARC metadata. > > Obstacles: the default UNIMARC indexing rules for the DOM filter need more > testing. There is also an ongoing discussion about the desired semantics > for the Any index, which at present behaves differently with the current DOM > indexing rules as compared with GRS-1. > > Upgrade considerations: in order to truly deprecate the GRS-1 filter, at > some point there will have to be a forced reindexing upon upgrade. > > [2] Use DBIx::Class to deploy the database schema for new installations. > > Reason: Maintaining multiple SQL schema scripts, one for each DBMS we want > to support, would be error prone. Making edits to classes under > Koha/Schema, then using ->deploy(), offers the possibility of initializing > both MySQL and PostgreSQL databases. > > DBIx::Class::Schema::Versioned could be used at as way of managing schema > updates > > Obstacles: DBIx::Class doesn't automatically know anything about indexes > required for good performance; consequently, it will be necessary to write > hooks for (at least) MySQL to create the necessary indexes. > > [3] Relaunch PostgreSQL support > > Reason: PostgreSQL is a compelling alternative to MySQL, and now that we > have DBIx::Class in place, managing the schema for PostgreSQL is now a more > reasonable proposition. > > For 3.16, I propose the following specific goals: > > - Koha will be installable on a Pg database > - A staff user will be able to create or import and bib record and item > - A public catalog user will be able to search for and retrieve that item > - a reasonable number of the database-dependent tests will pass > > In other words, I'm not proposing that Pg support be ready for production by > 3.16, just that it be just good enough that a developer who wants to improve > Pg support isn't starting from nothing. > > [4] Upgrade the version of Bootstrap we use to 3.x. > > A new major release of Bootstrap was made recently. Unfortunately, it is > not backwards compatible with previous versions (see > http://bootply.com/bootstrap-3-migration-guide for a taste of the issues > involved). > > As much as I'm personally not exactly a fan of the changes that were made to > the CSS class names, we're much better off if we bite the bullet now and > update both staff and OPAC to use the new version of Bootstrap rather than, > two years down the road, finding out that we're completely stuck on Boostrap > 2.3. > > Regards, > > Galen > -- > Galen Charlton > Manager of Implementation > Equinox Software, Inc. / The Open Source Experts > email: g...@esilibrary.com > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web: http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
