- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 01 Feb 2001 15:52:58 -0600
- To: Drew McDermott <drew.mcdermott@yale.edu>
- CC: pfps@research.bell-labs.com, danbri@w3.org, timbl@w3.org, horrocks@cs.man.ac.uk, www-rdf-logic@w3.org
Drew McDermott wrote: > > [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. As if there were any ;-) Each of us has his own perspective, experience, vision, and goals. W3C has a bunch of formal process rules, and RDF has some status in that context, but this conversation is essentially prior to the context in which those rules matter. > I think Dan King raised some > very good issues: > > Can currently existing RDF tools process and > interpret these DAML+OIL primitives? Some of them can; some of them get upgraded pretty easily (cf recent protoge release). > 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. Partial understanding is a fact of life. In commerce, I can check rules like "pay the invoice as long as it's less than $500" without understanding the item detail line that talks about aircraft widgets. In the semantic web, similarly, we can check each other's proofs without understanding all the terms in the formula. Parties involved in a transaction will have to agree on a certain number of axioms to get anything done; that's the art in this stuff. But checking proofs is science. > 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. Who is 'we'? A lot of what you're seeing is old ideas presented to and studied by a new audience. Much of this new audience understands and appreciates bytes-on-the-wire and running code, not abstract syntax. > 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.) Ah... good... things seem to be converging... > Anyway, the main questions would seem to be: How much expressivity do > we need? at least enough to stuff like this: The most general rule I can think of is of the form "if a statement of the form x follows from key set y then deduce f(x)." -- http://www.w3.org/DesignIssues/Toolbox > What sorts of inferences do we need? I don't expect inference to be the basis of interoperability. Various agents will know how to produce proofs for the things they need to do; for example, in proof-carrying code, the compiler knows how to prove that the code is correct; it's pretty much a by-product of compilation. If you have access to a web site, you generally know why and (with a little help from GUI tools) can produce a proof that you're authorized. > Should the language > have subsets at different points on the expressivity/tractability > spectrum? Absolutely. > What do we pay for the ability to check proofs in the > Calculus of Constructions (a very hairy type system)? Good question; I intend to find out shortly. One cost I'm already quite certain of: the cost of getting anybody to agree that this line of research is promising ;-) But I keep finding evidence that it's a good approach, starting with a little chat I had with Robert Boyer; I told him about RDF, and after the usual "huh? why just binary relations?" stuff you get from logicians, he agreed that "yeah... this idea of shipping little proofs around looks promising." > 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. Yeah... and you'd write hairy little tex macros for your abstract syntax so there's no way to read them on the screen, and no reliable way to convert them to any other format. I'm painfully aware of the way the logic community talks among itself. I hope that MathML matures quickly so we can stop encoding our knowledge in tex, a turing-complete language. cf On Formally Unconvertable Document Formats $Id: html-essay.html,v 1.2 1994/02/15 20:07:12 connolly Exp $ http://www.w3.org/MarkUp/html-spec/html-essay.html But we're bringing other communitites together. The internet community uses ASCII email to talk to each other. ASCII syntax is essential to such conversations. (n3 is sorta aimed at this level). The Web/XML/RDF crowd uses XML and XHTML and XSLT and DOM and python and perl and java and such. The RDF syntax is the result of a bunch of people getting together and talking to each other: library folks, HTML/web folks, hackers, and a precious few logic folks. > Instead, we seem to have a commitment to a very low-level and clumsy > concrete syntax (RDF) that everyone says has bugs. Well... we have an investment, yes. > 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). Who claimed any of this was settled? Peter asked for languages with the sort of expressive power TimBL was talking about; Brickley asked for software that does interesting stuff with any such language. I provided evidence of both, no? You get to decide whether my evidence is compelling/persuasive/interesting. But to refer to my research as "offhand remarks" is, well, rude, no? > 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? That's what we're doing, I think. By they way... along with XML, don't forget URIs. The value of the Web is the network of URIs. Any language disconnected from that context is totally worthless to me. As bad as RDF might seem, all the other languages I've seen in this design space are worse. Either (a) they don't connect to URI space, so why bother, or (b) they're even more baroque than RDF. Check out XMI, for example. http://www.oasis-open.org/cover/xmi.html http://www.google.com/search?q=XMI I'm certainly open to other XML-based syntaxes that are grounded in URI space. (in fact, as evidenced by notation3, I'm willing to play with non-XML syntaxes; but I'm not willing to give up URIs; that's where the value of the web is.) > (Step 2 should take > about 15 minutes.) Hah! I think you display a lack of experience in consensus building. > What exactly is the role RDF plays in all this? It's a little teeny formal system based on URIs and XML: two place predicates only, conjunctions and existentials but no negation, disjunction, universals, etc. > How committed are we to it? I'm quite invested in it, but I can certainly imagine it evolving coniserably or even being replaced altogether. I can't speak for 'we'. > Who decides when we aren't committed to > it any more? We do, whoever 'we' is. > -- Drew McDermott -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 1 February 2001 16:53:07 UTC