Template:DesignQL

From SPARQL Working Group
Jump to: navigation, search


This template is a suggested format for describing changed and new query language features. The sections are the basic units that are present in the SPARQL/2008 recommendation.

Formal use of symbols and definitions as in the style of the current document is helpful but it is better to describe in text than not describe. The formalization can happen later.

Or: design early - design often. Get some material done and leave other sections 'To Be Done'.

Status, To Do's

Brief notes as to what done, what's in progress and what need deciding.

Definition and scope of feature

Language description of the feature and approach; description, not justification. Identify what it is, and also what it is not.

Syntax

Changes the the grammar. Examples are also useful here and in the defintion.

Grammar rules. Examples are always useful. See A.8 Grammar in SPARQL/2008.

Algebra operator

Describe algebra operators introduced. This is the definition of the operation together with it's evaluation.

See 12.4 SPARQL Algebra and 12.5 Evaluation Semantics

SPARQL evaluation is strict evaluation and in applicative order - in other words, logically, the arguments to a algebra operation are evaluated then the operator called on the results. Implementations often improve on this but must obtain the same results of this naive evaluation.

Mapping from AST to algebra

How do we get from the syntax (Abstract Syntax Tree) to the algebra expression. Often trivial but consider potential interactions with elements in groups (which get joined together) and Basic Graph Patterns and filter migration (filters act as is done after the BGP regards of where in a BGP they are written).

12.2 SPARQL Query.

Test Cases

Finally, test cases. These are also useful in discussing a feature. A test case is a some data, a query and it's results. Can happen after the design settles but can be useful in discussions of different designs or of exactly what a design means.