Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
146 lines (106 sloc) 5 KB
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.