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.

Yes, sure. But now follow through on that thought. There are the 
integers, let us suppose, and we invent a way to represent them in 
the computer, say using base-4 numerals: 0 ,1, 2, 3, 10, 11, 12, ... 
Now we have one thing in the computer which we can define operations 
on, and something else, not in the computer, which that thing in the 
computer is supposed to 'represent'. How would we - we humans, who 
are building this thing - describe this whole set-up? Wouldn't it be 
reasonable to talk about the computable representations on the one 
hand, and the (possibly uncomputable) things they represent, on the 
other, and talk about the correspondence between them? We might for 
example say that the numeral '100' represents the number 16 in our 
representation system.

If you are comfortable with this way of talking, then you are doing 
model theory. That's all an MT interpretation (of a representation 
inside the computer) is: a collection of things that the symbols are 
supposed to represent, and a mapping between the symbols - more 
generally, expressions - and those things. MT just does this in a 
more systematic and general way, is all.

>  If we cannot represent the thing inside
>the computer, then the computer cannot deal with that thing.

Its not intended for the computer to deal with. It is for us, to help 
us talk about what the computer does.

>.....
>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.

Now tell us what it means to infer *correctly*, without somehow 
referring to truth or meaning.

>  >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

For any human being who wants to talk and think and theorize 
precisely about his program's meanings. If you don't want to do that, 
then by all means do whatever makes you happier. Some of us do, 
however.

>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.

But why would you want to? You ARE one of them.

>  > 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?

How? That is an infinite regress. If the interpreter defines the 
meaning of the RDF and is itself defined in RDF, where do we start? 
You can bootstrap, but you have to start somewhere.

>  > 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.

Seth, you really should learn something about what you are talking 
about before making guesses like that. All of LISP is a labelled 
directed graph. I can send you enough LISP code that you will never 
finish reading it all in one lifetime.

>
>>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.

Sure, but its just as easy (actually easier) to define one of these 
to draw invalid conclusions as it is to draw valid ones, so who is to 
say which one is right? Just behaving doesn't mean that one is 
behaving *correctly*.

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

OK, what does it do if it has two copies of the same graph but with 
the anonymous nodes permuted? Is it allowed to put new names on the 
anonymous nodes if they don't clash with any other names? Justify 
your answer :-)

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 16 October 2001 01:51:41 UTC