Re: universal languages

   [Dan C.:]
   Here's what I'm hoping to do with this stuff:

	   (a) model Guha's context logic in typed lambda calculus
		   (should be an elegant
		   front-side-of-one-page sorta thing;
		   a few hours work, if it'll work at all;
		   ist(context F) looks easy;
		   the nonmon stuff (circumscription) scares me though;
		   I'll probably skipt that)
	   (b) map the Boomborg-PC syntax to McDermott's RDF-ish syntax
		   (ugly syntax engineering, but nothing subtle)

I confess to being somewhat baffled by the ground rules of the
DAML-plus-or-minus-OIL/RDF discussion.  I think Dan King raised some
very good issues:

   Can currently existing RDF tools process and
   interpret these DAML+OIL primitives? Syntactically, because DAML+OIL is
   implemented with RDF, the answer is yes.  But semantically, because of the
   undefined functionality the answer is no.  Even after DAML+OIL (and +
   whatever else) has solidified and DAML+OIL tools are available, should RDF
   tools be modified to interpret DAML+OIL?  Since DAML+OIL is but one use of
   RDF, I don't think so. It appears to me that the vast majority of the
   semantics of DAML+OIL is not supported by RDF or its tools.  Hence,
   semantically speaking, DAML+OIL is not backward compatible with RDF.

There are several important issues in designing DAML, but they seem to
me to be mainly semantic and computational, not syntactic.  There has
been a lot of work on representation systems over the years, so that
by now we at least understand the tradeoffs involved.  In essence:
the more expressive the language the less tractable is its use.
Peter's mention of Montague was an ironic mention of one end of the
continuum.  Typed lambda calculus are at approximately the same
point.  (Montague can be considered to be lambda calculus applied to
representation of natural language.)

Anyway, the main questions would seem to be: How much expressivity do
we need? What sorts of inferences do we need?  Should the language
have subsets at different points on the expressivity/tractability
spectrum?  What do we pay for the ability to check proofs in the
Calculus of Constructions (a very hairy type system)?

As we answer these questions, we would develop an abstract syntax for
the language, that is, a syntax in which tree structures are taken as
primitive, so parsing isn't an issue.  Finally, we would discuss ways
of embedding it in concrete computational structures, such as XML.

Instead, we seem to have a commitment to a very low-level and clumsy
concrete syntax (RDF) that everyone says has bugs.  As Dan K. points out,
almost none of the problems solved by RDF tools are the problems we
actually care about.  This shouldn't be a big surprise.  If someone
developed a set of tools for manipulating Sanskrit, knowing nothing
but the alphabet, the tools could tell you how many occurrences of the
letter "A" there were, but not much else.  

When higher-level issues are raised, we hear offhand remarks to the
effect that Oh well, we can use KIF; or oh well, we can use typed
lambda calculus.  I don't understand why the central issues get
settled by offhand remarks (or usually, *not* settled).

Don't get me wrong.  I'm not arguing in favor of another concrete
syntax.  I like XML for the same reasons I like Lisp: it provides a
level of hierarchical structure intermediate between characters and
syntax trees.  But, like Lisp, XML imposes almost no constraints on
what actually gets expressed in it.  Great!  Why don't we define a
language and then find a way to embed it in XML?  (Step 2 should take
about 15 minutes.)  What exactly is the role RDF plays in all this?
How committed are we to it?  Who decides when we aren't committed to
it any more?

                                             -- Drew McDermott

Received on Thursday, 1 February 2001 16:02:08 UTC