\n

Structure

\n

Default LinkedDataHub dataset structure follows these conventions:

\n

\n
1. the default graph is not used
\n
2. each document's description is stored in an RDF named graph whose name is the same as the document URI. The graph can be managed using the Graph Store Protocol.
\n
3. documents form a parent/child hierarchy. There are 2 types of documents: containers that can have other documents as children, and items that cannot.
\n

\n

The default dataset is installed into an application service during the setup.

\n

\n

Hierarchical URIs

\n

By default, the URIs of the document resources represent the same parent/child hierarchy. Which means the root container's URI equals the base URI\n of the application, and descendant document URIs are relative to their parent container URIs.

\n

Uploaded files are an exception to this rule. They are content-addressed in the uploads/{sha1sum} namespace, where sha1sum is the SHA1 hash of the file content.

\n

\n

Default datasets

\n

The default datasets of administration and end-user applications can be found in platform/datasets/admin.trig and\n platform/datasets/end-user.trig, respectively.

\n

RDF terms (classes, properties etc.) used in the default datasets come from well-known vocabularies FOAF and SIOC (with additional LinkedDataHub-specific assertions) as well as system ontologies.

\n

\n

Storage

\n

The dataset of each application is stored in an RDF triplestore which is accessed as a SPARQL service. End-user applications and admin applications have separate datasets and are backed by two different services.

\n