Sesame 3.0 Preview: An Open Source Framework for RDF Data

fter downloading Sesame 3.0-alpha1, the first thing you might notice is that Sesame 3.0 is packaged slightly differently than in 2.x. The awkwardly named sesame-onejar.jar was replaced by sesame-client.jar and sesame-runtime.jar, the openrdf-workbench.war file is gone, and there is a new server script.

The sesame-client.jar contains the RDF parsers and writers distributed with Sesame along with the repository API, HTTP client, and manager. This is the only jar you need for most RDF programs that don't embed an RDF store. If your application embeds its own RDF store, you can use the sesame-runtime.jar instead. This jar contains the familiar MemoryStore, NativeStore, RdbmsStore, and more. As with 2.x, Sesame Server and Console are not present in either of these jars, but you can find them in the lib directory of the SKD, along with scripts to run them.

Model API

The new Model interface holds a collection of indexed statements and implements Set<Statement> with other convenient methods for quick access to the underlying information. You can use the class LinkedHashModel as an implementation and perform many of the basic operations of the MemoryStore, such as adding or removing statements, adding or removing namespace prefixes, and filtering statements by subject, predicate, object, or contexts. The Model, unlike the MemoryStore, does preserve the statement ordering, but unlike the MemoryStore it does not provide concurrent modification, transaction, or query support. The Model is a welcome addition for programs that simply need to read and write RDF files.

By simply including the sesame-client.jar, all RDF parsers, writers, and basic model types such as URI, Literal, Statement, and Model are available. To demonstrate working with RDF files, the code in Listing 1 shows how to read in an RDF file, validate it, and then write it back out in an organized format.

Repository API

The Repository API provides access to local and remote RDF stores. It was updated to clarify some confusing method names and provide a smoother, more integrated interface. For example, you could write the following Sesame 2.x code in one line using the 3.0 API.

// Sesame 2.x Repository API
RepositoryResult<Statement> result = con.getStatements(subj, pred, null, true);
try {
  if (result.hasNext())
    return result.next().getObject().stringValue();
  return null;
} finally {
  result.close();
}
// Sesame 3.0 Repository API
return con.match(subj, pred, null, true).asModel().objectString();

Every repository now includes RepositoryMetaData to allow an application to inquire about the features and behavior of the underlying RDF store. This provides the supported formats, query languages, functions, inferencing rules, and version used by the (possibly remote) repository.

The new 3.0 Repository API is not backwards compatible with the 2.x API. While many 2.x methods still exist (getStatements are deprecated in 3.0), some incompatibilities require client-side changes. The most prominent change in the Repository API is the Result types of both the RepositoryConnection and Query. Instead of the generic Result type of 2.x, 3.0 uses specific ContextResult and ModelResult. The TupleQuery now returns TupleResult from evaluate() and the GraphQuery now returns GraphResult. These are the most significant API changes in 3.0.

Blank nodes (Bnodes) are no longer globally referencable (as they were in Sesame 2.x); you can now only reference them within the same connection. Applications that used a BNode as a global reference must change to use a URI instead, as Sesame RDF stores might use different BNode IDs in different connections to reference the same internal resource. However, BNodes created outside of the connection automatically maps to a new BNode within that connection.

Author's Note: A BNode Java object is only valid within the connection it was created or received from.

This works similar to how RDF files are added to the RDF store: external BNodes are mapped to internal BNodes, within a particular scope. The following code demonstrates how you can use BNodes with Sesame 3.0.

BNode node = conA.getValueFactory().createBNode();
conA.add(node, RDF.TYPE, RDF.LIST);

conA.hasMatch(node, RDF.TYPE, RDF.LIST);

// [] no results because node was not created with conB
conB.hasMatch(node, RDF.TYPE, RDF.LIST); // maybe false
// contains the new statement, but with a different nodeID
conB.size(null, RDF.TYPE, RDF.LIST) >= 1;

Transactions

Sesame 3.0 introduces isolation levels to the API. In 2.x each store used its own fixed isolation level (MemoryStore, NativeStore, and RdbmsStore in 2.x used an isolation level similar to read committed). In Sesame 3.0, each connection can choose its own isolation level. These are similar to the ANSI SQL isolation levels, however, Sesame has created its own RDF-specific definitions and provides a few more isolation levels that are relevant to distributed and optimistic stores.

Unlike the ANSI SQL isolation levels, Sesame distinguishes between snapshot and serializable isolation levels. Furthermore, Sesame's definition of snapshot isolation allows independent RDF stores to use eventual consistency to manage the changes to the store. This makes clusters of RDF stores easier to implement for connections that allow eventual consistency, but still require a consistent non-changing view of the store. Some of Sesame's lower levels of isolation explicitly permit the use of HTTP caching (with some restrictions). This allows connections that only need weak consistency to operate at a significantly enhanced speed, by not having to check for new modifications every time.

Most of the RDF stores are not yet optimized for each of the isolation levels. By adding them to the API now, system architects and developers can start planning if and how they will implement caching, validation, federation, and distribution of RDF stores. For more details on the exact isolation levels supported, see the JavaDoc that is provided with the release.

Next Page