Re: Roles, again

Don Dwiggins <>
Date: Tue, 12 Sep 1995 22:52:50 -0400
From: Don Dwiggins <>
Message-id: <>
In-reply-to: <> (
Subject: Re: Roles, again
Reply-to: Don Dwiggins <>
Precedence: bulk
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.  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 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 entities 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?).

> 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.  (Aside: interestingly, in such cases,
relations wind up looking a lot like compound objects.  Or perhaps
compound objects are just relations: could an auto be usefully thought
of as just a relationship among its components?)

> 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

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.

In OO development, this higher level is the province of analysis.  My
point 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").  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 similarities of the "agent" roles in selling, trading, stealing,
giving, bartering, etc.?  By the way, I see a connection with mereology
here, and I'd like to become more knowledgeable about that field.

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
it's the wrong level for doing design.  (Incidentally, I'd be interested to
hear how applicable all this is to the design of knowledge bases.)

Don Dwiggins				"The truth will make you free,			 but first it will make you miserable"
               				 -- Tom DeMarco