- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 04 May 2005 16:22:40 +0100
- To: public-rdf-dawg-comments@w3.org
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