Main workflow and Architecture

Main workflow

Korbo aims at providing a coherent environment for users to aggregate semantically structured description of digital objects (in the form of RDF data), coming from different metadata providers, into personal baskets and to enable augmentation of such collected data relying on external, specific tools. A typical workflow in Korbo is made of four steps.

  1. Users choose from a set of data providers and perform a keyword based search to get a set of results. Alternatively
  2. Users select one or more items from the results and import them into their own “basket”. Upon import original data is opportunely transformed (or augmented with new RDF triples) to match Korbo data model (this operation is transparent to users)
  3. Users browse, annotate and augment items collected in their baskets with specific tools that Korbo makes at disposal
  4. The content of a basket, made of collected items metadata and semantic connections among them, is exposed as Linked Data and via a REST API to be accessed by third party applications (e.g. to create specialized visualization or to be further augmented)


This diagram shows the current architecture of Korbo and its basic components.
As different data providers have different search API, a set of drivers are needed to gather results and put them in a uniform format.
Currently, Korbo implements a simple search over standard SPARQL endpoint (used to collect results from the europeana LOD portal) and a driver to connect to Muruca DLs (which uses solr to index content). The result format of a search driver is a simple JSON.
The following is an example of the JSON returned:

    "entity": "", 
    "label": "Bildnis Ludwig Wittgenstein", 
    "score1": "2666"
    "entity": "", 
    "label": "Bildnis Ludwig Wittgenstein (1889 - 1951)", 
    "score1": "2666"
    "entity": "", 
    "label": "Mostrar problemas: Leitura de Philosophische Untersuchungen de Ludwig Wittgenstein", 
    "score1": "1920"

Import dirvers

Import drivers implement the logic to transform data from different content providers into Korbo items and import them into the Korbo storage layer and takes as input an entity URL.
Such a logic partially depends on the provider from which data is imported, and specifically by the particular data model.
The Standard Linked Data import driver simply fetches RDF dereferencing the entity URL.
In other cases, as in the case of Europeana LOD portal, which uses EDM (Europeana Data Model) multiple HTTP calls are need to fetch all the relevant data that is “distributed” among several related entities.

Import drivers also perform basic RDF data transformations. For example some RDF properties are added to provide back-links (inverse properties) to improve browsability.
Furthermore, the import of an item results in the instantiation of a new RDF resource representing the external resource in Korbo.
Such a resource (Korbo Proxy) has a two-fold purpose. First, it allows Korbo to provide a Linked Data representation of the resource which is independent from the one provided by the origin data provider. Second, it provides a resource (URL) to which augmentations can be attached without interfering with the original resource maintained by the data provider.
As in the case of search drivers, Korbo can be extended with additional import drivers.

Storage Layer

The Korbo storage layer is composed by a triplestore, where RDF representations of items and collections of items (baskets) are persisted, and by a relation database that handles users permissions, associations among users, baskets and items, and provides a fast access to basic item metadata (such as id, title and description).
Korbo currently implements only one augmentation tool connector, providing light weight integration with the Pundit semantic annotation tool. Detailed documentation of such an interaction will be added soon.

API and SPARQL-endpoint

Each basket in Korbo can be queried via a dedicated SPARQL endpoint.
Both items and baskets are exposed via Linked Data interface, powered by the ELDA open source implementation of the Linked Data API.
Additionally, a set of REST APIs are provided to access baskets in read-mode.