LinkedDataHub

Get started

All the basics of LinkedDataHub. From installation to customizing the model and user interface.

This guide will show how a LinkedDataHub application can be used to manage domain-specific RDF classes and instances. As an example, we will us SKOS concepts and concept schemes.

On LinkedDataHub, all management actions can also be performed using the CLI (Command Line Interface), which consists of shell scripts wrapping HTTP API calls. Where applicable, the UI and CLI instructions are shown side by side.

The CLI instructions use the environmental variable $SCRIPT_ROOT, which should point to the scripts in your LinkedDataHub fork. Then you can place the scripts and files from the examples in a folder outside LinkedDataHub — that will be the current directory for the CLI examples below. Alternatively, you can check out the source code of the SKOS demo app which implements the SKOS example used in this guide.

Setup

Using LinkedDataHub open-source, you need to launch the application in Docker setup. In the Cloud version, the platform manages that for you.

Get an account

Using LinkedDataHub open-source, you to obtain a WebID and use its client certificate for authentication. In the Cloud version, you can sign-in and authenticate using your social login.

Open your dataspace

Using LinkedDataHub open-source, the platform runs on https://localhost:4443/ by default. Open this address in the web browser (that you installed the WebID certificate to).

With LinkedDataHub Cloud, you can choose the URL of your dataspace.

Create a container

We will need to containers for our SKOS instances: one for the concepts and one for the concept schemes.

Use Concepts as title and concepts as URI slug for the former; Concept schemes as title and concept-schemes as URI slug for the latter.

Change the model

In order to be able to manage SKOS concepts and concept schemes, we need to create classes that represent them in the model of our dataspace. Not only will they serve as RDF types of the instances, but will have constructors attached that define the default properties and their (data)types for that class.

Since a SKOS concept is an abstract thing which cannot be directly dereferenced over HTTP, its instance has to be paired with a document instance. In the model, this relationship is defined by creating a property restriction between the two respective classes. We therefore need to create 2 classes and a restriction.

Model is managed in the administration application of a dataspace. Head there by clicking the Settings in the action bar and then choosing Administration.

In order to edit the access control, model, or sitemap of a dataspace, you need to be an administrator, i.e. a member of the owners group.

Create an instance

Go back to the end-user application and refresh the page — the previously created classes should now be available for instance creation. Follow these steps:

  1. Click the Create dropdown in the top-left corner
  2. Click on Concept in the drop-down list that appears
  3. Fill out the mandatory fields in the form:
    Title
    Enter concept title
    Title
    Enter document title
  4. Click Save

A concept and its item should appear with the URI https://localhost:4443/concepts/{slug}/, depending on the optional URI slug value (a unique UUID string is assigned by default).

Congratulations! You have just created the first concept instance based on your model.

Import CSV data

A common step at this point would be to populate your dataset with instances by importing data. LinkedDataHub currently supports CSV and RDF data imports.

Change the sitemap

By default, the concept documents will match an Document template from the application's Templates ontology. You can verify that by checking the HTTP response headers, which should include a template URI such as https://linkeddatahub.com/linkeddatahub/docs/ns/templates#Document. You can use it to look up the SPARQL query which is used to load the RDF data for the document.

Lets say we want to change the RDF description of the concept to return not only its own properties, but also include its narrower concepts. That data then can be used to render the narrower concepts on the same document, instead of just linking to them.

In order to achieve that, we need to override the LDT template that matches our concept items and specify our custom SPARQL query for the overriding template.

Change the layout

Changing the layout of the user interface is similar to changing the sitemap. It involves overriding templates as well, just not in the LDT ontologies but in the XSLT stylesheets.