\n

Linked Data proxy

\n

LinkedDataHub works as a Linked Data proxy (from the end-user perspective, as a Linked Data browser) when a URL is provided using the uri query parameter.\n All HTTP methods are supported.

\n

If the URL dereferences successfully as RDF, LinkedDataHub forwards its response body (re-serializing it to enable content negotiation).\n During a write request, the request body is forwarded to the provided URL.

\n

If the URL returns an HTML document, LinkedDataHub extracts every embedded JSON-LD script\n (<script type=\"application/ld+json\">) and parses it as RDF using JSON-LD 1.1. Pages annotated with schema.org markup\n can therefore 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. A supplier's homepage carrying this markup:

\n

<script type=\"application/ld+json\">\n{\n    \"@context\": \"https://schema.org/\",\n    \"@type\": \"Corporation\",\n    \"@id\": \"#this\",\n    \"legalName\": \"Exotic Liquids\",\n    \"telephone\": \"(171) 555-2222\"\n}\n</script>

\n

browses as these triples:

\n

<https://supplier.example/#this> a schema:Corporation ;\n    schema:legalName \"Exotic Liquids\" ;\n    schema:telephone \"(171) 555-2222\" .

\n

An HTML page with no JSON-LD has no RDF representation, so the proxy answers 406 Not Acceptable. The user interface then opens the\n page in a new browser tab, as an ordinary external link would.

\n

The proxy only accepts external (non-relative to the current dataspace's base URI) URLs; local URLs have to be dereferenced directly.

\n

The proxy forwards the origin's ETag and Last-Modified validators and passes conditional request headers\n (If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since) through. Preconditioned\n writes against proxied documents are therefore evaluated at the origin. Error statuses from the origin reach the client unchanged.

\n

\n

Federation

\n

The Linked Data proxy makes dataspaces interoperable across origins: one dataspace's client can browse, query, and write to another\n origin's dataspace, whether on the same LinkedDataHub instance or a different one.

\n

Browsing a UNESCO Thesaurus concept from the Northwind dataspace, for example, the proxy forwards the remote dataspace's hypermedia along\n with the RDF:

\n

GET /?uri=https%3A%2F%2Funesco-thesaurus.demo.linkeddatahub.com%2Fconcepts%2Fconcept3683%2F HTTP/1.1\nHost: northwind-traders.demo.linkeddatahub.com\nAccept: application/rdf+xml\n\nHTTP/1.1 200 OK\nContent-Type: application/rdf+xml\nLink: <https://unesco-thesaurus.demo.linkeddatahub.com/sparql>; rel=\"http://www.w3.org/ns/sparql-service-description#endpoint\"

\n

\n
• The remote dataspace's SPARQL endpoint is discovered from the Link headers the proxy forwards, so views and charts over\n remote documents query the remote endpoint
\n
• Writes are graph-scoped SPARQL updates (PATCH) or appends (POST) sent through the proxy under the origin's\n If-Match precondition
\n
• Requests carry the delegated identity of the requesting agent, so the remote dataspace's access control\n arbitrates every operation
\n

\n

In the user interface this means you can browse a remote dataspace and\n add data to its documents the same way as to local ones, provided the remote access control allows it.

\n

The example above uses the public demo hosts because they are reachable without any setup, but nothing about federation requires a second\n instance: two dataspaces on one LinkedDataHub are distinct origins, so the same exchange happens between\n northwind-traders.demo.localhost:4443 and unesco-thesaurus.demo.localhost:4443 once both are\n declared.

\n