[Koha-devel] Architectural goals for 3.16

[Magnus Enger]

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 <gmc at 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:  gmc at 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 at 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/