Emerging dedicated Semantic Web query languages change this view. Supporting such languages provides a comfortable infrastructure for distributed Semantic Web processing systems. This document describes the SWI-Prolog Semantic Web Server. The server provides access to the Prolog triple store using either SeRQL or SPARQL. At the same time it is an extensible platform for realising Semantic Web based applications.
The SWI-Prolog Semantic Web Server unifies the SWI-Prolog general Web support and Semantic Web support, providing both a starting point for dedicated applications and a platform for exchange of RDF-based data using a standardised language and protocol. An overview of the SWI-Prolog Web support libraries can be found in SWI-Prolog and the Web,1Submitted to Theory and Practice of Logic Programming
The current server supports two query languages: SeRQL and SPARQL. For both languages we provide an interactive service that presents the results as a human-readable HTML table, a service presenting its result as RDF/XML or XML that follows the HTTP protocol definition for the query language, the possibility to query the local database using a query language in Prolog and a Prolog client that can be used to query remote services supporting the query language and HTTP service.
For both query languages, queries are translated to a complex Prolog
goal calling rdf/3
to resolve edges in the graph and calls to predicates from
rdfql_runtime.pl that realise constraints imposed by the SeRQL
WHERE clause and SPARQL FILTER clauses.
SPARQL support is based on the SPARQL specification, versioned April 6, 2006. Status:
SeRQL support and compatibility is based on development version 20040820, with additional support for the new 1.2 syntax and some of the built-in functions. Both SeRQL and the HTTP API are fully defined in the Sesame documentation.
The file parms.pl contains a number of settings relevant
to the server. Notable the port to connect to, where to store user
information, etc. Persistent data kept by the server is a list of users
and their access rights (default users.db) and a file-based
backup of the in-memory store (default in the directory SeRQL-store).
Please check the content of parms.pl and follow directions
in the comments. On Unix-like systems, edit run.pl to
adjust the location of SWI-Prolog on the !# line. Next,
start run.pl and launch the server using the command below.
?- serql_server.
Now direct your browser to the server, using the default setup this is http://localhost:3020. If no users are defined the browser will prompt to enter the administrative password. After that the admin and anonymous users are created. Accounts can be created and modified by users with administrative rights through the List users ... link on the sidebar.
To restart from scratch, stop the server, delete the users database file and/or the triple backup file and restart the server as described above.
The parms.pl setting persistent_store(Directory,
Options) can be used to specify file-based persistent backup for
the in-memory triple store. The store is a combination of quick-load
triple databases and journal files that hold the modifications made to
the triple store. Details of the persistent store are documented with
the SWI-Prolog
Semantic
Web package
The kernel of the system is formed by serql.pl and sparql,
that implement the DCG parsers for the respective query languages as
well as a compiler that translates this into a Prolog goal executing the
query op top of the SWI-Prolog SemWeb package. The file
rdfql_runtime.pl contains predicates that implement the
constraints (SeRQL WHERE or SPARQL FILTER) and other constructs
generated by the query-compiler.
Entailment reasoning is defined by rdf_entailment.pl.
Specific entailments are in seperate files:
no_entailment.plnone. Query explicitely stored triples
only.rdf_entailment.plrdf. Any resource appearing in a
predicate position is of type rdf:Property. Any subject is
an instance of rdf:Resourcerdfs_entailment.plrdfs. Adds class- and property-hierarchy
reasoning to RDF reasoning, as well as reasoning on the basis of
property domain and range.rdfslite_entailment.plrdfslite. Only considers the class- and
property-hierarchy. Using a backward chaining solver this is much
faster, while normally keeping the intended meaning.
The query compiler and execution system can be called directly from Prolog.
rdfs. See section
4.1.construct and
select(VarNames), where VarNames is a list of
variables appearing in the projection.optimise_query.
describe and ask. Addional options are:
ORDER BY
clause.DISTINCT
modifier.
row(Arg ...) for select queries and terms rdf(Subject,
Predicate, Object) for construct queries. Subsequent results are
returned on backtracking.describe return rdf-terms like construct.
Queries of type ask return either true or false.By default, but under control of the setting/1
option
optimise_query(Bool), and the option optimise(Bool),
the query compiler optimises initial goal obtained from naive
translation of the query text. The optimiser is defined in rdf_optimise.pl.
The optimiser is described in detail in An
optimised Semantic Web query language implementation in Prolog. The
optimiser reorders goals in the generated conjunction and prepares for
independent execution of independent parts of the generated goal. With
the optimiser enabled (default), the provided order of path-expressions
on the query text is completely ignored and constraints are inserted at
the earliest possible point.
The SeRQL LIKE operator applies to both resources and
literals, while the SWI-Prolog RDF-DB module can only handle LIKE
efficiently on literals. The optimiser can be made aware of this using
WHERE label(X) LIKE "joe*". Taking the label informs the
optimiser that it only needs to consider literals. Likewise, equivalence
tests where one of the arguments is used as subject or predicate or has
the isResource(X) constraint tell the system it can do straight
identifier comparison rather then the much more expensive general
comparison.
Query optimisation is not yet supported for SPARQL.
The webserver is realised by server.pl, merely loading
both components: http_data.pl providing the Sesame HTTP API
using the same paths and parameters and http_user.pl
providing a browser-friendly frontend. Error messages are still very
crude and almost all errors return a 500 server error page with a
transcription of the Prolog exception.
The Sesame HTTP API deals with a large number of data formats, only
part of which are realised by the current system. This realisation is
achieved through rdf_result, providing an extensible API
for reading and writing in different formats. rdf_html,
rdf_write and xml_result provide some
implementations thereof.
The file sesame_client.pl, created by Maarten
Menken provides an API to remote Sesame servers. Below is a brief
documentation of the available primitives. All predicates take an option
list. To simplify applications that communicate with a single server
defauls for the server and reposititory locations can be specified using
set_sesame_default/1.
Option(Value).
If a list of such options is provided all options are set in the order
of appearance in the list. This implies options later in the list may
overrule already set options. Defined options are:
''). For thte Java
based Sesame this is normally '/sesame'.
Below is a typical call to connect to a sesame server:
...,
set_sesame_default([ host(localhost),
port(8080),
path('/sesame'),
repository('mem-rdfs-db')
]).
Name(Value) terms providing title and access details.
Options specifies the host, port and path of the server.
...,
sesame_graph_query('construct * from {s} <rdf:type> {o}',
rdf(S,P,O),
[]),
row(Col1, Col2, ... ColN). Options specifies the
host, port and path of the server as well as the target repository.off,
returning both explicit and inferred triples.
rdfxml.
foo:bar.
off.
rdf(Subject, Predicate, Object) or a list
of such terms. In addition to the server and repository options the
following options are defined:
foo:bar.
The SWI-Prolog SeRQL engine provides a (still incomplete) drop-in
replacement for the Sesame HTTP access protocol. Sesame's remote server
class can be used to access the SWI-Prolog SeRQL engine through the
Sesame Java API. Likewise the Prolog client realised by
sesame_client.pl provides a Prolog API that can be used to
access both Sesame and the SWI-Prolog SeRQL engine.
The file sparql_client.pl provides a client to the
SPARQL HTTP protocol. The protocol defines how a SPARQL query is asked
over HTTP and how the results are presented. It is possible to use the
SeRQL protocol on the same server to perform tasks such as modifying the
triple store.
The structure of the SPARQL client API is closely based on the SeRQL client.
?- sparql_set_server([ host(localhost),
port(3020),
path('/sparql/')
]).
HTTP Communication with the server, including usernames and passwords, is in cleartext and therefore sensitive to sniffing. The overall security of the server is unknown. It is advised to run the server as user with minimal access rights, only providing write access to the user database file.
The SWI-Prolog SeRQL engine is available from CVS using the following commands:
% cvs -d :pserver:pl@gollem.science.uva.nl:/usr/local/cvspl login Password: prolog % cvs -d :pserver:pl@gollem.science.uva.nl:/usr/local/cvspl co SeRQL
Infrequently announces and snapshots are provided through the Prolog Wiki
The SeRQL server has been realised as part of the HOPS project and could not have been done without Sesame and feedback from Jeen Broekstra and Maarten Menken from the Free University of Amsterdam (VU). Adding SPARQL support has been realised as part of the E-culture sub-project of Dutch MultiMedia project.