Linked (Open) Data turns RDF URIs (indentifiers) into URLs (locators). Requesting the data behind the URL returns a description of the resource. So, if we see a resource http://example.com/employe/bill, we get do an HTTP GET request and expect to receive a description of bill. This module adds LOD facilities to ClioPatria.
Running the LOD server
There are several ways to run the LOD server.
- The simplest way to realise LOD is to run ClioPatria there where the authority component of the URL points to (see uri_components/2 for decomposing URIs). This implies you must be able to create a DNS binding for the host and be able to run ClioPatria there.
- Sometimes the above does not work, because the port is already
assigned to another machine, you are not allowed to run ClioPatria
on the target host, the target is behind a firewall, etc. In that
case, notable if the host runs Apache, you can exploit the Apache
mod_proxyand proxy the connections to a location where ClioPatria runs. If you ensure that the path on Apache is the same as the path on ClioPatria, the following Apache configuration rule solves the problem:
ProxyPass /rdf/ http://cliopatria-host:3020/rdf/
- Both above methods require no further configuration.
Unfortunately, they require a registered domain control over DNS
and administrative rights over certain machines. A solution that
doesn't require this is to use www.purl.org. This allows you to
redirect URLs within the purl domain to any location you control.
The redirection method can be defined with purl. In the semantic
web community, we typically use See other (303). The catch
is that if the address arrives at ClioPatria, we no longer know
where it came from. This is not a problem in (1), as there was
no redirect. It is also not a problem in (2), because Apache
adds a header
x-forwarded-host. Unfortunately, there is no way to tell you are activated through a redirect, let alone where the redirect came from.
:- http_handler('/myvoc/', lod_api([ redirected_from('http://www.purl.org/vocabularies/myvoc/') ]), [ prefix ]).
By default, there is no HTTP handler pointing to lod_api/2. The example above describes how to deal with redirected URIs. The cases (1) and (2) must also be implemented by registering a handler. This can be as blunt as registering a handler for the root of the server, but typically one would use one or more handlers that deal with sub-trees that act as Linked Data repositories. Handler declarations should use absolute addresses to guarantee a match with the RDF URIs, even if the server is relocated by means of the http:prefix setting. For example:
:- http_handler('/rdf/', lod_api(), [prefix]).
- lod_api(+Options, +Request)
- Reply to a Linked Data request. The handler is capable of three
output formats. It decides on the desired format based on the
Acceptheader-field. If no acceptable format is found, it replies with a human-readable description of the resource using ClioPatria RDF browser-page as defined by list_resource//2.
- This option must be provided when using a purl.org or similar redirect. See overall documentation of this library.
- Description style to use. See rdf_bounded_description/4.
The default is
cbd(Concise Bounded Description)
- cliopatria:redirect_uri(+Format, +URI, -RedirectURL)[multifile]
- Compose a RedirectionURL based on the output Format and the URI
that is in our RDF database. For example, this could map the URI
http://example.com/employe/bill into Bill's homepage at
http://example.com/~bill if Format is
html. The default is to a format-specific extension to the path component of URI, returning e.g., http://example.com/employe/bill.rdf if the requested format is RDF.
- cliopatria:lod_description(+URI, -RDF:list(rdf(s,p,o)))[multifile]
- RDF is list of triples describing URI. The default is to use the Concise Bounded Description as implemented by resource_CBD/3.