Previous topic  Top  Next topic  Print this Topic

Standard Conformance



Implicit REDUCED mode: Using optimized evaluation strategies, an early elimination of duplicates is important. Therefore per default all SPARQL queries operate in REDUCED mode. This might also affect the selection part of CONSTRUCT and DESCRIBE queries.
Lexical literal value matching: As described in RDF Compatibility only the values, but not their original lexical representations are stored. Resulting queries for literals like "0001"^^xsd:integer will always be translated to "1" of type xsd:int.
Handling of unbound variables: This feature of SPARQL logic is implemented using a special NULL constant which represents an unbound variable. In combination with UNION patterns, a variable might be "actually bound" with NULL, which could prevent some of the valid solutions found outside the UNION pattern.
Default graph: In OntoBroker RDF also the default graph is labeled by an identifier (obl:reserved:defaultModule).
Namespace prefixes: Those definitions are only supported for a limited Unicode range (characters below 0x0300).
Blank nodes in WHERE clause: If explicitly named blank nodes are used in WHERE clause they are matched against those blank nodes in the store – and do not act as variables. If the standard W3C semantics are required, either an anonymous blank node or a variable has to be used.

OPTIONAL and UNION patterns

Multiple OPTIONAL patterns may decrease the overall query performance.
For limitations on UNION have a look at section General/Handling of unbound variables.

Expressions for FILTER and ORDER

Locality of filter expressions: The locality principle of filter expressions for variable bindings is not supported. Instead variable bindings are globally visible on all levels of nested structures.
Implementation of ternary logic: SPARQL filter expressions are based on ternary logic, which extends the boolean logic by the value 'error'. Inside OntoBroker RDF the mapping to horn logic enforces a "compatibility mode" where the value 'error' is mapped to 'false'. While most of the filter expressions work as expected, the result will differ especially for negation of errors (in SPARQL a negation of an error is an error, where in OntoBroker RDF the negation of false will be true).
Comparison of Boolean sub-expressions, such as (?a < 3) > (4 != ?b) is not supported.
XSD type casts are implemented for xsd:string, xsd:boolean, xsd:date, xsd:time, xsd:dateTime, xsd:duration, as well as the supported numeric values xsd:decimal, xsd:long, xsd:integer, xsd:int, xsd:double. For the numeric conversions, please consider OntoBroker's implementation of the RDF data model.
Extended date/time support: For convenience date/time values are already taken into consideration in compare operations.
Queries using filter expressions accessing variables (not only in the current graph pattern) may not be evaluated bottom-up. Please choose an alternative evaluation method such as Dynamic Filtering instead.


Order expressions: Only expressions not returning Boolean values are supported.


Construction patterns using blank nodes are memory-intensive and should only be used for small to medium result sets.
Solution modifiers will operate on the result graph, not on the intermediate query results. See DESCRIBE below for details and use cases.

DESCRIBE queries

As it is up to the SPARQL query processor to define descriptions, OntoBroker will describe every resource by all associated properties, i.e. statements with the resources to describe in subject position.
Solution modifiers for DESCRIBE like ordering are ignored. Using LIMIT and OFFSET modifiers the resulting graph will be sliced, but due to missing sorting the actual selection might be arbitrary. However, LIMIT could be used to restrict the resulting graph to a maximum number of statements, for example, for protection from denial-of-service attacks which might use queries with low selectivity to return large result sets.

Update operations

The SPARQL Update implementation is based on the current SPARQL Update W3C draft (14 October 2010), using the SPARQL 1.0 Query definition for the where-clauses. Minor differences in comparison to the W3C examples and grammar are explained in the following lines.
BASE and PREFIX definitions allowed at the beginning of an operation sequence and shared among the operations, and subsequent operation-local prefix definitions are not expected.