Architecturally LinkedDataHub is a read-write RDF Graph Store combined with a rich Linked Data/SPARQL client. LinkedDataHub does not persist RDF data itself but rather serves it from, and stores it in, a backing triplestore, which by default is the Apache Jena Fuseki.
-Every document in LinkedDataHub's dataspace is also a named graph in the Graph Store and has both RDF and HTML representations. The client is implemented using XSLT 3.0, a standard, declarative data transformation language. It can connect to any Linked Data resource or SPARQL 1.1 endpoint.
+Every document in LinkedDataHub's dataspace is also a named graph in the Graph Store and has both RDF and HTML representations. The client is implemented using XSLT 3.0, a standard, declarative data transformation language. The same stylesheets run in two environments: on the server (Saxon-HE) to produce the initial HTML response, and in the browser (Saxon-JS 3 with Interactive XSLT) to render the layout and drive all subsequent navigation without full page reloads. It can connect to any Linked Data resource or SPARQL 1.1 endpoint.
Since version 3.x LinkedDataHub does not use the Linked Data Templates anymore. However they can still be used to publish Linked Data from SPARQL endpoints using Processor.
You can find the changelog here.
diff --git a/docs/get-started/get-an-account.ttl b/docs/get-started/get-an-account.ttl index 478e1f8..bd5cf59 100644 --- a/docs/get-started/get-an-account.ttl +++ b/docs/get-started/get-an-account.ttl @@ -19,6 +19,7 @@Click the Login with Google button in the navbar to authenticate with your Google account.
If the email address of your Google account matches the dataspace owner's email address that was specified during setup, you will be authenticated as the owner with full control access rights.
Login with Google is only enabled if LinkedDataHub was configured with social login.
+Login with Google is only enabled if LinkedDataHub was configured with social login.
+Click the Login with ORCID button in the navbar to authenticate with your ORCID account using OpenID Connect.
+If the email address of your ORCID account matches the dataspace owner's email address that was specified during setup, you will be authenticated as the owner with full control access rights.
+Login with ORCID is only enabled if LinkedDataHub was configured with social login.
a:authUser, a:authPwd) and Bearer token authentication (a:authToken)The LinkedDataHub URI address space is split into dataspaces. Every dataspace consists of a pair of LinkedDataHub applications: end-user and administration.
-The end-user app will be available on the given base URI; the admin app will be available
- at that base URI with admin/ appended. The agent that installed the admin dataset will be the application owner.
The end-user app will be available on the given base URI; the admin app will be available on the corresponding
+ admin. subdomain (e.g. the admin app of https://example.com/ is served at https://admin.example.com/). 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.
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
- to it. Note that any URIs in the end-user application that are equal or relative to the admin application base URI will not
- be accessible.
The base URI of an administration application is the base URI of its end-user application with the admin. subdomain
+ prefixed to the host (e.g. https://example.com/ → https://admin.example.com/). Because the admin application lives on
+ its own subdomain (origin), it no longer occupies a path within the end-user application.
Since LinkedDataHub 5.1.0 the administration application is served on the admin. subdomain rather than under an
+ admin/ path. The subdomain must resolve in DNS and be covered by the server's TLS certificate.
Administration application provides means to control the domain model and the access control of its end-user application. Only dataspace owners have access to its administration application.
diff --git a/docs/reference/http-api.ttl b/docs/reference/http-api.ttl index fbd1b85..47b1877 100644 --- a/docs/reference/http-api.ttl +++ b/docs/reference/http-api.ttl @@ -238,6 +238,9 @@ Content-Type: text/turtle All HTTP methods are supported.If the URL dereferences successfully as RDF, LinkedDataHub forwards its response body (re-serializing it to enable content negotiation). During a write request, the request body is forwarded to the provided URL.
+If the URL returns an HTML document, LinkedDataHub extracts every embedded JSON-LD script
+ (<script type="application/ld+json">) and parses it as RDF using JSON-LD 1.1, so pages annotated with schema.org markup
+ can be browsed as Linked Data. The schema.org JSON-LD context is bundled with LinkedDataHub and served locally, so no external network request is made to resolve it.
The proxy only accepts external (non-relative to the current application's base URI) URLs; local URLs have to be dereferenced directly.
One XSLT stylesheet can be specified per application. In order to reuse LinkedDataHub's built-in templates, it should import the system stylesheet layout.xsl and only override the necessary templates. That is however not a requirement, the stylesheet could also use its own independent transformation logic.
If there is no stylesheet specified for the application, the system stylesheet is used. It defines the overall layout and imports resource-level and container-specific stylesheets, as well as per-vocabulary stylesheets.
Note that LinkedDataHub itself imports stylesheets from Web-Client, which uses the same template modes but produces a much simpler layout.
-There is also a special client-side stylesheet which is not used to render a full layout, but only manipulate DOM elements in the browser in response to user or system events. It is processed using Saxon-JS which provides IXSL (client-side extensions for XSLT). It imports and reuses some of the same sub-stylesheets as the server-side system stylesheet does, but avoids loading per-vocabulary stylesheets in order to improve page load time. Templates of the client-side stylesheet can also be overridden.
+The same XSLT 3.0 stylesheets run in two environments. On the server they are executed by Saxon-HE to produce the initial HTML response. In the browser they are executed by Saxon-JS 3, which provides IXSL (Interactive XSLT extensions) for reading and manipulating the browser DOM.
+There is a dedicated client-side stylesheet client.xsl that drives the browser. After the server-rendered page loads, its main template renders the layout client-side — the left sidebar, navigation, document and tab panes, content blocks, forms and modal dialogs are injected into the DOM using IXSL (e.g. ixsl:append-content). It also handles all subsequent navigation, so following links and switching documents re-renders in place without a full page reload. It imports and reuses the same document-, resource- and property-level templates as the server-side system stylesheet, but avoids loading per-vocabulary stylesheets in order to improve page load time. Templates of the client-side stylesheet can also be overridden.
$ldt:basexs:anyURI$lapp:Applicationdocument-node()?$ac:endpointxs:anyURIresolve-uri('sparql', $ldt:base))resolve-uri('sparql', ldt:base()))$sd:endpointxs:anyURI*ldh:ContentMode if the document has content blocks, otherwise ac:ReadMode)$lapp:originxs:anyURIxs:string?#)lapp:origin()xs:anyURIhttps://localhost:4443/. Used to build absolute URIs for static resources and same-site requestsldt:base()xs:anyURI$ldt:base parameterldh:request-uri()xs:anyURIxs:anyURI$query-params as map(xs:string, xs:string*) and $fragment as xs:string?ldh:parse-href($href as xs:anyURI)map(xs:string, item()?)ldh:href() — parses a local href back into its target URI, query parameters and fragment. Shared by the client-side navigation handlersldh:query-params($mode as xs:anyURI*)map(xs:string, xs:string*)document() does not incur an HTTP request and is much faster. The URI-to-file mapping
is defined as Jena's location mapping and can be found in
location-mapping.n3 and prefix-mapping.n3.
- Client-side stylesheets use <ixsl:schedule-action> (deprecated) and <ixsl:promise> to load XML documents asynchronously.
Client-side stylesheets use <ixsl:schedule-action> (deprecated) and <ixsl:promise> to load XML documents asynchronously. The metadata required to render forms — constructors, SHACL shapes, and property and object descriptions — is loaded client-side through chains of <ixsl:promise>, so the browser fetches it on demand rather than the server fetching everything up front.
LinkedDataHub navigates within a single page. When you follow a link to an external document (for example a resource fetched through the + Linked Data proxy), it opens in its own tab so that several documents can be kept open side by side. + A sticky tab bar appears at the top of the page once the first external tab is opened.
+Each tab keeps its own content pane, and modal dialogs (such as creation and edit forms) are scoped to the active tab pane. Switching between tabs is cached, so + returning to a previously opened tab does not re-fetch it. Closing a tab removes its pane and falls back to the base document's tab.
+The creation bar serves different functions depending on the current mode:
diff --git a/docs/user-guide/build-apps.ttl b/docs/user-guide/build-apps.ttl index adf6549..a2a1012 100644 --- a/docs/user-guide/build-apps.ttl +++ b/docs/user-guide/build-apps.ttl @@ -44,19 +44,19 @@ COPY files/style.css /usr/local/tomcat/webapps/ROOT/static/com/example/myapp/csThe Java layer of LinkedDataHub is a Maven project with a webapp layout. The codebase uses JAX-RS, specifically Jersey 3, as the HTTP/REST framework and uses Apache Jena for RDF I/O.
-If you want to extend the Java codebase, for example to add a custom REST endpoint, create a new Maven project (Java 17, packaged as WAR named ROOT) with LinkedDataHub as a WAR overlay dependency:
+The Java layer of LinkedDataHub is a Maven project with a webapp layout. The codebase uses JAX-RS, specifically Jersey 3, as the HTTP/REST framework and uses Apache Jena 6 for RDF I/O.
+If you want to extend the Java codebase, for example to add a custom REST endpoint, create a new Maven project (Java 21, packaged as WAR named ROOT) with LinkedDataHub as a WAR overlay dependency:
<dependencies>
<dependency>
<groupId>com.atomgraph</groupId>
<artifactId>linkeddatahub</artifactId>
- <version>5.3.2</version>
+ <version>5.5.3</version>
<classifier>classes</classifier>
</dependency>
<dependency>
<groupId>com.atomgraph</groupId>
<artifactId>linkeddatahub</artifactId>
- <version>5.3.2</version>
+ <version>5.5.3</version>
<type>war</type>
</dependency>
</dependencies>
@@ -66,7 +66,7 @@ COPY files/style.css /usr/local/tomcat/webapps/ROOT/static/com/example/myapp/cs
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
- <release>17</release>
+ <release>21</release>
</configuration>
</plugin>
<plugin>
@@ -99,10 +99,10 @@ COPY files/style.css /usr/local/tomcat/webapps/ROOT/static/com/example/myapp/cs
Server-side
The default server-side stylesheet layout.xsl and its imports can be found in the src/main/webapp/static/com/atomgraph/linkeddatahub/xsl/bootstrap/2.3.2 folder.
Client-side
- Client-side stylesheets are used to implement the interactive parts of the UI (event handling, AJAX calls etc.) using the IXSL extension
- provided by the SaxonJS library. This way the frontend is made completely declarative and does not require almost any Javascript code, with exceptions of 3rd party libraries such as Google Charts and OpenLayers.
+ Client-side stylesheets render the layout in the browser and implement the interactive parts of the UI (event handling, AJAX calls etc.) using the IXSL extension
+ provided by the Saxon-JS 3 library. After the server renders the initial page, the client-side stylesheet injects the left sidebar, navigation, document and tab panes, content blocks, forms and modal dialogs into the DOM, and re-renders in place as the user navigates. This way the frontend is made completely declarative and does not require almost any Javascript code, with exceptions of 3rd party libraries such as Google Charts and OpenLayers.
Client-side stylesheets share common document-, resource-, and property-level templates with the server-side stylesheets. The client-side stylesheet may not contain any XML entity declarations (limitation of
- SaxonJS) and must be compiled into a SEF file before it can be run by the SaxonJS runtime.
+ Saxon-JS) and must be compiled into a SEF file before it can be run by the Saxon-JS runtime.
By default, the URL of the client-side SEF stylesheet can be specified as the $client-stylesheet param of the document-level server-side xhtml:Script template.
The administration application of each dataspace is served on the admin. subdomain
+ of its end-user host (e.g. admin.ec2-54-235-229-141.compute-1.amazonaws.com). The subdomain must resolve in DNS and be covered by the
+ server's TLS certificate, otherwise the admin application will not be reachable.
Dataspace URIs need to relative to the system base URI in order to be reachable.
"""^^rdf:XMLLiteral . diff --git a/docs/user-guide/manage-dataspaces.ttl b/docs/user-guide/manage-dataspaces.ttl index b43cb95..2d8db45 100644 --- a/docs/user-guide/manage-dataspaces.ttl +++ b/docs/user-guide/manage-dataspaces.ttl @@ -33,8 +33,8 @@sd:Service instances to config/system.trig with the SPARQL endpoint connection detailsThe relationship between end-user and admin applications is automatically inferred based on naming conventions — you don't need to manually specify
- lapp:endUserApplication or lapp:adminApplication properties. Applications with base URIs containing admin/ are
- automatically recognized as administration applications.
lapp:endUserApplication or lapp:adminApplication properties. Applications whose origin (lapp:origin) uses the
+ admin. subdomain are automatically recognized as administration applications, and paired with the end-user application on the corresponding bare host.
Use URIs (for example in the urn: scheme) to identify apps and services, not blank nodes. Make sure both files' syntax is valid Turtle, otherwise the setup will not work. You can use Turtle Validator to check the syntax.