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 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 APIRepositoryResult 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 APIreturn 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.

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 conBconB.hasMatch(node, RDF.TYPE, RDF.LIST); // maybe false// contains the new statement, but with a different nodeIDconB.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.

Configuration

The Sesame Server and Console have changed the way they manage repository configurations. Previously, in 2.x, the configurations were hidden in a proprietary format that you needed to modify through a Java API. In 3.0, the Java API still exists, but the configurations are stored in RDF files under the configurations directory and you can modify them with any text editor. This makes setting up complicated repositories easier. The Console also continues to support configuration templates with the create command. These templates are stored in RDF under the templates directory. Templates allow you to reuse common configurations and the Console prompts you for simple configuration settings, such as repository id, description, and other known properties. The location of these directories is set using the -d option of the Console or Server.

The following code represents an in-memory RDF store configuration (or template):

 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix rep: <http://www.openrdf.org/config/repository#>. @prefix sr: <http://www.openrdf.org/config/repository/sail#>. @prefix sail: <http://www.openrdf.org/config/sail#>. @prefix ms: <http://www.openrdf.org/config/sail/memory#>. [] a rep:Repository ;    rep:repositoryTitle "Memory store" ;    rep:repositoryImpl [       rep:repositoryType "openrdf:SailRepository" ;       sr:sailImpl [          sail:sailType "openrdf:MemoryStore" ;          ms:persist true ;          ms:syncDelay 0       ]    ]. 

The following code is a memory RDF store wrapped in a RDFS inferencer and a dataset sail that auto-loads any query-referenced datasets (memory-rdfs-dataset.ttl):

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix rep: <http://www.openrdf.org/config/repository#>. @prefix sr: <http://www.openrdf.org/config/repository/sail#>. @prefix sail: <http://www.openrdf.org/config/sail#>. @prefix ms: <http://www.openrdf.org/config/sail/memory#>. [] a rep:Repository ;    rep:repositoryTitle "Memory Dataset store" ;    rep:repositoryImpl [       rep:repositoryType "openrdf:SailRepository" ;       sr:sailImpl [          sail:sailType "openrdf:DatasetSail" ;          sail:delegate [             sail:sailType "openrdf:ForwardChainingRDFSInferencer" ;             sail:delegate [                sail:sailType "openrdf:MemoryStore" ;                ms:persist true ;                ms:syncDelay 0             ]          ]       ]    ].

Server

The Sesame Workbench is no longer packaged with Sesame. However, much of the functionality provided by the Workbench is available through the Sesame Server and Console. When the Sesame Server is launched with the -u option (resolve URLs to URI descriptions), the server acts as an RDF resource resolver for URLs that resolve to it. Furthermore, it sorts the RDF triples in the result, to provide a more comprehensive view (you can control the order of the triples by listing the desired order in META-INF/org.openrdf.model.order-predicates). You can use this, combined with the new support for RDFa, to turn an HTML browser into an RDF browser. RDFa is a new standard that allows RDF attributes to embed into XHTML content. Using this standard with an RDF server, the traditional lines between an RDF browser and an HTML browser start to blur, as both an RDF client and an HTML client can use the response. By using predicates like <http://www.w3.org/1999/xhtml#title> and <http://www.w3.org/1999/xhtml/vocab#stylesheet> that are understood by HTML clients, you can improve the raw RDFa result in a visually appealing format.

The Sesame Server and protocol was revamped to support transactions; now, a remote repository behaves the same as a local repository. This allows applications to develop using an embedded RDF store and later move to a remote RDF store, while keeping the same behavior. The protocol was also extended to support server-side prepared queries. Large queries that are executed multiple times within a connection can be stored on the server and parsed only once reducing evaluation overhead.

The Sesame Server was extended to support weak consistency when the -c option (number of seconds clients can use their cache before validating) is given a value greater then zero. This allows clients to store results from the server for a period of time before validating the value on the server, and is appropriate when speed is more important than seeing the effects of all write operations. This enables RDF stores to scale much higher by enabling intermediate proxies to cache the results. The Sesame HTTP repository uses weak consistency (if enabled) when running in auto-commit mode for sizeMatch and hasMatch results. By using an intermediate proxy between the client and server, you can cache other results such as match and query evaluation.

Federation

The Federation SAIL is a new feature that allows you to unify multiple Sesame Repositories as a single Repository. The Federation supports writing to one member and does not fully support transactions across members. You can find sample federation configurations on the Aduna Open Source web site.

The Federation SAIL uses the new sizeMatch method of the RepositoryConnection for query optimizations. This causes noticeable delays when evaluating queries over large repositories. Changing the members to use weak consistency can help, but does not effect the time it takes to optimize new queries with new basic graph patterns. However, the Federation does have a few configuration options that can improve the query performance. The most significant is to ensure the members use the openrdf:SailRepository. This allows the Federation to transfer portions of the query to the members and significantly reduces bandwidth and evaluation latency. Setting the distinct configuration option to true allows you to stream results from the members without further processing; thus reducing memory and CPU usage in the Federation. The localPropertySpace configuration option reduces the cross-member joins done during query evaluation for members partitioned by statement subject. This combined with the openrdf:SailRepository drastically reduces the query processing overhead of multiple members. You can only use this option with predicates that are used with subjects that are co-located in the same member.

The HTTPRepository was overhauled to enable effective use within a Federation. It has two new configuration options that are specifically related to the Federation. These are the readOnly option and the subjectSpace option. The readOnly option prevents clients from writing to the remote store and informs the Federation which member should receive new statements. The subjectSpace option is an optimization that reduces redundant bandwidth by informing the Federation where a statement is located based on its subject.

The Expansion of Sesame

The Sesame API has expanded in both breadth and depth in this 3.0 release. It now covers more configuration options and supports multiple levels of transaction isolation, while still providing more convenient ways to perform RDF analysis and manipulation. The 3.0 branch causes some upgrade problems with the new API and the way BNodes are now being handled. However, many of these changes are necessary to support the wider growing interest in the Sesame platform. The new API represents the growing maturity of the semantic web community and the need for more convenient and reliable tools that will help build the next generation of semantic web applications.