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

modulo the screed at the top that you realize later missed the point,  
and the fact that you missed the point, the last paragraph is one  
that I think is important - the more "real" RDF graphs that we can  
process using OWL DL tools, without making the creators have to  
understand the details of getting things into RDF, the happier we all  
seem to be -- well, okay, Peter said in today's telecon "In some  
sense, I don't care, as this is all RDF-compatability stuff" but I'll  
take that as an abstention :-)
  anyway, I think having vocaulary that "MAY" (or even Should) be  
used, but where there are defaults that make sense when things are  
ambiguous (and where these defaults are shared, so we get  
interoperability) strikes me as an interesting idea - properly  
documented we could add some important features that are needed for  
easier processing and DL compatibility, without scaring users into  
believing they "MUST" understand these things before they can get  
started in OWL...
  What isn't clear to me is how much work this is - in Pellet (at  
least when it was still a Maryland entity) we actually had several  
heuristics for suggesting how to coerce things from Full to DL, and  
it worked pretty well, but I'm not sure how robust they were or how  
easily they'll be to generalize - but may be a place where some sort  
of consensus could lie
  -JH
p.s. Some people may be surprised after seeing the different blogs  
from RPI and C&P about the new WG documents that Bijan and I could  
ever agree on anything.  Actually, we did with surprising regularity  
for many years - the universe is stranger than most of us imagine :-)

On Jan 9, 2008, at 8:25 PM, Bijan Parsia wrote:

> 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.

"If we knew what we were doing, it wouldn't be called research, would  
it?." - Albert Einstein

Prof James Hendler				http://www.cs.rpi.edu/~hendler
Tetherless World Constellation Chair
Computer Science Dept
Rensselaer Polytechnic Institute, Troy NY 12180