Re: Roles, again
phayes@ai.uiuc.edu (Pat Hayes)
Message-id: <199509211934.AA27163@a.cs.uiuc.edu>
X-Sender: phayes@tubman.cs.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 21 Sep 1995 14:49:10 -0600
To: Don Dwiggins <dwig1@village.ios.com>
From: phayes@ai.uiuc.edu (Pat Hayes)
Subject: Re: Roles, again
Cc: cg@cs.umn.edu, fritz@rodin.wustl.edu, guarino@ladseb.pd.cnr.it,
srkb@cs.umbc.edu, carrara@cs.umbc.edu, giaretta@ipdunidx.unipd.it
Sender: owner-srkb@cs.umbc.edu
Precedence: bulk
At 12:23 AM 9/21/95 -0400, Don Dwiggins wrote:
>Like Nicola, I've had trouble lately getting time to compose a coherent
>reply to Pat's reply.
Its like washing the dishes: its best to get it out of the way first.
>Pat writes:
> What I meant was only that Im suspicious of relations that have too many
> argument places.......
>
>And it can get worse; my example of selling was a pretty simple one.
Agreed.
>Consider what's involved in selling a house, or some of the complex
>products in the stock market. I suspect that relations of 10 or 20
>places could be found in many sufficiently large real world domains.
>That's one reason I'm interested in principled methods of breaking them
>down and dealing with their internal structure
This is where I fail to understand you. A relation doesnt HAVE any
'internal structure': its just a relation, ie a set of n-tuples. Its not a
physical thing with parts. (At best one might say that subrelations, or
restrictions to a subset of its arguments, etc. are 'parts' of it in a
rather metaphorical sense, but that sense is quite amenable to
extensionalist descriptions.)
(or more commonly in
>design, building them up incrementally so as not to have to backtrack
>and start over too many times).
>
>Actually, you've touched on one of the basic issues that a designer has
>to face: where do you draw the boundaries of your domain? Since you're
>not trying to capture all of reality, the task at hand provides the
>guidelines (i.e., the "firm extensional ground"), but there are still
>difficult cases (particularly when trying to anticipate the evolution of
>requirements).
We arent communicating properly. I agree with you here: the really
interesting questions are what to say about your domain. The 'firm ground'
I was referring to is the semantic theory of the language in which you do
this saying. Let me put it this way: suppose you present to me some domain
description in a formalism which uses symbols from Senghalese written in
spiral patterns. Before we can even discuss what it says about the domain,
you have to tell me what the language means. This is where I recommend
sticking to an extensionalist account.
.......
>
>Dwig:
> relations wind up looking a lot like compound objects.
>Pat:
> Just say, looking like objects; thats what they do, indeed. But these
> objects arent any more compound than any other. The 'roles' arent PART of
> the relation like the wheels of my car are part of it.
>
>Why not?
Because its a category mistake; relations just arent the kind of thing that
has parts! One might as well ask what color a relation is.
>They can certainly be usefully viewed that way,
I suggest that viewing them this way only results in confusion. Its better
to keep in mind a clear distinction between parts of things, and
subrelations of relations. Then each idea doesnt get cluttered up with the
mental baggage of the other.
>just as it
>might be useful to view a component of a compound as a "role filler".
My car's engine fills the /Engine/ role in my car. Does this say anything
more than that a relation /Engine-of/ is true between my car and its
engine? If so, what? If so, notice the important distinction between my
engine (which is heavy and cost real money to manufacture, etc.) and the
relation (which doesnt weigh anything, etc.)
>BTW, when I distinguish a compound object from an atomic one, it's in
>the context of a particular modeling task, and taking certain binary
>relations to be "compositional". Atomic objects don't have components
>_in the subject domain_. What I'm doing here is a conceptual analogue
>of the logical reification of relations.
Analog, yes, but only that.
For example, as John points
>out, there are obligatory and optional arguments to relations;
>similarly, compounds may have obligatory and optional components. I
>sometimes think the only difference between a relation and a compound is
>how you look at it.
In HOL this may be almost right, since to say that my car exists might well
be transcribed as saying that a relation exists which is that which holds
between the parts of my car (and nothing else). But it would be very
difficult to give axioms for this relation without referrring somehow to
the car. In FOL, the key difference is that one can quantify over things
but not over relations.
>
>Dwig:
> In a sorted logic, yes. But logic -- even sorted logic -- hides just
> the distinctions and associations I'm trying to get at. It's like
> looking at an assembly language program and trying to recover the
> design.
>Pat:
....
> ...
> Again, I think you are making a conceptual error. Logic isnt at any
> 'level', its a very, very general-purpose notation for expressing things.
>
>I believe there is a very real notion of level that applies here. A
>rough characterization: given two conceptual tools, A and B, and an
>intellectual task to be accomplished, A is higher level for the purpose
>than B if it better facilitates thinking in terms natural to the task,
>and requires less effort in encoding the task into the terms of the
>tool.
Thats too vague to be helpful. With this definition, my son's tinkertoys
might be higher-level than a pencil and paper one minute and lower-level
the next. Also, A might be higher-level than B for one person but
simultaneously lower-level for another. You just mean something like
"handier" (as your examples illustrate).
......
> You might just TRY logic for doing design. I bet it will do just as well as
> anything you've seen so far; and if not, I'd be very interested to know
> exactly where it fails.
>
>People do use logic for this purpose, more in Europe than the US.
>Languages like Z and VDM have found serious use. However, they aren't
>the languages people conceptualize in. In fact, typical presentations
>of Z designs intersperse the formalism with English descriptions,
>graphical notations, etc. to help people understand the logic.
Ive been assuming that we are talking about a formalism suitable for
representation, not how to design an interface for engineers to use. (At
that level the people to talk to are probably perceptual psychologists and
graphic designers, not logicians.) The issue is not whether people find
conventional logical notation a handy one to use, but whether extensional
logic is capable of encoding all the distinctions in meaning that a
suitable interface might need. Its a representation language, not a
communication language. (For the record, I find it easier than anything
else Ive seen: its largely a matter of familiarity, I think.)
Pat
------------------------------------------------------------------------------
Beckman Institute (217)244 1616 office
405 North Mathews Avenue (415)855 9043 or (217)328 3947 home
Urbana, Il. 61801 (217)244 8371 fax
Phayes@cs.uiuc.edu