Introduction
See the general release-notes document for links to release notes for other recent releases and the current release.
This document has the release notes for versions 8.0.0.. There were no user-visible changes in version 8.0.1 (just internal changes).
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.
Full support for RDF-star semantics (see RDF-star document).
New implementation of AGWebView. This new interface is now the default. The traditional AGWebView is still supported. Click on Traditional WebView in the menu on the left side of the New WebView page and traditional AGWebView will appear in a new browser tab.
New within AllegroGraph method of specifying what triples a user (or role) can access using triple attributes (see the Triple Security document.
Support for Large Language Models and vector databases (see Large Language Models (LLM) and Vector Databases). See also LLM Examples where there are many examples using LLM to create and process text on specific topics and a large example where a body of work is read and stored in vector files which can be used for Retrieval Augmented Generation. Two APIs are supported: OpenAI and SerpApi.
A new distributed database system, FedShard, is introduced. See Fedshard. The older
Distributed Repositories Using Shards and Federation Setup still exists but will in time be deprecated.
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.
The agtool program, included with the AllegroGraph distribution, is also available as a separate download and can be run on any x86-64 Linux machine (same download location as the AllegroGraph downloads). If you want to have agtool available on machines other than the one where AllegroGraph is installed, use the separately downloaded version as it comes with all necessary additional files needed to run agtool. See agtool for installation instructions.
Support for specifying which users (and roles) can view which triples. AllegroGraph has for some time allowed using attributes to restrict access to triples by selected users, but this required SPARQL queries to be processed using a preprocessor which added the correct prefix to queries. These prefixes specified user attribute values. Users themselves could not directly query the AllegroGraph server as that would allow them to bypass restrictions. In 8.0.0, control has been moved within the AllegroGraph server and users can be assigned attribute values which, combined with triple attribute values, will determine whether the user can or cannot access specific triples.
There is a new version of AGWebView. As with traditional WebView adminstration can be managed using the new version. Both the new and traditional versions are supported.
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.
The tutorials/ subdirectory moved to github tutorials location in the Franzinc agraph-example github repository. This directory used to be included in the distribution. We moved it so that it is accessible to users without access to distribution files and also so tutorial examples can be improved (or fixed) more easily.
Audit events: an audit event is only generated by the
/webview/login
handler when authenticating with "Authorization" header, since cookie-authorized requests to it are used as "Are we still authorized?" checks.New AGWebView implementation. There is a new implementation of AGWebView. The old implementation is still supported and indeed is what comes up when you initiate AGWebView. The new implementation is described in the New ACWebView document.
An LLM playground is provided in the New WebView. The playground is initiated with just a single click (once certain adminstrative details have been taken care of), and it makes it simple to experiment with LLM queries.
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:[email protected]:10035 user:password@:1234 meaning user:[email protected]: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 external authentication in order to authorize users. In that case supplying passwords within AllegroGraph is neither necessary or desired, unless MMR is used, which still requires passwords for communication between servers. 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:
- HTTP [repo]/validate/shacl - dataGraph and shapesGraph args
- Lisp shacl-validate - :data-graphs and :shapes-graphs keyword args
- agtool shacl-validate -
--data-graph
and--shapes-graph
options - SPARQL Magic Properties - dataGraph and shapesGraph args
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.
SPARQL and GRAPHQL
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 |
|----------------------------------------------------|
| http://127.0.0.1:40123/repositories/test |
| http://127.0.0.1:40123/repositories/v0 |
| http://127.0.0.1:40123/v1 |
| http://127.0.0.1:40123/repositories/test#v2 |
when run through the main port on the repository test
and
| v |
|----------------------------------------------------|
| https://127.0.0.1:50456/sessions/UUID |
| https://127.0.0.1:50456/sessions/v0 |
| https://127.0.0.1:50456/v1 |
| https://127.0.0.1:50456/sessions/UUID#v2 |
when run through a session (actual UUID replaced with a placeholder).
Staring with AG v8.0.0, the default base URI is defined as
http://<host>:<port>/[catalogs/<cat>/]repositories/<repo>/sparql
for queries handled by backends and sessions that wrap a single concrete triple store and
http://<host>:<port>/sparql
for all other sessions. For example the query above will now return
| v |
|----------------------------------------------------|
| http://127.0.0.1:10035/repositories/test/sparql |
| http://127.0.0.1:10035/repositories/test/v0 |
| http://127.0.0.1:10035/v1 |
| http://127.0.0.1:10035/repositories/test/sparql#v2 |
for backends and sessions wrapping a single concrete triple stores, and
| v |
|----------------------------------------------------|
| http://127.0.0.1:10035/sparql |
| http://127.0.0.1:10035/v0 |
| http://127.0.0.1:10035/v1 |
| http://127.0.0.1:10035/sparql#v2 |
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 { <http://example.org/s0> }
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
MALFORMED QUERY: No base URI for URI ...
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 : <http://example.org/>
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 <http://example.org/p1> ?x1 . # 1
OPTIONAL { ?x1 <http://example.org/p2> ?x2 } # 2
OPTIONAL { ?x2 <http://example.org/p3> ?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.
Prolog
No significant changes.
Documentation
No significant changes other than new files for new features.
Distributed AllegroGraph
No significant changes.
User-visible changes in earlier releases and the current release
See the general release-notes document for links to release notes for other recent releases and the current release. See Change History for user-visible changes to all earlier releases.