Re: Datatyping Summary

On Wed, 2002-01-30 at 03:38, Jeremy Carroll wrote:
> 
> [More on query also a substantial clarification of why I "can't live with"
> S-B. It encourages unsafe type processing within the application layer].
> 
> Lets look at the example query first:
> 
> [[[
>    _:f <dc:Title> "10" .
>    <mary> <age> "10" .
> 
> Given a query:
> 
>    (?x <dc:Title> ?y) & (?z <age> ?y)
> 
> existing applications will return:
> 
>    ?x = _:f, ?y = "10", ?z = <mary>
> 
> ]]]
> 
> RDF Query is of course, still an active research area, rather than one where
> there is any stable deployed code base. (There is deployed code, but it is
> in development).
> 
> Hence, discussion about query semantics would perhaps be better placed on
> rdf-query, but ...

Not so... The query above is clearly analagous
to an entailment test; i.e. it's clearly within the scope of our
model theory spec, and soon to be in scope of our test cases spec.


> Under S-B (the relevant idiom here) and RDF M&S, the only possible meaning
> of whether two literal nodes are equal is whether their labels are equal.
> 
> Suppose RDF M&S and S-B are read untidily then each distinct triple with a
> literal as object has a distinct literal as object. There is no mechanism
> for indicating that two literals are the same or different except by their
> label.
> 
> Since the query is asking us to compare two literal nodes, under S-B or RDF
> M&S there is only one possibility, compare their labels. Both the new
> (untidy) model theory and TDL suggest a second possibility, that of
> comparing the values associated with the literal nodes. Neither rule out the
> old possibility, they simply permit a new possibility. It is deceptive to
> suggest something is not backwardly compatible simply because it offers a
> better alternative, while allowing the old deprecated approach.

I disagree; I think it is sneaky. I don't think you can have it
both ways.
But reasonable people may disagree...
I have asked the community what they think...
[grumble... my message hasn't made it to the archive yet; stay tuned for

From: 	Dan Connolly <connolly@w3.org>
To: 	RDF Interest <www-rdf-interest@w3.org>, RDF Logic
<www-rdf-logic@w3.org>
Subject: 	how does existing RDF software handle this datatypes test?
Date: 	30 Jan 2002 11:03:59 -0600
]


[...]
> This could all happen in response to dispatching node equality method on the
> basis of the type of the nodes being compared, and on the presence or not of
> a backwards compatibility flag.

Er... as Bill the Cat would say, Ack! barf! phtphtphtpt.

> This framework allows me to illustrate an aspect of my "can't live" issue
> with S-B.
[...]
> Brian, I would be very much obliged if you can condense this example to add
> to your summary list of concrete "can't live with" issues on the proposals.
> My title would be "S-B encourages logically errors in the application type
> processing."

I can sympathize with this view. It seems pretty analagous to a
preference for a type system like scheme (or even ML?) over something
like perl. But while it's very easy to write buggy programs with
perl, you must admit that there are lots of reliable perl programs
out there. Back to RDF: I agree that S-B gives folks enough
rope to hang themselves. But I don't see it as a showstopper.
I think there will be some problems, but I think there will
also be lots of successful use of S-B.

> PS. Sergey attacked Patrick's list of "can't live with" issues as largely
> advocacy of TDL; I do tend to feel that an aspect of "can't live with" is
> comparative. Logical errors happen, no framework prevents all logical
> errors. Choosing a framework that is logically unsafe when an alternative
> safe framework is available is folly.

By that argument, anyone who choses C over Java commits folly.
I think there's a time and a place for each.

But... hang on... S-B isn't any less safe than perl. Perl is
safe, in the traditional sense of programming language safety:
that is: any perl program
either executes per the language semantics or halts; it
can't go off in the weeds due to array-out-of-bounds problems.
Likewise, S-B doesn't specify unsound reasoning or require
that folks contradict themselves in order to get work done.
Perl and S-B are sort of "sloppy", compared to scheme or ML
or whatever, but they're not unsafe.

> However, modifications to S-B that
> assisted the application to make logically safe type inferences would be a
> substantial improvement that would address one of my major concerns.
> 
> 
> 
> Jeremy
> 
> 
> [1]Jeremy Carroll: Re: Datatyping Summary
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Jan/0369.html
> 
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Wednesday, 30 January 2002 14:40:14 UTC