Skip to content
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


SemantiKoha - exploring Linked Data in Koha


The short term goals of this project are to: 

- Harvest bibliographich records from Koha, convert them to RDF and 
  store the RDF in a triplestore. 
- Create proof-of-concept scripts to enhance the converted 
  bibliographic data in the triplestore with data from other sources. 
- Enrich the Koha OPAC with the data from the triplestore. 

The long term goal is to hopefully prove that we do not need the MARC 
data, but that we can do everything MARC could do, and a whole lot 
more, with Semantic Data/RDF/Linked Data. 


A live Koha demo reflectig the current state of the scripts in this 
repository is available here:

This demo works as follows:

1. Records are harvested regularly with the oai_harvester.rb script 
from and turned into RDF, using the 
default NORMARC-to-RDF mapping. The resulting records are stored in a 
triplestore here:

This triplestore is currently running ARC2 
( ), but this may change in the future. 

2. Scripts in the scripts/ directory are run, with the triplestore as 
their target. Currently, picks out URIs for persons 
from the data converted from MARC, that have not yet been enhanced. 
The name associated with the URI is used to query the SPARQL endpoint 
of the Norwegian project "Rådata nå!". When a match is found, RDF data 
from Rådata nå! containing "sameAs" pointers to further data for the 
same person are loaded into the triplestore and new "sameAs"-relations 
added through this process are explored and added to the triplestore 

In time, more original sources will be added, alongside Rådata nå!.

3. Data from the triplestore are displayed in Koha in two different 

3a. Detail pages

When a detial page in the OPAC is displayed, a small box containing 
data from the triplestore is inserted into the page with AJAX 

The following snippet of JavaScript code is included in the opacuserjs 
syspref in Koha:

jQuery(document).ready(function () {
  var id = $(".unapi-id").attr("title");
  $.get("/cgi-bin/koha/", { id: id },

This piece of code looks for an element with class unapi-id in the 
page, and extracts an identifier for the record being viewed, which 
has this form:


where x is the biblionumber of the record being displayed. This string 
is then used to construct an AJAX-request which is sent to the script:

/cgi-bin/koha/ then extracts the actual biblionumber from the string it 
gets passed, and uses that to construct the URI for the record in 
question. This URI is then used to retrieve information about the 
record from the triplestore. This information is formatted with 
templates/ and the resulting HTML-snippet is returned to 
the JavaScript-caller and inserted into the HTML of the record detail 

Currently only names and pictures of authors are retrieved from the 
triplestore to be included in the detail view, but this will of course 
be expanded. Names and pictures of authors are linked to the script, with the URI of the person in question as the 


3b. takes one of two arguments: "id" as described above, or 

Given a URI as argument, relevant information about that URI is 
fetched from the triplestore and displayed on the page. Currently 
pictures and Influenced/Influenced by is shown for persons, along 
with a simple table displaying the results of this generic query:

  GRAPH ?g { <uri> ?p ?o . }

Objects that are of type URI are made clickable so that it is possible 
to explore relations in the data. 

* Shortcuts

At this stage, this work is a proof of concept, so ease of development 
wins over doing things properly. To that end I am in fact running on a separate server from the Koha installation, and just 
making it appear as a page in the OPAC with the following Apache 

RewriteEngine on
RewriteRule /cgi-bin/koha/ [P]

So is in fact the same script as cgi-bin/ in the 
current repository. (I'll probably rename to one 
of these days...)


There is *a lot* of work to do in how displays relevant 
info for a URI. 

- What information to display should be configured in the triplestore, 
  not hardcoded
- should check the rdfs:type of a URI and then act 
  appropriately for each type we have said we are interested in, based 
  on configuration-data stored in the triplestore


You can’t perform that action at this time.