Re: RDF as a syntax for OWL (was Re: same-syntax extensions to RDF)

Hi Jeff,

On Jan 7, 2005, at 12:17 AM, Lansing, Jeff wrote:

[snip quotes of me :)]
> As this (fascinating and important) debate becomes focussed on "RDF  
> sucks as a syntax for OWL" there is a risk that some of the broader  
> "RDF sucks" points made at the beginning will get lost.
>
> So I bring one of them up here. It was claimed that RDF's real and  
> only real power is as a sort of unfettered (by DTD or Schema) XML.   
> [Bijan: "When we use RDF this way we treat it as if it were XML. XML  
> without DTDs even. Without well-formedness!"]

Er...That's still on the syntax point.

I did focus, for first steps, on syntactic issues. But if you consider  
the difference between having a relatively normal term based syntax,  
vs. a triple based one, when defining an interpretation function you'll  
see a big ole gap. When you *add* that the triples are meant to always  
have normal assertional force...then things get very difficult to  
impossible.

(Compare http://www.w3.org/TR/owl-semantics/direct.html and  
http://www.w3.org/TR/owl-semantics/rdfs.html)

> This of course goes counter to the popular belief that just by moving  
> from XML+Schema to RDF you have somehow jumped from empty syntax to  
> the realm of meaning itself

Let's suppose that's true (though I gag over such hype :)). The first  
question is whether the formalism for "meaning" (or domain modeling) is  
adequate or helpful for the domain of syntax.

>  (the word 'semantics' gets thrown in here), thereby enabling  the  
> power of reasoning. Sometimes it is hinted that this is because  
> "triples" are the language of thought.

Thanks to the efforts of the RDF Core working groups, we know exactly  
the (specified) expressive power of RDF.  And it's not a lot. Of  
course, just because your formalism can't express that:
	:bijan :currentAgeInYears "10";
	           :currentAgeInYears "20".
is contradictory (you can, of course, in OWL add the requisite  
constraints) doesn't prevent a system from doing so. It just takes some  
code. That code can be ad hoc, or it can use a more expressive  
standardized formalism. There's always code though! So we enter the  
land of tradeoffs ;)

Part of the deep problem with the current layering strategy is that it  
obscures rather than reveals what's actually being expressed. My  
anecdote about swoop: Swoop has several different "views" of the axioms  
"defining" a class. One of them uses more or less traditional  
Description Logic, variable free syntax (which has some nice  
conciseness advantages over the equivalent standard FOL  
syntax...counting quantifiers a.k.a., number restrictions even more  
so!) + a tabluiar layout, but there is also an AbstractSyntax view, an  
RDF/XML view, and a Turtle View with more to come. This is a *great  
way* to come to understand some of the affect on human beings of  
different styles.

I showed it to someone who'd been working with OWL for a few years (he  
has a AI PhD). He was *astonished* when browsing in the ConsiseFormat  
view. "So *that's* what it meant!!! Ouch, I've not said much here. You  
know, fore understanding, I'll use the ConsiceFormat. For impressing  
and confusing my boss, I'll use RDF/XML"

Really understanding a formalism requires getting a grip on the  
semantics. The more levels of crud you have, the harder understanding  
will be. It also helps to be able to relate multiple expressions that  
are equivalent (or distinct). Free, uniform syntax like RDF makes it  
*really* hard to do that, or to detect problems. We're just talking  
about the fluency barrier here! Modeling in a KR language is hard and  
alien enough, by itself!

If you are programming a reasoner, bad syntax choices can haunt you in  
a number of ways. One thing OWL has encouraged is "rule set"  
implementation of OWL reasoners (see Jos's). But I've not seen a one of  
these that isn't just misguided, where not horribly broken. It  
*deceives* people as to what the task is.

OWL Lite is similar. OWL Lite corresponds (roughly) to the Description  
Logic SHIF(D), SHIF can be characerized by the following set of  
constructors:
	and, or, not, some, all, inverse, subPropertyOf, subClassOf (with  
arbitrary class expressions on either side), functional (max 1) and  
min1 (well, not exactly, but that's a bit closer to OWL Lite).

Yet OWL Lite has no explicit constructors (syntax) for or (unionOf) not  
(completentOf) and a few other things.

The *semantic expressivity* is there, but it's hidden. If you write a  
reasoner based on the *express* syntax of OWL LIte, you might think you  
don't need to deal with negation. You'd be wrong.

There is a mild effort to describe "OWL TIny" which is supposed to be  
an ever easier to implement subset of OWL Lite, see:
	http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_4/#owl- 
tiny

It's not clear to me that it *is* an expressive subset!!!! Why deprive  
yourself of convenience syntax if it doesn't *actually* make (correct)  
implementation easier!?!?! (In fact, I'd argue it makes it harder.)

> Can you also shed some light on this?

There is also some general blurring of RDF as a semistructured data  
format (graphs vs. XML trees) and RDF as a minimal KR formalism. A lot  
of people who like RDF like it as semistructure data. But wellformed  
XML is pretty "free" too, so it's not clear who wins over all. Stefan  
Decker tried to argue with me at ISWC that RDF had a notion of *object*  
(and identity) and this was the big advantage on this front. I'm not  
entirely convinced. I do think that often an ounce of advantage at the  
bottom is outweighed by a ton of tools, mindshare, experience, and  
legacy applications. If you want to displace XML in an organization,  
how much of an advantage must you show? 2, 3, 10 times? Costs must be  
considered too, and it's not enough to show that the cost/benefit ratio  
is favorable. After all, if the cash flow gets screwed, then it doesn't  
matter that I'll save double 3 years from now (since I've gone under,  
now!).

I've got some feet in both camps (KR vs. data), but it's not clear to  
me that RDF, as it stands, is ideal for either, or even really good. It  
does seem to be workable for both given the right approach. For a  
standard, that's not bad :) But I think we need to be *MUCH* more  
humble about the "power of RDF" and much more *concrete*. If you can't  
show the advantage in a concerete, well spelled out way, don't claim  
it!

Oh, one point on the closer to KR part. RDFS is a bit of a peculiar  
beast (if you read Guha) though not without some fairly distinguished  
history. It's worth trying to understand that, and how it could well  
fit in with other approaches.

Cheers,
Bijan Parsia.

Received on Friday, 7 January 2005 08:41:42 UTC