[SCL] Re: Observation

Chris Menzel cmenzel at tamu.edu
Sun Jun 1 23:19:48 CDT 2003


On Sun, Jun 01, 2003 at 09:14:51PM -0500, Pat Hayes wrote:
> >On Fri, May 30, 2003 at 10:54:32AM -0500, Pat Hayes wrote:
> >> [Menzel wrote:]
> >> >The point Ian seemed to be making against SCL was that there are
> >> >sentences in HIS familiar first-order language that suddenly change
> >> >their logical properties when you interpret THAT VERY LANGUAGE via
> >> >SCL model theory. Not so on our latest SCL model theory in which the
> >> >relation between R and I is unspecified.  The logical properties of
> >> >a traditional first-order SCL language are identical whether
> >> >interpreted a la Tarski or a la SCL.  What you *can't* do is start
> >> >with a gonzo type-free SCL language and expect that a superficially
> >> >traditional first-order sentence ripped from that context will have
> >> >the same logical properties when interpreted a la Tarski.
> >>
> >> Ah, but that is what Ian WOULD expect. The point is that all
> >> sentences one comes across are 'ripped' from their context in this
> >> way: there are no contexts on the Web. There are only sentences. Or,
> >> to put the same point differently, if it looks like first-order, then
> >> it IS first-order. Or to put the point differently again: it must be
> >> possible to recognize the intended context simply by parsing the
> >> sentences. A file of sentences must be interpretable in one definite
> >> way without any other information being made available that is not
> >> somehow encoded in the form of the expressions in that file.?
> >
> >Well, how about then that parsers default to the least amount of
> >type-freedom?
> 
> But we also want the language to be monotonic, so Im suspicious of 
> defaults. But why do we need to do this? My understanding of your
> semantic proposal was always that the MT is simply agnostic; it does
> not need to make assumptions one way or the other. Given a set of
> sentences, there are many models; the satisfaction conditions require
> that relation symbols (which are in relation position) must denote
> relations in R and individual symbols (which are in the argument tuple
> positions) must denote elements of I, and we quantify over I.
> Textbook stuff, right?  The ONLY thing that is nonstandard is that we
> forgot to specify that the syntactic domains are disjoint, and if you
> read it quickly you probably didn't even notice that :-)  To the
> extent that the axioms get the syntactic categories overlapped, the
> semantic domains also must overlap at least to that extent in any
> satisfying interpretation: that follows from the satisfaction
> conditions. That is all we need to say, right?

You seem to be ignoring a point you made forcefully in a previous
message, viz., that the Horrocksian hordes would expect the meaning of
an FOL-looking sentence to have the same logical properties in every
context.  A Horrocks sentence won't, relative to SCL's semantics.  What
happened to that point?

> > That is, reasoners/parsers/etc receiving a file should
> >assume that a predicate is NOT an individual constant unless it is
> >used explicitly as such in that file.
> 
> Well, that is a cackhanded way to say it. Rather, they should NOT
> assume that it IS in the domain of quantification; 

These amount to exactly the same thing in my book (ignoring the fact
that you've given the point a semantic rather than syntactic spin).  To
make the assumption in question does not mean it can't later be
overridden.

> >One could then only get a Horrocks sentence in an inconsistent set (I
> >think).
> 
> Right, but the same applies without making the special assumption.
> 
> > Thus, if you receive, say,
> >"(x)(Px <-> ~Qx) & (x,y)x=y", then you assume "P" and "Q" aren't also
> >individual constants and hence don't denote individuals.
> 
> No, you just assume that you don't know that they do. 

Point taken, but this invocation of what you don't know has no real
place in the definition of a language.

> They might: the next thing you see might be R(P), and you don't want
> that to contradict anything.

Then you would simply retract the assumption in questin. 
 
> > No Horrocks
> >problem.  The only way to force them to denote would be add sentences
> >to the file in which "P" and "Q" occur as arguments.
> 
> The only way to FORCE them, yes.
> 
> > But then the
> >resulting file would be provably inconsistent for pretty much
> >standard first-order reasons:  you'd be able to prove "P=Q" from
> >"(x,y)x=y" and "~P=Q" from "(x)(Px <-> ~Qx)" and the usual rules of
> >identity.  (Suppose "P=Q".  then by the substitutivity of identicals
> >we have "(x)(Px <-> ~Px)", which is easily shown to be contradictory
> >in FOL.)
> >
> >I think you were saying something like this on the phone the other
> >day, but I didn't grok it at the time.
> 
> I thought this was what YOU had been saying for the past week :-)

Almost, but not quite.

> >> If this requires that the sublanguage in fact be a small
> >> subontology, as with the suggested use of Rel, then I reckon we
> >> ought to as far as possible absorb these little extensions in to
> >> the core language, so this ought to be scl:Rel and be given its
> >> semantic burden as part of the core model theory. That way, SCL has
> >> all the tools it requires to present its sublangauges to the world.
> >> I am pretty sure that we can do all the cases we are interested in
> >> with just a few of these: we decided a while back that Rel or
> >> something like it was going to be needed for GOFOL expressivity in
> >> any case, right?
> >>
> >> BTW, yet another tweak occurs to me. Having Rel in GOFOL as a
> >> predicate is illegal of course since there isnt anything there for
> >> it to be predicated of.?
> >
> >Oh but there is -- it is true of exactly those individuals that are
> >relations.
> 
> In GOFOL there aren't any relations which are individuals, by
> definition. 

That is false.  The domain of quantification in an first-order
interpretation is any nonempty set of things.  Those things might be
relations, either extensional or intensional.

-chris




More information about the Scl mailing list