System base URI

The system base URI is the URI at which the LinkedDataHub service is accessible.

A common case is changing the system base URI from the default https://localhost:4443/ to your own.\n Take https://ec2-54-235-229-141.compute-1.amazonaws.com/ as an example. Split the URI into components and set them in the .env file:

PROTOCOL=https\nHTTP_PORT=80\nHTTPS_PORT=443\nHOST=ec2-54-235-229-141.compute-1.amazonaws.com

A dataspace serves its documents from the root of its origin, so the base URI is always the origin followed by / — there is no\n sub-path component to configure. Serving several dataspaces from one instance is a matter of giving each its own subdomain, as described under\n Dataspaces.

Dataspace URIs need to be relative to the system base URI in order to be reachable — after the change, the\n origins in config/dataspaces.trig have to follow. For the Northwind Traders dataspace, deploying from local development to the demo\n host means:

# before\n<urn:linkeddatahub:apps/northwind-traders/end-user> a lds:Dataspace ;\n    lds:origin <https://northwind-traders.demo.localhost:4443> ;\n    lds:ontology <https://northwind-traders.demo.localhost:4443/ns#> .\n\n# after\n<urn:linkeddatahub:apps/northwind-traders/end-user> a lds:Dataspace ;\n    lds:origin <https://northwind-traders.demo.linkeddatahub.com> ;\n    lds:ontology <https://northwind-traders.demo.linkeddatahub.com/ns#> .

Restart the services (make down, then make up) for the changes to take effect. Note that changing the base URI does not\n rewrite URIs already stored in the dataset — documents minted under the old base URI keep it.

Configuration files

LinkedDataHub uses two main RDF configuration files that define dataspaces and services:

\n

config/dataspaces.trig

\n

Contains public metadata for each dataspace, including:

\n

\n

\n
• Base URIs and origins
\n
• Dataspace titles and descriptions
\n
• Associated ontologies
\n
• Custom stylesheets
\n

\n

\n

This file contains public-facing metadata and can be safely shared.

\n

config/system.trig

\n

Contains internal deployment wiring, including:

\n

\n

\n
• Dataspace-to-service bindings (admin and end-user roles)
\n
• SPARQL endpoint URLs
\n
• Graph Store Protocol endpoints
\n

\n

\n

This file contains internal configuration and is not intended for public sharing, but does not contain credentials.

\n

secrets/credentials.trig

\n

Optional file containing service authentication credentials, including:

\n

\n

\n
• Bearer tokens (a:authToken)
\n
• HTTP Basic auth credentials (a:authUser, a:authPwd)
\n

\n

\n

This file is gitignored and must not be committed to version control. See the credentials secret entry below for configuration details.

\n

All files are in TriG format and are mounted into the LinkedDataHub container at startup. The separation allows you to version control\n dataspace metadata and service wiring while keeping credentials out of version control entirely. The\n dataspace reference shows the Northwind Traders dataspace as a worked example across both\n config/ files.

Compose overrides

Environment-specific configuration goes into docker-compose.override.yml, which Docker Compose merges over\n docker-compose.yml automatically. Mounting a stylesheet under development, for example:

services:\n  linkeddatahub:\n    volumes:\n      - ./files/northwind.xsl:/usr/local/tomcat/webapps/ROOT/static/com/atomgraph/linkeddatahub/northwind/xsl/layout.xsl:ro

Compose-level variables

The variables in the .env file are interpolated by Docker Compose into docker-compose.yml. They define the\n system base URI and the host port mappings:

\n

PROTOCOL

\n

URI scheme of the system base URI (http or https)

\n

HOST

\n

Hostname of the system base URI

\n

HTTP_PORT

\n

Host port mapped to the container's port 8080, which redirects HTTP to HTTPS

\n

HTTPS_PORT

\n

Host HTTPS port, mapped to the container's port 8443

\n

Service configuration

SPARQL service endpoints are configured in config/system.trig. See service configuration in the triplestores reference for the RDF properties and examples, and the dataspace reference for the conceptual overview.

linkeddatahub service

Varnish services

The backend ports of the varnish-frontend, varnish-admin and varnish-end-user caching services can be\n customized when running LinkedDataHub behind additional proxies or in non-standard Docker networking configurations:

\n

VARNISH_FRONTEND_BACKEND_PORT

\n

Port for frontend Varnish backend. Defaults to 7070.

\n

VARNISH_ADMIN_BACKEND_PORT

\n

Port for admin Varnish backend. Defaults to 3030.

\n

VARNISH_END_USER_BACKEND_PORT

\n

Port for end-user Varnish backend. Defaults to 3030.

\n

fuseki service

A single Apache Jena Fuseki server holds a TDB2 dataset for every dataspace role — an end-user and an admin dataset per dataspace — declared in config/fuseki/config.ttl and persisted under the fuseki/ folder, one sub-folder per dataset. JAVA_OPTIONS carries the Java options of the Fuseki process, and is what sizes its heap.

Datasets are named after the dataspace origin with the deployment host dropped and the role appended — northwind-traders.demo.end-user, northwind-traders.demo.admin — so the names hold across development and production; the root dataspace's are plain end-user and admin. See the dataspace reference for the service declarations that bind a dataspace to its datasets.

egress service

A forward proxy (Squid) that the outbound SPARQL SERVICE and LOAD requests of both Fuseki and the platform pass through. It permits public destinations and refuses loopback, private and link-local ones, resolving each where it connects so redirect hops and DNS answers are checked too. Federation with public endpoints keeps working, while a SERVICE clause cannot reach another dataset, the cache or the platform.

Fuseki is pointed at it through its JAVA_TOOL_OPTIONS; the platform's own in-process queries (imports and PATCH updates) are routed through it when EGRESS_PROXY is set to its host:port. Without a proxy and without ALLOW_INTERNAL_URLS, the platform disables SERVICE in those queries rather than leaving it open.

sef-compiler service

Compiles each dataspace's client-side stylesheet together with the stylesheets of its imported packages into a SEF that the browser runs, so a package's rendering reaches the client as well as the server. The platform composes the wrapper and submits it; the compiled SEF is written to the sef bind mount (/var/www/linkeddatahub/sef, served under /static/xsl/sef/) and its URL travels to the page as a Link header. The service is built from the same Dockerfile as the platform, so its copy of the stylesheets is the deployed one.

SEF_ROOT and SEF_COMPILER reach the platform through CATALINA_OPTS and are optional: without them packages compose server-side only, and the client runs the stock stylesheet. A deployment with its own compose file adds the service, the platform's depends_on on it and the bind mount.

CLIENT_STYLESHEET names the client stylesheet the SEF is composed from and defaults to the platform's client.xsl. A deployment whose page bootstraps its own client stylesheet sets it to that stylesheet's webapp path - it must import the platform's client.xsl directly, by an href that resolves from that path - and its layout prefers ldh:client-stylesheet() over its own SEF; otherwise the site's rules vanish from a package dataspace on the first client-side navigation, while a reload brings them back.

nginx service

\n

SERVER_CERT_FILE

\n

Location of the server's SSL certificate. Defaults to /etc/nginx/ssl/server.crt.

\n

SERVER_KEY_FILE

\n

Location of the server's SSL certificate's key. Defaults to /etc/nginx/ssl/server.key.

\n

SSL_VERIFY_CLIENT

\n

optional_no_ca to enable TLS client certificate authentication on the $HTTPS_PORT port; off to disable it, which also disables LinkedDataHub's WebID-TLS authentication method.

\n

Disabling can be used to avoid the certificate prompt in the browser in end-user facing dataspaces. The client certificate authentication is still available on port 5443.

\n

MAX_BODY_SIZE

\n

Maximum allowed request body size (linkeddatahub has a separate setting for this). Defaults to 2097152.

\n

By default nginx is configured to guard against DoS by limiting the rate of requests per second, which can be necessary on a public instance. The limiting can be disabled in platform/nginx.conf.template\n by commenting out all lines starting with limit_req using #.

services:\n  nginx:\n    environment:\n      - SERVER_CERT_FILE=/etc/letsencrypt/live/kgdev.net/fullchain.pem\n      - SERVER_KEY_FILE=/etc/letsencrypt/live/kgdev.net/privkey.pem\n    volumes:\n      - /etc/letsencrypt:/etc/letsencrypt