Bug 10787 - Linked Data/RDF Omnibus
Summary: Linked Data/RDF Omnibus
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on: 7236 10788 18585
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-27 10:43 UTC by Magnus Enger
Modified: 2018-08-13 01:48 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2013-08-27 10:43:59 UTC
This bug will be an omnibus for adding support for Linked Data/RDF to Koha. Actual work will be done on bugs linked to this bug. 

See http://wiki.koha-community.org/wiki/Linked_Data_RFC for some thoughts on what can/will be done.
Comment 1 David Cook 2018-08-13 01:48:01 UTC
I've been thinking a bit more about RDF in Koha and wondering if we should primarily store the RDF metadata in Koha, as Nick Clemens suggested long ago.

I suppose my reasoning is based on my experience with Fedora Commons (https://wiki.duraspace.org/display/FEDORA4x/Configuring+JDBC+Object+Store) and Apache Fuseki. The production recommendation for Fedora Commons is to use ModeShape within a relational database for storing RDF. Then people can use Fedora's ActiveMQ message queue for updating Apache Fuseki from there. 

As I understand it, Apache Fuseki seems to have one maintainer (who I've talked to using JIRA as I've reported issues and tested fixes for Fuseki). Fuseki doesn't support replication and doesn't really seem to scale that well. It can do online backups which is cool although there are several versions where the backup system is broken. If you do a disk-based backup while Fuseki is running, you'll get a corrupted backup, so you need to use its application-based backup (like with a relational database). 

I think that I like the idea of keeping the source metadata in MySQL and then having the ability to update Fuseki or any other triplestore from there. Even if you did lose all of your Fuseki data, you could always re-create it from the persisted data in MySQL. 

In other words, I think we could leverage the maturity and stability of relational databases, while also taking advantage of the SPARQL query power of a triplestore like Apache Fuseki.