SPARQL Release Notes | AllegroGraph 9.0.1
Author: Franz Incorporated

Copyright (c) 2005 - 2026 Franz, Incorporated
Last updated 27 May 2026 at 10:34

# Notes on AllegroGraph's conformance to the W3C specifications

- Documentation Index
  - Release Notes
  - Quick Start
  - SSL/TLS Quick Start
  - Introduction
  - Setup and Configuration
    - Download
    - Server Installation
    - Server Configuration and Control
    - WebView
    - Database Upgrading
    - Managing Users
  - Server Management
    - Performance Tuning
    - Deleting Duplicate Triples
    - Purging Deleted Triples
    - Auditing
    - Managing Users
    - Replication
    - Point-in-Time Recovery
    - Transaction Log Archiving
    - Security Overview
    - Security Implementation
  - Tools
    - agtool
    - Data Loading
    - Data Export
    - Backup and Restore
    - Querying
    - RDFS++
    - Materializer
    - Event Scheduler
    - SHACL
  - Details
    - Triple Indices
    - Freetext Indices
    - Encoded IDs
    - Connection Pooling
    - N-dimensional Geospatial Overview
    - 2-D Geospatial
    - Temporal
    - Social Network
    - JavaScript
    - Datatypes
    - Data Conversion (Rapper)
    - Stored Procedures
    - Triple Attributes
    - Lineparse Format
  - Querying
    - SPARQL documentation summary
    - SPARQL Reference
    - SPIN
    - SPARQL Magic Properties
    - Prolog
  - 3rd-party tools
    - Solr text Indices
    - MongoDB integration
    - TopBraid Composer Plugin
    - Cloudera
  - Client APIs
    - Gruff
    - GraphTalker
    - REST/HTTP interface
    - HTTP reference
    - Javadocs (Sesame and Jena)
    - Python API
    - Lisp Reference
    - JavaScript
  - Tutorials
    - N-dimensional Geospatial
    - SPARQL Tutorial
    - Java Sesame
    - Java Jena
    - Python Sesame
    - Lisp
    - Prolog
    - More...
  - Other
    - Conferences and Seminars
    - Source Code on Github
    - Amazon EC2
    - Copyrights
  - Franz, Inc.

- Introduction
- Clarifications and deviations
- Other points of note

Documentation Index

## Introduction

There are a few areas where the SPARQL specification is unclear or has changed, necessitating a clarification of AllegroGraph's behavior. The purpose of this document is to detail each of these areas.

## Clarifications and deviations

- Blank node labels in SPARQL are scoped to their enclosing basic graph pattern. It is an error to reference the same blank node label outside of that basic graph pattern. AllegroGraph does not signal an error in this circumstance: you are responsible for ensuring that the rules around blank node labels are followed. For example, against the following triples:

      rdf:type rdf:type rdfs:Property .
      rdf:type rdf:foo "foo" .
      rdfs:Property rdf:foo "bar" .

This query:

    SELECT ?foo {
      { _:x a ?type }
      { _:x ?p ?foo }
    }

will return the following results:

    <?xml version="1.0"?>
    <sparql xmlns="http://www.w3.org/2005/sparql-results#">
      <head>
        <variable name="foo"/>
      </head>
      <results ordered="false" distinct="false">
        <result>
          <binding name="foo">
            <uri>http://www.w3.org/2000/01/rdf-schema#Property</uri>
          </binding>
        </result>
        <result>
          <binding name="foo">
            <literal>foo</literal>
          </binding>
        </result>
      </results>
    </sparql>

The correct behavior here is for an error to be signaled. If an error is not signaled, each use of `_:x` should regardless represent a different blank node, which is not the case. You might find that the provided behavior is more useful.

## Other points of note

- There is an outstanding SPARQL issue regarding the semantics of unbound variables in `OPTIONAL`, described here. This has not yet been addressed by the DAWG.

  AllegroGraph will behave as follows:

      PREFIX ex: <http://example.org/>
      SELECT ?s
      FROM <data.rdf>
      WHERE {
        OPTIONAL { ex:a ex:b ?s }
      }

→ one result, { s : unbound }.

    PREFIX ex: <http://example.org/>
    SELECT ?s
    FROM <data.rdf>
    WHERE {
      OPTIONAL { ex:a ex:b ?s }
      FILTER BOUND(?s)
    }

→ no results.

The reasoning is that the main body of the expression, including the optional, produces one result, in which `?s` is not bound. The querier obviously wishes to remove all results in which `?s` has no value, so AllegroGraph discards that result.

- Similarly, the behavior of a SPARQL engine when an unbound variable is passed to a filter expression is not precisely defined. The document states that all arguments (apart from, obviously, those to `BOUND`) must be RDF terms, which suggests that it is an error to pass an unbound variable.

- It is important to note that the empty graph pattern matches any graph. This manifests itself in the production of one completely empty result, if no other patterns apply.

- There is no prohibition in the specification on the matching of literals by blank nodes in the query pattern. In this respect, blank nodes behave exactly like variables with the exception that they cannot be part of the results bindings.

Reports of any unusual or incorrect behavior are welcome.