- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Sat, 30 Jun 2012 13:57:32 +0100
- To: public-rdf-dawg-comments@w3.org
Peter, This is a a change-in-progress, the tests and the editors' working draft have been updated. http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml notes a change since second last call: [[ Non-matching return in STRBEFORE and STRAFTER changed to be the empty simple literal always. ]] Details: http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#func-strbefore http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#func-strafter > STRBEFORE("日本語"@ja,”s”) = ”” > What’s the correct response? No match - now returns the empty string, without lang tag. > STRAFTER(“abc”,””) = “abc” > STRAFTER(“abc”@en,””) = “abc”@en > STRAFTER(“abc”^^xsd:string,””) = “abc”^^xsd:string The empty string matches at the start. > However, this contradicts the specification, which states that the > result should be an empty string if arg2 is the empty string. The editors working draft currently says that the empty string is considered to be a match at teh end for STRAFTER, returning arg1. I hope this answers your comment - I would be be grateful if you would confirm this with a reply to this list. Andy On 28/06/12 21:03, Peter Waher wrote: > Hello > > Perhaps you’ve already discussed this in previous messages, or corrected > it somehow. I just wanted to point it out, and/or receive your thoughts > about the matter: > > http://www.w3.org/TR/sparql11-query/#func-strbefore > > To me, there seem to be two inconsistencies between the specification > and the conformance tests: > > The first is how STRBEFORE() or STRAFTER() handles the case of language > literals in first parameter, and the second parameter not found. There’s > also no example showing how to interpret this, and the tests interpret > it differently for the two functions: > > According to the *strbefore01a* conformance test (which is declared as > Not Classified), > > STRBEFORE("日本語"@ja,”s”) = ”” > > (i.e. a simple literal with the empty string, without language tag). > This violates this statement in the specification: “The function returns > a literal of the same kind (simple literal, plain literal same language > tag, xsd:string) as the first argument |arg1|.”. > > Later in the text, it states that if the string is not found, it should > only return an “empty string”, without stating if this means a simple > literal, overriding the previous statement that it should be of the same > type as arg1. Then it re-uses the phrase “empty string” again: “If the > lexical form of |arg2|is the empty string, the lexical form of the > result is the emprty string.”. In this case, the specification shows > that “empty string” in this case is not a simple literal, but a literal > of the same type as arg1 (as shown in the typed literal example following.). > > What’s the correct response? A simple literal (regardless of type of > arg1)? Or an empty string of the same type as arg1? > > The second inconsistence, this time in the specification (the test is > the logical one here), is *strafter02 *(also Not Classified). Here: > > STRAFTER(“abc”,””) = “abc” > > STRAFTER(“abc”@en,””) = “abc”@en > > STRAFTER(“abc”^^xsd:string,””) = “abc”^^xsd:string > > However, this contradicts the specification, which states that the > result should be an empty string if arg2 is the empty string. However, > the logical response is to return the entire string again. In this way > CONCAT(STRBEFORE(?s,?x),STRAFTER(?s,?x)) would return ?s with the first > occurrence of ?x removed, even if ?x is the empty string. > > Thanks for your time, > > Sincerely, > > Peter Waher >
Received on Saturday, 30 June 2012 12:58:02 UTC