A new major version of the dotNetRDF library is now available for download.

This release introduces a number of breaking API changes and a repackaging of the monolithic 2.x library into several smaller modules, as well as support for new features such as RDF-Star. Upgrading users are strongly advised to read through the section on Upgrading to dotNetRDF 3.0 in the documentation for guidance on upgrading to 3.0.

dotNetRDF 3.0.0 can be found here on NuGet and also on GitHub.

Restructured Packages

The restructured NuGet packages for dotNetRDF 3.0 are:

  • dotNetRdf - a meta-package that pulls in all of the packages listed below.
  • dotNetRdf.Core - contains the core libraries. This includes support for reading and writing RDF; and for managing and querying RDF data in-memory.
  • dotNetRdf.AspNet - provides a framework for hosting RDF data in an IIS web application. This includes implementations of the SPARQL Protocol and SPARQL Graph Store Protocol.
  • dotNetRdf.Client - provides support for working with a range of triple stores.
  • dotNetRdf.Data.DataTables - a package which integrates RDF data with System.Data.DataTable
  • dotNetRdf.Dynamic - provides an API for accessing and updating RDF graphs using .NET’s dynamic objects.
  • dotNetRdf.HtmlSchema - provides an RDF writer that generates HTML documentation for an ontology that uses the RDF Schema vocabulary.
  • dotNetRdf.Inferencing - provides some basic inferencing support including RDF-Schema, SKOS and a small subset of OWL reasoning.
  • dotNetRdf.Ontology - provides an API for manipulating an OWL ontology.
  • dotNetRdf.Query.FullText - provides a full-text query plugin for dotNetRDF’s Leviathan SPARQL query engine. The text indexing is provided by Lucene.
  • dotNetRdf.Query.Spin - provides an implementation of SPIN using dotNetRDF’s Leviathan SPARQL query engine.
  • dotNetRdf.Shacl - provides an API for validating a graph using SHACL.
  • dotNetRdf.Skos - provides an API for working with a SKOS taxonomy.

Platform support

As of release 3.0 of dotNetRDF, we provide support for .NET Standard 2.0. This ensures compatibility of the libraries with .NET Framework from 4.7 forwards, .NET Core from 2.0 forwards and .NET from 5.0 forwards. We now build and test on both Windows and Ubuntu.

Breaking API Changes

This is a short summary of the changes that can potentially break existing code. More detail can be found in the docs.

Support for Pellet Reasoning has been dropped

Due to lack of a supported open-source implementation of the Pellet server to test against, we have decided to drop support for reasoning via Pellet.

Support for the Virtuoso client library has been dropped

The Virtuoso client library is only supported on .NET Framework. To provide a consistent set of features across all environments we have decided to drop support for connecting to a Virtuoso server via the client library. Applications can still use dotNetRDF’s generic SPARQL connectors to connect to a Virtuoso server via its SPARQL endpoints.

Removed Global Options

The global Options class has been removed and options are now specified closer to where they are used or in some cases removed entirely

.NET serialization support has been removed

We recommend instead using one of the supported RDF/SPARQL syntaxes to serialize/deserialize triples, graphs, stores or SPARQL results.

The static UriLoader class has a new non-static replacement

The new VDS.RDF.Parsing.Loader class provides similar functionality to the VDS.RDF.Parsing.UriLoader class but uses the more modern System.Net.Http library for its HTTP connections. Making the class non-static allows you to create multiple loader instances configured with different HttpClient instances. The main “missing” feature of the new Loader class is caching, which can (and should) be handled at the HttpClient layer.

Graph Names are now specified using the Name property, not BaseUri

Prior to this release of dotNetRDF, the BaseUri property of an Graph served a dual purpose - it provided a base URI that could be used to resolve relative URI references (e.g. when creating new UriNodes in the graph); and it served as the name of the graph in an RDF dataset.

With 3.0, the name of the graph can now be either an IUriNode or an IBlankNode (matching the definition of graph names in the 1.1 version of the RDF specification). This is accessed through the Name property of the IGraph interface. This property is read-only as a graph name should be immutable (especially when it is used to index that graph in collections such as an RDF dataset) - so it can only be set as a constructor parameter. The BaseUri property remains on the IGraph interface, but it is actually now inherited from the INodeFactory interface (which IGraph extends) and is used only to resolve relative URIs when creating a new UriNode. BaseUri is a read-write property as you can (and may want to) change the effective base URI depending on the sources of RDF you are parsing to load the graph with data.

Added ISparqlResultSet interface and changed SparqlResults to implement IEnumerable rather than IEnumerable

The ISparqlResultSet interface has been added to allow a more clean separation between results generated by the Leviathan engine and those generated by other engines or as the result of SPARQL result set parsing. This will cause compile-time implicit type conversion errors where code is receiving values into a variable typed as SparqlResultSet. Changing such variables to ISparqlResultSet should enable clean compilation.

Triple and IRdfHandler changes

The Triple class no longer has a Graph property. This property was used in dotNetRDF 2.x to reference the IGraph instance that the triple was created in and not necessarily the graph that the triple existed in, which could lead to some confusion. Because Triple has been changed to remove this property, the IRdfHandler interface has been extended to add a new HandleQuad method which receives a Triple and a IRefNode as arguments. This method is invoked when handling a triple that is asserted in a graph, with the name of the graph as the IRefNode argument. When updating your implementations of IRdfHandler, please be aware that some parsers (especially those that support graphs as part of their syntax) may report triples in the default graph by invoking HandleQuad with a null value for the IRefNode argument, rather than by invoking HandleTriple. You should therefore ensure that you provide an implementation of HandleQuad even if your handler does not handle triples in a named graph. In your handler you can then decide whether to treat a non-null IRefNode argument as an error or to handle it in some other way (e.g. by ignoring the graph component, or by ignoring the whole quad).