[Koha-bugs] [Bug 10787] Linked Data/RDF Omnibus

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10787

David Cook <dcook at prosentient.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcook at prosentient.com.au

--- Comment #1 from David Cook <dcook at prosentient.com.au> ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.