Design:FunctionLibrary

Status, To Do's

The overall rationale of this feature is to pick/add only widely uses/implemented/demanded functions and operators to the ones already supported in [SPARQL/Query 1.0]. The basis for newly added functions shall be provided by XQuery 1.0 and XPath 2.0 Functions and Operators.

Issues:

• shall we allow n-ary plus/minus, e.g. A + B + C, ie. sparql:plus(A, B, C)
• commas or whitespaces to separate operands? e.g. ex:operator(A, B) vs. ex:operator(A B) (so far we allow/use only commas)
• namespace prefix for sparqlfn:
• aggregate functions (MIN, MAX, AVG, COUNT, SUM, plus extensibility by custon aggregates?) not (yet) covered here
• shall all supported core operators get a sparqlfn: URI (and this namespace prefix be allowed to be dropped) or shall we just reuse e.g. the fn: namespace

(there is no namespace for op:) or reuse e.g. RIF's func: and pred: namespaces

ARQ and Glitter use the same namespace for fn: and op: (<http://www.w3.org/2005/xpath-functions#>)

Definition and scope of feature

This feature

• extends the set of Operators defined in [SPARQL/Query 1.0], Section 11.3
• gives URLs to all existing operators

Scope

See also Leigh Dodds's survey.

• A minimal approach would be to add from XQuery 1.0 and XPath 2.0 Functions and Operators
  • string operations, being the most requested,
  • some widely supported numeric functions not yet present in SPARQL.
• As for supporting functions and operatorsfor other datatypes [RIF-DTB] has a fairly comprehensive list of the most important functions and operators for datatypes supported in RIF and OWL2.
• Some more that have been mentioned in discussions and being thought useful, but aren't covered in XPqrg:
  • functions/predicates to convert between URIRefs and strings, BNODES and strings?
  • COALESCE,IF (available in SQL99), cf. Andy's mail
  • getNamespace, getLocalName: e.g. "Get me all triples using foaf: properties?", e.g. Jena's qnameFor, getLocalName(), getNameSpace()

Decided by TF to be beyond scope:

• fulltext-search functions

Syntax & Semantics

All Operators in SPARQL can be called by their URI using a standard functional syntax (prefix-notation with parentheses), some operators support prefix or infix shortcut notation. Each Operator is mapped to a function depending on the operand Types. Different arities for the same operator are allowed, e.g. sparql:plus

To be completed, further functions cf. http://www.w3.org/2009/sparql/wiki/Feature:FunctionLibrary#Starting_Points

XQuery 1.0 and XPath 2.0 Functions and Operators

SPARQL already uses operations from XQuery 1.0 and XPath 2.0 Functions and Operators

Things marked (()) are already in SPARQL as operator symbols.

A minimal approach would be to add the string operations, being the most requested.

((Already:
       6.2.1 op:numeric-add
       6.2.2 op:numeric-subtract
       6.2.3 op:numeric-multiply
       6.2.4 op:numeric-divide
       6.2.5 op:numeric-integer-divide
       6.2.6 op:numeric-mod
       6.2.7 op:numeric-unary-plus
       6.2.8 op:numeric-unary-minus
   6.3 Comparison Operators on Numeric Values
       6.3.1 op:numeric-equal
       6.3.2 op:numeric-less-than
       6.3.3 op:numeric-greater-than
))
   6.4 Functions on Numeric Values
       6.4.1 fn:abs
       6.4.2 fn:ceiling
       6.4.3 fn:floor
       6.4.4 fn:round
       6.4.5 fn:round-half-to-even
((    7.3.2 fn:compare))
       7.4.1 fn:concat
       7.4.3 fn:substring
       7.4.4 fn:string-length
       7.4.7 fn:upper-case
       7.4.8 fn:lower-case
       7.5.1 fn:contains     (collation form optional)
       7.5.2 fn:starts-with
       7.5.3 fn:ends-with
((
       9.2.1 op:boolean-equal
       9.2.2 op:boolean-less-than
       9.2.3 op:boolean-greater-than
       9.3.1 fn:not
))

Without requiring support for xsd:date:

((
       10.4.6 op:dateTime-equal
       10.4.7 op:dateTime-less-than
       10.4.8 op:dateTime-greater-than
))        

Maybe:

       10.5.7 fn:year-from-dateTime
       10.5.8 fn:month-from-dateTime
       10.5.9 fn:day-from-dateTime
       10.5.10 fn:hours-from-dateTime
       10.5.11 fn:minutes-from-dateTime
       10.5.12 fn:seconds-from-dateTime
       10.5.13 fn:timezone-from-dateTime

SPARQL specific

Constructors of RDF terms are mostly missing from SPARQL 1.0:

IRI(string) -> IRI
BNODE() -> fresh blank node
BNODE(string) -> same blank node as other use of BNODE(string)
LITERAL(str) -> 
LITERAL(str, IRI) ->
LITERAL(str, string) ->

LITERAL(str, IRI) is a dyanamic case unlike xsd:integer("1") where the datatype is fixed at parse time. Could be CAST(str, IRI).

LITERAL(str, string) (create literal with languag etag) is visually similar to LITERAL(str, IRI) and SPARQL functions are dynamically typed. An easy mistake to make is LITERAL(str, ?var) where ?var is expected to be an IRI but is in fact a string. A different name for the casting and language tag literals would be better.

LITLANG(str, string)

Another possibility is dynamic function invokation - the function IRI to call may be in a variable.

?function(?arg1, ?arg2, ....)

or via a specific keyword.

CALL(?function, ?arg1, ?arg2, ....)

?function is a URI of the function to call with the rest of the argument list as arguments.

These should also all have IRIs, as should the existing operators (e.g. sameTerm).

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.