[Fwd: Comments on section 11, Testing Values]

Forwarded comments
The original email has not appeared.

-------- Forwarded Message --------
From: Richard Cyganiak <richard.cyganiak at hp.com>
To: public-rdf-dawg-comments@w3.org
Subject: Comments on section 11, Testing Values
Date: Tue, 03 May 2005 20:58:20 +0100

Comments on
http://www.w3.org/2001/sw/DataAccess/rq23/
regarding section 11 on Testing Values:


11 Testing Values

The paragraph

| A significant of RDF data has untyped literals. Literals may be
| cast to typed literals to use the SPARQL operators.

would benefit from one more word, and from a link to Table 11.2.

The use of namespaces and prefixes in the whole section 11 is somewhat
confusing. Some prefixes are used only in the spec, but not in actual
queries (fn:, op:, sop:). An expansion is provided for fn:, but not for
op: and sop:. Both xs: and xsd: are used. No expansion is provided for
the r in the r:URIRef and r:Literal casts; is it builtin?

The "Namespaces" subsection of 11.1 should clarify all this, but
doesn't. It "declares" op: twice.



11.1 Operand Data Types

The identifiers for RDF terms are used inconsistently. In 11.1, they are
called r:URI and r:Literal. In Table 11.1, we have rdf:uri and
rdf:literal. In Table 11.2 it's r:URIRef and r:Literal.


On casting:

| In addition, any r:Literal may be cast to xs:string or xs:numeric
| when used as an argument to an operator expecting that type.

To me, the meaning of the sentence is unclear. Can the processor
implicitly convert the types when necessary, or does it mean the query
author can use casting functions to manually do the conversion? If the
latter, the sentence should be removed as it is confusing in the context
of automatic type promotions.

The assertion that "any r:Literal may be cast to xs:numeric" is
misleading since the operation might result in a type error.



11.2 SPARQL Functions and Operators

The section fails to define how to deal with unbound variables. Type
error for all ops/functions except BOUND()?

The terminology around type errors could be more consistent. Are there
other kinds of errors relevant to SPARQL? 11.2.1 and Table 11.1 talk
just of "errors", 11.2.3.8 uses "fails".



Table 11.1 Operator Mapping

The argument of sop:str is given as "rdf:uri or rdf:literal" in the
table, but as r:URI in section 11.2.3.6.

The arguments of BOUND(), isURI(), isBLANK() and isLITERAL() are of type
"variable". This looks arbitrary to me; why not r:term? This could
remove a small implementation burden. Also, the grammar contradicts the
operator table by allowing any expression for the isFOO() functions, but
only Var for BOUND().

The REGEX link in the operator table links to the wrong grammar rule
(should be #rCallExpression).

The operator table states that the pattern and flag arguments of REGEX
are xs:string. This implicitly allows any expression that generates an
xs:string, while the grammar restricts them to constant strings only.



11.2.3.7 on sop:lang: What is returned for plain literals without a
language tag?


11.2.3.8 on sop:datatype states:

| Returns the datatype of its argument if that argument is a
| typed literal. Otherwise it fails.

Having sop:datatype return an unbound value for plain literals would let
me distinguish plain and typed literals, which would be quite useful:

    FILTER BOUND(DATATYPE(?x))
    FILTER !BOUND(DATATYPE(?x))



Table 11.2 SPARQL Casting Functions

r:Literal seems to refer to plain literals only here, but to any literal
in 11.1.

The table states that xs:string can be casted to r:Literal for some
values only. Which values?

Other literals or URIs cannot be casted to r:Literal. I think that's a
valid choice, but a note on the reasoning behind the decision would be
appropriate in the spec.

SPARQL has the STR() function and the r:Literal() cast, which seems
redundant to me.

I would like to see a definite list of all casting functions, (including
STR()?), in one place. This would be quite helpful. Table 11.2 comes
close, but has the wrong narrative. Basically it says:

| SPARQL imports some casting functions from XPath. Here's a list
| of them, and we've also added some additional ones. (Implication:
| More casting functions might be hidden in other parts of the spec.)

I would like it to say:

| Here's a list and table of all casting functions available in
| SPARQL. Some come from XPath, some are defined by SPARQL.

Maybe it's possible to integrate the automatic conversions (type
promotion and effective boolean value) in the table?



11.3 Extensible Value Testing

I think the community would benefit from a clear name for those
externally-defined functions. I never know what to call them. User
functions? Extension functions? Custom functions?


About the return type of extension functions:

| These are provided by functions in the query that return true or
| false for their arguments.

So the return type must be xsd:boolean? Later:

| A function returns an RDF term.

And one of the examples returns a number. This looks like a
contradiction to me.


Can extension functions generate type errors?

Can extension functions generate other types of errors (e.g.
my:squareRoot(-1))?

Can extension functions generate unbound values?

The grammar requires one or more arguments for all function calls.
Relaxing this to zero or more would be useful for cases like this:

    FILTER ?date > system:now()
    FILTER ?owner = system:user()

Received on Wednesday, 4 May 2005 15:23:37 UTC