Re: Notes on value testing 11.1

On Wed, Apr 13, 2005 at 05:29:18PM +0100, Seaborne, Andy wrote:
> 
> I went through section 11.1 with a view to implementing.  These are some 
> thing I came across. rq23 v1.298
> 
> 	Andy
> 
> 11.1 "may come from the instance data" confused me.  Where else might it 
> come
> from (at an RDF level?).

obselete misconception that it could come from a PSVI.
gone

> 11.1 xsd:dateTime is an exact point in time so the software is not between
> 19:00 and 19:01 (all other dates and times are durations - I pretty sure
> dateTime is not)
> 
> Not clear where "software upgrade" comes from anyway - the data didn't
> suggest it to me

gone

> Going straight into casting in 11.1 - bit of a shock to the reader!

wiggled stuff around a bit. maybe a little better.

> End 11.1 "r:" is not defined

+ and types of RDF terms with the prefix r:

> 11.1.1 Example "xs:integer(7)+xs:float(6.5)" ...
> 
> Seems to mix casting and promotion in one example.  Might be worth steping
> through one example in detail.

+FILTER xsd:dateTime(?date) < xsd:dateTime("2005-01-01T00:00Z")
ensures they've seen casting by this point.

> The list above does not have xs:integer in it so there is another rule
> being applied as well (not yet mentioned) about xs:integer => xs:decimal

~s/integer/decimal/

> 11.1.1 Cast of r:Literal : I got lost here : is an explicit case needed?
> Seems to say not, because xs:integer(7) is truned in to xs:float(7)
> automatically but I wasn't sure.

Turfed until later. will attack through test cases. worried about
whether ?x => "a", ?y => "a", ?x = ?y is sufficiently defined. I guess
it shoudl reflect XQuery's treatment of untyped atomic. Howard?

Good heaves, I'll be happy when I resolve this issue.

> I suggest writing "7"^^xsd:integer if you mean the typed value, not a cast
> of soemthing.

ooo, good idea

> Suggest distinguish explict and implicit "casting" or reserve casting for
> explicit casts (e.g. xs:integer("7") ) Whichever, it will need to agree
> with 11.1 discussion of casting.

I think [[
In summary: each of the numeric types is promoted to any type higher
in the above list when used as an argument to function expecting that
higher type. When an argument is promoted, the value is cast to the
expected type.
]] works for the former.

> This seems to be at odds with the "11th hour proposal" DT-0 which I took to
> mean no implicit casting.

Yeah, forget that one.

> "Any r:Literal can be cast ... " - does that mean that
>   "3" + 5
> 
> is legal (I have no view here but its worth noting) - an explicit example
> would be useful here if it is legal

turfed.

> 11.2 -- 3rd bullet -- says "or" .  Is that the syntax?  It's || later on.

||

> 11.2.1. "Set of arguments" -- list of arguments might be clearer as they
> are ordered.

true, and an argument can be repeated.

> Effective Boolean Value in 11.2 is a forward reference unless the reader
> knows F&O

forward reference now manifests in printed version

> Table: A!=B is defined as not(A=B) (closed world assumption) that caused
> some debate in BOS

+Some of the operators are associate with nested function expressions,
e.g. fn:not(op:numeric-equal(A, B)). Note that per the xpath
definitions, fn:not and op:numeric-equal return an error if their
argument is an error.

> If any RDF literal xcan be cast implicitly, then from the table, there seem
> to be 2 ways to determine "03" = "3"
>   1/ Numeric-equals so "03" => value 3 and it's true.
>   2/ RDFterm-equals so "03" is a string, and is not equal to a string "3"
> 
> Somewhere I missed why that isn't a problem.

turfed

> REGEX has become MATCHES : when did this happen?  The grammar has REGEX as
> per WG discussion after F2F-BOS.  No problems - but I need to know which.
> 
> (Observation: REGEX is clearly not a LIKE thingy, that MATCHES mightimply)

s/MATCHES/REGEX/g

> 11.2.3.1.
> 
> "Semantically equivalent" - is that different to value equal?

yeah, that was a stupid choice of words. it just tests to see if
things are the same node OR falls back to the other equivilance
operators. The challenge here is finding the handling of A = B
that is most natural for the user.

Use cases:
	bindings		same	type-specific
    ?x		?y		node	equivilence
    <foo>	<foo>		1	error
    _:a		_:a		1	error
    "123"	"123"		1	error
    "123"^^int	"123"^^int	1	1  =(int, int)
    "123"^^int	"123"^^float	0	1  =(float, float)
    "11:01"^^dt	"11:01"^^dt	1	1  =(dateTime, dateTime)

Constructing a literal creates the same node as if it were encountered
in the RDF graph. Thus
  ?x => "123"^^int, '?x = "123"^^int' tests true for same node.
Proof: we count on that in graph patterns ala '?s ?p "123"^^int' .

'<' and '>' are easier so long as we don't provide ordering operators
for RDF terms; they have only type-specific comparison functions.

> What if two URIs are owl:sameAs?

I don't think owl:sameAs asserts that its args are the same term. I
bet jjc could offer some insight.

> Second example invokes xsd:dateTime-equal surely?  How does it relate to
> the RDFterm-equal?

If I were to get buy-in on, and sufficiently explain the above
table, would that clarify this point?/usr/sbin/dhcpd eth1

> 11.2.3.2 : Typo in data "04::04Z" => "04:04Z"

~

> Earlier dateTimes don't have the seconds - are they required?  I thought
> they are all required and seconds are a decimal

~ normalized

> What's the data for the second example of 11.2.3.2?
> If it as before, then Bob has a foaf:givenName, not a foaf:name
~
> 11.2.3.4 : results table has 2 columns but query has three variables in
> SELECT
~
> Uses foaf:given -- earlier it was foaf:givenName (which is the right one, I
> think).  Similarly, foaf:family
> 
> The text (last line of 11.2.3.4) talks about foaf:knows but the example
> uses dc:creator for the isBlank() check
> 
> 
> 11.2.3.6 Earlier it says that STR() applied to rdf:literal but here it only
> mentions r:URI.
> 
> 11.2.3.8 Datatype fails (error? false?) on a plain literal.  This might be
> somewhat confusing.  Suggest returns something (xs:string?)
> 
> The example tests for xsd:float but the results have the integer data
> item.  Did it need a != ??
~
-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.