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.
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.
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
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
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
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
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.
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
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
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).