Known Issues for dotNetRDF

Home > Project Outline > Known Issues
Versions: English
View Printer Friendly Version

Introduction

This page details all the Known Issues with the dotNetRDF Library. Please be aware that currently the Library is a Beta release so bugs will exist and will generally be fixed in the next release. Issues are organised by version and you can jump to issues with your version of the Library using the list below. Where appropriate fixes/workarounds will be linked to though in general we will aim to address as many issues as possible with our subsequent releases.

If you find a bug not listed here please report it to us at dotNetRDF-bugs@lists.sourceforge.net so we can address it ASAP.

In some cases we have done re-release builds of a specific version to fix bugs that need addressing quickly, you can check the build number of your version of dotNetRDF when it is referenced in Visual Studio by looking at the Version property in the properties window when the reference is selected.

Known Issues by Platform

We provide builds for Silverlight and Windows Phone 7, please see Notes for Silverlight/WP7 Developers developers for issues pertaining to those platforms.

Our standard .Net builds run natively on Mono, please see the Mono Issues page for Mono specific issues.

Known Issues by Version

Current Release

Version 1.0.6

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • The W3C Recommendation for TriG (25th February 2014) is not yet supported
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this

Past Releases

Note that past releases known issues do not include issues which were discovered in subsequent releases, treat any issue from the current release as potentially affecting previous releases. We strongly recommend that you always use the latest release of the library.

Version 1.0.5

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • The W3C Recommendation for TriG (25th February 2014) is not yet supported
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this

Version 1.0.4

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • The W3C Recommendation for TriG (25th February 2014) is not yet supported
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this

Version 1.0.3

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • The W3C Last Call Working Drafts of NTriples, NQuads and TriG (5th November 2013) are not yet supported
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
  • Storage
    • Data.Virtuoso library is not fully compatible with recent Virtuoso releases

Version 1.0.2

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • The W3C Last Call Working Drafts of NTriples, NQuads and TriG (5th November 2013) are not yet supported
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this

Version 1.0.1

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • The W3C Last Call Working Draft of TriG (19th September 2013) is not yet supported
    • The W3C Last Call Working Drafts on NTriples and NQuads (5th September 2013) are not yet supported
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this

Version 1.0.0

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • The W3C First Public Working Draft of TriG (9th April 2013) is not yet supported
    • The W3C Note on NTriples and NQuads (9th April 2013) is not yet supported
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • The zero or more property path operator * may produce incorrect results, using the one or more + operator should give correct results and generally returns more useful results

Version 0.9.0 RC 4

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Core API
    • A spurious NullReferenceException can be seen when running under the debugger, see this blog post for more information
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • Turtle W3C support is 100% to the latest specification as far as we are aware, there are some things that may change and the test suite is a little limited so we do not guarantee 100% compliance
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • Support is almost 100% to the latest specification but there are still a couple of things that may change so we do not guarantee 100% compliance

Version 0.8.2 RC 3

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Core API
    • A spurious NullReferenceException can be seen when running under the debugger, see this blog post for more information
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • Turtle W3C support is 100% to the latest specification as far as we are aware, there are some things that may change and the test suite is a little limited so we do not guarantee 100% compliance
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • Support is almost 100% to the latest specification but there are still a couple of things that may change so we do not guarantee 100% compliance
  • Storage
    • The Async Storage API has been tested as far as possible but we cannot guarantee that there aren't bugs in this new API

Version 0.8.1 RC 2

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Core API
    • Graph Collection may return incorrect URI for default graph
    • ToLiteral() extensions may serialize literals in wrong culture
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • Turtle W3C support is 100% to the latest specification as far as we are aware, there are some things that may change and the test suite is a little limited so we do not guarantee 100% compliance
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • Support is almost 100% to the latest specification but there are still a couple of things that may change so we do not guarantee 100% compliance
  • Storage
    • The Async Storage API has been tested as far as possible but we cannot guarantee that there aren't bugs in this new API

Version 0.8.0 RC 1

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Core API
    • There is a critical bug in GraphCollection caused by a change in an external dependency, use 0.8.1 instead
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • Turtle W3C support is 100% to the latest specification as far as we are aware, there are some things that may change and the test suite is a little limited so we do not guarantee 100% compliance
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • Support is almost 100% to the latest specification but there are still a couple of things that may change so we do not guarantee 100% compliance
  • Storage
    • The Async Storage API has been tested as far as possible but we cannot guarantee that there aren't bugs in this new API

Version 0.7.2 Beta

  • NuGet
    • There is a requirement for Silverlight/Windows Phone projects using this library to reference System.Xml.XPath because it is required by HtmlAgilityPack which cannot be handled automatically by NuGet at this time
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • Turtle W3C support is almost 100% to the latest specification, there are some things that may change and the test suite is a little limited so we do not guarantee 100% compliance
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • Support is almost 100% to the latest specification but there are still a couple of things that may change so we do not guarantee 100% compliance
  • Storage
    • The Async Storage API has been tested as far as possible but we cannot guarantee that there aren't bugs in this new API

Version 0.7.1 Beta

  • Core
    • The new TreeIndexedTripleCollection introduced by this release has a couple of serious bugs, this is a non-default implementation so most users should not be affected
    • The Triple indexing has a bug whereby it is possible for triples to be indexed such that a lookup of one combination of nodes may yield triples not actually matching that combination. Setting Options.FullTripleIndexing to false should workaround this issue but will slow performance and it may still be possible to encounter this issue in rare cases. The next release will resolve this issue.
    • There is a regression in PersistentTripleStore that will cause a StackOverflowException when attempting to retrieve a Graph in some circumstances. The next release will resolve this issue.
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • Support is as close to the 1.1 specification as we can get but there are some things which are still unclear in the latest editors draft and the current test suite is incomplete wrt to the latest draft so we do not guarantee complete support in this release
    • There is a corner case bug involving blank nodes and in-memory updates that may be encountered
  • Storage
    • The Async Storage API has been tested as far as possible but we cannot guarantee that there aren't bugs in this new API

Version 0.7.0 Beta

  • Core
    • There are issues with handling certain forms of URI encoding throughout the library
  • Parsing
    • RDFa 1.1 support does not currently meet the latest version of the specification
    • Not all valid language specifiers can be parsed
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • Support is as close to the 1.1 specification as we can get but there are some things which are still unclear in the latest editors draft and the current test suite is incomplete wrt to the latest draft so we do not guarantee complete support in this release
  • Storage
    • The Async Storage API has been tested as far as possible but we cannot guarantee that there aren't bugs in this new API

Version 0.6.2 Beta

  • Parsing
    • RDFa 1.1 support does not match the latest revision of the specification
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this

Version 0.6.1 Beta

  • Parsing
    • RDFa 1.1 support does not match the latest revision of the specification
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • There are some regressions in SPARQL support, 0.6.2 fixes these
  • Sesame
    • Some queries may return results that select the wrong parser
  • Virtuoso
    • Some SPARQL queries using Virtuoso extensions are rejected by the library

Version 0.6.0 Beta

  • Parsing
    • RDFa 1.1 support does not match the latest revision of the specification
  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
  • Storage
    • StardogConnector is broken in this release (fixed by 0.6.1 Maintenance Release)

Version 0.5.1 Beta

  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
  • Storage
    • Old SQL Stores are officially deprecated, a new SQL store is available as a separate library dotNetRDF.Data.Sql.dll
    • Virtuoso support has been moved into a separate library to reduce dependencies in the core library, existing users who use dotNetRDF with Virtuoso must now use dotNetRDF.Data.Virtuoso.dll in addition to the core library

Version 0.5.0 Beta

  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide for details on how to guarantee this
    • The SPARQL CSV/TSV results formats which we support do not currently match the official recommendations, this will be addressed in the next release
  • Storage
    • Old SQL Stores are officially deprecated, a new SQL store is available as a separate library dotNetRDF.Data.Sql.dll
    • Virtuoso support has been moved into a separate library to reduce dependencies in the core library, existing users who use dotNetRDF with Virtuoso must now use dotNetRDF.Data.Virtuoso.dll in addition to the core library

Version 0.4.1 Beta

  • Query and Update
    • Queries and Updates are not always thread safe - see User Guide (in particular Advanced SPARQL Operations for details on how to guarantee this
  • Storage
    • SQL Storage is officially deprecated though still usable - will be rewritten entirely in future releases (currently planned for 0.4.3 release)
  • Writing
    • PrettyRdfXmlWriter has a bug where temporary namespace generation may fail for some properties
  • Silverlight/Windows Phone 7
    • Features that rely on HTTP are broken on Silverlight and Windows Phone 7 due to a bad sync vs async workaround taken from MSDN which proved to be flawed

Version 0.4.0 Beta

  • Query and Update
    • Leviathan passes the entire SPARQL 1.0 Test Suite except three of the normalization tests - this is due to how .Net handles normalization esp. wrt. URIs
    • ISparqlDataset is not currently thread safe - queries/updates executing on different threads against the same dataset may interfere with each other
    • SPARQL 1.1 Support is as close to the editors drafts as possible at the time of release. Majority of the test suite is passed but we fail 16 and ignore a further 11 of 308 tests due to the following issues (Fixed in 0.4.1 release as of 20/5/2011):
      • Property Path semantics have changed since the previous drafts but our implementation has not so we particularly fail tests involving variable and zero length paths
      • Blank Nodes used as wildcards in INSERT/DELETE commands is not supported as it is unclear whether the WG will endorse this usage or not. If they do the feature presents a significant implementation hurdle which is why it is not currently implemented
      • There are some tests which use syntax which is invalid according to the current drafts so we ignore these tests
    • SPARQL XML Results may be malformed in the case where nulls are bound to a variable - see blog post for details and workaround (Fixed in 0.4.1 release as of 20/5/2011)
  • Storage
    • SQL Storage is officially deprecated though still usable - will be rewritten entirely in future releases (currently planned for 0.4.3 release)

Version 0.3.1 Alpha

  • Parsing
    • RDF/XML parser incorrectly interprets elements of the form <ex:element rdf:datatype="http://example.org/type" /> as empty elements and thus fails to parse them rather than interpreting them as literals
  • Query
    • The Leviathan conforms much more closely to the SPARQL specification but still returns incorrect results on a very small number of queries (~6/441 in the official SPARQL Test Suite)
    • Some SELECT queries containing FILTERS are LIMIT will be optimised to use lazy evaluation but a flaw in the evaluation means the results may be incorrect in some cases
    • Some SELECT queries containing DISTINCT and LIMIT will be optimised to use lazy evaluation when they shouldn't be leading to incorrect results in some cases
  • Storage
    • Write speeds can still vary wildly depending on how you perform the write and the data itself
    • Update support for 4store is broken
    • Virtuoso ADO.Net provider has a serious bug whereby Virtuoso returns some Literals as plain literals rather than typed literals

Version 0.3.0 Alpha

  • Parsing
    • Variety of bugs around corner cases of numeric literals and potentially ambigious '.' terminators in Turtle/N3/TriG and SPARQL (Fixed in 0.3.1 Release)
  • Query
    • ASK queries and queries using MINUS, LIMIT and OFFSET may execute slowly depending on the query (Fixed in 0.3.1 Release)
    • Blank Nodes are not always constructed correctly in SPARQL queries (Fixed in 0.3.1 Release)
    • Leviathan conforms much more closely to the SPARQL specification but still returns incorrect results on a very small number of queries (5/441 in the official SPARQL Test Suite)
  • Storage
    • Write speeds can still vary wildly depending on how you perform the write and the data itself
    • Update support for 4store is highly experimental and uses a feature that is not yet stable in 4store itself and in fact is not in the standard 4store builds
    • Virtuoso 6 support requires Virtuoso 6.1.1 or higher to work correctly
  • Update
    • SPARQL Update does not always work properly on SQL backed Stores (Fixed in 0.3.1 Release)
    • SPARQL Update doesn't construct Blank Nodes correctly in INSERT/DELETE commands (Fixed in 0.3.1 Release)

Version 0.2.2 Alpha

  • Parsing
    • Turtle parser fails to support + at the start of plain numeric literals (Fixed in the 0.3.0 release as of 11/8/2010)
    • Turtle & N3 parsers incorrectly handle unescaped " at end of long literal (Fixed in the 0.3.0 release as of 11/8/2010)
    • UriLoader caching when using ETags does not work correctly (Fixed in the 0.3.0 release as of 11/8/2010)
  • Storage
    • Disposing of an ISqlIOManager multiple times without PreserveState on causes the process to hang in some cases (Fixed in the 0.3.0 release as of 11/8/2010)

Note: All the above known issues are fixed in SVN and so the next release will not have these issues.

All Known Issues for 0.2.1 also apply 0.2.2 since all of these issues are general issues rather than specific bugs.

Version 0.2.1 Alpha

  • Query
    • There are now two SPARQL Engines provided with dotNetRDF - see SPARQL Engine for up to date Known Issues
    • Labyrinth (the original engine) has a variety of issues particularly with complex queries and those using Blank Node variables. It also cannot handle some of the new SPARQL 1.1 features
    • Leviathan is a new engine which conforms much more closely to the SPARQL specification and is recommended for all new development. It performs far better than Labyrinth but still returns incorrect results on a very small number of queries (5/441 in the official SPARQL Test Suite)
  • Serialization
    • The RDF/XML serializers are slow, all the other serializers write in the region of 70,000 triples/second but the RDF/XML serializers currently only achieve well under a 1000 triples/second which is very poor. We provide a FastRDFXMLWriter which writes at about 25,000 triples/second but produces less compressed syntax
  • Storage
    • Write speeds can still vary wildly depending on how you perform the write and the data itself
    • Update support for 4store is highly experimental and uses a feature that is not yet stable in 4store itself and in fact is not in the standard 4store builds
    • Virtuoso 6 support works mostly but due to an issue with the current builds of 6.1 SELECT queries return data in incorrect formats so data can not be read reliably. There is a patch for Virtuoso which fixes this and OpenLink should be rolling out updated binaries soon but this issue is beyond my control.

Version 0.2.0 Alpha

  • Parsing
    • Turtle and N3 Tokenisers handle character escapes incorrectly in some cases (Fixed in the 0.2.1 release as of 11/3/2010)
    • Turtle, N3, TriG and SPARQL tokenisers handle some long literals incorrectly, specifically the case where the last character(s) in a long literal are themselves quotation marks (Fixed in the 0.2.1 release as of 11/3/2010)
  • Query
    • There are now two SPARQL Engines provided with dotNetRDF - see SPARQL Engine for up to date Known Issues
    • Labyrinth (the original engine) has a variety of issues particularly with complex queries and those using Blank Node variables. It also cannot handle some of the new SPARQL 1.1 features
    • Leviathan is a new engine which conforms much more closely to the SPARQL specification and is recommended for all new development. It performs far better than Labyrinth but still returns incorrect results on a very small number of queries (5/441 in the official SPARQL Test Suite)
  • Serialization
    • The RDF/XML serializers are slow, all the other serializers write in the region of 70,000 triples/second but the RDF/XML serializers currently only achieve well under a 1000 triples/second which is very poor. We provide a FastRdfXmlWriter which writes at about 25,000 triples/second but produces less compressed syntax
    • The TriG writer may compress some URIs to QNames incorrectly without including the required prefix information in the header of the file. This will depend on the exact data being written (Fixed in the 0.2.1 release as of 11/3/2010)
    • All writers may compress some URIs to invalid QNames in some cases when one namespace URI is equivalent to the start of another namespace URI and the writer does not have an explicit QName validity checker (Fixed in the 0.2.1 release as of 11/3/2010)
    • All NTriples type writers may fail to correctly escape special characters in some cases (Fixed in the 0.2.1 release as of 11/3/2010)
  • Storage
    • Write speeds can still vary wildly depending on how you perform the write and the data itself
    • Joseki support appears stable but has not received widespread testing (exact functionality depends on the underlying store)
    • 4store & Talis connectors may fail repeatedly with HTTP Time-out errors when attempting to do a sequence of reads and writes in quick succession (Fixed in the 0.2.1 release as of 11/3/2010)
    • There are a number of bugs with Virtuoso support:
      • Works incorrectly with Virtuoso 6 due to issues in our code and issues with Virtuoso 6 and its ADO.Net provider (Fixed in the 0.2.1. release as of 11/3/2010)
      • Some queries which use Virtuoso specific SPARQL syntax may not return correct results (Fixed in the 0.2.1 release as of 11/3/2010)

Version 0.1.3 Alpha

  • Query (Almost all issues fixed in the 0.2.0 release as of 3/2/2010)
    • We've identified a variety of issues in the SPARQL engine which affect all the 0.1.x releases and have fixed most of in the forthcoming 0.2.x builds. Please see the SPARQL Engine page for details of the engine and specific know issues.
  • Serialization
    • The RDF/XML serializers are slow, all the other serializers write in the region of 100,000 triples/second but the RDF/XML serializers currently only achieve well under a 1000 triples/second which is very poor. We provide a FastRDFXMLWriter which writes at about 25,000 triples/second but produces less compressed syntax
  • Storage
    • Write speeds can still vary wildly depending on how you perform the write and the data itself
    • Joseki support is experimental and not yet fully tested - use with caution (Better tested and officially supported in the 0.2.0 release as of 3/2/2010)
    • 4store connector may fail repeatedly with HTTP Timeout errors when attempting to do a sequence of reads and writes in quick succession

Version 0.1.2 Alpha

  1. Parsing (Fixed in the 0.1.3 release as of 18/12/2009)
    • When using the Turtle/Notation 3 parsers there are some flaws in it's Blank Node handling related to the use of anonymous blank nodes and of remapping node IDs to avoid ID collisions. We are working on a 1.3.0 release for next week to solve these issues.
  2. Query
    • When you use plain literals in patterns (integers, decimals, doubles and booleans) type inference is not automatically applied so they will only match untyped literals of the same value and not typed literals of the appropriate type (Fixed in the 0.1.3 release as of 18/12/2009)
    • We provide an otherwise complete (to the best of our knowledge and ability) in-memory SPARQL implementation, the performance of this varies widely depending on the query and the size of the store you are querying over. Execution Timeout and partial result returns are supported to mitigate this.
  3. Serialization
    • All the RDF/XML serializers encounter issues when asked to serialize Graphs that have a namespace bound to the empty prefix. This issue will be solve in the 1.3.0 release next week. (Fixed in the 0.1.3 release as of 18/12/2009)
    • The RDF/XML serializers are slow, all the other serializers write in the region of 100,000 triples/second but the RDF/XML serializers currently only achieve well under a 1000 triples/second which is very poor. We provide a FastRDFXMLWriter which writes at about 25,000 triples/second but produces less compressed syntax
  4. Storage
    • Write speeds can still vary wildly depending on how you perform the write and the data itself

Version 0.1.1 Alpha

  1. Parsing (Fixed in the re-release build 0.1.1.20361 as of 5/10/2009)
    • It is possible to create a file which when parsed will lose Triples since user assigned IDs could potentially clash with auto-assigned IDs
    • NativeNTriplesParser incorrectly parses Literal Objects which are untyped and have no language specifier
  2. Query (Fixed in the 0.1.2 release as of 27/11/2009)
    • Same issues as Version 0.1.0 Alpha, as per the Project Roadmap we are now working to optimise our SPARQL implementation for the 0.1.2 Alpha release in late November
    • Some queries will result in the SPARQL engine returning duplicate results unnecessarily, currently you can eliminate these by doing a SELECT DISTINCT and the fix for this will be in the 0.1.2 Alpha release
    • The Query engine in this release is affected by pattern ordering and queries with a large number of Triple patterns often result in no results when they are answerable due to this.
    • Note SPARQL Optimisation and bug fixes are now our top priority and will now be in the 0.1.2 release
  3. Storage
    • Writing speeds to our SQL based stores can still be slow though we've made some improvements in this release.
    • Accessing Stores created and populated on a 64 bit system from a 32 bit system (or vice versa) can be buggy depending on the data involved
  4. URI Resolution (Fixed in the 0.1.2 release as of 27/11/2009)
    • QNames of the form :name which are used when a default Namespace is not defined are resolved against the Base URI incorrectly, this will be fixed in the next release
  5. Writing (Fixed in the 0.1.2 release as of 27/11/2009)
    • The RDFXMLWriter and RDFXMLTreeWriter are very slow, we provide a FastRDFXMLWriter which is significantly faster but produces very verbose and unreadable syntax.
    • Graphs written using the FastRDFXMLWriter may be incomplete if they contain subjects which are only mentioned in one Triple with an rdf:type predicate
    • When using WriterCompressionLevels.None as the Compression Level for some of the improved faster writers invalid syntax is produced (Fixed in the re-release build 0.1.1.20361 as of 5/10/2009)

Version 0.1.0 Alpha

  1. Parsing (All of these issues are resolved in Version 0.1.1. Alpha)
    • URI Resolution in this version is broken for certain types of Base URI and URI Reference combinations
    • Parsing large files containing 10s of thousands of Triples can take a very long time
    • Unicode escape support in the Turtle and NTriples parsers is provided but will simply pass the Unicode escape into the value of the Node, Notation 3 Parser provides full support (Unicode escapes are converted to Unicode characters)
  2. Storage (Version 0.1.1 Alpha provides some improvements)
    • Writing speeds to our SQL based stores can be very slow, we've provided a number of different ways to achieve speed ups via multi-threading and batching classes. Speeds are also highly dependent on the Triples being written, writing will be faster when there are fewer unique nodes in the data.
    • Read speeds are generally very good providing that you've stored the data in different named graphs, if you store all the data in one graph it can be very slow to read as currently we provide no means to multi-thread the reading of a single Graph
  3. Query (Unresolved)
    • We provide a complete (to the best of our knowledge and ability) in-memory SPARQL implementation, the performance of this varies widely depending on the query and the size of the store you are querying over. Execution Timeout and partial results returns are supported to mitigate this.

Tags

Bugs, Errors, Issues, Known Issues, Problems

Related Content
 
 

Powered By Visual Log from Visual Design Studios

Visual Log is Licensed Free for Any Use on this Website (User is Unregistered)