Re: what is the meaning of the RDF model theory?

From: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>

> > Which is where you loose me:(     If we are making a theory that the
> > computer can use, then, me thinks, being able to manifest the
interpretation
> > of it inside the computer is a *requirement*.   Allowing part of the
model
> > to be sustainable only by the ideals in a human's mind seems to me to be
> > less useful.
>
> Nope, sorry, wrong answer.  Next contestant please.  :-)
>
> Consider the humble integers.  A theory of the integers would have several
> operations, such as addition, whose interpretation is infinite and thus
> cannot be manifested inside a computer.  Nevertheless, the theory of
> integers is still quite useful.

Well let me rephrase:  Being able to *represent* the thing inside the
computer should be our requirement.  If we cannot represent the thing inside
the computer, then the computer cannot deal with that thing.  Infinite
extensions of objects, I believe, will always need some form of recursion to
be *represented*.  Representing recursion in computers is very easy.  Here
is a labeled directed graph that represents all of the positive integers ...
its response: {true or false} can be taken as the definition of a positive
integer:

http://robustai.net/mentography/positiveInteger.gif

> Yes, this is not quite the point you were making but I think that it is
> illustrative nonetheless.
>
> > But I think there is one simple yet adequate ~model theory~.  Define an
arc
> > (or even a pencil of them which is an sexpression) down to it's fine
detail
> > such that it can be manifested in the computer.   Then something is in a
> > model (entailed by it?) iff an arc exists in the model or can be
inferred by
> > the interpreter of the model.  The interpreter is just a program that
> > operates only on arcs.
>
> Sure, this is one way of proceeding, but how are you going to define
> ``inferred''?

There are lots of ways to infer things in lots of different kinds of logic.
But inevitably they all come down to an algorithm.  Represent the algorithm
that generates the behavior called inference and you have adequately defined
what it means to infer.

>You have several choices, one of which (and I happen to
> think that it is the best one) is ..... a model theory.

Problem is that if such a theory cannot be represented in the computer, then
it is just for the professors and the priests and cannot have any bearing on
the behavior of the computer except indirectly through the action of the
priests and professors.  Please don't get me wrong and that that as a slight
against  priests and professors.  But mathematically I think we can get them
out of the loop.

> Another choice (that is often used, but that, I think is by far the worst
> one) is to anoint a particular program as the definer of inference.

Why anoint just one program?  Why not specify in RDF which interpreter and
inference engine applies for each context?

> However, there are lots of problems with this approach.  First, a program
> is a big thing, and for that reason, and others, is hard to analyze and
> duplicate.

I'm not so sure that is true.  If we break down our algorithms to labeled
directed graphs, then they should be easy to analyze and duplicate.  And I
would guess any technique which actually does analyze programs will  first
decompose the program into some variety of  label directed graph.

>Second, the behavior of programs is quite hard to define.

Perhaps so ... but turn that around the other way and there is no problem ..
the behavior defines the concept, not the concept defines the behavior.

>If
> you want to define its behavior via its ``behavior in the field'' as it
> where, you need to define the field, and I sure don't want to have to have
> a definition of Windows XP as part of the definition of RDF!

There is no need to define Windows XP as part of the definition of RDF.  But
we could define a virtual machine interpreter that would function on RDF
graphs to define (and manifest) behavior.  I know this is possible.

>If you want
> to use the formal definition of the programming language, if it has one,
> then you are back to either a very complicated formal operational
semantics
> or to a slightly less complicated .... model theory.

I'm not sure what a 'formal operational semantics' would feel like ... would
that mean that we would get to put on our Tux before writing down a formula
like Pat says he does ?  ;-)

> So maybe you say that we should use a simple programming language.  OK,
> let's try a very simple one, the lambda calculus.  (Why not, it's Turing
> complete after all.)   Drat, the theory of the lambda calculus is suitable
> as the sole subject of a upper-level mathematics course---not exactly
> simple after all.

An interpreter running on RDF type graphs is so simple that even I can
understand it.

Seth Russell

Received on Monday, 15 October 2001 13:28:38 UTC