Re: Punning, typed vocabulary, and handling RDF graphs (and ISSUE-65)

On 10 Jan 2008, at 00:59, Jim Hendler wrote:

> Bijan - just a quick response with a half-baked thought, but I  
> don't have time to bake it and don't want to lose it.
>
> If I type the equation
>  X = a - b x c
> it would be ambiguous, except that math comes with a set of  
> precedence rules, so the multiply comes before the subtract --  
> thmath has survived for a pretty long time using this idea and I  
> haven't seen a lot of complaints about lack of interoperability  
> between calculators

First, it *can* be ambiguous...try typing that in order into the  
dashboard widget calculator :)

However, that's not the issue. What are the *types* of the variables?  
(or the coefficents even)? Are the integers? rationals? algebraic  
reals? reals? algebraic numbers? complex numbers? Doubles?

Consider the following equation:

(1)	x*x = 2

is this:
(2)	x^^xsd:integer * x^^xsd:integer = 2^^xsd:integer?

If so, then it is *unsatisfable*, i.e., has *no answer*. Same for  
rational. (there is an real, irrational answer, of course). But note

What if it *approximated* the answer into the integers? What would be  
a good approximation? 1? (but then we'd have 1= 2) 2? then we'd have  
4=2. Rounding errors suck.

So you say, "always coerce to the reals!" That might sorta work,  
except that the *explicitly* typed:
(3)	x^^xsd:integer * x^^xsd:integer = 4^^xsd:integer

Is well behaved. How do I know that I should coerce x * x = 4 to (3)  
but (1) to (2)? It doesn't seem statically determinable. And absent  
user input, I don't know whether they *meant* (2).

But in this case I have a syntax for the untyped *and* the typed  
version. The problem with ISSUE-65 is that we *need* extra vocabulary  
(or my syntax trick) in order to be able to overide the default  
coercion.

> I am wondering if there is not something similar we could do (maybe  
> as part of Alan's document on how DL processors should handle non- 
> DL inputs).  If we got things mostly right, I suspect we could make  
> it so DL reasoners would generate a "warning" but still produce an  
> answer (and all produce the same answer) without making these  
> declarations mandatory  (i.e. in math I can break the precendence  
> by inserting an override like X = (a - b) x c )
>
> so the typing vocabulary would enter the language for when it was  
> needed, but most naturally occuring RDF graphs would not cause the  
> problem, and there would be a standard way to solve things

Ah, yes. This is my thought too. But that means we should resolve  
ISSUE-65 in favor of the extra vocabulary. I guess I should have read  
all the way through before replying :)

Oops, no it doesn't. If my alternative serialization works, then we  
don't even need the extra vocab at the cost of uglier to write. Meh.

> I know it would take some work to work this out, but might be worth  
> doing as it would meet a need that, strangely, you and I both agree  
> on, which is, as you say, to handle more RDF graph

This has been a strong, explicit motivation in OWL 1.1 from the first  
OWLED. We phrased it as "closing the gap between OWL DL and OWL Full"  
but I realize now that I don't care about that per se. I care more  
about "sensible" *interoperable* handling of RDF graphs people are  
likely to write down. This is why punning, in principle, even though  
it misses some OWL Full entailments, is a good move even if it breaks  
"the alignment". It gives us a principled, coherent way of handling  
more RDF graphs that people are likely to write in likely-to-be- 
implemented systems. I don't really see the point of preserving  
compatibility if it is very unlikely to be implemented, or will only  
be implemented on systems handling very inexpressive fragments of OWL  
(because then we'll lose interoperability between those systems and  
systems striving to be more complete).

Cheers,
Bijan.

Received on Thursday, 10 January 2008 01:23:20 UTC