- From: Tim Berners-Lee <timbl@w3.org>
- Date: Thu, 1 Feb 2001 17:42:55 -0500
- To: "Drew McDermott" <drew.mcdermott@yale.edu>, <connolly@w3.org>
- Cc: <pfps@research.bell-labs.com>, <danbri@w3.org>, <horrocks@cs.man.ac.uk>, <www-rdf-logic@w3.org>
Here is my 2cents worth ... ----- Original Message ----- From: "Drew McDermott" <drew.mcdermott@yale.edu> 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> Sent: Thursday, February 01, 2001 4:02 PM Subject: 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. I think we are missing the concept of a subset language here. I suppose you could think of an RDF engine as a DAML engine deprived of a number of axioms. It can't infer so much. (In practice, RDF is used in applications where the semantics is almost all implicit. DAML-ont makes more explicitly statable in a machine-readable way. DAML-hol more....) > There are several important issues in designing DAML, but they seem to > me to be mainly semantic and computational, not syntactic. Yes. But there is a parallel discussion of syntax. Those langauges which map into RDF triples take advantage of the separation of syntax and semantics which the triples were designed to enable. > 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? Enough to be able to express anything in any of the applications which will use the web. So, we would want anything (data, rule, query...) from Peter's system or Ian's system to be expressable in the universal language. This of course means that the language will be powerful enough to ask uncomputable questions. But we do not ask to be able to export a query which A's system can answer and have B's system answer it. We do export a subset of the infromation from one system to another. We do rqeuire that if A's system infers something it can write a proof in the universal langauge and B will be able to *check* (not find) the proof. > What sorts of inferences do we need? I am not an expert, so excuse any misuse of terms. There are many related logics, which use different sets of axioms and inference rules, but have the (provable) property that there is a mapping from formulae in one to formulae in another such that one engine cannot infer something which mapped across it false in the other system. The universal language defines this set of logics, if you like. It doesn't define which set of axioms any engine should use. It doesn't define which set of inference rules. It does require that whatever you do use must be consistent with some standard set. So all expressions of FOPC for example are basically equivalent. I understand that Conceptual Graphs and KIF are higher order logics and are equivalent. I library catlog system for example may have a very limited inference system. Lots of systems will be based on SQL databases. They will douseful work because they will operate on queries and datasets foming very well-defined and limited situations. At the other end of the scale, the web of all hte stuff these theings are operating on will be a paradise as fodder for the AI hacker. > Should the language > have subsets at different points on the expressivity/tractability > spectrum? Absoluteley! > 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. (I have often felt that making a version of KIF which used URIs and namespaces for identifiers (webizing kif) would get this community off to a faster start when it came to email discussions. It would also make a few points about where the world is a tree and where a graph. The whole interst in the SWeb is that it is a web -- that the same term can be referred to in formulae all over the planet. There is a tension with the totally tree-structured nature of a parse tree, on the surface, at least.) > Instead, we seem to have a commitment to a very low-level and clumsy > concrete syntax (RDF) that everyone says has bugs. The bugs are well known and can be irradicated easily. The abstract syntax of triples (like lists in KIF) is cleaner. We are trying to bring together formal systems and real engineering which has just graduated from ASCII to XML. Its a culture thing. So long as the abstract langauge is clean, the syntax which others use for it is something which can be compromised. And you can have more than one syntax. But the triples model was, as I said, a way of isolateing the syntax issues and semantics issues. When you reject that, you get the discussions linked again. > 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. Yes. > 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). I haven't seen anyone presume these issues settled. Nor any presumtioin that it would be easy. Though the KIF folks do often imply that their language is experssive enough to eat most of the other contentants as the universal one in practice. > 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? Ok, go ahead. > (Step 2 should take > about 15 minutes.) What exactly is the role RDF plays in all this? RDF is the triple model, plays the same role as lists in Lisp. To not use it woudl be like breaking a way from dotted pairs in Lisp. > How committed are we to it? Who decides when we aren't committed to > it any more? When you show that your XML syntax for your universal language can't be expressed at all nicely as triples. There is an open question as to whether building on RDF means bulding using triples or building using triples and ohter stuff (nary predicates for example). The first would be very neat. It would allow inference to be expressed in terms of triple operations. But we don't have to shoot ourselves in the foot to get it. In theory the questions becomes menaingless when you can translate any language into triples. For example, DAML tells you how to represent lists. I converted the KIF axioms for DAML into DAML lists and processed them as triples. I could have done it the other way around. So I agee we concentrate primarily on the language. > -- Drew McDermott Tim Berners-Lee > >
Received on Thursday, 1 February 2001 17:43:21 UTC