Mana_central_database for the recent realisation of the below dream.

Intro

Since a long time a question worries me: why does each Koha librariy have to define manually its subscription numbering patterns ? for a given title, all libraries will enter the same data. A more efficient way of doing this is to have a shared "catalogue" of subscriptions numbering pattern.

Thinking more of it, We could do the same thing with SQL queries. In France, all universities must file a yearly report (esgbu) and all public libraries another one (DLL statistics).

Libraries also enter vendors coordinates, that could be shared.

We could have a "worldwide" database, containing those informations, contributed and maintained by the community of koha-libraries. Each local Koha would be connected to this central DB and could derivate info from here

With this in mind, BibLibre has decided to hire a developer for the next summer (3 months). He will work on this project with one of us (probably Julian).

Hopefully, at the end of summer, in subscriptions, statistics, vendors ( written SSV in the rest of this document), there will be the following features added :

the librarian can search for a given SSV in a central database (in the relevant part of Koha, usually adding)
see and clone it locally.
send to the central DB the data, for sharing worldwide (in case the data you're expecting does not exist)
Comment a central data (text) and rank it (at least "wrong data" or "good data, I'm using it")

Technical thoughts

hosted on TBD.koha-community.org (to be created), BibLibre will/can host it (if you have an idea for the name, feel free to propose. We need to find a fancy & appealing name. What about wdh.koha-community.org=Worldwide Data Hub ?)
The DB structure would be generic, to be able to be extended to any other Koha data that would be useful to share.

Proposed DB structure (proposed in SQL. Should we investigate a NoSQL ?)

datashared {id int(11),
    module {subscriptions|statistic|vendor},
    value longtext #data stored in a YAML file
    kohaversion #used to store the kohaversion. Will be useful in case of a DB change,
    email, # the email address of the librarian sharing the data. Cannot be empty
    timestamp, # just in case
}

datashared_description {
    datashared_fk int(11),
    lang, # will contain the description language. Set by default to the staff interface language
    description, (longtext) # description cannot be submitted empty.
    email, # the email of the description writer. Can be empty
    timestamp, # just in case
}

ranking { id int(11),
    datashared_fk int(11),
    email # the email address of the librarian who wrote this rank. Can be empty
    description (text),
    lang, #will contain the language of the staff interface of the "ranker",
    rank boolean, # 0= wrong data, 1=I confirm it work
    kohaversion #for reference
    timestamp #just in case
}

About email addresses:

The email will be the identifier used for updates if a librarian want to update his share.
The fact that we are sending the email address will be clearly displayed on each concerned screen.
The email will be displayed if the librarian says he want so. A ranking can be made without sharing the email.
Sharing a data REQUIRES to share the email. Other things don't require (language description, ranking).

The language thing

Descriptions will be displayed in staff interface language. If not available it will be displayed in English. If not available any activated staff interface languages will be displayed. If none available, random choice.

For ranking, staff interface language ranks will be displayed 1st, then english, then others.

Koha DB changes

The datashared.id will be added into the relevent Koha tables. If the user want to update the central data, this will be used to know which data to update. (question : do we want/need to log changes submitted on wdh.koha-community.org ?)

Details for each shared info

Vendors management

A given vendor can have more than one contact. We store the aqbookseller & all aqcontacts info in a given line.
In the acq module, if a vendor is selected, the librarian can check which contacts he want to import. If the librarian want to share his contacts, they'll be added to the contacts list, not replace it (a dedup will be made on contact email address though)
the value will contain name, address, phone, fax, notes, email, url and aqcontact name, position, phone, altphone, fax, email, notes
the search will be made on the vendor & contact name & email.

Subscription management

The value will contain subscription title, editor, issn, notes, vendor name, and subscription pattern/frequency definition.
search will be made on title, editor, issn

Statistics management

The value will contain saved_sql fields : report_area, report_group, report_name, saved_sql, notes.
search will be made on report area, group, name, notes.

SharingDatasBetweenKohas rfc

Contents