Table of Contents

Release 4.9

Major Changes in release 4.9

Post release note about the Top Braid Composer Plugin

Major Changes in release 4.8

Major Changes in release 4.7

Changes in earlier releases

AllegroGraph 4.9 user-visible changes

AllegroGraph Server: General Changes

HTTP Client

SPARQL

AGWebView

Changes to the Lisp API

Documentation

Python Client

Java Client

AllegroGraph 4.8 user-visible changes

AllegroGraph Server: General Changes

HTTP Client

SPARQL

AGWebView

Changes to the Lisp API

Documentation

Python Client

Java Client

AllegroGraph 4.7 user-visible changes

AllegroGraph Server: General Changes

HTTP Client

SPARQL

AGWebView

Changes to the Lisp API

Documentation

Python Client

Java Client

AllegroGraph 4.6 user-visible changes

AllegroGraph Server: General Changes

HTTP Client

SPARQL

AGWebView

Changes to the Lisp API

Documentation

Python Client

Java Client

Release 4.9

This document lists all changes for the most recent major release (releases with number X.Y) and subsequent minor releases (with numbers X.Y.Z and perhaps further identifiers), including major and important changes and a list of all user-visible modifications. Change History repeats the list of user-visible modifications for this release and includes similar lists for earlier releases.

The release described in the documentation set is 4.9.

Major Changes in release 4.9

The changes in the previous major release, version 4.8, are listed just below.

Post release note about the Top Braid Composer Plugin

The Top Braid Composer Plugin (see Top Braid Composer Plugin) also now works with TBC version 4.0.x (it has been tested on 4.0.0). No change to AllegroGraph is required. Just change what you download, as described in Top Braid Composer Plugin. Note too TBC version 3.6.2 is no longer supported by Top Quadrant.

Major Changes in release 4.8

The changes in the previous major release, version 4.7, are listed just below.

Major Changes in release 4.7

Release 4.7 has, in addition to numerous bug fixes and general enhancements described below, the following new features:

Changes in earlier releases

This document lists changes in the current release, 4.7 and 4.6. See the Change History for a list of all changes in the earlier releases.

AllegroGraph 4.9 user-visible changes

AllegroGraph Server: General Changes

Rfe11922 - Add materiazer. See Materializer for details.

Rfe11879 - Improve error message on invalid license

AllegroGraph now prints information to the console when there are problems with the license settings in the configuration file.

For example, if the configuration file is missing the LicenseExpires parameter, then AllegroGraph will print: 

AllegroGraph Server Edition 4.9, built on October 01, 2012 10:04:33 GMT-0700  
Copyright (c) 2005-2012 Franz Inc.  All Rights Reserved.  
current-time: Monday, October 01, 2012 10:43:09 AM  
 
Daemonizing...  
Server started: LicenseExpires parameter missing. Running with triple-limit of 5,000,000.

Rfe11845 - Optimize blank node printing

Blank nodes now print slightly faster and more efficiently than they did before.

Rfe11827 - Reduce memory footprint a bit

Result arrays are now freed right when they become unused. Previously, garbage accumulated until a certain limit was reached. This should have a small positive effect on high water-mark memory footprint.

Rfe11784: Release memory back to the operating system after query failure

Prior to this change, AllegroGraph would continue to claim memory used for queries even after the query would complete. AllegroGraph will now return unused memory back to the OS when a query memory failure occurs.

Rfe11762: Improve the efficiency of queries with unbound results

Queries that use UNION or OPTIONAL can have unbound columns in the result set. This change improves the way AllegroGraph does joins when there are unbound columns in a result set.

Rfe11756: Improve the chunk processing behavior of ORDER BY and LIMIT queries

The chunk-at-a-time processor automatically reduces the size of the chunks being processed based on the limit (it makes no sense to process a chunk of 500,000 rows if you are only interested in the first one!). In the case of ORDER BY queries, however, it makes sense to keep the larger limit since all of the results must be examined. This is now the case.

Rfe11728: Improve handling of large DISTINCT or ORDERed results

This enhancement improves the efficiency of the on-disk merging operations so that the size of ORDERed or DISTINCT result sets is limited only by disk space and not by available RAM.

Bug21531 - Non-simple EXISTS FILTERs could cause query failure

AllegroGraph was incorrectly processing non-simple graph patterns in an EXISTS or NOT EXISTS FILTER. This meant that queries like 

SELECT * {  
   ...  
   FILTER( EXISTS { ... } ||  
           EXISTS { ... FILTER( ... ) } )  
}

could cause an error rather than being correctly processing. This has been corrected.

Bug21415 - Queries could return invalid solutions

It was possible for solutions with no bindings for some of their variables to escape from the right-hand side of a join. This would cause too many solutions to be returned from the query.

This has been corrected.

Bug21410 - Duplicate suppression not handling deleted triples correctly

AllegroGraph was handling deleted triples improperly when duplicate suppression was enabled. This has been corrected.

Bug21407 - An error in a SELECT expression prevented processing of subsequent ones

An error in a SELECT expression would prevent processing of the rest the expressions in the query for the current solution. For example, depending on the data, in a query like: 

SELECT  
        ?s  
        ?str  
        (STRAFTER(?str,"b"@cy) AS ?abcy)    # could cause a type error  
        (STRAFTER(?str,"ab") AS ?aab)  
WHERE {  
        ?s :str ?str  
}

The evaluation of STRAFTER() with a second argument of "b"@cy could signal a type-error. AllegroGraph was stopping further computation at that point which meant that the binding for ?aab could be left empty when it should not have been.

This has been corrected: now, each expression is computed separately.

Bug21404 - Config file EOL format

Previously, non-unix newlines (CR+LF, LF+CR) in the license section of the config file could prevent the server from starting up. This has been fixed and any mix of Unix, Mac and DOS style newlines is accepted.

Bug21398 - Variables in EXISTS filter could be incorrectly bound

It was possible for variables that appeared only in an EXISTS (or NOT EXISTS) filter to be incorrectly bound during query evaluation which could lead to incorrect results.

This has been corrected.

Bug21390: N-Triples serializer does not handle embedded angle brackets

Even though valid URIs are not allowed to contain embedded angle brackets, it is still possible to add them to a triple-store. For example, the valid N-Triples file: 

<ex://h> <ex://p> <ex://invalid\u003E>

would add a triple whose object is ex://invalid>.

AllegroGraph was serializing such URIs without performing the necessary \u escaping which meant that the data exported could not be re-read by AllegroGraph's parsers.

This has been corrected.

Note that this was only a problem for data with invalid URIs.

Bug21377 - Updates with both DELETE and INSERT

Due to a race condition in a shared backends, updates that involved both DELETE and INSERT could produce bogus results. This bug has been fixed.

Bug21376 - Wrong results with ORDER BY

Due to a rare race, in shared backends, queries with ORDER BY could produce bogus results. This has been fixed.

Bug21367 - Expressions in ORDER BY could cause query failure

Queries with expressions in an ORDER BY could cause query failure during string look up. This bug was introduced in AllegroGraph v4.8 and is now corrected.

Bug21349 - Eager evaluation of boolean FILTERS could lead to failures

If a query used FILTERS consisting of boolean combinations of simpler filters and also used external variable bindings such that some of the FILTER clauses could be evaluated immediately, then it was possible for the FILTER evaluator to signal an error.

This has been corrected.

Note that bug21342 corrected this problem for the simpler case of negation. This bug fixes the more general case.

Bug21345 - Possible problem with BIND inside of an OPTIONAL

If a query included a BIND clause that stood by itself and there was a join, it was possible to lose the value of the binding. In particular, a query like 

SELECT * { ?a ?b ?c . OPTIONAL { bind('hello' as ?x } }

could leave ?x unbound. This has been corrected.

Bug21344 - Bind could fail to use external variable bindings

If a query used the BIND form and the value of the expression depended on variables set via an external binding (e.g., via the with-variables argument in the Lisp API or via HTTP parameters in the HTTP interface), then it was possible for the BIND expression to ignore those values. This has been corrected.

Bug21342 - Eager evaluation in FILTERs can lead to problems using variables

If a query uses a FILTER and also variable bindings such that an expression in the FILTER could be evaluated before actually running the query and if the expression was used in other boolean combinations (e.g., with not, and, or or), then it was possible for AllegroGraph to signal an error. For example, if the query was 

select * { ?a ?b ?c . FILTER( ! bound( ?d )) }

and if ?d was bound using a variable binding, then AllegroGraph would signal an error instead of correctly realizing that the FILTER could never succeed.

This has been corrected.

Bug21341 - Non-simple IF statements could cause an error

It was possible for non-simple IF statements in an expression to lose track of their variables which led to an error at query planning time.

This has been corrected.

Bug21326 - Geospatial query failure

Fixed a bug that, under rare circumstances, caused geospatial queries to fail with bus error.

Bug21325 - Lost results in sub-queries and some joins

When an internal buffer holding intermediate results was grown in a sub-query or in some joins, results could have been lost. This bug has been fixed.

Bug21272 - No results with BIND

Sometimes, as in the query below, instead of no results, a single result was returned when BIND was involved. 

select * {  
  bind('o' as ?c)  
  ?a ?b ?c .  
  ?d ?e ?f .  
  filter( ?a < ?d && ?d < ?a )  
}

This bug has been fixed.

Bug21270 - Sub-queries with ORDER BY can fail to bind results

Depending on the data and what other queries have been evaluated, a query that used an ORDER BY clause in a sub-query could fail to correctly bind the result variables. For example, a query like: 

select ?age {  
  { select ?age {  
        ?who <http://people.example/age> ?age .  
    } order by ?age  
  }  
}

could return results but leave the bindings for ?age unbound.

This has been corrected.

Bug21260: Xpath Constructor Functions fail on strings to numbers

The XPath Constructor Functions should convert typed string literals into the requested numeric type when the value of the string can be so coerced. For example: 

xs:int('2'^^xsd:string) ==> 2

AllegroGraph was raising a type error in this case. This has been corrected.

Bug21256: Parser problem with some queries that mixed aggregation and sub-query

AllegroGraph was incorrectly signaling a parser error on some queries that mixed aggregation and sub-query. For example, 

select (max(?a) as ?foo) {  
  select distinct ?a ?b {  
    ?a a ?c .  
    ?c a ?b .  
  }  
}

This has been corrected.

Bug21245: Allegrograph's turtle parser performs URI normalization incorrectly

Percent encoded URIs should not be unescaped when loading data in the Turtle format. AllegroGraph was incorrectly doing so. This has been corrected.

Bug21243 - Non-QNameable URIs cause turtle serializer error

If a triple contained a URI that could not be expressed as a QName, then the turtle serializer would signal an error that it could not split the URI rather than just emitting the entire URI and continuing. For example, a triple containing the URI would cause this error: 

Cannot split <http://example/> into XML QName.

This has been corrected.

Bug21226: Agload max blank node cache size not obeyed in all cases

Agload could over-allocate memory in a certain case. This has been fixed.

Bug21215 - Improve cursor resource usage of Prolog SELECT queries

AllegroGraph previously closed some of the cursors created while running a Prolog query lazily. It now closes them when the query completes which improves overall resource utilization.

Bug20906 - Remove duplicate triples fails on a store with zero triples

An error would be raised if duplicate deletion was attempted on a store with zero triples.

This has been corrected.

HTTP Client

Rfe11755 - Add support for insert-graph-uri, remove-graph-uri, etc.

Version 6 of the Sesame HTTP Protocol includes several graph parameters that can be used to control the behavior of SPARQL Update statements. These are:

These four parameters are now supported by AllegroGraph

Rfe11743: Add baseURI to the SPARQL HTTP Protocol

The SPARQL HTTP protocol now accepts baseURI as an HTTP query request parameter. This can be used to shorten the rest of a SPARQL query.

Bug21408 - Retrieving JSON statements over HTTP

Fixed a bug that caused the statement list to be truncated when an 'application/json' encoded response was requested via the HTTP protocol.

Bug21280 - Query failures cause spurious errors

AllegroGraph 4.8 modified the internal API used to signal query failures (e.g., due to timeout or memory limits). Unfortunately, the code in the HTTP layer of AllegroGraph was not modified to accommodate the change which led to spurious bus errors when a query failed. This has been corrected.

SPARQL

Rfe11862 - Match default dataset behavior for SPARQL Update and Query

SPARQL Update was using a default dataset that contained only triples with unnamed graphs (the default graph in AllegroGraph terminology) in the FROM portion and put triples with graphs into each of their graphs in the FROM NAMED. This was different from the default dataset for SPARQL Query which put all of the triples into the FROM portion and treated the FROM NAMED portion similarly.

AllegroGraph now uses the same default dataset behavior for both Query and Update. This dataset is as described for query above. Note that this means that an Update command like 

DELETE DATA { <eh://a> <eh://b> <eh://c> }

will delete the triples 

{ <eh://a> <eh://b> <eh://c> }

from every graph in which it appears whereas the previous behavior would have been to delete it only from the default graph.

Note that triples added during an Update command which do not specify a graph will be added to the triple-store's default graph.

Rfe11817 - SPARQL parser should signal an error on badly formed requests

Previously, the SPARQL parser would silently accept nonsense queries like: 

<http://www.foo.com> <http://www.bar.com> 'banana' .

because it would silently ignore tokens that came before the SPARQL prologue (i.e., before PREFIX and BASE) and convert such a query into an empty UPDATE request (i.e., a non-operation).

These queries will now signal a SPARQL parse error. Because the parser is now more strict, some queries that previously parsed may now signal an error. For example, this invalid query was previously accepted and now will not be: 

# WRONG: bad prefix because it ends with a period (".")  
PREFIX ex: <http://example.com> .  
SELECT * { ?s ex:testsFor ?o . }

Rfe11793 - Improve handling of numeric and date literal equality filters

Improve the SPARQL 1.1 query planner's handling of numeric and date literal equality filters. In particular, AllegroGraph will now optimize queries with FILTER clauses like: 

?s ex:p1 ?o .  
FILTER( ?o = 3 )

which would previously have required a scan of all triples with predicate ex:p1.

Rfe11787 - Support SPARQL 1.1 UUID and STRUUID functions

Adds support for the SPARQL 1.1 UUID() and STRUUID() functions.

Rfe11779 - Support SPARQL 1.1 change to in-line data syntax

SPARQL 1.1 recently switched from a syntax for in-line data that used BINDINGS to one that uses VALUES. The standard also made it possible to use in-line data in more places. AllegroGraph now fully supports this feature and passes all of the Data Access Working Group (DAWG) tests for it.

Note that the BINDINGS syntax is still supported in this version of AllegroGraph. It will be deprecated and removed in some future release.

Rfe11757 - Provide select-N strategy for ordered results with small limit

Typically, a SPARQL query with an ORDER BY clause must accumulate all of the results before sorting them. If, however, the query has a small LIMIT, then it can be more efficient to retain the top LIMIT results and only sort those.

Rfe11555: Manage memory used to ensure unique results from CONSTRUCT and UPDATE

The data structures AllegroGraph uses to ensure that results of a SPARQL CONSTRUCT or UPDATE are unique have been modified so that result sets can be processed correctly regardless of size (up to the amount of available disk space).

Bug21401 - SPARQL Update must intern strings from variable bindings

If variable bindings are used in a SPARQL Update query and these bindings are part of the template being used to insert new triples into the store, then the strings from the variable values must be added to the triple-store's string table. This was not being done which could lead to a UPI not in string table error.

This has been corrected.

Bug21391 - Queries against in-memory-triple-stores could return incorrect results

The Lisp SPARQL API allows for the creation of in-memory-triple-stores from CONSTRUCT and DESCRIBE queries. These suffered from a bug such that queries that specified more than two of subject, predicate, object and graph fields could return incorrect triples. As examples, a query like: 

ASK { ex:foo ex:bar ?o }

would work correctly whereas a query like 

ASK { ex:foo ex:bar ex:baz }

could return yes when it should have returned no.

This has been corrected.

Bug21372 - Possible error when requesting sparql-xml output for Prolog select

An error could be signaled if the default query engine was sparql-1.0 and a results format of sparql-xml was requested for a Prolog select query.

This has been corrected.

Bug21371: IF confusion with free variables

SPARQL queries with free variables could produce incorrect results when using IF. For example, the following query 

SELECT ?result {  
  BIND( IF(!bound(?dataType), "first", "second") as ?result)  
}

would return second instead of first. This occurred because the query engine was not correctly analyzing the free variable ?dataType (this variable is free because the query provides not binding for it).

This has been corrected.

Bug21361 - Improve SPARQL BASE URI handling

AllegroGraph was not always correctly merging base and relative URIs. For example, a query like 

BASE <http://localhost:8080/>  
SELECT * { ?a ?b </> }

was being incorrectly run as if it was 

SELECT * { ?a ?b <http://localhost:8080//> }

This and other similar issues have been corrected.

Bug21357 - SPARQL blank-node parsing was too strict

The SPARQL parser was not allowing the full range of blank node names to be used. Thus, queries like: 

SELECT * {  
  ?a ?b _:123 .  
  _:123 ?c _:fv-0 .  
}

would fail to parse correctly. This has been corrected.

Bug21354 - Update STRAFTER() and STRBEFORE() to match changes in the standard

Recent changes to the SPARQL 1.1 standard changed the output of STRAFTER() and STRBEFORE() when no match is found. Previously, they were specified to return an empty literal with language or datatype that matched the first argument. Now they should produce an empty literal with neither language nor datatype. AllegroGraph now matches the standard.

Bug21294 - Sparql XML results for ASK queries missing head clause

The SPARQL XML generated by AllegroGraph was missing the <head/> clause. Since this clause is generally empty, only systems that validate the results against an external DTD were effected by the missing clause.

This has been corrected.

Bug21277 - Improve cursor resource usage of SPARQL 1.1 queries

AllegroGraph previously closed some of the cursors created while running SPARQL 1.1 queries lazily. It now closes them when the query completes which improves overall resource utilization.

Bug21266: Queries with only a geospatial clause could fail to gather solutions

If a SPARQL query contained only a geospatial clause, then the SPARQL 1.1 engine could fail to add the solutions it found to the answer set. This has been corrected.

Bug21249: Incorrect return value of COPY GRAPH TO GRAPH

A SPARQL Update statement like 

COPY DEFAULT TO DEFAULT

should have no effect on the triple-store and should succeed. AllegroGraph implemented the behavior correctly but was returning failure instead of success. This has been corrected.

Bug21239 - Concurrent queries in shared backends

With the sparql-1.1 engine, queries running in the same shared backend concurrently had unexpected interactions that lead to various errors. This has been fixed.

Bug21237: Computations in aggregate expressions could fail

If a complex expression was used inside of a SPARQL aggregation function, the value could be left unbound. A work-around was to express 

(min(2 * ?x) as ?smallestDoubled)

as 

(min(?x) as ?smallest) (2*?x as ?smallestDoubled)

This is now corrected and the work-around is no longer necessary.

Bug21233: SPIN functions could fail when used with constants

SPARQL queries that used SPIN functions could fail if the arguments to the functions were constants not already in a triple-store's string-table. This has been corrected.

Bug21222: Failing SPARQL UPDATE HTTP request should error

Previously SPARQL UPDATE requests that failed would return false in SPARQL/XML format. In order to be better conform with other SPARQL endpoints, AllegroGraph now returns a 412 status code (precondition failed) instead.

Bug21163: Add new default-dataset-behavior: rdf

SPARQL leaves things up to the implementation when no explicit dataset is specified (i.e., when no FROM or FROM NAMED clauses are part of the query). AllegroGraph now provides three choices for dataset behavior:

AllegroGraph's standard behavior continues to be :all. You can change this on a per-query basis using the defaultDatasetBehavior query option: 

PREFIX franzOption_defaultDatasetBehavior: <franz:rdf>

AGWebView

Rfe11910 - Add HTTP handlers for materialization

Added the materializeEntailed service.

A PUT request will materialize entailed triples based on the with, without, useTypeSubproperty, and commit query parameters.

A DELETE request will remove the materialized triples.

Rfe11856 - WebView: new UI Beta for Graph

In WebView next to the Documentation menu is a link to "WebView Beta" a new experimental UI for Query and Graph. A link at the top will returns to the classic WebView.

A link at the top will open the new Graph View UI.

Also Node queries have a View menu in the results to open the node in Graph view.

Administration features of WebView are not yet included within the new UI.

Rfe11676: Webview: in Scripts editor, use CodeMirror JavaScript

The WebView Scripts editor now supports syntax highlighting and indentation by including the CodeMirror JavaScript mode.

rfe11596: WebView: new UI Beta for Query

In WebView next to the Documentation menu is a link to WebView Beta a new experimental User Interface (UI) for Query. The new UI provides a modern style and easier navigation. A link at the top will returns to the classic WebView.

All existing features of WebView Query are implemented:

Administration features of WebView are not yet included within the new UI.

Rfe11582: Webview: upgrade Query Editor to CodeMirror v2.32

The query editor for SPARQL and Prolog, implemented by CodeMirror, has been upgraded from v2.24 to v2.32.

Bug21250: Webview: remove limit from download

The download link for Query results no longer uses the limit parameter in the query UI.

Changes to the Lisp API

Rfe11454: get-triples-list (Lisp API) returns cursor only on request

The Lisp get-triples-list function previously returned the cursor it created as a second value. Now, however, it returns a cursor if either one was passed in initially (using the cursor keyword argument) or if the new keyword argument return-cursor is true.

Bug21381 - (Lisp API) SPARQL introspection functions required engine argument

The functions get-allowed-results-formats and get-allowed-rdf-formats returned nil if no query engine was provided. This has been corrected.

Bug21378 - (Lisp API) sparql-1.1 engine does not implement destination-db

The Lisp API allows SPARQL Update commands to specify the triple-store that they modify. This feature was not included in the sparql-1.1 engine. This has been corrected.

Documentation

No significant changes.

Python Client

Rfe11911: Add materializer calls to python client

Added materializeEntailed and deleteMaterialized calls to RepositoryConnection.

Java Client

Rfe11906 - Java support for the materializer

With this change, the Java client now supports materialization, allowing inferences to be generated and added to a repository in a transactional fashion. See the Javadoc for AGMaterializer#newInstance() to acquire a configurable materializer, and AGRepositoryConnection#materialize to run the materializer.

Rfe11771: Upgrade embedded JavaScript implementation

Fixes several small bugs in the way uploaded JavaScript scripts are interpreted. The most visible one was that the !== operator was acting like the < operator.

Rfe11241 - Support more query/update protocol params

With this change, the Java client now sends HTTP protocol params for update, baseURI, timeout, remove-graph-uri, insert-graph-uri, using-graph-uri, using-named-graph-uri, and logQuery.

AllegroGraph 4.8 user-visible changes

AllegroGraph Server: General Changes

Rfe11711 - Improve cursor resource usage of Geospatial Prolog queries

AllegroGraph previously closed cursors created while running a Prolog geospatial query lazily. It now closes them when the query completes which improves overall resource utilization.

Rfe11653 - Rm requests can be processed out of order

The order in which file management requests were processed caused unexpected errors under heavy load. The bug is now fixed.

Rfe11649 - Manage memory for ORDER BY and DISTINCT queries

Previously AllegroGraph needed to accumulate all results in memory for queries that used DISTINCT or ORDER BY. This could greatly increase the overall memory footprint. AllegroGraph now handles large result sets in available memory.

Rfe11631 - Improve query optimizer when inference is enabled

One part of query optimization is reordering the triple-patterns in each BGP. This reordering is based on the statistics collected by the store and these statistics do not take inference into account. This meant that the plan produced could be quite bad.

This has been corrected by modifying the estimation code to take RDFS++ into account.

Rfe11416 - Provide greater control of query memory usage

Added a memoryLimit query option that controls how much memory a query can use. If a query needs to allocate more memory than this value, it will fail.

Bug21235 - Resource manager sync-files effectively ignores msync errors

If the filesystem on which a database resided filled up during a checkpoint, this fact was logged but the checkpoint process would continue running as if the error didn't happen, which would result in database corruption. This bug has been fixed. Now when a full filesystem is detected during a checkpoint, AllegroGraph stops operating in order to protect committed data.

Bug21224 - Crashes while processing queries with DISTINCT

Under rare circumstances, the internal data structures used while processing DISTINCT queries could get corrupted leading to segmentation faults. This bug has been fixed.

Bug21214 - Correct scope of BINDings introduced on the LHS of union

The binding of a variable on the left-hand side of a UNION should not influence its value on the right-hand side. For example, the following query should produce two rows with ?a bound to 1 in one of them and left unbound in the other. 

select ?a {  
  { bind(1 as ?a) } union { bind(2 as ?b) }  
}

AllegroGraph was retaining the binding on the LHS across to the RHS of the union and so was answering with two rows each of which had ?a bound to 1. This has been corrected.

Bug21187 - Stack exhaustion with shared cursor

With lots of deleted triples a query could run out of stack when creating cursors. This has been fixed.

Bug21182 - Unbound values in distinct aggregrates could lose results

If a variable binding used in a distinct aggregate was unbound, it could cause other aggregrates in the same row to fail to update properly. For example, a query like: 

SELECT (count( distinct ?taste) as ?tasteCount ) (count(?who) as ?whoCount) {  
	   ?who <http://people.example/age> ?age .  
	   OPTIONAL { ?who <http://people.example/taste> ?taste . }  
}

could lose data for the ?whoCount bindings if the ?taste binding from the OPTIONAL was unbound. This has been corrected.

Bug21145 - agload: message corrected for insufficient buffer size

The error message for insufficient ntriples/nquads buffer size was reporting buffer as size -1. This message has been corrected and now reports actual buffer size in order to abate confusion about the condition.

Note: This condition is usually triggered when an ntriple of greater than 4MB is encountered while using the default dispatch strategy.

Bug21136 - Free BGP patterns can lead to very large memory allocation requests

Queries with free patterns (like ?s ?p ?o) in a BGP on the right-hand side of a query could lead the query size estimator to believe that it should reserve a very large space to save the putative result set. For example, a query like 

SELECT ?s WHERE {  
    { ?s ?p ?o }  
    MINUS  
    { ?other ?p ?o . ?other ?someProp ?s }  
}

would lead the query engine to try and allocate 1024-Petabytes. This has been corrected.

Bug21124 - Zero length path between non-matching constants

AllegroGraph was incorrectly finding a path between two different constants which led to queries like the following to return a single (empty) result when they should have returned no results at all. 

select * {  
  ex:one ex:connectsTo{0} ex:two .  
}

This has been corrected. Other zero-length path queries were behaving correctly.

Bug20853 - Updated the soundex algorithm

AllegroGraph's freetext indexing word filter was using an older variant of the Soundex algorithm that did not match the latest version (cf. http://www.archives.gov/research/census/soundex.html). The algorithm has now been updated.

Freetext indexes created with the soundex word-filter should be dropped and re-built.

HTTP Client

Rfe11681 - HTTP: Allow statements queries using the POST method

Add a [store]/statements/query URL that corresponds to /statements, except that it isn't limited to the GET method, and thus can be used to do complex queries without building up overlong URLs.

Rfe11680 - HTTP: Add /unique/[column] service

Add a [store]/unique/[column] URL that allows clients to fetch the set of unique parts that occur in a column in the database, optionally restricting other columns.

SPARQL

Rfe11682 - Improve performance of SPARQL OPTIONAL queries

If a query has the form A OPTIONAL B (where A and B share variables so that it is a join) and the A part has no rows, then it is not necessary to evaluate the B part at all.

The SPARQL 1.1 query engine now recognizes this situation and skips the evaluation of the right-hand side.

Rfe11591 - Modified the Lisp run-sparql API to better handle query failure (e.g., for when a query runs out of time or other system resources).

Previously run-sparql would return (as multiple values):

Now run-sparql returns four values. In normal execution, the first three values are the same and the fourth value will be nil. When a query fails, the results will be:

Code that requests a cursor should be prepared to handle a condition of type db.agraph.query.base:cancel-query-condition.

Rfe11581 - handle repeated Prologues in SPARQL UPDATE queries

SPARQL 1.1 UPDATE allows the Prologue (BASE and PREFIX definitions) to be repeated between each UPDATE command. Previously, AllegroGraph only allowed BASE and PREFIX to be used at the beginning of a SPARQL statement. This is now corrected.

Rfe11559 - Add logQuery parameter to the HTTP SPARQL protocol

SPARQL queries can now use the logQuery parameter in their HTTP requests. The parameter can be set to one of:

The log output can be cryptic; please contact Franz Inc. for support in interpreting the messages.

Bug21220: SPARQL Update LOAD should require only write permission (not eval)

A user would need to have evaluate permission on a triple-store in order to use SPARQL Update's LOAD command to load data from a file. This has been changed so that having write permission is sufficient.

Bug21203 - SPARQL Update insert data fails to treat blank nodes correctly

The INSERT DATA and MODIFY SPARQL Update commands failed to use the small blank node identifier in the INSERT template. This caused multiple blank nodes to be created when there should have been only one.

Bug21192 - Upi not in string table error when mixing BIND, SPARQL Update and FTI

SPARQL Update queries that produced new strings (e.g., using BIND) on a triple-store with free-text indexing turned would lead to UPI not in string table errors. Note that in this case a triple would have been added to the store but its strings would not be added to the string table which could cause subsequent queries to fail until the errant triple was removed.

This has been corrected.

Bug21168 - Support SPARQL 1.1 COUNT(DISTINCT *)

The SPARQL 1.1 query engine was not correctly handling the COUNT(DISTINCT *) form. This has been corrected.

AGWebView

No significant changes.

Changes to the Lisp API

No significant changes.

Documentation

No significant changes.

Python Client

Rfe11697 - Added RepositoryConnection.prepareUpdate

Added RepositoryConnection.prepareUpdate for SPARQL 1.1 Update requests. The call to evaluate on the returned UpdateQuery object returns True or False.

Java Client

Rfe11748 - Upgrade to sesame 2.6.8

With this change, the Java client has been upgraded to use openrdf sesame 2.6.8 jars.

Rfe11243 - Support X.509 authentication

With this change, the Java client now supports X.509 server and client authentication. For set up details, see the javadoc for AGServer.

Bug21225 - With no requestEntity, post using setRequestBody

Previously, AGHTTPClient post method used setQueryString to pass params when there was no requestEntity provided. This burdened the server when a param became very large. Now params are passed using setRequestBody when no requestEntity has been provided.

AllegroGraph 4.7 user-visible changes

AllegroGraph Server: General Changes

Rfe11587 - Change InstanceTimeout defaults

The configure-agraph script now supports instance timeouts in interactive mode and via the --instance-timeout command line option. It defaults to one week.

Also, the default value the InstanceTimeout configuration directive (effective when there is no global or catalog level InstanceTimeout) has been changed from 0 (= disabled) to one hour.

Rfe11536 - Transitive inference queries could be slow

The RDFS++ reasoning for transitive queries could be slower than necessary for some datasets. The code has been reimplemented to be significantly faster.

Rfe11285 - Improve query constraint analysis

AllegroGraph now does a better job of applying filter constraints throughout a query. For example, previous versions of AllegroGraph would not have transformed either of the two BGPs (on either side of UNION) into range queries (which are more efficient). 

SELECT * {  
  ?a ex:d ?c .  
  { ?a ex:b ?c . } UNION { ?a ex:c ?c . }  
  FILTER (?c > 2)  
}

Now it will.

Bug21114 - Instances lingering too long

Instances with non-zero InstanceTimeout only timed out when there was activity involving the service daemon. This has been corrected. Instances with an InstanceTimeout of zero (the default) are not affected.

Bug21094 - Queries against federations could signal UPI-not-in-string-table errors

It was possible for queries against federated triple-stores to lead to UPI-not-in-string-table errors. This has been corrected.

Bug21089 - agload division by 0

Progress reporting failed with division by 0 if the operation completed within 1ms.

Bug21077 - Expressions can be analyzed too eagerly

It was possible for constant expressions to be analyzed to their final values too quickly which could lead to an error if the expressions were used in a BIND. For example, this query would fail: 

select * { bind(str('hello') as ?x }

rather than producing a single binding of ?x to the string hello. This has been corrected.

Bug21069 - A warm-standby client now exits non-zero if error occurs during commit replay

Replication secondary (warm-standby client) now exits non-zero if error occurs during commit replay. This is to ensure transactional behavior in the replica.

Bug21059 - Improve efficiency of all predicates cache when RDFS++ is enabled

The query engine keeps track of the predicates in the triple-store to optimize queries which contain clauses where the predicate position is a variable. If RDFS++ was enabled and the cache was not already fresh, then AllegroGraph would try to find all of the store's predicates with reasoning enabled. Since new predicates cannot be inferred, this could be hugely inefficient. This has been corrected.

Bug21057 - Fix log rotation causing crashes

When the SIGHUP handler closes a log stream, attempts to log could fail with a 'stream closed' error potentially crashing the server. This bug has been fixed.

Bug21040 - Turtle data import should use UTF-8 encoding

The Turtle specification mandates that Turtle files are encoded using UTF-8. AllegroGraph was not enforcing this in all cases which could mangle Unicode data on import. This has been corrected.

Bug21022 - Group expressions with unbound elements could be dropped

AllegroGraph could lose rows in a aggregation query if the GROUP BY expression resulted in unbound columns. This has been corrected.

Bug21008 - Correct XSD datatype for certain division operations

When performing division of two xsd:integers or two xsd:decimals, AllegroGraph was emitting the result as an xsd:float rather than an xsd:decimal. This has been corrected.

Bug21007 - Error creating a session with non-default graph for inferred triples

The syntax for starting a reasoning session that uses a different graph for its inferred triples is 

<store>[rdfs++#<graph>]

AllegroGraph was failing to parse this specification correctly and signaled an error instead. This has now been corrected.

HTTP Client

Rfe11601 - HTTP and WebView: MongoDB interface config

Added resources to HTTP protocol for MongoDB parameters: 

GET /repositories/[name]/mongoParameters  
POST /repositories/[name]/mongoParameters

See Mongo Interface, The HTTP Protocol, GET mongoParameters, and POST mongoParameters.

SPARQL

Rfe11558 - Add query logging support

To add in query debugging and tuning, SPARQL queries using the 1.1 query engine can now be logged to the AllegroGraph log file. To log a query, use the prefix option notation by pre-pending this prefix to your query: 

prefix franzOption_logQuery: <franz:yes>

The log output will go directly to the AllegroGraph log. In this release, the output is relatively cryptic. Please consult with Franz (support@franz.com) to interpret the data.

Rfe11492 - Add support for SPARQL CSV and TSV

Added CSV (comma separated values) and TSV (tab separated values) as native SPARQL output formats. Also corrected problems with using CSV output on result sets with unbound values.

Rfe11486, Rfe11538 - improve SPARQL 1.1 engine geospatial integration

The SPARQL 1.1 query engine did not implement the POINT extension for SPARQL FILTER functions so that queries like: 

SELECT * {  
   ...  
} ORDER BY geo:haversine-km(?loc,POINT(105.842328, 21.0184040))

would fail. This has been corrected. Additionally, the geospatial query analyzer has been improved so that more computations are carried out at query analysis time rather than at query execution time. This can speed up some geospatial queries tremendously.

Bug21117 - Some SPARQL 1.1 path queries could parse incorrectly

The SPARQL 1.1 parser could combine some combinations of alternation and sequences incorrectly. For example, this query 

SELECT ?xxx ?yyy {  
    ?xxx (dc:aaa|dc:bbb/dc:ccc) ?yyy .  
}

would have been parsed as if it read (dc:aaa|dc:bbb|dc:ccc). This has been corrected.

Bug21093 - SPARQL UPDATEs could fail to save newly created strings

If run with chunkProcessingAllowed, a SPARQL UPDATE query that generated new strings could fail to save some of these new strings in the underlying triple-store. This has been corrected.

Bug21082 - Optional cross-product with no bindings could fail

If the final step of a query was a LEFT-JOIN and that LEFT-JOIN was also a cross-product (i.e., the right hand side shared no variables with the left hand side) and the right hand side produced no bindings of its own (e.g., it was all constant or its variables could be elided because they were not used anywhere else in the query), then it was possible for AllegroGraph to incorrectly remove answers. This has been corrected.

Bug21078, bug21083 - Handle sub-query SELECT expresions and filters correctly

SELECT expressions in sub-queries were not being handled correctly by AllegroGraph. This has been corrected so that queries like 

SELECT ?a (?a * 2 as ?b) ?c ?d {  
  BIND(1 as ?a)  
  { SELECT ?c (2* ?c as ?d) {  
    BIND(20 as ?c)  
  } }  
}

now perform properly.

It was also possible for AllegroGraph to incorrectly optimize FILTER expressions in sub-queries that returned all variables (*). This too has been corrected.

Bug21072 - unused variable check could remove variables in EXISTS filters

The SPARQL 1.1 query planner removes variables that are not used in the query from the set of bindings maintained during query execution. Unfortunately, the check to see whether or not a variable was used could fail to properly descend into EXISTS (and NOT EXISTS) filters. For example, the following query would have failed: 

PREFIX :    <http://example/>  
PREFIX  rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#>  
SELECT DISTINCT (?s1 AS ?subset) (?s2 AS ?superset)  
WHERE  
{  
        ?s1 rdf:type :Set .  
        ?s2 rdf:type :Set .  
        ?s1 :member ?x .  
        FILTER ( ?s1 = ?s2 || NOT EXISTS { ?s2 :member ?x . } )  
}

This has been corrected.

Bug21064 - Unneeded graph variables with DISTINCT query could error

If the variable in a GRAPH clause was not needed by the query (because, e.g., the query asks for DISTINCT results and the graph variable is not used anywhere else in the query), then the query planner will remove the variable from the plan. Unfortunately, the query executor could still try to assign a value to the graph variable which would lead to an error at query execution time. This has been corrected.

Bug21046 - Multiple MINUS clauses could lead to query execution error

A SPARQL query with multiple MINUS clauses could cause the SPARQL 1.1 query engine to incorrectly determine the variables on which to join the clauses. For example, this query would fail: 

SELECT (?s1 AS ?subset) (?s2 AS ?superset) {  
    # All pairs of sets  
    ?s2 rdf:type :Set .  
    ?s1 rdf:type :Set .  
 
    MINUS {  
        ?s1 rdf:type :Set .  
        ?s2 rdf:type :Set .  
        # Assumes ?s1 has at least one member  
        ?s1 :member ?x .  
        # If we want to exclude A as a subset of A.  
        # This is not perfect as "?s1 = ?s2" is not a  
        # contents based comparison.  
        FILTER ( ?s1 = ?s2 || NOT EXISTS { ?s2 :member ?x . } )  
    }  
    MINUS {  
        # If we don't want the empty set being a subset of itself.  
        ?s1 rdf:type :Set .  
        ?s2 rdf:type :Set .  
        # Choose the pair (empty set, empty set)  
        FILTER ( NOT EXISTS { ?s1 :member ?y . } )  
        FILTER ( NOT EXISTS { ?s2 :member ?y . } )  
    }  
}

This has been corrected.

Bug21037 - Construct queries with Turtle results format can cause string lookup error

If a SPARQL CONSTRUCT query used expressions to create strings that were not already in the underlying triple-store and if the RDF format requested with Turtle, then a UPI not in string table error could be generated. This has been corrected.

Note that the other RDF formats do not exhibit this behavior.

Bug21031 - Remove unstable optimization

The SPARQL 1.1 query engine attempted to reduce the amount of work needed to evaluate certain joins. Unfortunately, it was possible to create queries that exposed a conflict between this optimization and other optimizations which would lead to an error at query evaluation time. This optimization has been temporarily removed. It will be added again once the conflicts it exposed have been resolved.

Bug21023 - Correct datatype of the seconds() function

The SPARQL 1.1 seconds() function should return a value of type xsd:decimal but AllegroGraph was returning xsd:float. This has been corrected.

The date and time functions (like month() and seconds()) were also not behaving correctly on literals of type xsd:time. This has been corrected.

Bug21019 - Filter EXISTS with fixed triple patterns could fail

If a SPARQL query used FILTER (NOT) EXISTS and the EXISTS clause contained fixed triple-patterns, then AllegroGraph could signal an error. For example, this query would fail: 

SELECT * {  
  ?a a ex:Fruit .  
  FILTER EXISTS { ex:apple a ex:Plant . }  
}

This has been corrected.

Bug21016 - UPDATE with blank nodes could lead to error

A SPARQL UPDATE query that included blank nodes in the INSERT template could lead to an error. This has been corrected.

Bug20994 - Correct (in)equality test between plain and typed literals

Some comparisons between plain literals and typed literals could return false rather than signaling a SPARQL type error. This meant that a FILTER that tested for (in)equality could succeed where it should have failed. This has been corrected.

Bug20840 - Improve comparisons between xsd:dates and xsd:dateTimes

The SPARQL operator mapping table is quite strict in the sort of comparisons that are allowed. AllegroGraph was allowing inequality comparisons between xsd:dates and xsd:dateTimes even though these datatypes are not strictly comparable. These sort of comparisons will now signal a type error leading FILTER conditions to fail. I.e., a query like 

... FILTER ( ?aDate > ?aDateTime ) ...

will now fail (correctly) even though it may have resulted in results previously.

Bug20736 - Federated-triple-stores can fail to find equivalent literals

In SPARQL filters, typed-literal equality is based on the value of the literal, not its lexical form. I.e., these literals are all the same:

To reduce the amount of work during query execution, the SPARQL engine checks to see whether any triples exist with literals of these (encoded) types. This check was being handled incorrectly for federated triple-stores which could lead to answers being left out of federated result sets. This has now been corrected.

Bug20770, Bug21020 - improve SPARQL 1.1 aggregation support

SPARQL 1.1. allows assignment in a GROUP BY clause. For example: 

... GROUP BY (str(?name) as  ?theName) ...

AllegroGraph did not allow for this syntax and required the work-around of: 

... BIND(str(?name) as ?theName) ... } GROUP BY ?theName ...

This omission has been filled.

Secondly, AllegroGraph did not allow aggregate expressions in the HAVING clause or SELECT expression involving more than one aggregate. For example, these queries would fail: 

SELECT (avg(?value) as ?avg) ((min(?value) + max(?value)) / 2 as ?half {  
  ...  
}

and 

SELECT * {  
  ...  
}  
group by ?value  
having(sum(?value) > 20)

Both of these omissions have also been corrected.

Bug20165 - Unnecessary variable in a BIND clause could cause error

If the variable in a BIND clause was not needed by the query (because, e.g., the query asks for DISTINCT results and the variable is not used anywhere else), then the query planner will remove the variable from the plan. Unfortunately, the query executor could still try to assign a value to the variable which would lead to an error at query execution time. This has been corrected.

AGWebView

Rfe11601 - MongoDB interface config

Added support in WebView for setting MongoDB parameters, in the Repository Overview page. See Mongo Interface.

Rfe11557 - WebView: serve doc files

AllegroGraph documentation, a collection of HTML files installed with the server, is now served by WebView, and the Documentation menu in WebView links to these local files in addition to those on www.franz.com.

Rfe11474 - Execute query without changing text

In the Query editor, a query may now be executed without editing the text.

Rfe11398 - Update query editor to CodeMirror v2.24

The query editor for SPARQL and Prolog, implemented by CodeMirror, has been upgraded from v2.15 to v2.24, including javascript and css.

Bug21085 - Webview: Recent queries should not add items redundantly

WebView Recent Queries now keeps the most recently used queries. If a previous query (including the same planner and limit) is repeated, that query is moved to the top of Recent Queries, with the number remaining the same. Limit and planner are displayed on the Recent Queries page.

Bug21062 - Recent queries in multiple browser tabs

Using WebView in multiple tabs of a browser caused a javascript error leading to a blank screen below the menu. This has been fixed by consistently using localStorage.

Note for using multiple browser tabs/windows: the last tab to execute query will overwrite localStorage of "recent queries" that will be seen if a new browser tab is opened.

Bug21050 - WebView: CodeMirror Query editor steals arrow keys

When the cursor is in Query Editor, Alt-LeftArrow and Alt-RightArrow will now perform the default browser behavior instead of navigating within the editor page.

Bug21036 - Editor empty after 40 recent queries

WebView holds up to 40 recent queries, but incorrectly restored the text when more than 40 were made. This is fixed.

Note that logout and login will clear the list of recent queries.

Bug20998 - Webview: failures in IE7

Many links to navigate between WebView pages did not work in Internet Explorer 7 (IE7) due to usage of browser history. In the Query editor page, limit and planner options did not take effect in IE7. These problems have been fixed.

Bug20982 - Query limit and planner selections ignored

In the Query editor screen, the limit and planner selections were ignored. Now, they are both used for Execute and Download. Also, they will remain set after Execute, and following a link from the Recent Queries page will remember these settings for that query (but they are not stored for a Saved Query).

Changes to the Lisp API

Bug21042, Bug21043 - standardize remote-triple-store SPARQL cursors

The cursors returned by run-sparql for remote-triple-stores behaved differently from ones returned for other triple-store classes. In particular, SELECT queries could not request a results-format of :cursor and the rows returned by cursors were lists of bindings rather than arrays of bindings.

The cursors for remote-triple-stores are now standardized to behave in the same way as cursors in the rest of AllegroGraph. This item is repeated above under AllegroGraph Server: General Changes, where it is also pointed out this applies to Lisp clients only.

Bug20067 - Make session ping threads more resilient

Remote clients ping their sessions to keep them from timing out on the server. Intermittent network errors could cause the ping thread to fail. This fix makes pinging attempts continue until the session timeout passes without successful pings.

Documentation

Bug21080 - Doc layout bad in IE intranet-mode

AllegroGraph docs now use html5 doctype and style. For Internet Explorer (IE), the highest mode available will be used because IE7 layout is not optimal.

Python Client

Rfe11244: Python Support for client X.509 certificate authentication

To support X.509 certificate authentication with SSL, AllegroGraphServer objects now have cainfo and sslcert keyword arguments for indicating the client security information. verifyhost and verifypeer can also be used.

These arguments correspond to the pycurl.CAINFO, pycurl.SSLCERT, pycurl.SSLVERIFYHOST, and pycurl.SSLVERIFYPEER settings on the Curl object if you want to read about them in the pycurl documentation for more information.

user and password keyword arguments can be omitted when using certificate authentication.

See src2/franz/openrdf/tests/tests.py's test_ssl for example use.

Java Client

Rfe11523 - Upgrade to Sesame 2.6.5 jars

With this change, the Java client has been updated to use the Sesame 2.6.5 jars.

Rfe11358 - Upgrade Clojure to 1.4.0

The Clojure client API now uses Clojure 1.4.0 and Leiningen 1.7.1.

Bug21099: java pool holds sockets open

Problem: the AGConnPool used one MultiThreadedHttpConnectionManager per AGRepositoryConnection, but only closed it with the pool rather than with the repo. This used multiple connections to the main AGraph port and left http socket connections open for them and a session port after the AGRepositoryConnection was closed. Session ports are not recycled by the AGraph server if SessionPorts is not specified.

Fix: use a SimpleHttpConnectionManager for each AGRepositoryConnection and close both at the same time. This minimizes socket connections and avoids the secondary pool within MultiThreadedHttpConnectionManager.

Bug21092 - Clojure: errors in tutorial

Enhanced repo-federation to work without rcon-args as was used in the tutorial. This fixes tutorial example16.

Enhanced value-factory to work with either Repository or RepositoryConnection. This reduces reflection warnings in the tutorial.

AllegroGraph 4.6 user-visible changes

AllegroGraph Server: General Changes

Rfe11449 - Timeout for database instances

Support has been added for making database instances linger for some amount of time after their last close. This allows for reducing the likelihood that a subsequent access to an otherwise idle database will require a long startup time. The time to linger is determined by the global and per catalog InstanceTimeout directive whose default is 0s.

InstanceTimeout is from the instant the last session or backend that has the store open closes it.

New function ensure-not-lingering of the same argument as open-triple-store.

close-triple-store has a new keyword arg :ensure-not-lingering.

Rfe11445 - Queries with large intermediate result sets could generate segfaults

Queries with very large intermediate result sets could generate segmentation faults. This has been corrected.

Rfe11440 - Remove trailing slash from server URL

With this change, AGServer now removes any trailing slash from the specified server URL. Previously, an errant trailing slash on the server URL resulted in an obscure error message about "No suitable response format available" that was difficult to diagnose.

Rfe11418 - improve efficiency of AllegroGraph's turtle parser

Improved the memory usage and speed of AllegroGraph's turtle parser making it more than twice as fast as previous versions.

Rfe11404 - Optimized opening stores

By reducing inter-process communication latency, opening triple stores has been made significantly faster.

Rfe11177 - Agload --relax-syntax flag

agload now uses --relax-syntax flag instead of --relax-for-btc flag. This flag now allows for underscores and dashes to be used in anonymous node strings for N-Triples and N-Quads. agload is documented in Data Loading.

Rfe11126 - SSL client certificate and CRL support

New https-verification keyword argument to open-triple-store and create-triple-store.

Rfe8881 - Optionally suppress duplicates at commit time

AllegroGraph now has a switch duplicate-suppression-strategy, which will prevent new duplicate triples (both duplicates already in the store, and duplicates within the same commit) from being committed to the store.

Bug20997 - Solve latency issue while starting replication.

Fixed a bug where transaction logs (tlogs) were repeatedly (and unnecessarily) examined when performing replication. Now each tlog is examined once. This results in the time required to be O(n) instead of O(n*n) (that is, time is linear with the number of tlogs rather than increasing by the square of the number of tlogs).

Bug20984: Turtle serializer emitted invalid blank node identifiers

The rdf-n3 (turtle) serializer was emitting blank node identifiers without prefixing them with ":_". This has been corrected.

Bug20981 - Exhausted cursor recycling happens too early

Exhausted cursors were being recycled too early which could sometimes result in program crashes. This has been fixed.

Bug20968 - Improve string dictionary cache performance

When heavily used, AllegroGraph's string dictionary cache could become bogged down in bookkeeping resulting in very poor performance. This change prevents this excessive bookkeeping and provides the expected near-constant cache performance.

Bug20943 - Free text index bug under replication

When a new free-text index was created while replication was enabled, it caused an error in the standby process. This is now fixed.

Bug20913: Xsd date and time coercion functions could signal error

If given invalid input, the type coercion functions for dates, times and dateTimes could signal an error other than a SPARQL type error. This would lead to a query error rather than a filter failure. For example, this query: 

prefix xsd: <http://www.w3.org/2001/XMLSchema#>  
select ?ds ?d {  
  bind( '2012-12-04 is my favorite day' as ?ds )  
  bind( xsd:date(?ds) as ?d )  
}

would signal an error rather than returning a single result for which the binding for ?d is empty.

This has been corrected.

Bug20910 - Queries with variable predicates could lose results

If AllegroGraph finds a query pattern with variable predicates and distinct results (and certain other conditions that are data dependent are also true), then it will optimize the pattern by converting it into an iteration over all of the distinct predicates in the store. A typical query of this form is 

select distinct ?p {  
  ?s a ex:Animal .  
  ?s ?p ?o  
}

Because computing all of the distinct predicates is expensive, AllegroGraph caches this information. Previously, AllegroGraph could fail to update the cache correctly when new triples were added. This could lead to queries returning too few results.

This has been corrected.

Bug20896 - Hang when max chunks for an index reached

As part of their operation, the automatic index optimization processes will sometimes merge some number of input chunks into a single output chunk in order to keep the total chunk count below a certain threshold. However, under some circumstances, some indexes would never undergo the optimization process so this chunk reduction would not occur. Eventually the chunk limit would be reached and the database would hang. This problem has been corrected.

Bug20887 - AllegroGraph XML parsers should not follow external references

AllegroGraph's RDF/XML and TriX parsers could try to follow external references in input files and fail. This has been corrected.

Bug20877 - xs:date could fail on some short plain literals

The xs:date constructor function could fail to correctly create a date if the argument passed to it was a small plain literal. E.g., constructs like 

BIND (xsd:date( concat(str(?date), '-01-01')) as ?begin_date)

could pass a string whose length was less than 10 to the xs:date function and this could lead to the failure.

This has been corrected.

Bug20833 - openFederated should handle remote stores

AllegroGraphServer.openFederated now works on remote stores. Previously it always attempted to open supplied arguments as local stores.

The openFederated API still has some limitations. To open a federated session with all federation minilanguage features such as reasoning and graph filtering, pass a properly formatted spec string to AllegroGraphServer.openSession directly.

Bug20822 - Cascading error can occur if database create/open fails

Previously, if there was an error during database open/create, another error could occur during the cleanup process, obscuring the actual problem. This has been fixed.

Bug20819 - problem with some combinations of multiple OPTIONAL clauses

Some query patterns with OPTIONALs whose left-hand side was empty could lead to incorrect results. An example of a query that could have failed was: 

select distinct ?value ?type ?name {  
  OPTIONAL {  
    ?value <http://example.com#isa> ?type .  
  }  
  OPTIONAL {  
    ?value <http://example.com#name> ?name .  
  }  
  FILTER( REGEX(STR(?name),'Sa') && BOUND(?type) )  
}

This has been corrected.

Bug20814 - Make session urls unique

In order to avoid accidental sharing of sessions, include a unique session id in the session-url. Behind the scenes, what previously looked like http://localhost:55555 is now something like: http://localhost:55555/sessions/7e8df8cd-26b8-26e4-4e83-0015588336ea.

Bug20806 - fix loading of initfile and sitescripts

Initfiles and sitescripts longer than 4096 characters were presented with 4096 character long blocks in reversed order. This bug is now fixed.

Bug20799 - turtle-parser was case sensitive when parsing numbers

AllegroGraph's turtle parser was failing to parse floating point numbers that used an upper-case E before the exponent. This is now corrected.

Bug20793 - RDFS++ queries with free predicate could infer invalid triples

If a query involving RDFS++ reasoning used an unbound predicate, the reasoner could use inverse property reasoning to infer invalid triples. This has been corrected.

Bug20757 - Problems when starting agraph while another agraph is running

Previously if you tried to start AllegroGraph when it was already running, the second start would fail but it would cause the already-running AllegroGraph to stop operating correctly. This has been fixed.

It has always been acceptable to run two or more AllegroGraph servers simultaneously as long as they, at the very least, used different settings for the following parameters in their configuration files:

The operating system already enforced a unique Port setting. This change adds enforcement of unique SettingsDirectory and GlobalShmServerDirectory settings. Therefore some (dangerous) side-by-side AllegroGraph configurations that used to work may no longer start up. An instructive error message will be displayed in this case.

Bug20628 - Changes to warmstandby API

PUT /repositories/[name]/warmstandby

If one attempts to start a replication task that already exists, an http 409 Conflict response will be returned.

Bug20533 - Agload --rapper flag documentation

The --rapper flag is now specified in the group "Other options". Previously it was not given a group in the command line help. agload is documented in Data Loading.

Bug20508 - Remote triple store can't use the RDFS++ reasoner

Added support for apply-rdfs++-reasoner on a remote client triple-store.

HTTP Client

Rfe10812 - Improve http tracing

HttpTrace is now a global configuration directive of the same meaning as the --http-trace command line option. The global directive HttpTraceOptions and the command line option --http-trace-options were added, the value of which is a comma separated list of options. Options starting with the character + turn on the corresponding log category. Those starting with - turn them off. Use the max-message-size= option to truncate overly long messages. The default is +log,max-message-size=1000.

Bug20798 - Improved http error handling

Previously, if the client that was performing an http request died and the backend couldn't transmit the response, then the backend was killed and the request was retried on another backend that also failed because the client socket was closed which wasted resources. The new behavior is to let the backend live on (without retrying), if the error is really from the client side.

SPARQL

Rfe11469: add line number to SPARQL parser error messages

The SPARQL parser will now indicate the line at which an error is encountered. The error message has also been reformatted to make it easier to understand the parsing problem.

Rfe11357 - enhance SPARQL 1.1 engine for changes to standard

The SPARQL 1.1 standards committee recently made several small changes to the standard. To accommodate these, AllegroGraph's SPARQL engine has:

There are several other changes to the standard which AllegroGraph will support in a future release. These include:

For additional information, please see the SPARQL release notes.

Bug20951 - SPARQL could fail to match plain and typed strings

SPARQL specifies that a plain literal (like "hello") is equivalent to a literal with type xsd:string (like "hello"^^xsd:string). The SPARQL 1.1 query engine was failing to provide this entailment in some cases. This has been corrected.

Bug20939 - CLEAR only recognized if it's the first verb

The SPARQL 1.1 UPDATE verb CLEAR was only recognized correctly if it was the first verb in a SPARQL statement. This has been corrected.

Bug20936 - OFFSET 0 and LIMIT did not mix

If a SPARQL query used an explicit OFFSET of zero, the LIMIT would be ignored. I.e., a query like: 

SELECT * { ?a a ex:Animal . }  
LIMIT 10 OFFSET 0

would return all ex:Animals rather than just 10. Leaving the OFFSET off entirely would produce the correct behavior. This has been corrected so that OFFSET 0 is treated as expected.

Bug20912 - Inequality filters could signal an error

Inequality filters in SPARQL queries can be transformed into fast range queries. If a query used a filter like 

FILTER( ?a < 0.0 )

then the SPARQL 1.1 query planner could attempt to decrement an unsigned number below zero which would lead to a segmentation fault.

This has been corrected.

Bug20911 - SPARQL could lose precision on very small numbers

SPARQL numeric conversion routines could treat double-floats and decimals as single-floats which would lose precision. For example, a query with a filter like 

FILTER( ?x > 4.5e-45 )

would have been interpreted as 

FILTER( ?x > 0 )

This has been corrected.

Bug20898 - Complex queries could fail on federated triple-stores

Because of the way statistics were calculated on federated triple-stores, SPARQL queries with many clauses in a basic graph pattern (BGP) could fail when the query engine attempted to re-order them. This has been corrected.

Bug20891 - Improve SPARQL comparator selection

SPARQL specifies difference comparison operations depending on the type of the things being compared. The SPARQL 1.1 query engine could select the wrong operation if both the left and right hand sides were variables. This has been corrected.

Bug20884: improve Lisp client remote-triple-store SPARQL interface

The remote-triple-store implementation of the Lisp client was unable to execute SPARQL queries with non-trivial filter clauses. This has been fixed. (Repeated in the Lisp API section below.)

Bug20867: REPLACE function in SPARQL 1.1 used incorrect syntax for matches

The SPARQL 1.1 REPLACE function was implemented using a different syntax for pattern replacement than that specified by the standard. Replacements are now correctly specified using the $<number> syntax.

Bug20863 - Some SPARQL XSD numeric computations could fail

Depending on the datatypes of the numbers involved, it was possible for a SPARQL numeric computation to signal a type error rather than correctly returning a value. This has been corrected.

Bug20859 - Some filter combinations could cancel each other out

If a SPARQL query used IN (or several FILTERS like ?uri = constant) and if there were other filters on variables that overlapped with the variables in the IN construct, then it was possible for AllegroGraph to lose track of the additional filters in some circumstances. This happened due to two separate query optimizations handling the filters inconsistently. This problem has been corrected.

Bug20852 - remote-triple-store and SPARQL UPDATE don't mix

The Lisp remote-triple-store client could signal an error after evaluating a SPARQL UPDATE statement. The UPDATE would occur but the result would be mis-interpreted and signal an error. This has been corrected.

Bug20851 - SPARQL FILTERs could be too strict

Certain combinations of triple patterns in a BGP and FILTERs could cause AllegroGraph to misapply the FILTERs. For example, depending on the underlying triple-store, this query 

SELECT ?first_film ?actor ?second_film {  
  ?first_film dbpp:starring dbpr:Jack_Black , ?actor .  
  ?second_film dbpp:starring dbpr:Joan_Cusack , ?actor .  
  FILTER ( ?actor != dbpr:Joan_Cusack )  
  FILTER ( ?second_film != ?first_film )  
  FILTER ( ?actor != dbpr:Jack_Black )  
}

could have misapplied the ?actor filter and produced fewer results than expected.

This has been corrected.

Bug20838 - SPARQL CONSTRUCT queries could fail for large result sets

Due to limitations in the internal mechanisms used to keep track of intermediate results, SPARQL CONSTRUCT queries that returned more than 100,000 rows would cause a segmentation fault. This has been corrected.

Bug20830 - Some inequalities could use the wrong comparisons

Some SPARQL 1.1 queries could select the wrong comparison code when comparing two variable clauses with either >= or <=. This could lead to incorrect results. This has been fixed.

Bug20821 - EXISTS or NOT EXISTS and additional filters did not mix

The new SPARQL 1.1 EXISTS and NOT EXISTS filters failed to parse correctly when combined with other FILTER clauses. This has been fixed.

Bug20805 - encodeforuri could produce incorrect results

The SPARQL 1.1 encode_for_uri could produce incorrect results for some UNICODE characters. This has been corrected.

AGWebView

Rfe10885 - Setting duplicate suppression from AGWebView

Added "Suppress duplicate statements" feature to the repository overview page. This sets the duplicate-suppression-strategy switch, which can be set to prevent new duplicate triples (both duplicates already in the store, and duplicates within the same commit) from being committed to the store.

Bug20996 - Webview: js error creating a new repo

This fixes a javascript error when creating a repository from the Catalog page.

Bug20993 - Webview: Internet Explorer (IE) compatibility mode

AGWebView now includes an HTML meta header for IE9 so that IE9 will use its documentMode instead of IE7 compatibility. Also tested with IE8.

Also using html5 doctype to get standards mode in all browsers.

Bug20963 - Fix session url in AGWebView

URLs for sessions are changed in Bug20814 (described under AllegroGraph Server: General Changes above). This fixes AGWebView and changes the url for its use of sessions to include the uuid.

Bug20894 - AGWebView not working with ie9 on intranet

When connecting to AGWebView on an intranet site IE may automatically use Compatibility Mode. A syntax error causes it to only display the "Loading" message and not continue. Work-around is to use a full url, or otherwise not use compatibility mode. The syntax error is now fixed so an intranet does not cause the error.

Bug20843 - AGWebView sometimes clears the editor

The execute button would clear the query editor (and the results area). This happened when the same query had been executed sometime before in the same browser followed by logout/login. The browser history mechanism had not been fully cleared. Recent queries are cleared after logout. This is now fixed.

Changes to the Lisp API

Bug20884: improve Lisp client remote-triple-store SPARQL interface

The remote-triple-store implementation of the Lisp client was unable to execute SPARQL queries with non-trivial filter clauses. This has been fixed. (Repeated in the SPARQL section above.)

Bug20883: improve the Lisp client's remote-triple-store caching interface

The Lisp client's remote-triple-store implementation did not support the spogi-cache-enabled-p or spogi-cache-size methods. This has been corrected.

Bug20185 - Remote lisp client used wrong value for restriction reasoning

For a remote reasoning store, this method used the wrong string internally, leading to an error when a query was made: 

(setf (restriction-reasoning-enabled-p *db*) t)

For a remote reasoning store, this method enabled restriction reasoning if the key :restriction-reasoning-enabled was present regardless of the key's value. Now respects t or nil. 

(apply-rdfs++-reasoner :restriction-reasoning-enabled nil)

Documentation

No significant changes.

Python Client

Rfe11313 - Remove export*, use response capture

RepositoryConnection.export and exportStatements have been deprecated. They used client side serialization of statements that was buggy and not up to spec. The functionality has been replaced with a way to capture server responses of any supported mime type.

A new context manager function on RepositoryConnection is called saveResponse, and can be used as follows: 

with open('out', 'w') as response:  
    with conn.saveResponse(response, 'application/rdf+xml'):  
        # The server response is written to response  
        conn.getStatements(None, None, None)

You can reference the function testsaveresponse in src2/franz/openrdf/tests/tests.py for examples.

Java Client

Rfe11493 - Support writing N-Quads from an AGModel

With this change, the Jena adapter now supports writing to N-Quads via AGModel.write(out, "N-QUADS").

Rfe11438 - Provide N-Quads parser/writer META-INF/services in agraph.jar

With this change, the agraph.jar now provides N-Quads implementations for org.openrdf.rio.RDFParserFactory and org.openrdf.rio.RDFWriterFactory in META-INF/services (Sesame doesn't yet provide N-Quads implementations).

Rfe11436 - Add Sesame 2.6.2 src jar

With this change, the openrdf-sesame-2.6.2-onejar-src.jar has been added to eclipse project classpaths (repo and distribution) for convenience.

Rfe11397 - Support RepositoryFactory and Repository configuration

With this change, the Java client now supports Sesame's RepositoryFactory api and Repository configuration from RDF data. See javadoc for the new com.franz.agraph.repository.config package for details.

Rfe11240 - Support user/role management

With this change, AllegroGraph superusers can now dynamically manage users and roles. See the AGServer javadoc for details.

Rfe11230 - Support masquerading as another user

With this change, an AllegroGraph superuser can now masquerade as another user when issuing requests. See the javadoc for AGRepositoryConnection#setMasqueradeAsUser for details.

Bug20946 - IE javascript error in Mold: innerHTML is null

Work-around: the error dialog can be dismissed and the search results are still displayed. Fixed.

Bug20811 - Allow prolog queries from javascript

To run javascript the user must have the "execute arbitrary code" permission which should be enough to run prolog queries too. The bug that was fixed prevented the user from running prolog queries from javascript.

See Change History for user-visible changes to earlier releases.