Re: representing patterns and structures

Danny Bobrow <bobrow@parc.xerox.com>
Message-id: <QioKKG4B0V0w9KhwNc@nero.parc.xerox.com>
Date: 	Mon, 21 Nov 1994 19:29:22 PST
From: Danny Bobrow <bobrow@parc.xerox.com>
To: "Peter Clark" <pclark@cs.utexas.edu>,
        brayman@zuben.ca.boeing.com (Bill Brayman),
        phayes@cs.uiuc.edu (Pat Hayes)
Subject: Re: representing patterns and structures
CC: srkb@cs.umbc.edu
In-reply-to: <199411212226.AA14202@dante.cs.uiuc.edu>
References: <199411212226.AA14202@dante.cs.uiuc.edu>
Sender: owner-srkb@cs.umbc.edu
Precedence: bulk

Excerpts from mail: 21-Nov-94 Re: representing patterns a.. Pat
Hayes@cs.uiuc.edu (1897*)

> Heres an interesting issue for this discussion. Years ago, complicated
> interactive CAD systems allowed notions of 'grouping', so you could specify
> eg. a pattern of holes all of a certain diameter* a certain spacing* apart
> in a hexagonal* grid filling a certain area* on a sheet of metal, just by
> specifying the starred parameters. Then it was possible to say that they
> should be all moved a leeeetle bit closer together, and have the system
> draw the result for you on the screen. Very pretty, until you wanted to
> fill in just one of these holes. This was impossible if the thing was
> specified this way, since in a real sense that particular hole-token didnt
> actually exist in the internal representation.

> How could we allow for such pattern-exceptions? One idea is to have them
> added as post-defaults, so that this piece of surface starts being there,
> then removed by the hole-grid, then replaced by the exception. But this
> fails when someone changes the grid-parameters: its essential to tie the
> repatching to the place where that particular hole is, and this thing - one
> particular hole in the pattern described as a pattern - just isnt *there*
> in the representation, to have anything tied to it.

There are some interesting presuppositions about representations in this
problem.  First that there is a fact of the matter as to whether there
is something representing  each hole in the representation -- that it is
unique or only described intensionally,  and that if it is unique it has
copied onto it all the properties  that it inherits from intensional
descriptions at one time.  One could imagine a representation that given
an intensional description such as the one above created a parasitic
description that allowed access to surrogates for the particular hole. 
Properties of the hole that derived from the initial intensional
description would be inherited by default.  Other descriptions might be
attached to the singular surrogate, with a trail of information telling
which  descriptions in the intensional description are overridden.  

But why stop with unique surrogates, and one intensional description. 
Consider the array of holes, with the first row of holes having a
diameter of 1/4 inch larger than the rest.  

What this leads to is a theory of description construction with
properties like selection (of a subset found by a property),
modification of selected descriptions (either incrementally -- 1/4 inch
larger, or absolutely 1/2 inch in diameter), and a representation of
description combination in the language. (NO I don't have a language to
propose)

Excerpts from mail: 21-Nov-94 Re: representing patterns a.. Fritz
Lehmann@rodin.wust (2717)

>      This issue is a very deep one, that of individual identity.
> Those holes are _intensional_ in the initial description, yet you want
> to "tag" one of them as an individual  to state an exception.  The problem
> is, what does "one of them" mean?  If the holes are moved "a leeeetle bit
> closer together", are they "the same" holes?   What if a circle of eleven
> holes is made into a circle of ten holes?  Which of the eleven evaporates?
Fritz here is talking about either the problem of description
modification (e.g. that array with the lower left and upper right holes
removed -- or with two holes removed ...), or description matching
(given two descriptions,  here is a way of mapping one into another).  
Both of these may leave underspecified various parameters, or the
identity of various elements in pairs of descriptions.  Then asking
about which things are "the same" depends on the purpose for which
"same" is being used.  Suppose one hole in the circle was larger and the
eleven were mapped to ten.  Then it might make a difference which hole
was removed (total material left).  Talking about identity without
giving the purpose for which identity is sought leads to wonderful
philosophical discussions, but rarely leads to deinitve answers.  

Let us find ways of providing nested (layered) descriptions, and ways of
specifying interesting correspondences between elements identified by
descriptions.  Let us find ways of using descriptions as frames for
selection, perhaps a full  algebra of descriptions.  Then let us find
efficient implementations that support reasoning with these in cases we
care about.

Flame off,
danny