[Koha-devel] Linked Data Discussion from Hackfest

Joy Nelson joy at bywatersolutions.com
Tue Apr 11 23:11:36 CEST 2017


Here's a quick recap of the linked data discussion we had at Hackfest in
Marseille.  It's a two part email: a little linked data background by me
and technical discussion by Nick Clemens.
Thanks!
joy & nick


Joy Nelson
I gave a brief presentation on linked data and the benefits and potential
challenges inherent in moving towards a linked data system.  It was based
loosely on the presentation given at KohaCon 2016 which can be viewed here:
https://www.slideshare.net/talljoy/kohacon2016

We discussed some of the challenges in linked data.  One of those is
"Choice of Linked Data Vocabulary".  In the U.S. the Library of Congress is
developing BibFrame as a MARC replacement.  Ideally, the system created
would be 'vocabulary agnostic'.  The Koha linked data system should allow
users the ability to utilize one of many vocabularies or *any* vocabulary
they wish. (bibframe, bf:lite, schema.org, dublin core, etc)

Identifying the purpose of Linked Data is another area that needs
discussion and some consensus.  How do libraries envision themselves using
this kind of data/system?

    -Do we create triplestores converted from MARC to store and allow those
stores to be crawled?  Thereby making a collection visible on the web in
search results.
    -Do we concentrate on creating a system that allows for libraries to
connect their data to other libraries, data stores external or internally?
For example, Is the goal to link our authors and subject tags to URIs on
the web that we can pull in to Koha and display more information to the
user?
    -Do we create linked data URIs for special libraries (museums, academic
institutions) to provide to other institutions and allow others to link
into their system to gather data to display to their users?

Linked Data is a fundamental shift in how we think about our data and how
we will use that data.  It is a much more cooperative venture in cataloging
that will provide benefits to both staff and patrons.

Nick Clemens
I presented the basic work I have done on implementing a triplestore
backend for Koha which can be found on github here:
https://github.com/bywatersolutions/bywater-koha-devel/tree/RDF

The code is very basic so far and does a few things:
1 - Implements Koha::RDF::Store as a base for which all individual backend
implementations will be built
2 - Adds a beginning implementation of RDF::Trine to allow storage and
retrieval of RDF triples
3 - A very basic form on the intranet details page to enter a predicate and
subject (assuming the URL of the details page) as the object

The code is a start and begins to raise a few of concerns which I see and
what we need to do to continue. I am very interested in developing Koha/RDF
in a way that is backend agnostic and allows for differing front end
implementations.

The next steps I see are:
1 -  We must agree on a common set of subroutines that any backend will
support. They will require basic CRUD and options for retrieving in various
formats
2 - We will need to develop endpoints: A SPARQL endpoint, and REST
endpoints for CRUD, and OAI endpoints
3 - We need to decide on how we will mint and serve URIs - we could
continue to use the current details URLs and add parameters for format to
supply triples or xml, however, for things like works and authors we will
need some method of linking.  Links with parameters are not as 'cool' as
named or numbered URIs but provides the ability for linking our data out to
other resources, making it crawlable, and internally linking.

Once we can agree on building a base together, than we can all proceed to
develop in different directions as we see fit and provide various options
that can all be pursued without conflict or duplicated effort.

-- 
Joy Nelson
Director of Migrations

ByWater Solutions <http://bywatersolutions.com>
Support and Consulting for Open Source Software
Office: Fort Worth, TX
Phone/Fax (888)900-8944
What is Koha? <http://bywatersolutions.com/what-is-koha/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20170411/3f029408/attachment-0001.html>


More information about the Koha-devel mailing list