LinkedDataHub dataspaces and services

Dataspaces

The LinkedDataHub URI address space is split into dataspaces. A dataspace is identified by its origin — scheme, host and port — and\n every resource it serves is relative to that origin. A single LinkedDataHub instance serves as many dataspaces as are configured, each on its own origin.

Every dataspace has the following traits:

Base URI: The URI that identifies the dataspace. All request URIs it processes are relative to it.; URIs in the dataspace's dataset are usually (but not necessarily) relative to its base URI.
Service: SPARQL service the dataspace's dataset is stored in
Namespace ontology: Ontology that defines the terms (classes, properties, constraints etc.) of the dataspace's domain. It can import\n other ontologies from within the dataspace as well as from external documents.; Ontologies are managed in the administration dataspace.
Stylesheet: The XSLT stylesheet that renders the dataspace's layout

\n info\n

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

The agent that installed the dataspace's dataset is its owner. The secretary is a special agent\n which represents the software itself; it is distinct from the owner agent and is used to delegate the owner's access.

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

Each dataspace's data is structured as a hierarchy of containers and items — see the\n document hierarchy reference for details and the\n management actions that can be performed on documents.\n See also the administration reference.

End-user dataspaces

An end-user dataspace serves the domain data: the document hierarchy, its namespace ontology and whatever an agent is authorized to read or write. It is\n typed lds:EndUserDataspace and is what a visitor reaches at the dataspace's own origin.

Administration dataspaces

An administration dataspace provides the means to control the domain model and the\n access control of the end-user dataspace it administers. It is typed lds:AdminDataspace, and only owners\n have access to it.

The two are associated by origin rather than by declaration: an administration dataspace's origin is its end-user dataspace's origin with the\n admin. subdomain prefixed to the host (e.g. https://example.com/ → https://admin.example.com/), and LinkedDataHub\n derives the counterpart from the host in either direction. You do not configure the relationship.

\n info\n

Since LinkedDataHub 5.1.0 the administration dataspace is served on the admin. subdomain rather than under an\n admin/ path, so it no longer occupies a path within the end-user dataspace. The subdomain must resolve in DNS and be covered by the\n server's TLS certificate.

Configuring dataspaces

Dataspaces are configured using RDF files in TriG syntax — see the\n configuration reference for the files and their roles.

A second dataspace added to config/dataspaces.trig — one named graph per dataspace, identified with\n urn: URIs, the end-user and administration dataspaces associated by the admin. origin prefix. This is the template the\n create a dataspace guide refers to; the origins follow the\n <app>.demo.<host> shape the demo site uses, so the same declaration works locally on\n localhost:4443 and deployed on a public host:

<urn:linkeddatahub:apps/northwind-traders/end-user>\n{\n    <urn:linkeddatahub:apps/northwind-traders/end-user> a lds:Dataspace ;\n        dct:title \"Northwind Traders\" ;\n        lds:origin <https://northwind-traders.demo.localhost:4443> ;\n        lds:ontology <https://northwind-traders.demo.localhost:4443/ns#> ;\n        ac:stylesheet <https://northwind-traders.demo.localhost:4443/static/xsl/layout.xsl> ;\n        lds:public true .\n}\n\n<urn:linkeddatahub:apps/northwind-traders/admin>\n{\n    <urn:linkeddatahub:apps/northwind-traders/admin> a lds:Dataspace ;\n        dct:title \"Northwind Traders admin\" ;\n        lds:origin <https://admin.northwind-traders.demo.localhost:4443> ;\n        lds:ontology <https://w3id.org/atomgraph/linkeddatahub/admin#> ;\n        ac:stylesheet <https://admin.northwind-traders.demo.localhost:4443/static/xsl/admin/layout.xsl> .\n}

and its service bindings in config/system.trig:

<urn:linkeddatahub:apps/northwind-traders/end-user>\n{\n    <urn:linkeddatahub:apps/northwind-traders/end-user> a lds:EndUserDataspace ;\n        lds:service <urn:linkeddatahub:services/end-user> .\n}\n\n<urn:linkeddatahub:apps/northwind-traders/admin>\n{\n    <urn:linkeddatahub:apps/northwind-traders/admin> a lds:AdminDataspace ;\n        lds:service <urn:linkeddatahub:services/admin> .\n}

Source: config/dataspaces.trig, config/system.trig · Live: northwind-traders.demo.linkeddatahub.com

Services

A service is a persistent SPARQL 1.1-compatible store from which a dataspace's RDF dataset is accessible over HTTP. LinkedDataHub provides\n generic services as well as triplestore-specific ones, which allow simpler configuration and optimized access.

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

\n info\n

The end-user and administration services need no federation between them: the platform queries each service on its own, and the\n stores' outbound SERVICE requests go through the egress proxy, which refuses internal destinations —\n so a query on one dataset cannot reach another.

Generic services

Generic service has the following properties:

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Service fields and whether each is required
Field	Value	Required
Endpoint	SPARQL 1.1 Protocol endpoint URI	Yes
Graph Store	SPARQL 1.1 Graph Store Protocol endpoint URI	Yes
Quad Store	Endpoint URI for dataset-level RDF CRUD operations. Without it, LinkedDataHub falls back to graph-scoped Graph Store Protocol.	No
Username	HTTP Basic username	No
Password	HTTP Basic password	No
Auth token	Bearer authentication token, as an alternative to HTTP Basic. Stored in the `credentials` secret file under `a:authToken`.	No

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

Each dataspace has its own end-user and admin service, pointing at its own datasets in the single fuseki server. A dataset is named after the dataspace origin with the deployment host dropped and the role appended, so the Northwind Traders end-user service reads northwind-traders.demo.end-user:

<urn:northwind-traders:services/end-user>\n{\n    <urn:northwind-traders:services/end-user> a sd:Service ;\n        dct:title \"Northwind Traders service\" ;\n        sd:supportedLanguage sd:SPARQL11Query, sd:SPARQL11Update ;\n        sd:endpoint <http://fuseki:3030/northwind-traders.demo.end-user/> ;\n        a:graphStore <http://fuseki:3030/northwind-traders.demo.end-user/> ;\n        a:quadStore <http://fuseki:3030/northwind-traders.demo.end-user/> .\n}

The root dataspace's services keep the plain end-user and admin dataset names. Several dataspaces may still share one service where isolation is not required.

Source: config/system.trig

\n info\n

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

If you are ready to create a dataspace, see the dataspace management user guide.