Re: Literals (Re: model theory for RDF/S)

From: Graystreak <wex@media.mit.edu>
Subject: Re: Literals (Re: model theory for RDF/S)
Date: Thu, 4 Oct 2001 17:36:21 -0400

> PFPS asserted:
> > If you can understand a specification like Corba or JTAPI or even the
> > meaning of a programming language, like C++ or ML, then you should be
> > able to work your way through a model theoretic specification.  After
> > all, RDF and DAML+OIL are a lot more simple than Corba or C++!
> 
> Speaking as a true naif here, no.  They're not.  I'm not at all sure what
> it means to "understand the meaning of a programming language."  To my
> knowledge, programming languages don't have meanings.  They're just
> syntactic sugars, in which programs are written.  Sometimes very smart
> people can figure out some formal semantics of some of those programs,
> provided the programs aren't even a little bit complex.

[I just can't let this one go.]

Programming languages do certainly have ``meaning''.  In fact, they have
several meanings, one of which even looks something like the RDF model
theory, but a LOT more complicated than RDF (or DAML+OIL or FOL) model
theory.  Even an operational portion of the operational meaning of
programming languages is very complicated---just think how long it took
until you were a decent Java (or FORTRAN or COBOL or IBM Assembler or
LISP---insert your first programming language here) programmer.  

Now to make things more difficult here, we are participating in (or at
least observing) the creation of a new representational language.  (And
yes, this is still part of the creation of RDF and RDFS.)  So don't expect
that things will be exactly correct the first time and don't expect ``RDF
for Dummies'' quite yet.  Further, this is the creation of RDF and RDFS,
not the use of RDF or RDFS, so even more is needed to understand what is
going on.

Consider the situation if you were part of the group that created COBOL or
FORTRAN.  (I'm using COBOL and FORTRAN because they were created by
``standards'' groups, and many more-recent languages weren't.)  You would
have had to get up to speed on lots of new (or new to CS) stuff.  If you
hadn't, you could not have understand what was going on.

> So when someone like me sets out to read and comprehend Patrick Hayes'
> "RDF Model Theory" document, it's bloody slow going.  (Thanks to Patrick
> for doing that work, btw.)
> 
> When those of us who are used to sitting down and building things try to
> wrap our brains around this RDF stuff it gets tricky.  It has these two
> weird properties in that it's all wrapped up in FOPL which we learned
> back in undergrad days was a formal system not connected to the real
> world.  And it's supposedly the way real knowledge is to be represented,
> such as business information, rules of operation, and so forth.

I view this as completely analogous to the situation with respect to
programming languages.  They are all wrapped up in Turing machines which I
learned was a formal system not connected to real computers.  And they are
supposedly the way real programs are written, ....  

> I still haven't figured out how to synthesize the two notions; I don't
> think I'm atypically stupid.  

I'm not sure that you should (synthesize or denegrate yourself, both).

There is a notion of model theory (Turing machines) and that notion is used
in formalisms (programming languages) that are actually used to represent
stuff (write programs).  So what you need to do is, I think, see how the
one can be used to support the other.

I do agree that all this is not trivial, even for CS people, and, maybe,
even difficult for most of them.  I've been doing similar stuff for a long
time now (and I haven't been doing much teaching), so I don't have good
intuitions on how hard it is to grok.

> I could go on, here, but I think Peter
> himself pointed at the problem about a week ago, in a note to
> rdf-interest:
> 	"I'm not happy at all with the fact that RDF has a 51 paragraph
> 	document just to define what a literal is."

And the model theory has nothing to do with (or, more accurately, is only a
consumer of) this rather large specification, just as (most) programming
languages have nothing to do with the instruction set of the Pentium III
processor even though programs often run on Pentium IIIs.


> --Alan Wexelblat
> wex@media.mit.edu		http://wex.www.media.mit.edu/people/wex/
> CHI'02 Panels Chair 		moderator, rec.arts.sf.reviews

Peter F. Patel-Schneider

Received on Thursday, 4 October 2001 19:05:56 UTC