I'm going to be at SemTech 2011 presenting dotNetRDF on the 6th June, see the details of the talk here.

My talk has been featured on SemanticWeb.com recently.

If you are a user or are interested in dotNetRDF please make sure to come say hello while you're at the conference. You can always get my attention by tweeting @RobVesse or contact me in any of the other ways listed on our Contact Us page.

There are currently no Tags for this Content!

Hot on the heels of this mornings release of dotNetRDF 0.4.1 Beta comes the latest version of our Tools package.

You can get this by going to Download dotNetRDF Toolkit for Windows

This release includes the following changes and additions to the Toolkit:

• rdfConvert
  • Reworked default mode (reduced complexity of command line syntax) - note -rapper mode is unchanged
  • Faster converions in default mode
• rdfEditor
  • Added Recent Files List
  • Added more Appearance Customisation
  • Made most user settings roaming
  • Improved auto-completion
• rdfOptStats
  • New tool for generating statistics files for use with our WeightedOptimiser in the core dotNetRDF library
• rdfQuery
  • No Direct Changes
  • Upgrade to using dotNetRDF 0.4.1 allows full SPARQL 1.1 including property paths when using local endpoints
• rdfWebDeploy
  • Added a -negotiate flag for the -deploy and -xmldeploy modes which will automatically include the Negotiate by File Extension module in the Web.config file
• soh
  • No Changes
• SparqlGUI
  • Added a View Log button for reviewing the Log File
• StoreManager
  • Added support for In-Memory and Stardog connections
  • Significantly reworked internals to perform most operations in Background
  • Added Export Data feature for Generic Stores
  • Added Delete Graph feature for Generic Stores
  • Improved Import feature for Generic Stores

Tags: 0.2.0, Alpha, Releases, Toolkit, Tools, Utilities, Windows

dotNetRDF 0.4.1 Beta has been released - you can get it by going to Download dotNetRDF or get the source code via either the dotNetRDF SVN Repository or by going to Download dotNetRDF Source.

As usual please see the Change Log in the downloads for full details of changes. Please note that there are some Breaking Changes in this release which we have previously detailed here.

Here's a highlight of new features and improvements:

New Parser Subsystem

For example you can now quickly count triples e.g.

CountHandler handler = new CountHandler();
TurtleParser parser = new TurtleParser();
parser.Load(handler, "example.ttl");
Console.WriteLine(handler.Count + " Triple(s) parsed");

This is a fairly basic example but you can do all sorts of interesting things like save the Triples to a Triple Store as you read them, write them directly out to a file in another format etc.

We've also provided support for doing multiple things at once i.e. you can combine multiple actions together so read into a Graph and save to a Triple Store at the same time.

SPARQL Improvements

We have also now made it possible for you to inject arbitrary Query and Algebra optimisers into our engine.

Writing Improvements

We also added a new PrettyRdfXmlWriter which generated pretty human readable RDF/XML output.

Acknowledgements

• Graham Moore
• Laurent Lefort
• Felipe Santos
• Sergey Novikov
• Adonis Damian
• Bob Morris

Tags: 0.4.1, API, Beta, dotNetRDF, Downloads, Releases

So I'm afraid to say that there are some breaking changes coming up in the next release (0.4.1 Beta) of the core library and this blog post describes what they are and how they'll affect your code.

We have not made these changes lightly, these are based on feedback we've received from our users and addresses both this feedback and our own concerns over a limitation in the API. This change is at the fundamental data model part of the API so will likely affect a lot of code, don't panic though the change can be easily accommodated by a simple Find and Replace as I'll detail later.

The problem with our API is that we had 5 different Node Types, the core 3 RDF types - URI, Blank Node and Literal - plus the N3 extension types - Graph Literal and Variable. All these were implementations of one single interface INode. The only way to distinguish between these node types and get at their actual values was to inspect their NodeType property and then cast them to the appropriate concrete type.

And here is where the problem arose, this did not permit for external developers to create their own node implementations since everybody's code assumed the use of the concrete implementations in the core API. So to address this each node type now has a dedicated interface (which extends INode) for it with relevant properties for each node type on it's interace. All code that takes/returns a concrete node implementation now returns the appropriate interface type instead. This has many advantages in terms of extensibility and allowing writing of more generic code.

But it will break your existing code where you've strongly typed/cast things as our concrete Node implementations. For example the following snippet will cause an error under the new release:

Graph g = new Graph();
UriNode u = g.CreateUriNode(new Uri("http://example.org"));

Under the new release it must be changed to the following:

Graph g = new Graph();
IUriNode u = g.CreateUriNode(new Uri("http://example.org"));

You'll notice that the change from a code perspective boils down to just adding an I in front of the class names for each of the concrete node types. Therefore you should find it relatively quick and easy to just do a Find and Replace on your code to fix this issue.

We recommend you do the following Find and Replaces for each node type, we just use UriNode as the example here but you should do this for each node type you use:

"UriNode " => "IUriNode " - Replaces use of concrete type with interface type
"(UriNode)" => "(IUriNode)" - Replaces cast to concrete type with cast to interface type
"is UriNode" => "is IUriNode" - Replaces concrete type check with interface type check

Note: In the first example make sure to include a space at the end of both the find and replace strings otherwise you will change functions names like CreateUriNode which have not changed with invalid names.

Also we would strongly recommend that you do not use the 3rd form in your code anywhere as far as is possible. Anytime you need to check the type of a Node we suggest using the NodeType property instead, once you know the type you can cast to the appropriate interface for that type.

I apologise again for having to break your code outside of a major release but this addresses a limitation with the API which we felt was important to address sooner rather than later especially given the feedback of existing users with regards to this.

Tags: 0.4.1, API, Breaking Changes, Changes, Release