Table of Contents
In this chapter, we explain some basics about setting up your application development environment to work with Sesame. In Chapter 8, Basic Programming with Sesame we go into details of the use of the APIs. If you do not want to program against the Sesame libraries but just want to install and run the Sesame HTTP server, please skip ahead to Chapter 5, Server software installation.
As was explained in Chapter 2, Downloading Sesame, various download options are available to you. The quickest way to get started with using the Sesame libraries is to download the Sesame onejar library and include it in your classpath.
However, it is important to note that the Sesame Framework consists
of a set of libraries: Sesame is not a monolithic piece of software,
you can pick and choose which parts you want and which ones you
don't. In those cases where you don't care about picking and
choosing and just want to get on with it, the onejar is a good
choice. If, however, you want a little more control over what is
included, you can download the complete SDK and select (from the
lib directory) those sesame libraries that you
require.
An alternative to picking libraries by hand is to use Maven. Apache Maven is a software management tool that helps you by offering things like library version management and dependency management (which is very useful because it means that once you decide you need a particular Sesame library, Maven automatically downloads all the libraries that your library of choice requires in turn), and giving you a handy-dandy build environment. For details on how to start using Maven, we advise you to take a look at the Apache Maven website at http://maven.apache.org/. If you are familiar with Maven, here are a few pointers to help set up your maven project.
OpenRDF Sesame has its own Maven repository. To configure your project to use the correct repository, add the following to your project's pom.xml (or to your Maven configuration file: settings.xml):
<repositories> ... <repository> <id>aduna-opensource.releases</id> <name>Aduna Open Source - Maven releases</name> <url>http://repo.aduna-software.org/maven2/releases</url> </repository> </repositories>
The groupId for all Sesame core artifacts is
org.openrdf.sesame. To include a maven dependency
in your project that automatically gets you the entire Sesame core
framework, use artifactId sesame-runtime:
<dependency>
<groupId>org.openrdf.sesame</groupId>
<artifactId>sesame-runtime</artifactId>
<version>${sesame.version}</version>
</dependency>
For many projects you will not need the entire Sesame framework, however, and you can fine-tune your dependencies so that you don't include more than you need. Here are some typical scenarios and the dependencies that go with it. Of course, it's up to you to vary on these basic scenarios and figure exactly which components you need (and if you don't want to bother you can always just use the `everything and the kitchen sink' sesame-runtime dependency).
If you require functionality for quick in-memory storage and querying of RDF, you will need to include dependencies on the SAIL repository module (artifactId sesame-repository-sail) and the in-memory storage backend module (artifactId sesame-sail-memory):
<dependency>
<groupId>org.openrdf.sesame</groupId>
<artifactId>sesame-repository-sail</artifactId>
<version>${sesame.version}</version>
</dependency>
<dependency>
<groupId>org.openrdf.sesame</groupId>
<artifactId>sesame-sail-memory</artifactId>
<version>${sesame.version}</version>
</dependency>
A straightforward variation on this scenario is of course if you decide you need a more scalable persistent storage instead of (or alongside) simple in-memory storage. In this case, you can include the native store:
<dependency>
<groupId>org.openrdf.sesame</groupId>
<artifactId>sesame-sail-nativerdf</artifactId>
<version>${sesame.version}</version>
</dependency>The Sesame parser toolkit is called Rio, and it is split in several modules: one for its main API (sesame-rio-api), and one for each specific syntax format. If you require functionality to parse or write an RDF file, you will need to include a dependency on any of the parsers for that you will want to use. For example, if you expect to need an RDF/XML syntax parser and a Turtle syntax writer, include the following 2 dependencies (you do not need to include the API dependency explicitly since each parser implementation depends on it already):
<dependency>
<groupId>org.openrdf.sesame</groupId>
<artifactId>sesame-rio-rdfxml</artifactId>
<version>${sesame.version}</version>
</dependency>
<dependency>
<groupId>org.openrdf.sesame</groupId>
<artifactId>sesame-rio-turtle</artifactId>
<version>${sesame.version}</version>
</dependency>
If your project only needs functionality to query/manipulate a remotely running Sesame server, you can stick to just including the HTTPRepository module (sesame-repository-http):
<dependency>
<groupId>org.openrdf.sesame</groupId>
<artifactId>sesame-repository-http</artifactId>
<version>${sesame.version}</version>
</dependency>
Before you begin using any of the Sesame libraries, one important configuration step needs to be taken: the initialization and configuration of a logging framework.
Sesame uses the Simple Logging Facade for Java (SLF4J), which is a framework for abstracting from the actual logging implementation. SLF4J allows you, as a user of the Sesame framework, to plug in your own favorite logging implementation at deployment time. SLF4J supports the most popular logging implementations such as Java Logging, Apache Commons Logging, Logback, log4j, etc. See the SLF4J website for more info.
What you need to do is to determine/decide which
logging implementation you (are going to) use and
include the appropriate SLF4J logger adapter in your
classpath. For example, if you decide to use Apache
log4j, you need to include the
SFL4J-Log4J adapter in your classpath. The SLF4J
release packages includes adapters for various logging
implementations; just download the SLF4J release
package and include the appropriate adapter in your
classpath (or, when using Maven, set the appropriate
dependency); slf4j-log4j12-(version).jar,
for example.
One thing to keep in mind when configuring logging is that SLF4J expects only a single logger implementation on the classpath. Thus, you should choose only a single logger. In addition, if parts of your code depend on projects that use other logging frameworks directly, you can include a Legacy Bridge which makes sure calls to the legacy logger get redirected to SLF4J (and from there on, to your logger of choice. When you set this up correctly, you can have a single logger configuration for your entire project.