LinkedDataHub dataspaces, applications, and services

Dataspaces

The LinkedDataHub URI address space is split into dataspaces. Every dataspace consists of a pair of LinkedDataHub applications:\n end-user and administration.

The end-user app will be available on the given base URI; the admin app will be available\n at that base URI with admin/ appended. The agent that installed the admin dataset will be the application owner.

The secretary is a special agent which represents the software application itself. It is distinct from the owner agent and is used to delegate the owner's access.

Configuring dataspaces

Dataspaces are configured using RDF files in TriG syntax:

config/dataspaces.trig: Application metadata: base URIs, titles, descriptions, ontologies, and stylesheets
config/system.trig: Internal service wiring: app-to-service bindings and SPARQL endpoint connection details
secrets/credentials.trig: Service authentication credentials (optional, gitignored). See the authentication reference for details.

See the configuration reference for more details about these files.

Application relationships (end-user ↔ admin) are automatically inferred based on naming conventions — applications with base URIs containing\n admin. prefix are recognized as administration applications, and their corresponding end-user applications are automatically determined.\n You do not need to manually specify these relationships.

Applications

All LinkedDataHub applications have the following traits:

Base URI: Base URI is a URI by which an application can be identified. All request URIs processed by an application are relative to one of its base URIs.; URIs in the application dataset are usually (but not necessarily) relative to its base URIs.
Service: SPARQL service
Namespace ontology: Ontology that defines the terms (classes, properties, constraints etc.) of the application's domain. It can import\n other ontologies from within the application as well as from external documents.; Ontologies as managed in the administration application.

Base URI must end with a forward slash (/).

In addition to that, LinkedDataHub applications have one additional property:

Stylesheet: XSLT stylesheet that renders the applications layout

End-user

The base URI of an end-user application is also the base URI of its dataspace.

Every end-user application is related to one administration application.

Administration

Every administration application is related to one end-user application. It cannot exist standalone.

The base URI(s) of an administration application is the base URI(s) of its end-user application with admin/ appended\n to it. Note that any URIs in the end-user application that are equal or relative to the admin application base URI will not\n be accessible.

Administration application provides means to control the domain model and the\n access control of its end-user application. Only dataspace owners have access to its\n administration application.

The agent which installs the adminstration application dataset becomes the owner of\n its dataspace.

LinkedDataHub imports the default datasets for each application type\n into its service. The dataset URIs are rebased to be relative to the base URI of the application.

Services

A service is a persistent SPARQL 1.1-compatible store from which the application's RDF dataset is accessible over HTTP. LinkedDataHub supports\n generic services as well as triplestore-specific services which support easier configuration and optimized access.

Services support two authentication schemes: HTTP Basic authentication and Bearer token authentication.

LinkedDataHub works with various SPARQL backends, using Apache Jena Fuseki by default. See the triplestores reference for compatibility requirements and configuration examples.

The end-user application service must be able to federate with the administration application service using the\n SPARQL SERVICE keyword.

Generic services

Generic service has the following properties:

Endpoint: SPARQL 1.1 Protocol endpoint URI (required)
Graph Store: SPARQL 1.1 Graph Store Protocol endpoint URI (required)
Quad Store: Endpoint URI for dataset-level RDF CRUD operations (optional); If not provided, LinkedDataHub will use graph-scoped Graph Store Protocol as a fallback
Username: HTTP Basic username (optional)
Password: HTTP Basic password (optional)
Auth token: Bearer authentication token (optional, alternative to HTTP Basic); Auth tokens are stored in the credentials secret file using the a:authToken property

You can use either HTTP Basic authentication (username/password) or Bearer token authentication (auth token), but not both for the same service.

Custom services

LinkedDataHub has extension points for vendor-specific SPARQL services, which can be used to implement proprietary authentication schemes, for example.

Document hierarchy

The basic structure of resources in an application is analogous to the file system, but built using RDF\n resources and relationships between them instead. There is a hierarchy of containers,\n which are collections of items as well as sub-containers. Both containers\n and items are documents. Items cannot contain other documents.

The first level of resources in a container is referred to as its children (of which that container\n is the parent), while all levels down the hierarchy are collectively referred to as\n descendants.

When a user logs in, the application loads its root container (unless a specific URI was requested). From there,\n users can navigate down the resource hierarchy, starting with children of the root container. At\n any moment there is only one current document per page, on which actions can\n be performed: it can be viewed, edited etc.

If you are ready to create a dataspace, see our step-by-step tutorial on dataspace management.