Re: Roles, again
phayes@cs.uiuc.edu (Pat Hayes)
Message-id: <199509140037.TAA28478@eris.ai.uiuc.edu>
X-Sender: phayes@tubman.ai.uiuc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset="-ascii"
Date: Wed, 13 Sep 1995 19:38:45 -0600
To: Don Dwiggins <dwig1@village.ios.com>, phayes@cs.uiuc.edu
From: phayes@cs.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 10:52 PM 9/12/95 -0400, Don Dwiggins wrote:
>Pat Hayes writes:
>> Thanks for the example. To illustrate my suggestion: there are no 'roles',
>> at least as actual entities. What you have is the relation (sold-to-for
>> x,y,z,w) - rather an awkward one, but leave that for now - and its four
>> arguments, which are restricted to being respectively an agent, an agent,
>> an entity, and a quantity of value. These are sort restrictions on its
>> arguments.
>
>Why do you call the relation awkward -- it's a pretty common one, and one
>that I'm sure you've participated in many times.
What I meant was only that Im suspicious of relations that have too many
argument places. In this case for example I'd be inclined to hypothesise
that there were things called 'sellings' which have various properties. The
problem with putting everything into arguments of a relation is that there
is no way to know how many you will need. For example, consider the
relation of sold-to-for-attime, which has 5 arguments, and
sold-to-for-attime-atplace, with 6, etc.. If these are all different
relations, then one needs axioms to establish the connections between them.
If you have things called Sellings then your 'roles' become relations
between them and the objects they relate to, so you can write thngs like
Selling(x) implies (exists y)(Agent(y) & Seller-of(y,x))
or maybe ....& Seller(x) = y )
Notice that a Selling then is not a relation.
One of the things I'm
>interested in is that the two "agent" roles are different, even though
>they're of the same sort; playing one is not at all the same as playing the
>other. I'm interested in a way of characterizing that difference, in a more
>insightful way than distinguishing the argument places.
What is not 'insightful' about distinguishing two argument places? I think
you probably mean, more explicitly labelled by the notation (so that the
human writer of this stuff doesnt have to remember which argument is which)
OK, then by all means label them in some way; but don't think that these
labels have an meaning within the notation itself. Or, use the reification
idea outline earlier.
>> What you are calling 'roles' here are simply the argument places of the
>> relation, and your conceptual Jabberwockiness comes directly from trying to
>> think of them as actual enties when they are, at best, only a kind of
>> metasyntactic relationship between a relation and a sort.
>
>No, I'm precisely trying not to think of them as entities. It's the nature
>of that "metasyntactic relationship" interests me (by the way, what does the
>"meta" signify here?).
That the 'relation' is between something and an aspect of syntax, ie its
about the syntax, in part. I should probably have said 'metalinguistic'.
>
>> OO languages lead one into thinking this way, since the notation is unable
>> to handle n-place relations for n>2, so one has to use the trick of making
>> these relations into Objects and linking their arguments to them.
>
>Actually, OO _programming_ languages don't express relations directly at
>all; one has to represent relations in terms of variables containing
>pointers, and suchlike tricks. Some OOA&D notations do allow expressing
>n-ary relations, much like CGs do.
The languages that I am familar with simply reify relations into individuals.
(Aside: interestingly, in such cases,
>relations wind up looking a lot like compound objects.
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.
Or perhaps
>compound objects are just relations: could an auto be usefully thought
>of as just a relationship among its components?)
One answer: damned if I know. Another answer: yes, trivially. Since a
relation is an n-tuple, its the relation which is true of the parts exactly
when they constitute your automobile. Third answer: this is the kind of
useless pseudophilosophical question that one gets led into without a firm
extensional ground to stand on. Fourth answer: see Wittgenstein,
Philosophical Investigations for some initial, tentative thoughts on the
matter by a deeper thinker than any of us are ever going to be.
>> As you say: 'a role of a given relation specifies the kind
>> of entity that can "play the role" '. However, you go on to make the
>> mistake: 'and it "carries the meaning" of such an entity being in that role
>> in that relation'. No; it - the role - doesnt carry any meaning. Its just a
>> syntactic restriction.
>
>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.
No, its not. Thats a common mistake. Representational languages arent like
implementation languages in this way. There isnt any notion of 'level' or
compilation, etc.., because there isnt any machine code. Is ZF set theory
like assembler? Or Carnap's axiomatisation of geometry? Or Cyc? All you can
say is that some axioms talk about more familar ideas than others, but that
depends on the reader.
>Maybe it'll help if I provide more context for what I'm doing. In
>designing a system, you first begin at a high level to outline the
>architecture and isolate the basic concepts. Later, in detailed design
>and implementation, you translate these into an implementation-oriented
>notation, focusing on concrete representations, algorithms, etc (this is
>an oversimplification, but OK for now). If you start at that detailed
>level, without having clarified the higher level, you're likely to get
>things muddled and create an implementation that's hard to understand or
>modify when needed. Indeed, diving prematurely into implementation has
>led to some of the classic software disasters.
Fine, I'll agree with all that.
>In OO development, this higher level is the province of analysis. My
>oint is this: current analysis methods don't provide a good way of
>capturing the important things about roles: not just types/sorts, but
>other restrictions and characteristics (e.g., "in order to be a seller,
>one must be able to deliver the merchandise").
Seller(y) = x implies possible( (exist z)(Delivery(z) & Agent(z)=x &
Delivered(z)=Sold-to(y) )
this isnt quite enough for your sentence, as I think you have changed the
meaning of 'seller' slightly from a role in a selling event to something
like a type of agent. This is fine, but recognise that there is a change of
meaning here.
I want to have a good
>conceptual framework for capturing these things, the kind of mental tool
>that suggests the things you need to pay attention to, supports proper
>chunking, etc. There are also considerations of reusability: what are
>the similaritie of the "agent" roles in selling, trading, stealing,
>giving, bartering, etc.?
Good question. That there is one, suggests looking for a more general
relationship of which these are all restrictions (or instances), maybe
something like change-of-ownership-of, or making-a-deal-with
>By the way, I see a connection with mereology
>here, and I'd like to become more knowledgeable about that field.
Good luck. I dont see it, myself. Mereology, roughly, identifies membership
with part-of. This has all kinds of interesting consequences (most of
mathematics instantly vanishes like smoke in the wind, for example), but to
put it together with conventional notations is like trying to mix oils with
acrylics.
>If your target language for detailed representation is predicate logic, all
>such knowledge will of course be uniformly represented by assertions, like all
>other knowledge in the domain. This level is fine for doing proofs, but
t's the wrong level for doing design.
Again, I think you are making a conceptual error. Logic isnt at any
'level', its a very, very general-purpose notation for expressing things.
You might just TRY it 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.
Pat Hayes
------------------------------------------------------------------------------
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