Summary: A description and example of using Select2 to build an editing interface for RDF data. Sample HTML and JavaScript is included that relates skos:Concepts from the assignFAST webservice provided by OCLC to local researcher URIs.

Overview

I've been working on a project that requires an end-user web interface that is both simple to use but also updates underlying RDF data about researchers and their activities. When we started this project, we reviewed available libraries for building web based editing interfaces on top of RDF and found a fair number. During our review, however, most of those we found fell short of meeting our requirements, mostly because few are being actively maintained or developed.

Knowing that there is a great deal of work being done with JavaScript frameworks and libraries, we looked outside the scope of RDF specific tools. Select2 was quickly identified as tool we wanted to use. Select2, as the project says somewhat humbly, "is a jQuery-based replacement for select boxes." It supports searching, remote data sets, and infinite scrolling of results." The examples page does a great job of showing the capabilities of the library and documenting its feature.

One of the primary editing functions we wanted to support with our web application was the ability for users to add relationships to concepts (e.g. topics or geographic areas studied) or people (collaborators). Select2's tagging widget seemed like a good candidate because it provides a straightforward input element for users to begin typing tags and the library provides autocompletion to match existing terms. Select2 also supports loading remote data via AJAX, which again suited us well because the RDF application we are using, VIVO provides autocomplete web services as well. The remote loading, via AJAX, also makes it possible to look up entities in external systems and pull those into the user interface as suggested tags.

Solution

After determining Select2 was a good solution to our user interface requirements. We began to investigate how we could create triples like below from Select2 editing events.

@prefix ex: <http://example.org/>.
@prefix vivo: <http://vivoweb.org/ontology/core#>.

ex:person123 vivo:hasResearchArea ex:concept456 .

Since Select2 as a library focuses on the front-end editing interaction, it doesn't prescribe a backend for storing data created. Adapting it to create the data we needed was a matter of reading the documentation and taking advantage of the rich options offered.

The next step was to develop a way to embed RDF-like information in the page so that we could create triples representing the data that users changed. We considered several approaches to embedding this semantic information into the application but decided using HTML5 data attributes were a simple and straightforward way. See the snippet below. The URI for the entity being updated 'ex:jsmith' is added as a data attribute to the containing div. The Select2 input element has the data attribute for the predicate 'vivo:hasResearchArea' and the term resolved via autocomplete will become the object. We are using a standard set of namespace prefixes so the embedded qnames - 'data:jsmith' - can be expanded to the full uri, e.g. http://example.org/individual/jsmith'.

    <div id="profile" data-subject="ex:jsmith">
        <h5>John Smith - reseacher</h5>
        <label for="research-area">Research areas:</label>
        <input id="research-area" data-predicate="vivo:hasResearchArea"/>
    </div>

With the HTML data properties in place, we can then use Select2's support for remote data sources to pull in suggested tags (either a local webservice or third party API) and use the events generated by Select2 objects (tag added or tag removed) to create intermediate JavaScript data structures to represent triples. When the change event is triggered, JavaScript reads the event and reads the HTML data attributes to assemble the triples. For example:

{
    subject: "ex:jsmith",
    predicate: "vivo:hasResearchArea",
    object: "http://id.worldcat.org/fast/932231"
}

This data is then posted as JSON to a local REST API that reads JSON data like above and the action (add or remove), converts the statements to the necessary RDF triples, and issues a SPARQL update query to change the data in the underlying store. This data transformation is invisible to users because it happens in the background after selecting a tag. The editing is also inline and not part of a form so users don't have to click a save button or confirm updates. Again, we are focusing on ease of use and trying to mask as much of the complexity of the underlying data as possible from the end user.

Demo

I have created a JSFiddle with a complete example of this editing process. In the example, the URIs for objects are skos:Concepts representing research topics and are pulled in real time from a web service from the assignFAST webservice provided by OCLC.

I have also posted a sample Django application, based on our production system, that demonstrates this editing workflow and others. It also has code for processing the posted JSON and updating the triple store via SPARQL.

If you are doing similar work or interested in learning more about our application, please leave a comment here or email lawlesst AT gmail.com.