Re: same-syntax extensions to RDF

On Jan 5, 2005, at 10:57 AM, jos.deroo@agfa.com wrote:

> waw Bijan!

Yes, I know. The typos are a bit much. I was a little sleepy when I  
wrote it. I shall strive to do better in the future.

> I haven't experienced most of your issues, both as developer and
> as user i.e. even not a while ago

The relentless application of the logic of my last email could lead to  
the following trilemma:
	1) you've cheated (I mean this in non-moral terms, i.e., you  
intentionally or unintentionally took a shortcut, or special cased, or  
dealt with a toy, didn't handle the actual semantics, etc.)
	2) you've not done the same kind of tasks
	3) you have perverse tastes :)

Ok, the last is a bit of a joke, but I can sorta rephrase it as, it's  
not clear that you are a proper judge as i don't believe you have the  
relevant experience with the contrast classes.

Or perhaps it would be better to phrase it thus: There has been no  
independent invention (to my knowledge) of this approach, and there is  
no, to my knowledge, interest in adopting this approach in other areas  
of logic, knowledge representation, logic programming, etc. I don't  
believe it's a matter of us hidebound academic fogies failing to grasp  
the benefits.

Let's take a trivial example, in my own made up syntax:

	some(P, C)

or, to sexpr it

	(some P C)

That's equivalent to the class expression (in owl)
	<owl:Restriction>
		<owl:onProperty rdf:resource="P"/>
		<owl:someValuesFrom rdf:resource="C"/>
	</owl:restriction>

Or, to turtle it
	[a owl:Restriction;
	owl:onProperty P;
	owl:someValuesFrom C]

Or, how about:
	_:x rdf:type owl:Restriction;
		owl:onProperty P.
          ...insert a hundred triples....
	_:x owl:someValuesFrom C.

Or I could owl the original:

<erzatzOwl:Restriction>
	< erzatzOwl:onProperty rdf:resource="P"/>
	< erzatzOwl:someValuesFrom rdf:resource="C"/>
</erzatzOwl:Restriction>

This is no less verbose than the original OWL, but it parses directly  
to (or could parse to):
	some(P, C)
	(some P C)
	(some . (P .  (C .())))

But guess what! I can have a schema or DTD that detects if there's a  
missing erzatzOwl:someValuesFrom! Or had two! Or, given syntax, I could  
easily make it pretty painless to have too. In either case, I'm gonna  
want to have something that looks a whole hell of a lot like what I  
parsed it too. And I'm going to want it to *mean* what I parsed it to  
means (when I interpret it).

This is the groovy life. This is data pleasant to work with. This is  
the advantage of Lisp/Prolog code/data "equivalence".

This is not what RDF gives you. Not even merely syntactically. Then  
through in the semantics and you are screwed.

(For fun! Negate the expression! Convert it to negation normal form! Do  
it all at the triple layer! Using XSLT!)

(More fun! Provide the semantic conditions for the normal  
interpretation in FOL of that expression!)

> http://lists.w3.org/Archives/Public/www-archive/2004Aug/0024.html
>
> [[
> found a proof using the E prover
> http://www4.informatik.tu-muenchen.de/~schulz/WORK/eprover.html
> for the OWL test case
> http://www.w3.org/2002/03owlt/description-logic/inconsistent502.rdf
> which we translated into
> http://lists.w3.org/Archives/Public/www-archive/2004Aug/att-0024/ 
> inconsistent502.tstp
> and the proof is
> http://lists.w3.org/Archives/Public/www-archive/2004Aug/att-0024/ 
> inconsistent502-proof.tstp
>
> (both are in the TSTP format
> http://www.cs.miami.edu/~tptp/TSTP/
> but that can be connected to the "proof bus" using N3)
> ]]
>
> we can't find that proof with euler but can convert it
> back to N3 and use it's triples, well given that
> {{:a :b :c} :d :e. {:f :g :h} :i :j} :k {{:l :m :n} :o :p}.

Cheat. That's not RDF. The formula isn't encoded in RDF. You've added  
considerable syntax. You are in our camp.

It's also a dodge. I completely fail to see how one, hand translated,  
very disciplined example stands up to the experience of theory,  
standard, and generic tool building.

Let's take another case, qualified number restrictions. A simple  
extension to any of syntaxes

(> 5 P C)

Apparently very difficult for RDF.

Any notation requires training, of course, but it is striking to me  
that when I used (or showed to people) Swoop's various panes  
(http://www.mindswap.org/2004/SWOOP/), people strongly preferred the  
concise syntax, even if it took a little explaining (and the fonts a  
bit too small!). Just being able to *see the real structure* of your  
assertion is HUGELY illuminating. Being able to work with that  
structure is also really happy making. (I hope to have some user  
testing to confirm this.) So forget the extra semantic crud problem  
(which is significant), it's just clearly much better to work with  
natural syntax than with some wretched twist of something else.

Indeed, isn't this what we argue against XML? Graphs vs. Trees? You can  
encode graphs in XML (see RDF/XML). Why don't we just work with the  
XML? Isn't XML data pleasant to work with? (For syntax, this is surely  
true!!!)

> is 1 triple with nested triples and respecting
>
>   whenever, in a sentence, we wish to say something
>   about a certain thing, we have to use, in this
>   sentence, not the thing itself but its name or
>   designation -- Alfred Tarski

I understand that.

> So I believe that all those "certain things" are
> rdfs resources, wether they be {} or literal values
> or URI referenced things, the names are just
> different designations.

I don't understand that, but I believe it to be irrelevant.

So, write a species validator. Write a converter to and from the  
abstract syntax (note which way is *much much much* easier!!!) Propose  
an encoding of N3 in OWL Full that is a same-syntax semantic extension,  
with model theory.

These sorts of things could refute me. Or simply try the negation  
normal form challenge.

Or come visit OWL-S land some time. I'll show you new meanings of the  
word "pain".

The two functions would be:

	def nnf(triplestore) #returning triplestore

and
	def nnf(term) #returning term

or, better,
	def nnf(RDF/XML) #returning RDF/XML but using a triplestore

and an XSLT stylesheet for and XMLization of, say, KRSS.

How about just checking for wffs?

(Y'know, isn't it painfully obvious that the open world assumption is  
*JUST WRONG* for syntax? I mean, if  a term isn't there, it's *not  
there*. It's not that it *might* be there but I just can't see it. It  
really isn't there. Bad term! You didn't just stray...you wandered off  
the edge of the universe into oblivion!)

(Someone tried to claim that having to encode multiple arity predicates  
in RDF was a *good* thing *because* of the open world assumption. After  
all, you might decide later that your "between/3" predicate *really*  
was a "between/24"!!! WHO KNOWS?!??!?!)

In general, I strongly appreciate the idea that we should put more  
burden on implementors than on users, given the ratio of implementors  
to users (although, worse is better argues passionately against this!).  
But I do not believe that this should be interpreted as we should make  
implementor lives a living hell, and then screw the users too.

Some history: I started out a TripleHater (I really need to revive my  
article "The Trouble with Triples" (which was a loose parody of the  
Star Trek episode  
http://www.startrek.com/startrek/view/library/episodes/TOS/detail/ 
68744.html), alas, it was lost in a crash; actually, I was more  
TriplePuzzled than TripleHating), then, because I just couldn't  
understand why all these people loved them, I tried extra special hard  
to understand and imbibe the koolaid (see,  
http://monkeyfist.com/articles/815). Well, I've *drunk* the koolaid;  
I've  *bathed* in it, *drowned* in it. And, alas, it's both sticky and  
it irritates my rather thick skin.

Aren't applications and algorithms (both which the SemWeb is in dire  
need of) enough trouble?

(So, how do we resolve the disagreement? I take it I win by TKO on the  
semantics. When the two lead editors of the semantics for OWL and RDF  
not only wail together on the pain, but are highly skeptical of the  
*possibility* of doing the encoding any futher, I think the burden of  
proof is hugely on the other side. And that means providing actual  
model theories of the desired form for, say, SWRL. Next let's look at  
the internals of any toolkit providing more semantics than raw RDF and  
see if they use RDF encodings directly. I don't know about Euler, but  
CWM does not (formulae are distinct, and scoped). Etc.)

Cheers,
Bijan Parsia.

P.S. I understand that Sandro is gathering data, and I supply these  
screeds as data :)

P.S.S. (Yes, that's deliberate. These aren't Post Scripts. But Post  
Screed. This is the Post Screed Screed :)) I though XML was the syntax  
layer? Why is RDF being polluted? Well I know why, because some people  
don't understand the difference between an assertion and syntax,  
connectives and syntax, etc. And something weird about parsers, but  
that *CAN'T BE* the explanation any more, because we have ever more  
syntaxes. Ok, it's about *abstract* syntax, or something. Bad abstract  
syntax. Bad descriptions of bad abstract syntax, maybe :)

P.P.S.S. I will try to make it my last screed :) But I do believed I  
answered the question Sandro originally asked. He finds RDF data  
pleasant enough to work with that he is inclined to head down the  
encoding route. My experience is violently different. This is *aside*  
from the various theoretical point raised. Which are devestating, btw.  
Even if possible, it would still be painful and pointless, IMHO. There  
is no Nice here.

Received on Wednesday, 5 January 2005 06:18:53 UTC