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)
- triple_filter(+Request, -Filter) is det[private]
- Extract Triple-Filter from Request. Ignores the filter if it is invalid.
- Translate an RDF triple pattern into a list of
- lod_request(+URI, +AcceptList, +Request, +Filter, +Options)[private]
- Handle an LOD request.
- lod_uri(+Request, -URI, +Options)[private]
- URI is the originally requested URI. This predicate deals with
redirections if the HTTP handler was registered using the option
redirected_from(URL). Otherwise it resolves the correct global URI using http_current_host/4.
- handler_location(+Request, -Location) is det[private]
- Location is the requested location on the server. This includes the handler location, normally concatenated with the path_info.
- redirect(+URI, +AcceptList, -RedirectURL)[private]
- Succeeds if URI is in the store and a RedirectURL is found for it.
- preferred_format(+AcceptList, -Format) is det[private]
- Format is the highest ranked mimetype found in the Acceptlist of the request and that we can support. Expects an AcceptList sorted by rank.
- format_request(+URL, -URI, -Format) is semidet[private]
- True if URL contains a suffix that corresponds to a supported output format, and the global URI occurs in the database.
- lod_describe(+Format, +URI, +Request, +Filter, +Options) is det[private]
- Write an HTTP document describing URI to in Format to the current output. Format is defined by mimetype_format/2.
- triple_in(+RDF, ?S, ?P, ?O, ?G) is nondet[private]
- Lookup a triple in the graph RDF, represented as a list of
- lod_description(+URI, -RDF, +Filter, +Options) is det[private]
- RDF is a graph represented as a list of
rdf(S,P,O)that describes URI.
- mimetype_format(?MimeType, ?Format) is nondet[private]
- Conversion between mimetypes and formats.
- format_suffix(?Format, ?Suffix) is nondet[private]
- Suffix is the file name extension used for Format.
- lod_resource(+Resource) is semidet[private]
- True if Resource is an existing resource for the LOD server. Typically, this means it appears as a subject, but when considering symmetric bounded descriptions, it should certainly also hold for resources that only appear as object.
- 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.