- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Thu, 1 Feb 2001 16:02:03 -0500 (EST)
- To: connolly@w3.org
- CC: pfps@research.bell-labs.com, danbri@w3.org, timbl@w3.org, horrocks@cs.man.ac.uk, www-rdf-logic@w3.org
[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