The Seer

Moving my shop to a new site

noreply@blogger.com (J1) — Mon, 13 Jun 2011 06:45:00 +0000

I have had nothing but good experiences with Blogger. Nevertheless, I have decided to move and actually start hosting my own (one-man) company website and tech weblog. This means that this is quite likely the last blog-posting here. My new website is at http://rivuli-development.com/. RSS 1.0 feed available at http://rivuli-development.com/feed/rdf. Please adjust your bookmarks

Sesame 2.4.0 with SPARQL 1.1 Query support

noreply@blogger.com (J1) — Thu, 19 May 2011 21:45:00 +0000

I am very proud to announce the release of Sesame 2.4.0. This is a major new release featuring support for SPARQL 1.1 Query.

Sesame 2.4.0 implements all features of SPARQL 1.1 Query as outlined in the October 14 W3C Working Draft, with the exception of basic federated query. SPARQL 1.1 for Sesame is developed by Ontotext in cooperation with Aduna.

The list of new SPARQL query features includes:

Use of expressions in the SELECT clause
Aggregates (COUNT, MIN, MAX, AVG, SUM, GROUP_CONCAT), HAVING and GROUP BY
Property paths
Subqueries
Negation: (NOT) EXISTS and MINUS
Set membership: (NOT) IN
Conditionals: IF
Various new builtin functions: COALESCE, BNODE, IRI, isNumeric, strLang, strDt

Apart from this impressive array of new query language features, Sesame 2.4.0 also implements a number of bug fixes and improvements, including scalability and performance improvement in the Native store. For a full overview, see the release notes.

SPARQL 1.1 Query: negated property sets and the algebra

noreply@blogger.com (J1) — Thu, 28 Apr 2011 00:18:00 +0000

I've just finished the implementation of SPARQL 1.1 property paths in Sesame. The major thing still missing was the implementation of negated property sets.

Negated property sets enable you to formulate a query like, for example: "give me back two resources x and y which are related in any direction via some property, but not via foaf:knows". In SPARQL 1.1, this would look like:

   SELECT ?x ?y
   WHERE { 
           ?x !(foaf:knows|^foaf:knows) ?y .
   }

The current SPARQL 1.1 draft defines a new abstract symbol for supporting negated property sets, called NegatedPropertySet. The SPARQL algebra, in turn, maps this abstract symbol directly to a new algebraic operator, so the algebra is extended with an additional operator in order to support negated property sets, and it also gives a specific evaluation semantics for this new operator.

However, although perhaps useful in terms of brevity, it is in fact not necessary to thus extend the algebra. Negated property sets do not actually introduce additional expressivity to the language (in contrast to, for example, arbitrary-length property paths): the above query could have been formulated in SPARQL 1.0:

   SELECT ?x ?y
   WHERE { 
       { ?x ?p1 ?y . FILTER (?p1 != foaf:knows) }
       UNION
       { ?y ?p2 ?x . FILTER (?p2 != foaf:knows) }
   }

This simple fact makes it possible to implement negated property sets without having to extend Sesame's query model with an additional algebra operator. The advantage of this is that all of Sesame's existing query optimizing/rewriting/evaluation strategies can immediately handle negated property sets, without having to be 'recalibrated' or indeed extended to take a complex additional operator into account.

So, the SPARQL parser processes a negated property set and translates it to the necessary collection of Joins, Filter comparisons and Unions. The algorithm is roughly as follows:

 let NPS be a negated property set with elements e_1...e_n.
 let s be the subject variable of the NPS.
 let ap be the (anonymous) predicate variable of the NPS.
 let O be the set of object variables of the NPS. 
 let F and F_i be two sets of filter conditions.
 let p(e) be the predicate IRI of e.

 for each e in NPS :
    create a filter condition f: p(e) != ap .
    if e is inverted: add f to F_i, otherwise add f to F .
 
 let J be a Join on basic graph patterns. 
 if F is not empty:
    for each o in O :
       add BGP(s, ap, o) to J .

 let I be a Join on basic graph patterns. 
 if F_i is not empty:
    for each o in O :
       add BGP(o, ap, s) to I .
 
 if I and J are both not empty:
    return Union(Filter(J, F), Filter(I, F_i)) .
 else if I is not empty :
    return Filter(I, F_i).
 else if J is not empty :
    return Filter(J, F).

The end result of applying this algorithm to the example SPARQL 1.1 query we saw above would be the following (slightly adapted for readability) Sesame query algebra expression:

Projection({x, y}, 
   Union(
      Filter(StatementPattern(y, ap, x), Compare(!=, ap, foaf:knows)),
      Filter(StatementPattern(x, ap, y), Compare(!=, ap, foaf:knows))
   )
)

Short and sweet. Of course, it gets less short and sweet when using more complex property sets, or property sets in combination with other property path features, but the algorithm caters to that. Such more complex expression just result in a larger set of unions and joins.

Notes on evaluating arbitrary-length property paths

noreply@blogger.com (J1) — Fri, 15 Apr 2011 05:20:00 +0000

I have more or less finished implementing parsing and basic evaluation for SPARQL 1.1 property paths in Sesame. The only thing still missing is negated property sets. Negated sets of properties... Who the heck wants that? Honestly.

Anyway. Apart from the fact that the property path syntax is not quite simple to parse, there are some concepts involved which make evaluation of property-paths tricky - especially if arbitrary-length paths are involved.

Arbitrary-length paths are paths specified with a '+' or '*' modifier. For example, the path ?x foaf:knows+/foaf:name ?name specifies a match where either ?x knows someone with name ?name, or knows someone who knows someone with name ?name, or ... you get the point. The trouble with such queries in 'traditional' evaluation is that there is no a-priori length: you can not simply use the SPARQL parser to build a set of joins.

A path of fixed length n will usually be translated by the parser to n-1 joins on individual statement patterns. In order to allow evaluation of non-fixed length paths, we need something that amounts to graph traversal. Fortunately, Sesame's default evaluation strategy (essentially lazy iteration over bindings) is well suited for this task. What I have done is the following:

the SPARQL parser translates an arbitrary-length property path to a new algebra operator, called (rather appropriately I thought) ArbitraryLengthPath.
the default EvaluationStrategy for such an operator is based on a dynamically expanding iterator, which creates new joins while being evaluted.

Effectively, this new iterator (called PathIteration, currently located as an inner class in the EvaluationStrategyImpl) implements a depth-first graph traversal strategy. It reports back results iteratively and expands the path sequence length (using an ever-increasing iterative creation of nested joins) until it reaches a length at which the nested join no longer produces any matches. Cycle-detection is implemented by the simple expedient of adding an boolean comparison operator (NEQ) on top of our join: if the start node of the path has the same value as the end node, we have a cycle.

Sesame 2.4.0-alpha1 released, with SPARQL 1.1 Query support

noreply@blogger.com (J1) — Thu, 31 Mar 2011 20:13:00 +0000

I'm very pleased to announce a first test release of Sesame with SPARQL 1.1 support: Sesame 2.4.0-alpha1. This first alpha-release of Sesame 2.4 contains support for various SPARQL 1.1 Query features as specified in the current SPARQL 1.1 Query Working Draft. The implementation of SPARQL 1.1 in Sesame is led by Ontotext.

The list of features includes:

Use of expressions in the SELECT clause.
Use of aggregates (COUNT, MIN, MAX, AVG, SUM)
Use of HAVING and GROUP BY
Use of Subqueries
Negation: (NOT) EXISTS and MINUS
Set membership: (NOT) IN
Various new builtin functions: COALESCE, BNODE, IRI, isNumeric, strLang, strDt
Partial support for property paths. Current support includes path sequences (/), path alternatives (|), zero or one matches (?), specific numbers of occurrences ({n, m}), and inverted properties (^). Not yet supported are arbitrary-length paths (+ and * wildcards) and negated properties (!).

As this is an alpha release we advise you to use it for testing and evaluation purposes only. We are actively looking for your feedback in terms of bug reports and other problems you may encounter. We'd love to hear your comments! Please send your feedback to the sesame-general mailinglist.

In other news, the OpenRDF.org website has been given a fresh coat of paint and a good update. I'm sure Arjohn will be pleased to hear your feedback. Take a look, and fill in the survey.

Cooking with Sesame: parsing and writing RDF with Rio

noreply@blogger.com (J1) — Mon, 14 Feb 2011 23:11:00 +0000

The Sesame Cookbook has moved to my new site: http://rivuli-development.com/

The Sesame framework includes a set of parsers and writers called Rio. Rio (a rather imaginative acronym for "RDF I/O") is a toolkit that can be used independently from the rest of Sesame. In this recipe, we will take a look at various ways to use Rio to parse from or write to an RDF document. I will show how to do a simple parse and collect the results, how to count the number of triples in a file, how to convert a file from one syntax format to another, and how to dynamically create a parser for the correct syntax format.

If you use Sesame as a triplestore (via the Repository API), then typically you will not need to use the parsers directly: you simply supply the document (either via a URL, or as a File, InputStream or Reader object) to the RepositoryConnection and the parsing is all handled internally. However, sometimes you may want to parse an RDF document without immediately storing it in a triplestore. For those cases, you can use Rio directly.

The Rio parsers all work with a set of Listener interfaces that they report results to: ParseErrorListener, ParseLocationListener, and RDFHandler. Of these three, RDFHandler is the most useful one: this is the listener that receives parsed RDF triples. So we will concentrate on this interface here.

The RDFHandler interface is quite simple, it contains just five methods: startRDF, handleNamespace, handleComment, handleStatement, and endRDF. Rio also provides a number of default implementations of RDFHandler, such as RDFInserter, which immediately adds any received RDF triples to its supplied RepositoryConnection, and StatementCollector, which stores all received RDF triples in a Java Collection. Depending on what you want to do with parsed statements, you can either reuse one of the existing RDFHandlers, or, if you have a specific task in mind, you can simply write your own implementation of RDFHandler. Here, I will show you some simple examples of things you can do with RDFHandlers.

Collecting all parsed triples in a List

As a simple example of how to use Rio, we parse an RDF document and collect all the parsed statements in a Java List object. For this, we need the following ingredients:

an RDF file;
a RDFParser object;
a RDFHandler object.

For the RDF file, let's say we have a Turtle file, available at http://example.org/example.ttl:

java.net.URL documentUrl 

               = new URL("http://example.org/example.ttl");

InputStream inputStream = documentUrl.openStream();

We now have an open InputStream to our RDF file. Now we need a RDFParser object that reads this InputStream and creates RDF statements out of it. Since we are reading a Turtle file, we create a TurtleParser object:

RDFParser rdfParser = new TurtleParser();

(note: all Rio classes and interfaces are in package org.openrdf.rio or one of its subpackages)

We also need an RDFHandler which can receive RDF statements from the parser. Since we just want to create a Java List of Statements for now, we'll just use Rio's StatementCollector:

java.util.ArrayList myList = new ArrayList();

StatementCollector collector = new StatementCollector(myList);

rdfParser.setRDFHandler(collector);

Finally, we need to set the parser to work:

try { 

   rdfParser.parse(inputStream, documentURL.toString());

}

catch (IOException e) {

  // handle IO problems (e.g. the file could not be read)

}

catch (RDFParseException e) {

  // handle unrecoverable parse error

}

catch (RDFHandlerException e) {

  // handle a problem encountered by the RDFHandler

}

After the parse() method has executed (and provided no exception has occurred), the list myList will be filled by the StatementCollector. As an aside: you do not have to provide the StatementCollector with a list in advance, you can also use an empty constructor and then just get the collection, using StatementCollector.getStatements() .

Using your own RDFHandler: counting statements

As a simple example of writing your own RDFHandler, suppose you want to simply count the number of triples in the RDF file. You could of course use the above code for this, adding all triples to a List, and then just checking the size of the List. However, this will get you into trouble when you are parsing very large RDF files: you might run out of memory. And in any case: creating and storing all these Statement objects just to be able to count them seems a bit of a waste. So instead, we will create our own RDFHandler, which just counts the parsed RDF statements and then immediately throws them away.

To create your own RDFHandler implementation, you can of course just create a class that implements the RDFHandler interface, but a useful shortcut is to instead create a subclass of RDFHandlerBase. This is a base class that provides dummy implementations of all interface methods. The advantage is that you only have to override the methods in which you need to do something. Since what we want to do is just count statements, we only need to override the handleStatement method. Additionaly, we of course need a way to get back the total number of statements found by our counter.

class StatementCounter extends RDFHandlerBase {

  private int countedStatements = 0;

  @Override

  public void handleStatement(Statement st) { 

     countedStatements++;

}

 public int getCountedStatements() {

   return countedStatements; 

}

}

Once we have this, our custom RDFHandler class, we can supply that to the parser instead of the StatementCollector, and we're done.

Converting RDF serialization formats

A useful trick with Rio is to pipeline parsers and writers. Since all Rio RDFWriters are in fact RDFHandler implementations, you can directly supply them to a parser, thus creating a very simple syntax convertor.

Say, you have a file in Turtle format, and you want to convert it to RDF/XML. Simply create a TurtleParser as shown above, and provide it with a RDFXMLWriter, which is an RDFHandler implementation that writes the received RDF statements to an outputstream in RDF/XML format.

Creating the right parser for the right format

In the examples sofar, we have created a parser by simply using the constructor of the specific format's parser class. In other words: our program code assumes that the input file is a Turtle file, so we just create a new TurtleParser object. However, you may not always know in advance what exact format the RDF file is in. What then? Fortunately, Rio has a couple of useful features to help you.

The Rio class is a factory class which can create a RDFParser object given a specific RDFFormat. RDFFormat is a set of constants defining the available serialization formats. It also has a couple of utility methods for guessing the correct format, given either a filename or a MIME-type. For example, to get back the RDF format for our Turtle file, we could do the following:

RDFFormat format = RDFFormat.forFileName(documentURL.toString());

This will guess, based on the extension of the file (.ttl) that the file is a Turtle file and return the correct format. We can then use that with the Rio factory class to create the correct parser dynamically:

RDFParser rdfParser = Rio.createParser(format);

As you can see, we still have the same result: we have created an RDFParser object which we can use to parse our file, but now we have not made the explicit assumption that the input file is in Turtle format: if we would later use the same code with a different file (say, a .owl file - which is in RDF/XML format), it would still work.

Summary

I have tried to show a couple of useful ways to employ Rio in practice. It is a versatile set of streaming RDF parsers and writers that can be easily used in your own programs, and it can be used separately from the rest of the Sesame framework. Of course, more could be said about it (for example, how to configure its error handling, datatype verification, and so on), but that's for next time and/or the comments. Enjoy! And any feedback on these recipes is of course much appreciated.

Implementing SPARQL 1.1 Query - first findings

noreply@blogger.com (J1) — Sat, 05 Feb 2011 04:03:00 +0000

I am currently in the middle of implementing SPARQL 1.1 Query Language into Sesame 2 (code can be found in Sesame's subversion repository, branch 2.4). The current working draft specifies a number of new features for SPARQL, and I will briefly make some points about the features I have implemented thus far, noting problems I encountered or where the current working draft was unclear to me.

1. Expressions in SELECT

This new feature was fairly straightforward to implement, mainly as Sesame already had support for it in its query algebra. I only needed to adapt the parser.

2. Negation

In section 8 two additional operators are introduced, both of which can be used to express negation. They are (NOT) EXISTS, and MINUS. Implementation of the EXISTS function again was quite straightforward, Sesame already having algebraic support for it.

The definition of MINUS in SPARQL gave me some headaches, however. In Sesame's native query language SeRQL, the MINUS operator is a set operator operating on collections of triples - that is, the result of {A} MINUS {B} is the set of all triples matching A, minus all triples matching B. In SPARQL, however, MINUS is defined in terms of compatible solutions. This means that Sesame's own algebra operator for MINUS can not simply be reused for SPARQL. However, it also seems that SPARQL's definition of MINUS makes it, for all practical purposes, exactly equivalent to using a NOT EXISTS filter. To see why this is, we have to take a look at the definitions of both operators.

In section 8.3 , the difference between NOT EXISTS and MINUS is explained, with a number of examples. This explanation shows that when the right-hand side pattern shares no variables with the left-hand pattern, the outcome is different. However, what is also apparent from this explanation that when a MINUS operator is used and no shared variables exist between the two patterns, the MINUS operator effectively does nothing.

This also follows if we look at the definition of MINUS in the SPARQL algebra and the definition of compatible solutions in section 17.3: by definition any two solutions µ and µ' which share no variables v are compatible. So the outcome of any such query would be exactly the same as if the MINUS were not there. This leaves us with two scenarios:

the two patterns share a variable, in this case the MINUS can be replaced with a NOT EXISTS;
the two patterns do not share a variable, in this case the MINUS can be ignored.

All in all it seems to me that MINUS as currently defined does not add additional expressivity to the language and is only a syntactic variant. If that is intended, that might be useful to clarify in the working draft.

3. Subqueries

Sesame already having basic support for this in the algebra, again this was rather simple to add, as it only required me to tweak the SPARQL parser. I will probably need to test it further though.

4. Aggregates

Fortunately for me, it turns out that basic support for aggregate functions had been added to Sesame's algebra earlier, courtesy of David Huynh. It required a bit of tweaking to be compatible with SPARQL's definitions, but the framework was already there, ready for me to extend.

There are a number of things unclear in the working draft however, regarding the expected behaviour of aggregate functions.

The first problem has to do with datatypes. Most examples take it as given that all input to, say, a SUM operator will be numeric values. It is not clearly stated what the expected behaviour is if a particular variable binding turns out to be non-numeric value. As a case in point, SUM is formally defined in terms of the XPath function op:numeric-add. This function explicitly states that it operates only on specific numeric types. No mention is made however, of expected behaviour when one operand is not a numeric type (section 16.3 of the SPARQL WD does mention that a type error results for incompatible operands, but it is not clear if this also applies to aggregate functions). Moreover, it is not clearly stated how a type error in an aggregate function should influence the result. I can see a number of possible scenarios, when a type error occurs during evaluation of an aggregate function:

the entire query fails with an error;
the incompatible operand value is ignored and evaluation continues;
the aggregate operator fails silently, returning 0.

From a usability perspective, I would probably have a preference for option 2, although I note that in other mathematical operators (+, -, *, etc.) Sesame's interpretation currently is that an incompatible operand results in a failed query.

Another problem with the definition of aggregates, or more in general with aggregates in combination with several other features, is that it is not always clearly defined how they should interact (disclaimer: perhaps it is properly defined in section 10.2, but I'm having a hard time following the definitions there). For example, what happens when we apply an ORDER BY on a graph pattern that already has a GROUP BY and an aggregate function? For example, take the following data set:

:org1 :affiliates :auth1, :auth2 .

:auth1 :name "John" .

:auth2 :name "Paul" .

:org2 :affiliates :auth3 .

:auth3 :name "Ringo" .

And the following query:

SELECT (GROUP_CONCAT(?name) AS ?names)
WHERE {
?org :affiliates ?auth .
?auth :name ?name.
}
GROUP BY ?org
ORDER BY ASC(str(?name))

My intuitive understanding would be that the result of this query would be:

?names      

"Ringo" 

"John Paul"

That is: the ordering is applied to the intermediate result of the grouping, thus supplying the aggregate operator (in this case, GROUP_CONCAT) with an ordered sequence (which makes sure that we get a concatenated string "John Paul" rather than "Paul John"). But it is not completely clear to me from the working draft if the ORDER BY clause should be applied to a grouping in this fashion.

These are my findings thus far. I have not yet started on property paths or federated query. In the mean time, I would welcome any feedback on my notes, including feedback that tells me I should have read section so-and-so and it's all clear as glass if I had just taken the time to study it properly :)

Also, this: in the course of this work I have written several DAWG-Manifest style unit tests to check conformance as I saw it. They can be found in Sesame's SVN repository, and I'd be happy to let them be reused.

Back to working on Sesame

noreply@blogger.com (J1) — Thu, 20 Jan 2011 23:48:00 +0000

Ontotext, the Bulgarian Semantic Web company of OWLIM fame, have given me the opportunity to return to working on Sesame as a developer. Specifically, I have been contracted to help implement SPARQL 1.1 Query and Update into the Sesame framework.

Work has already started and I'm happy to report that various features have already been implemented and tested - the fact that Sesame's query algebra is based on the SeRQL language helps a lot here, as various SPARQL 1.1 features were already available in SeRQL. This includes the use of expressions in the SELECT, as well as negation features and subqueries. More challenging will be the inclusion of aggregates and property paths. More soon.

New personal weblog

noreply@blogger.com (J1) — Sat, 04 Dec 2010 10:47:00 +0000

My wife and I have started a new personal weblog, about our emigration to New Zealand: http://naarnz.blogspot.com/. This new weblog will be in Dutch, as its primary purpose is to keep our families and friends back in Holland and Belgium up to date. So, if you understand a bit of Dutch and want to know more about our decision to move to the other side of the world and follow how we fare, have a look!

SWC 0.10.1 - bugfix release

noreply@blogger.com (J1) — Mon, 18 Oct 2010 14:17:00 +0000

I've just put version 0.10.1 of the SWC online. This is a bugfix release that addresses a number of annoying problems:

several buttons on the construct query tab were not visible due to layout problems;
the namespaces tab and context comboboxes were not properly updated after uploading new data;
when adding a file was aborted for any reason, the tool forgot to close the file stream.

As always, we welcome your feedback. By the way, for anyone interested in discussing the tool with us, there is a mailinglist for this purpose at Sourceforge.

Cooking with Sesame: the RepositoryManager

noreply@blogger.com (J1) — Tue, 12 Oct 2010 11:12:00 +0000

The Sesame Cookbook has moved to my new site: http://rivuli-development.com/

(This is part of series of weblog postings on using the Sesame framework more effectively.)

As is also explained in the official Sesame user manual, the Repository API (see also the Sesame Javadoc) is the starting point for anyone wanting to program against Sesame. While the user manual gives some good examples on getting you started with using that API, however, there are some tips and tricks for more effective use that I thought I might share, in a series of weblog postings I'm planning on "Cooking with Sesame". This first episode, I'll go a bit deeper into creation and management of Sesame repositories, specifically using the RepositoryManager and related classes.

Creating repositories: the basics

Sesame supports a number of different types of Repository. The two that are most commonly used are the SailRepository, for local repositories, and the HTTPRepository, a proxy for repositories on a remote Sesame server.

A SailRepository is an object that represents a local Sesame database. Note that, although we call it a database, this does not automatically mean persistence, or anything "heavy" - it can be a simple in-memory representation of an RDF graph. In fact, the easiest way to load any RDF file into memory using Sesame is by creating a SailRepository using an in-memory database.

The type of database (main memory, native, relational, ...) is determined by the SAIL stack provided to the SailRepository (the SAIL API is a Sesame system-internal API that is used to wrap the details of the underlying storage and reasoning mechanism). For example, for creating a simple in-memory repository, we do the following:

import org.openrdf.repository.Repository;
import org.openrdf.repository.sail.SailRepository;
import org.openrdf.sail.memory.MemoryStore;

Repository repository = new SailRepository(new MemoryStore());

repository.initialize();

The MemoryStore object referred to here is a SAIL backend that simply stores all RDF in-memory. Sesame provides various different SAIL backends, as well as various options for configuring each SAIL backend. Some further examples of the creation of various types of repositories (including also the use of the HTTPRepository) are shown in chapter 8 of the Sesame user manual.

Once you have created a Repository object like this, you can open a RepositoryConnection on it to make further use of the repository: adding or removing data, executing queries, and so on.

The RepositoryManager

So far so good: we can easily create and use various different types of Sesame repositories. However, when developing an application in which you have to keep track of several repositories, sharing references to these repositories between different parts of your code can quickly become complex. Of course, you could declare some static references for use throughout your application, but if several repositories have to be juggled this way, this too can become cumbersome. Ideal would be one central location where all information on the repositories in use (including id, type, directory for persistent data storage, etc.) is kept. This is the role of the Sesame RepositoryManager.

Using the RepositoryManager for handling repository creation and administration offers a number of advantages, including:

a single RepositoryManager object can be more easily shared throughout your application than a host of static references to individual repositories;
you can more easily create and manage repositories 'on-the-fly', for example if your application requires creation of new repositories on user input;
the RepositoryManager stores your configuration, including all repository data, in one central spot on the file system.

The RepositoryManager comes in two flavours: the LocalRepositoryManager and the RemoteRepositoryManager.

A LocalRepositoryManager manages repository handling for you locally, and is always created using a (local) directory. This directory is where all Sesame repositories handled by the manager store their data, and also where the LocalRepositoryManager itself stores its configuration data.

You create a new LocalRepositoryManager as follows:

import java.io.File;
import org.openrdf.repository.manager.LocalRepositoryManager;

File baseDir = new File("/path/to/storage/dir/");
LocalRepositoryManager manager =
               new LocalRepositoryManager(baseDir);
manager.initialize();

To use a LocalRepositoryManager to create and manager repositories works slightly differently from what we've seen above about creating Sesame repositories. The LocalRepositoryManager works by providing it with RepositoryConfig objects, which are declarative specifications of the repository you want. You add a RepositoryConfig object for your new repository, and then request the actual Repository back from the LocalRepositoryManager:

import org.openrdf.repository.config.RepositoryConfig;

String repositoryId = "test-db";
RepositoryConfig repConfig = 
      new RepositoryConfig(repositoryId, repositoryTypeSpec);

manager.addRepositoryConfig(repConfig);
Repository repository = manager.getRepository(repositoryId);

In the above bit of code, you may have noticed that I provide an innocuous-looking variable called repositoryTypeSpec to the constructor of our RepositoryConfig. This variable is an instance of a class called RepositoryImplConfig, and this specifies the actual configuration of our new repository: what backends to use, whether or not to use inferencing, and so on.

Creating a RepositoryImplConfig object can be done in two ways: programmatically, or by reading a (RDF) config file. Here, I will show the programmatic way (in a future article we may look at the other method, using RDF config files).

import org.openrdf.sail.config.SailImplConfig;
import org.openrdf.sail.memory.config.MemoryStoreConfig;
import org.openrdf.repository.config.RepositoryImplConfig;
import org.openrdf.repository.sail.config.SailRepositoryConfig;

// create a configuration for the SAIL stack
SailImplConfig backendConfig = new MemoryStoreConfig();

// create a configuration for the repository implementation
RepositoryImplConfig repositoryTypeSpec = 
                new SailRepositoryConfig(backendConfig);

As you can see, we use a class called MemoryStoreConfig for specifying the type of storage backend we want. This class resides in a config sub-package of the memory store package (org.openrdf.sail.memory). Each particular type of SAIL in Sesame has such a config class.

As a second example, we create a slightly more complex type of store: still in-memory, but this time we want it to use the memory store's persistence option, and we also want to add RDFS inferencing. In Sesame, RDFS inferencing is provided by a separate SAIL implementation, which can be 'stacked' on top of another SAIL. We follow that pattern in the creation of our config object:

import org.openrdf.sail.inferencer.fc.config.ForwardChainingRDFSInferencerConfig;

// create a configuration for the SAIL stack
boolean persist = true;
SailImplConfig backendConfig = new MemoryStoreConfig(persist);

// stack an inferencer config on top of our backend-config
backendConfig = 
     new ForwardChainingRDFSInferencerConfig(backendConfig);

// create a configuration for the repository implementation
SailRepositoryConfig repositoryTypeSpec = 
                new SailRepositoryConfig(backendConfig);

The RemoteRepositoryManager

A useful feature of Sesame is that most its APIs are transparent with respect to whether you are working locally or remote. This is the case for the Sesame repositories, but also for the RepositoryManager. In the above examples, we have used a LocalRepositoryManager, creating Sesame repositories for local use. However, it is also possible to use a RemoteRepositoryManager, using it to create and manage Sesame repositories residing on a remotely running Sesame server.

A RemoteRepositoryManager is initialized as follows:

import org.openrdf.repository.manager.RemoteRepositoryManager;

// URL of the remote Sesame server we want to access
String serverUrl = "http://localhost:8080/openrdf-sesame";
RemoteRepositoryManager manager = 
              new RemoteRepositoryManager(serverUrl);
manager.initialize();

Once initialized, the RemoteRepositoryManager can be used in the same fashion as the LocalRepositoryManager: creating new repositories, requesting references to existing repositories, and so on.

Disclaimer: although I have done my best to check the correctness, I can give no guarantees that any of the provided code examples work as expected. Also I make no claims on whether any of this is the 'official' way of working with Sesame.

SWC 0.10 - OWL Reasoning support

noreply@blogger.com (J1) — Thu, 30 Sep 2010 12:51:00 +0000

Anton and I have just released version 0.10 of SWC, the Sesame Windows Client. The main new feature of this release is support for OWL reasoning.

The Sesame Windows Client now includes the latest version of Ontotext's SwiftOWLIM store, a high-performance in-memory store and OWL reasoner. SWC allows you to create a local SwiftOWLIM store like any other Sesame repository, with the added advantage that it supports OWL semantics. OWL reasoning made easy!

Also, we have made a number of improvements in the performance of data upload and data export, as well as several minor changes in the UI.

Next steps in the development of SWC are: adding support for other triplestores that have a Sesame API bridge (including Virtuoso and AllegroGraph), as well as improving the SPARQL endpoint support (by allowing additional parameters to be set). And oh yeah, we're still looking for a good new name for the SWC...

Semantic Mediawiki Conference (SMWCon) Fall 2010

noreply@blogger.com (J1) — Mon, 20 Sep 2010 14:10:00 +0000

I just came back from an exhausting but highly inspirational 2 days of talks and demos about Semantic Mediawiki and various extensions and use cases: SMWCon Fall 2010 (hosted at the Open University in Amsterdam).

Some of my personal highlights (in no particular order):

Semantic Maps as presented by Jeroen de Dauw. This was a bit of an eye-opener, as I had previously briefly thought about using something like this, but decided it wouldn't be worth the bother if it involved having to type in a lot of coordinates.
Well guess what, you don't have to: it provides full geocoding functionality, effectively allowing you just to type in a street address. It ties in with Google maps as well as Open StreetMaps, Yahoo maps and OpenLayers. Overall it looks just massively useful.
WikiTags by Jesse Wang: a very impressive demo on how to link the world of (semantic) wikis to the world of MS Office. Automated annotation of terms in MS Word, live links between Outlook and the wiki, quick and easy adding of e-mail messages to the wiki, etc. etc. The thought behind this effort appeals to me: don't rage against the machine but accept that MS Office tools are the daily working environment for many people and organisations, and cater to that.
The Suite of Halo extensions presented by Daniel Hansch: although I was already aware of the Halo extensions I had not yet completely grokked the full range of features and improvements it encompasses. In particular its support for fine-grained access control is something that captured my attention. On the ToDo list to take for a test drive.
SparqlExtension by Alfredas Chmieliauskas and Chris Davis: particularly impressive about this demo was the way in which this extension enables integration of (RDF) data from many different sources and creating all sorts of reportings on that data. Can't wait to tweak this one to talk to a Sesame server and start testing it on our internal group wiki.
Rudi van Bavel and Michael Cariaso both showed very interesting stuff involving the creation, maintenance and use of SNPedia, a wiki containing huge amounts of human genetic data.

To be honest, though, I found all presentations and demos, not just the ones mentioned above, interesting and engaging. The atmosphere throughout the two days was positive and pragmatic, with lots of interesting group discussion going on. It was great to see people from so many different background coming together to share experiences and show new and innovative ways in which the SMW platform can be used and extended.

SWC 0.9 released: out-of-the box triplestore and SPARQL query library

noreply@blogger.com (J1) — Tue, 14 Sep 2010 11:44:00 +0000

Hot on the heels of the previous SWC release comes another major update of the Sesame Windows Client. Version 0.9 has a whole range of useful new features and improvements:

You can now create and use local repositories (many thanks to the IKVM developers and Enrico Minack for making this possible);
"My Query Book" allows you to save and reuse your favorite SPARQL queries;
You can now open the result of a SPARQL SELECT query in a new (paged) window;
You can now directly save the result of a SPARQL SELECT query as comma-separated values, XML, or JSON;
Your most recently used server URLs are now remembered;
Autocompletion when typing in a server URL.

The use of local repositories means that you can use the SWC as a quick and easy RDF triplestore. Create a new store, add your RDF data, and start querying. No need to install a separate triplestore server.


Query Book screenshot (click to enlarge)

The Query Book allows you to not only save your queries, but also to document them. This way, you can quickly create a library of useful SPARQL queries and document not only what they do, but also on which repository or SPARQL endpoint the query is most likely to give a useful result. The Query Book's search feature makes sure that even in a large library you can still easily find back any query.

Another new feature is the opening of a SPARQL SELECT query result in a new (paged) window. What is especially useful about this is that you can now execute one query, keep the result in a separate window, and then execute another query and compare its result with the previous one.

If you want to save the result of a SPARQL query, you can now do so, in a choice of three formats: comma-separated values (CSV), which is useful for import in e.g. Excel, is the default choice, but the official SPARQL Query Results XML format and the SPARQL JSON format are also suppported.

Both Anton and I are quite happy with this new release, and hope you find it useful as well. As always, the new release can be found on the project homepage on Sourceforge.

Sesame 2 Windows Client - or is that SPARQL Windows/Linux Client?

noreply@blogger.com (J1) — Fri, 03 Sep 2010 08:38:00 +0000

I've just released a new version of the Sesame 2 Windows Client. Thanks to a new co-developer, Anton Andreev (of OntoText), the SWC tool is now a full-fledged SPARQL client: it can connect to any SPARQL endpoint, not just Sesame servers.

Apart from this new feature, the tool also has a couple of other improvements:

context information fetching can now be disabled when connecting to large repositories;
namespace clauses can now be automatically generated, based on the prefixes used in the query.

The only problem with this new release is that the name of the tool is now even more of a mismatch. Not only is the Sesame 2 Windows Client not just for Windows (it also runs on Linux under Mono), but now it is also not just for Sesame. A free drink to whoever suggests a good new name!

As always, the new release can be found on the project homepage on Sourceforge. The source code can from now on be found in the Sourceforge SVN repository.

Moving to New Zealand

noreply@blogger.com (J1) — Mon, 30 Aug 2010 10:11:00 +0000

Karen and I are taking the plunge together. Well, another plunge: we are emigrating to New Zealand at the end of this year.

This is not, of course, something you decide on a whim. We've both long felt that we might like to make a "big change" for the better, and a long holiday spent getting to know New Zealand and its people convinced us that it is everything we were hoping it would be. New Zealand is an absolutely breathtakingly beautiful place, its people are friendly and easy-going, and for what is basically a predominantly Anglosaxon culture they actually make very good coffee as well.

The plan is quite simple. We have both obtained our permanent residence visa, and will move to New Zealand, to the Wellington area, in December. Although neither of us has secured a job yet, I am actively on the lookout, and confident that something suitable will turn up. NZ and especially Wellington is full of smaller and larger IT firms, and every job vacancy site I check literally posts 2 to 6 positions for (Java) developers a day, at least. However, what I've not been able to find much of yet, is companies or institutes who work in Semantic Web/Ontologies, or who have a need for expertise in that area. If any of you have tips for me (or a job offer ;-)), it would be much appreciated!

I will post updates on developments now and then on this weblog. Oh and yes: we will of course be giving a farewell party later this year ;-)

wurvoc.org - linked open data for Quality of Life

noreply@blogger.com (J1) — Fri, 11 Jun 2010 09:43:00 +0000

I am proud to announce the official launch of wurvoc.org. Built by the Intelligent Systems Group at Wageningen UR Food & Biobased Research, the goal of wurvoc.org is to serve as a hub for various vocabularies and semantic web services we have developed and are still developing. Many of these vocabularies (modeled in RDF and OWL) have been built using public funding and we feel it important that this information is also publicly available in a way that is open and reusable.

Vocabularies

Currently, wurvoc.org publishes 4 vocabularies:

The Ontology of Units of Measure models concepts and relations important to quantitative scientific research. It has a strong focus on units and quantities, measurements, and dimensions.
The Food Additives vocabulary describes substances added to food to improve the flavour, taste, shelf-life, stability et cetera of the food product. Food additives that are approved by EFSA, the European Food Safety Authority are labelled with an E-number.
The Dairy ontology contains a hierarchy of types of dairy products and provides general information about these products.
The Drinks vocabulary contains a classification hierarchy of various types of beverages.

Our aim is both to publish more vocabularies and data in the near future, and to extend and improve the current vocabularies: although the data is Open, it is not yet truly Linked in the sense that it has very few relations with external datasets.

Software

We've developed the wurvoc publication platform, a set of REST services on top of the Sesame framework. In line with linked data principles, the platform publishes each vocabulary and each vocabulary term on its own URI. For example, an ontology on food additives is available at http://www.wurvoc.org/vocabularies/food-additives/, and the food additive Pectin is reprsented by http://www.wurvoc.org/vocabularies/food-additives/Pectin.

The platform uses HTTP content negotation to determine the representation format, currently supporting XHTML, RDF/XML, Turtle, N3, NTriples, and TriG (with JSON on the ToDo list).

OUM Web Services

Apart from a vocabulary publication platform, wurvoc.org also offers a number of SOAP-based web services on top of the Ontology of Units of Measure (OUM). These web services provide a number of useful functions, including lookup and matching functions as well as more advanced stuff, such as unit conversion or formulaic consistency checking.

Future plans

We are aiming to publish the publication platform software as open source as soon as possible. Various improvements are also planned, including a SPARQL endpoint and support for JSON.

I'd very much like to hear your comments on what we've brewed sofar, what you think is good and what you think could be better. I encourage you to reuse our linked data (and would appreciate it if you could let us know if you do).
I also plan to keep you up to date on our findings regarding use, performance, and general lessons that we learn after the launch of this project. Watch this space :)

Accessing DBpedia's SPARQL endpoint with Sesame

noreply@blogger.com (J1) — Fri, 19 Mar 2010 12:53:00 +0000

I'd like to share a tip on using Sesame as a client for SPARQL endpoints. This may be rather trivial to some but perhaps new to others.

We are developing a tool called ROC (Rapid Ontology Construction) (see our paper@ASWC'08), which is a tool that allows domain experts to quickly build a basic vocabulary for their domain, re-using existing terminology whenever possible. How this works is that the ROC tool asks the domain expert for a set of keywords that are 'core' terms of the domain, and then queries remote sources for concepts matching those terms. These are then presented to the user, who can select terms from the list, find relations to other terms, and expand the set of terms and relations, iteratively. The resulting vocabulary (or 'proto-ontology', basically a SKOS-like thesaurus) can be used as is, or can be used as input for a knowledge engineer to base a more comprehensive domain ontology on.

ROC is developed on top of Sesame, and up until now we simply supplied the tool with 'remote sources' by adding data to a locally running Sesame repository. In order to act with the LOD cloud, we obviously needed something a bit less awkward, so I started looking into ways to extend the functionality to be able to query linked open data.

Fortunately, I didn't have to look far, because Sesame actually already supports this: Sesame's client server protocol is a superset the SPARQL protocol. This I already knew, but what I hadn't yet tried was to see if that meant you could use Sesame's client libraries to query any SPARQL endpoint (instead of just connect to a remote Sesame server, which is what it is primarily designed for, after all). And guess what, it turns out that you can!

Here's a bit of code that connects to DBPedia's SPARQL endpoint and fires a query. The idea is simply to reuse Sesame HTTPRepository class, supply the endpoint URL as the server, and specify no repository:

String endpointURL = "http://dbpedia.org/sparql";
HTTPRepository dbpediaEndpoint = 
         new HTTPRepository(endpointURL, "");
dbpediaEndpoint.initialize();

RepositoryConnection conn = 
         dbpediaEndpoint.getConnection();
try {
  String sparqlQuery = 
         " SELECT * WHERE {?X ?P ?Y} LIMIT 10 ";
  TupleQuery query = conn.prepareTupleQuery(SPARQL, query);
  TupleQueryResult result = query.evaluate();

  while (result.hasNext()) {
      ... // do something linked and open
  }
}
finally {
  conn.close();
}

Now, I'm perhaps easily impressed, but to me this was beautifully easy. This makes integrating arbitrary linked open data in most of our Sesame-based tooling (including ROC) completely painless.

VU Dies Natalis: Web and Science

noreply@blogger.com (J1) — Wed, 21 Oct 2009 07:10:00 +0000

Yesterday, the VU University Amsterdam celebrated its 129th birtday (or Dies Natalis, as universities obviously do not have something as common as a 'birthday'). The theme of this year's celebration was "Web & Science".

The Dies Natalis lecture was delivered by Frank van Harmelen and centered on the question how Web technologies are not just speeding up communication between scientists, but how these new technologies change the way in which we do science itself: is the academic paper, the yardstick of academic achievement, getting out of date, and what other possible yardsticks do we have? Van Harmelen paints a picture of a future landscape of science where data-driven research, empowered by the web, becomes the dominant way of conducting research: the vast amounts of data produced by individual scientists can be shared on the Web and aggregated, integrated, interpreted, and be used to fuel new hypotheses on a scale that was impossible before. In this world, scientific achievement should not just measured by number of published papers or citations, but by number of published data sets or downloads of one's data sets. By using Semantic technologies it may become possible for computers to assist the scientist not just in writing his e-mail and marking up his paper, but in finding relevant data sets, hypotheses, arguments pro and contra, and so on. It would even be possible for the machine to point out contradicting results in two different publications and offer a suggestion for an experiment that shows which result is correct. Science fiction? Perhaps, but van Harmelen argues that at least some of these ideas are closer than we realize.

Highlight of the Dies celebration was the bestowing of an honorary Doctorate to Sir Tim Berners-Lee, not only for his achievement in creating the WWW, but in admiration of his personal commitment to keeping the WWW truly open and universal.
Tim, obviously a bit uncomfortable with the ceremony (which involved him standing in the middle of the podium, wearing a rather peculiar robe, while Guus Schreiber said all sorts of nice things about him), was characteristically humble and gracious in his acceptance, pointing out that all he did was working out a good idea, and that basically the Web came about not just because he had a good idea, but that other people also considered it a good idea and spent tremendous time and effort in making it happen.

The morning session was devoted to the dies symposium, titled "The World Wide Web and Social Development". The focus was very much on how Web technology can be more effectively employed to help developing nations. A highlight was the film and subsequent talk about Yacouba Sawadogo and the efforts in re-greening Africa's drylands, and how more effective communication technology is needed in order to scale up these efforts. Also, a very interesting talk was given about the creation of the WWW Foundation, which focuses on breaking down barriers to effective access to and use of Web technology in less priviliged countries.

All in all, an inspirational day. The beer (specially brewed for the occasion) was not bad either :)

Simple rules using construct queries in Sesame

noreply@blogger.com (J1) — Thu, 08 Oct 2009 12:18:00 +0000

A while ago I put together a simple rule-based reasoner for Sesame 2 (available in Aduna's Sesame extension SVN). The idea was to have a configurable rule-based reasoner that would reuse Sesame's query engine (in combination with SeRQL/SPARQL CONSTRUCT queries) to perform simple customized entailment.

The idea is fairly simple: the reasoner works as a stacked SAIL in Sesame's repository configuration (the SAIL is a Sesame internal api that wraps the physical data storage medium). Rules are defined in an RDF format that reuses SeRQL syntax for defining graph patterns. By adding these rules to the Sesame repository the reasoner picks up on them, creates actual SeRQL CONSTRUCT queries out of these rules and then uses Sesame's own query engine to execute the rules, adding the rule result back into the repository.

For example, a rule defining that an uncle of some person P is the brother of one of the parents of P would look like this (using Turtle syntax):

ex:defUncle a custom:Rule;
   rdfs:comment "my parent's brother is my uncle";
   custom:head "{X} ex:uncleOf {Y}";
   custom:body "{X} ex:brotherOf {} ex:parentOf {Y}" .

The reasoner would translate this to the following SeRQL query:

 CONSTRUCT {X} ex:uncleOf {Y}
 FROM {X} ex:brotherOf {} ex:parentOf {Y}

For those of you not familiar with SeRQL, the SPARQL equivalent would look like this:

 CONSTRUCT {?X ex:uncleOf ?Y }
 WHERE {?X ex:brotherOf ?Z.  ?Z  ex:parentOf  ?Y. }

I've recently returned to this reasoner, for use in the Tiffany project. In this project, we are developing a Research Management System for researchers in the food industry, and one core concept in this system is a hierarchy of Research Questions and associated activities. Each activity is used by at least one team, and we need to keep a number of things up to date. For example, if a Research Question has an associated activity that is used by team X, the research question itself should also be marked as "used by team X". Moreover, if a research question A has a subquestion B, and that subquestion is used by team X, then research question A should also be marked 'used by team X'.

Previously we tried to support this from code, by explicitly calculating and asserting RDF triples for the 'isUsedBy' relation whenever an activity is linked to (or unlinked from) a research question, or whenever the research question hierarchy is changed. However, the seemingly simple rules for entailment of isUsedBy quickly become devilishly complex when implemented in an imperative fashion. The function that deals with this is well over 100 lines of code. Now, compare that to the rule-based approach:

 tifrule:activityUsedBy a custom:Rule ;
    custom:body "{X} tifn:activity {Y} tifn:isUsedBy {T} " ;
    custom:head "{X} tifn:isUsedBy {T} " .

 tifrule:inheritanceUsedBy a custom:Rule ;
    custom:body "{X} rdf:type {tifn:ResearchQuestion} ;
                     tifn:isUsedBy {T} ,
             {Y} tifn:hasSubQuestion {X} " ;
    custom:head "{Y} tifn:isUsedBy {T} "

Simple. And from some early tests I ran, remarkably good performance too.

Next steps are to investigate how the performance of the approach holds up when I add more rules, and when I start doing many updates on the repository (after all, it's nice if querying is quick, but we also expect users to add new data or update existing information, and that requires that we do not have a large performance penalty for updates).

SKOS Browser

noreply@blogger.com (J1) — Wed, 12 Nov 2008 15:03:00 +0000

The latest release of my pet project, the Sesame 2 Windows Client (SWC), has a nice little feature that I though was worth sharing with you: a SKOS hierarchy browser.

Many ontology editors and viewers have the option of showing a class hierarchy but to my surprise I found very few tools that could display a SKOS broader/narrower hierarchy. So I hacked one together and put it in this client.

Add your SKOS thesaurus to a Sesame Repository, point the SWC at it, go to the "Browse Hierarchy" tab and choose "SKOS Hierarchy".

For now you can only click around in the hierarchy, you can not follow cross-taxonomical links or do any editing.

Sesame 2 Desktop Client

noreply@blogger.com (J1) — Thu, 11 Sep 2008 14:21:00 +0000

I recently needed a programming excercise in creating a Windows graphical user interface, and decided to create a simple Sesame 2 client. This has turned out to become quite a useful little tool so I've decided to make it available open source.

The Sesame 2 desktop client is a windows (.Net) application that can communicate with a (remote) Sesame 2 server, perform queries, add/remove data, and so on. It is somewhat similar to the Sesame Workbench application, but it has a couple of nice user-friendly options (such as implicit adding of namespace declarations to your queries, dynamic sorting of the query result, etc).

You can downlo ad it from sourceforge. Give it a spin, tell me what you think, suggestions most welcome!

Of and of course my thanks to the dotSesame people, whose work I've gratefully reused in this tool.

Sesame 2.0 final released (while you weren't looking...)

noreply@blogger.com (J1) — Wed, 02 Jan 2008 09:11:00 +0000

While everybody was busy stocking food and drink, the Sesame developers apparently have been at it in overdrive, managing to release the final release of Sesame 2.0 just in time for Christmas. From the openRDF.org announcement:

"Thanks to an overwhelming number of people that have tested the previous release candidates and reported any issues that surfaced, we can now proudly present Sesame, version 2.0!
After the second release candidate, only one serious issue was reported and fixed. We found and fixed some minor, non-critical issues ourselves and made some small improvements here and there, mostly related to HTTP communication and OpenRDF Workbench. All in all, we think the code is now sufficiently tested to call it 2.0-final.
The development focus will now shift to performance and scalability improvements. An RDBMS-based Sail implementation is currently under development and the first results look very promising. The performance of the native- and memory stores will also be improved. As there hasn't been put a lot of effort into this so far, we expect to achieve good results here."

I just want to take the opportunity to congratulate the people at Aduna with this important milestone! Great job, and thanks!

.Net is truly like a foreign country...

noreply@blogger.com (J1) — Wed, 12 Dec 2007 09:19:00 +0000

...they do things exactly the same there.

I have recently been involved in a project where an RDF ontology + instance set needs to be exposed through a web UI. Being a Java man myself I was immediately set to start fiddling about with JSP/JSF, Spring MVC and (obviously) a Sesame 2 store.

However, in this project my coworkers are .Net developers, so we were left with either me doing all the work myself or somehow figuring out a way of using a Sesame store in a .Net environment. Given that I only have one brain and two arms, and the project has a deadline that falls within the first half of this century, we decided to go for the second option. The web frontent will be in ASP/.Net, the server backend will run Sesame in Java. So, how to get them to talk?

Our first attempt involved using Spring-WS to write a Web Services wrapper (SOAP messaging, WSDL description, the works) around the Sesame store. However, this wrapper was application-specific (talking in terms of business objects from the application domain rather than being a generic sesame wrapper), and really rather large, clumsy and difficult to maintain, so we decided to try something else.

Enter IKVM.net. This is a Java implementation for Mono and .Net that can also be used to do a static porting of Java classes to .Net bytecode (or CIL as they call it in .Net-land). Using a handy little tool called ikvmc I managed (in about half an hour time, mostly spent on trying to figure out which of Sesame 2's impressive collection of jar files to in- and exclude from the process) to create a DLL and he presto! A Sesame 2-compatible HTTP Repository proxy API for .Net Is Born!

Using this DLL we can now access, in C#, a remote Sesame server in exactly the same fashion as we would from a Java environment: by simply using Sesame's own Repository API.

Perhaps not the most elegant and robust solution - and not nearly as much fun as spending several man-months on painstakingly building a .Net client library from scratch, including the creation of parsers and writers for N3, Turtle, RDFXML, Trig, TriX, SPARQL XML result format, SPARQL, SeRQL, and Sesame 2's transaction serialization format - but in a pinch and on a tight budget quite a satisfactory little workaround.

Moving on to new things

noreply@blogger.com (J1) — Fri, 22 Jun 2007 08:25:00 +0000

Some of you may have heard this already, but I have recently decided to take a new step in my professional career.

I will be leaving Aduna, effective August 1, and therefore also leave as lead developer of the Sesame framework. I will also leave my position at the Eindhoven University of Technology (TU/e).

I will take up a position as researcher/developer at the Wageningen UR (the Agrotechnology & Food Science Group, AFSG), where I will take part in projects dealing with the use of SW technology in the agrotechnology and food sector (think biology researchers, or food processing/distribution companies, etc.).

I have spent a wonderful 8 years at Aduna, working with a great team, and I take enormous personal pride in the fact that I have helped create an RDF framework that is used successfully by so many people. I have every confidence that the Sesame framework will continue to be the success it is today and that all the Sesame developers, both in the Aduna team and outside it, will continue to work on making it even better.