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

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 10 Jan 2008 01:25:14 +0000
Message-Id: <CBA3998D-52C3-4B80-9777-4846DBA5DE1B@cs.man.ac.uk>
Cc: "Web Ontology Language ((OWL)) Working Group WG" <public-owl-wg@w3.org>
To: Jim Hendler <hendler@cs.rpi.edu>
```
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:02 UTC