W3C home > Mailing lists > Public > www-rdf-logic@w3.org > March 2001

Re: DAML+OIL (March 2001) released

From: Seth Russell <seth@robustai.net>
Date: Sat, 31 Mar 2001 08:44:25 -0800
Message-ID: <006a01c0ba01$da14be20$b17ba8c0@c1457248a.sttls1.wa.home.com>
To: "Jonas Liljegren" <jonas@rit.se>, "pat hayes" <phayes@ai.uwf.edu>
Cc: <www-rdf-logic@w3.org>
From: "pat hayes" <phayes@ai.uwf.edu>

> Perhaps not, but that was not the primary goal of everyone on the
> committee. DAML+OIL is RDF-compliant (for political rather than
> technical reasons), but do not make the error of thinking of it as
> simply an extension to RDF.  DAML+OIL was constructed by a committee
> with members who have a variety of agendas, and taking RDF seriously
> was of central importance only to a minority. In particular, being
> what might be called RDF-politically correct is not of central
> importance to me personally, since in my view RDF is based on a
> fundamentally flawed semantic model and is not viable for long-term
> use as a representation language.

I think it would help the RDF community if you would publicly explain in
detail what the flaws are.

> RDF graphs are just one data structure convention among many others
> in use around the world, and for many purposes they are not even the
> best.  The basic simplicity of the 'triples' model is often cited,
> but the fact that arbitrarily complex graphs (and hence arbitrarily
> complex syntactic constructs) can be encoded in triples has been
> widely known since the 1880s (CS Peirce wrote extensively on the
> subject) and has been a commonplace observation in data structuring
> since the early 1960s; so the enthusiasm for this supposed
> universality seems to reflect ignorance rather than insight.

I'm having troubles following the logic of that paragraph.  I parse it this

  [triples (can encode) (arbitrarily complex syntactic constructs)]
      is WellKnown;
      (refer to this as) (supposed universality x).
   (somebody who)
        (has enthusiasm for) (supposed universality x);
        reflects (ignorance rather than insight).

Which doesn't follow in my book.

> triples have no special syntactic advantages over, say, LISP
> Sexpressions, and they provide no special functionality or semantic
> power.

While I think this is doubtlessly true; since we can transform any triples
diagram into sexpressions and visa versa without loss (can't we?); it would
seem to me that there is an advantage in thir simplicity.  Of course, the
enthusiasm for the triples in the community at large is also an advantage,

>The RDF documentation and discussion archives are rife with
> elementary errors (such as confusing use and mention, confusing
> syntactic structure with meta-description, confusing asserting with
> reference, confusing names with URIs, and confusing dereferencing
> with denotation) that they often border on being simply incompetent.

Hey man! ...then give us a hand ...

> All the RDF engines I am aware of provide only primitive
> data-structuring abilities and have a level of sophistication in
> inferencing which is best described as pathetic.

Inferencing is an application that sits on top of the triples ... let the
best one win.  I fail to see how this is an argument against simply using

> That is a political claim, not a technical one, and one that I would
> strongly oppose. RDF has created far more problems for DAML+OIL than
> it has been of utility.  The quote refers to difficulties of
> capturing semantics: right now, RDF has no semantics, and until it
> gets one, being part of the " bigger RDF network"  simply endorses
> confusion.

The politics of RDF is the politics of agreeing to use a common standard.
What is your problem with that kind of politics?  It seems to me that we got
too many cooks mucking with the soup.  We got CG, and KIF,  and CycL and
lord know what other KR systems floating around.  It makes my head spin !

"Can't we all just get along ?"

Received on Saturday, 31 March 2001 11:47:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:34 UTC