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

Re: universal languages

From: Tim Berners-Lee <timbl@w3.org>
Date: Thu, 1 Feb 2001 17:42:55 -0500
Message-ID: <035101c08ca0$51cb7c40$85061812@CREST>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:38 GMT