This document lists all changes in the current release, which is 8.0.1. This release has some internal changes but no user-visible changes, so this document is just a repeat of the v8.0.0 release notes.

See the Recent Release Notes documents for the release notes for versions 7.3.1/7.3.0 and some earlier releases (as said above, 8.0.0 changes are described in this document).

Change History repeats the list of user-visible modifications for this release and includes similar lists for all earlier releases.

Release 8.0.0

Release 8.0.0 is a major release with many significant new features as well as bug fixes and enhancements.

New in Release 8.0.0

Release 8.0.0 is a major release with important new features.

Database internal format is unchanged from version the previous version (7.3.1)

Release 6.4.6 had a different internal format. All releases since then have the same internal format. This means version 6.5.0 through 7.3.1 repositories can be directly loaded into version 8.0.0 without upgrading. Note that backing up repositories before loading them into a new version is always recommended. Once a database has been used in a later release, it cannot be used in an earlier release regardless of whether or not the database format is the same. Upgrading is discussed in the Repository Upgrading document.

Version 8.0.0 Admin notes

This sections notes changes which may affect AllegroGraph administration, which includes managing users, dealing with passwords, and so on.

Version 8.0.0 Programmer notes

This section notes changes which may affect how certain code or operations work compared to earlier releases. These are emphasized here because the changes may be unexpected. The complete list of user-visible changes below also mentions these changes in a shorter format.

Version 8.0.0 user visible changes

This section lists changes in the current release. See the Change History for a list of changes in all earlier releases.

AllegroGraph Server: General Changes

Some changes to install-agraph

You run the install-agraph program to install the tar file distribution of AllegroGraph. Relative pathnames are now supported and there are new arguments including --help (describe how the program works), --license-file (specify a file containing the AllegroGraph license saving you from having to edit the config file after creation) and --super-password (actually not new but now works more intuitively) and --super-password-file (the latter in particular allowing you to avoid entering the password in the transcript which might be visible to others).

Users will be logged out after 30 minutes of idle time

Logging back in will return to the state when the logout occurred. If you have multiple browser tabs open to AllegroGraph, all will be logged out and logged back in simultaneously.

Two new AuthPolicy values external-token and token-external

See AuthPolicy in the Server Configuration and Control document.

Further allowed abbreviations of server specs

Now allowed are:

user:password@ meaning user:password@127.1:10035 user:password@:1234 meaning user:password@127.1:1234

127.1 is the same as localhost. 10035 is the default port number which is used unless another port is specified. See the Repository Specification document where server specs and associated repository specs are discussed.

Some changes when configuring AllegroGraph

User password is by default handled within AllegroGraph, but users may wish to use some external authentication via LDAP in order to authorize users. In that case supplying passwords within AllegroGraph is neither necessary or desired. During installation if using the install-agraph script, supplying a blank superuser password can be accepted but only after confirming you wish to disable password authentication:

SuperUser account password: [user simply enters Return]  
Password can't be blank!  
Would you like to disable authentication via password?:  
[n]: y 

Also the default instance timeout is now 1 hour (3600 seconds).

Exiting shared backend processes

Shared Backend processes (not session backend processes) will now exit if they are haven't been used for the last ten minutes. This will free up system resources and allow repos to close if the only reason they are open is that a backend process has them open. See the agraph.cfg parameter BackendMaxIdle to control how long a backend must be idle before it is eliminated.

SHACL now allows specifying all graphs

Previously you could specify default or a list of graphs. Now all also works for specifying the union of all graphs in the triple-store. This works with:

Text starting with a # is a comment in agraph.cfg

Previously, # had to be the first character of a line to make the following text a comment. Now everything after # on a line is a comment regardless of where the # appears. So the line

Auditing no   # may enable if needed 

suppresses auditing and ignores # may enable later.

Names of Fedshard shards now end in .fshard

The Fedshard utility (see the Fedshard-def document) requires that names or shard repos end in .shard, in part to distinguish them from normal repos. Some users may have used earlier experimental versions of Fedshard available in earlier releases where that was not a requirement. They must change names to conform with the new specification.

Backing up settings now backs up attributes data

See the description of backing up settings in Repository Backup and Restore.

Rfe17027: Add delete-duplicate-triples and get-dupliate-triples support to agtool

Duplicate triples can now be obtained with agtool get-duplicate-triples ... and deleted using agtool delete-duplicate-triples .... See agtool.

Bug26968: Occasional segmentation faults when using user attributes

User attributes could cause segmentation faults on repositories that used advanced features like reasoning or security filters. This has been fixed.

Bug26926 - Bogus results produces by joins on optional variables

When joining on a variable that is bound in some results and unbound in others, like the variable ?x3 in the following query

SELECT ?x0 ?x1 ?x2 ?x3 ?x4 {  
  ?x0 :pred1 ?x1 .  
  ?x0 :pred2 ?x2 .  
  OPTIONAL { ?x0 :pred3 ?x3 }  
  OPTIONAL { ?x3 :pred4 ?x4 }  

the correct behavior for the rows where ?x3 is unbound is to compute a cross-product of the triples with predicate :pred4. Due to a bug in the internal join machinery, AllegroGraph computed cross-products for incorrect rows instead, producing bogus results. This has been fixed.

Bug26397 - login failures caused by AGWebView tabs of different versions

WebView login used to fail when there were multiple browser tabs with different WebView versions. This has been fixed.

HTTP Client

Rfe17140 - support prefixed names in HTTP API endpoints accepting parts

Many HTTP API endpoints taking triple parts as arguments used to only allow complete IRIs to denote resources. This is no longer the case and now prefixed names like rdf:type are also allowed, but only if the given namespace is defined in that context (e.g. only server-level namespaces are used for security filters, while user namespaces are used for API calls <repository>/statements; see Namespaces hierarchy for more details).

Rfe17040 Add RedirectHTTPOnHTTPS AG directive

When set, HTTP requests sent to the AG SSLPORT will result in a 301 Moved Permanently response with the location set to the HTTPS version of the URL.


Single quotes work like double quotes to designate strings in GraphQL

Strings in GraphQL can be written 'foo' as well as "foo". Also '''string''' is supported just like """string"""

This is an AllegroGraph extension to the GraphQL spec. See the GraphQL document.

New configuration and query options for query caching

The query option allowCachingResults can cause query results (unaffected by LIMIT or OFFSET) to be cached so running the same query repeatedly (perhaps with different OFFSETs and LIMITs) can simply access the chached results. New configuration options QueryResultsCacheSize and QueryResultsCacheStorageSize allow specifying the maximum number of query caches and space used by query caching or to disable cahcing altogether.

Rfe17214 - Opt-in unification of owl:sameAs duplicates in SPARQL queries

If multiple items are declared owl:sameAs, you may wish only one returned in response to a query. This can be done with the new query option unifyOwlSameAsDuplicates. See its documentation in the SPARQL Reference for further details and an example.

Rfe17183 - support for owl:SymmetricProperty in materializer

The materializer now supports OWL 2 prp-symp (owl:SymmetricProperty) axiom as called for by the dynamic RDFS++ reasoner. (It was not supported in earlier versions of the materializer.)

Rfe16975 - Use the same default base URI for all backends/sessions

A base URI for the SPARQL query can be supplied via one of the two query parameters (uri or baseURI), but if neither is present, AllegroGraph falls back to using the URL of the query request itself. This could result in different base URIs for different SPARQL query invocations, because the request URL would contain a port of the actual AllegroGraph backend or session that was handling the request, for example the following query

SELECT ?v { VALUES ?v { <> <v0> </v1> <#v2> } } 

would return

| v                                                  |  
|           |  
|             |  
|                          |  
|        | 

when run through the main port on the repository test and

| v                                                  |  
|              |  
|                |  
|                         |  
|           | 

when run through a session (actual UUID replaced with a placeholder).

Staring with AG v8.0.0, the default base URI is defined as


for queries handled by backends and sessions that wrap a single concrete triple store and


for all other sessions. For example the query above will now return

| v                                                  |  
|    |  
|        |  
|                          |  
| | 

for backends and sessions wrapping a single concrete triple stores, and

| v                                                  |  
|                      |  
|                          |  
|                          |  
|                   | 

for all other sessions.

Rfe16328: Warn about unknown constants in SPARQL DESCRIBE clauses

AllegroGraph used to be silent about non-existent IRIs in the DESCRIBE clauses of simple SPARQL DESCRIBE queries like the following

DESCRIBE <http://non-existent/resource> 

This has been changed and now, just as for SELECT queries, an unknown-constants query warning is included in the response.

Bug27048 - query parsing failures with aggregates and outer VALUES

SPARQL queries containing both aggregates and a VALUES clause after the WHERE clause, like

SELECT (COUNT(?o) AS ?count)  
WHERE { ?s ?p ?o }  
VALUES ?s { <> } 

used to fail during parsing. This has been fixed.

Bug27090 - SPARQL SERVICE calls do not follow HTTP redirects

SPARQL SERVICE calls used to only perform a single HTTP request and fail if a redirect response was received. This has been fixed and HTTP calls in SERVICE clauses now follow redirects up to 5 times.

Bug26880 - Saved queries HTTP API ignores uri/baseURI arguments

When using session's saved queries API to save a named query that contains a relative IRI, it was impossible to supply a base URI via the uri/baseURI query arguments, as they would be ignored and the operation would fail with something like


The only way to supply a base URI was through the BASE declaration in the query itself. This has been fixed and the uri/baseURI parameters now work as expected.

Bug26772: Obscure errors in patterns with repeated variables on MJQE

When using MJQE, if a query contains a pattern with repeating variables or blank nodes, and either a VALUES clause that injects bindings into that pattern, for example

SELECT * {  
  VALUES ?o { :o1 :o2 }  
  ?a ?a ?o.  

or a numerical range FILTER clause on one of the variables in that pattern, for example

SELECT * {  
  ?a ?a ?o.  
  FILTER (?o > 10)  

it might fail with an incomprehensible error. This has been fixed.

Bug26675: Possible incorrect bindings order in SPARQL solutions

Queries with OPTIONAL clauses in rare cases can return solutions with wrong binding order. For example, the following rather synthetic query

PREFIX : <>  
SELECT ?p ?o {  
  VALUES ?g { :g0 }  
  VALUES ?b { :b }  
  GRAPH ?g {  
    :a :next ?b.  
    ?b :next ?c.  
    OPTIONAL { ?c ?p ?o }  

could return a solution with values for variables ?p and ?o switched. This has been fixed.

Bug25697 - Wrong results with OPTIONAL clauses sharing a variable

SPARQL queries that perform a join on variable that might be unbound, like, for example, variable ?x2 in the following query

SELECT ?x0 ?x1 ?x2 {  
  ?x0 <> ?x1 .            # 1  
  OPTIONAL { ?x1 <> ?x2 } # 2  
  OPTIONAL { ?x2 <> ?x3 } # 3  

might return incorrect results, because patterns (2) and (3) get inlined into BGP (1) during optimization, but the proper join is not introduced, which results in a cross product between patterns (2) and (3). This optimization can turned off by setting

PREFIX franzOption_inlineSingleBGPOptionals: <franz:no> 

but the query might still return incorrect results due to bug26926. Both issues have been fixed.

Changes to the Lisp API

No significant changes.


No significant changes.


No significant changes other than new files for new features.

Distributed AllegroGraph

No significant changes.

User-visible changes in earlier releases

See Release Notes for Recent Versions for changes in recent release and Change History for user-visible changes to all earlier releases.