Category Archives: Abstract Objects

Paul Vincent Spade On Motivating The Mediaeval Problem Of Universals

“It is well known that the problem of universals was widely discussed in mediaeval philosophy — indeed, some would say it was discussed then with a level of insight and rigor it has never enjoyed since.” What follows is an extremely good motivation of the medieval problem of universals, offered by Paul Vincent Spade in the introduction to FIVE TEXTS ON THE MEDIAEVAL PROBLEM OF UNIVERSALS.

“It is easy to motivate the problem of universals. Consider these two capital letters: A A. Ignore everything else about them and for now observe only that they are of the same color: they are both black.

As you look at the two letters, how many colors do you see?  Two different answers are plausible.  You may want to say  you see only one color here, blackness.  You see it twice, once in each of the two capitals, but it is the same color in both cases.  After all, did I not just say the two letters were “of the same color“?  Isn’t that obvious by just looking at them?  This single blackness is the kind of entity that is repeatable, found intact in both letters at the same time; it is what philosophers call a “universal.”  If this is your answer, then you believe in the reality of at least one universal, and are in that sense a “realist” on the question.

But now reset your mental apparatus and look at the two letters again.  On second glance, isn’t it obvious that you see two colors here, two blacknesses:  the blackness of the first A, this blackness, and then the blackness of the second A, that blackness?  The two colors look exactly alike, yes, but aren’t they visually as distinct as the two letters themselves?  If this is your answer, then you do not believe in the reality of universals (at least not in this case) and are a “nominalist” on the question.  The problem of universals is in effect the problem of deciding between these answers. ”

Of course, my eros for the mediaeval problem of universals is just a stepping stone on the path to eros for the platonic form BEAUTY.  And the stepping stone previous to eros for the mediaeval problem of universals is, in the grand tradition of platonic philosophy, eros for gorgeous young men such as this one, who is today’s homage to Plato’s SYMPOSIUM.


If Plato can include a bad boy like Alkibiades in his SYMPOSIUM, I can include a bad boy like Josh in my post.


Logical Pairings

In previous posts I’ve tried to interpret the canonical Tagalog sentence (e.g., maganda si Taylor Lautner) in terms of an equality relation, GORGEOUS_EQUALS_GORGEOUS.  Conceptually, the relation is formed by logically pairing each member of the set GORGEOUS (MAGANDA) to each of the members, then taking a subset of the set that results from this logical paring.  That subset comprises those logical pairings in which each member of the pair is identical with the other.

What do I mean by ‘logical pairing’?  In the real world, to pair one thing with another is to bring the two things together in some way.  One may pair, for example, some particular matte board, with its particular color, with the painting one is getting framed.  Here, the matte board and painting are getting physically paired.  Or one may pair John with Bill by picturing them in the mind’s eye as together as a couple.  Or one may pair John with John by first seeing him double (i.e., seeing him twice but simultaneously), then by realizing the two Johns are in fact one.

To get a logical pairing, abstract from any concrete form of pairing, that is, ignore any particular way in which the bringing together is done.  Ignore in fact everything about them except that they go under the heading ‘bringing together’ (since maybe that is the only single thing they all have in common.)   Then be content with the fact that, while each member of the set MAGANDA can potentially be brought together with every member of that set,  any actual pairings will be performed just every now and then, and only for a few members.  (For example, in a particular article, Dan Savage pictures Ashton Kutcher and Matt Damon together.)  A logical pairing is a bringing together in which all concrete details of the bringing together (how it is done, in what sense the things are brought together?  Physically?  In the imagination only?  By already knowing that the “objects” of one’s double vision are in fact one and the same?) are ignored.  One salient detail in particular is ignored:  is the pairing actually being done in any given instance, or is it just something that could be done?

If one does not want to rest content with each member of the set being brought together just potentially with every other member of the set, they (plural third person intentionally being used here as a neutral singular third person) are free to imagine a Demiurge ala Plato or a God ala the medievals whose cognitive capacities are sufficiently large as to simultaneously bring together in its mind’s eye every member of the set MAGANDA with every member of that set, so large, in fact, as to be able to see Matt Damon twice with the mind’s eye but already know that Matt Damon is, well, Matt Damon.

I will end by confessing that I like to think of projection as the Demiurge’s ignoring one or more attributes of a relation, and of restriction as the Demiurge’s ignoring one or more tuples in the relation.

Today, my homage to Plato’s SYMPOSIUM (first, gorgeous guys, then the Relational Algebra, then the form Beauty itself) will take the form of a concrete (not just a logical) pairing of Matt Damon and Ashton Kutcher:



Sigh.  There is too much beauty in the world.

Some Clean-Up Work: Why A Name Needs A Selector If One Is To Be Fully Explicit

Let me unpack a bit the NAME() selectors I have been using.  A selector such as NAME(‘Tom’) takes as an argument the string ‘Tom’ and returns the name Tom.(Tom is being mentioned here, not used.  The arguments surely have to be syntactic arguments.)  A string comprises 0 or more written characters (henceforth  just ‘characters’).  A character is an abstract object:  the character ‘e’, for example, can be instantiated by a blob of ink, a pencil mark, a set of pixels….  So a string is an abstract object comprising other abstract objects, and exists at one level-of-abstraction higher than they.

A string of characters is not itself a name, since a name can also be instantiated by a zero or more sounds.  I say “0 or more” because I can imagine a language that uses the glottal stop as a name, whatever the merely practical difficulties might be in doing so.  (A name that could never be pronounced by itself, but only within a stream of other sounds?)

(Perhaps — to jump back to characters for a moment — this language could write the name as ”.  So a name could be instantiated by strings comprising 0 or more characters. )

(Perhaps — to jump back to sounds for a moment — if I tried hard enough I could turn a sound into an abstract object (perhaps one sound can be instantiated by any number of configurations of sound waves?), but I will not try this at the moment. )

Instantiated, as I was saying, by either strings or sounds, a name is an abstract object, one existing at one level of abstraction higher than the abstract object STRING, which itself is one level of abstraction higher than the abstract object CHARACTER.   Not identical with either a sound or a string, a name is best represented not by, for example, ‘Tom’ or <<some sound>>, but by NAME(‘Tom’) or NAME(<<some representation of a string of sounds>>).

This, then, is why, when I am trying to be fully explicit, I refer to a name not as, e.g., ‘Tom’, but as NAME(‘Tom’).

Today’s homage to Plato’s SYMPOSIUM is Ashton Kutcher:


There is too much beauty in the world.  How can one concentrate on anything at all with gods like this walking the earth?

The Relational Algebra Gives Us Something (Or Somebody, Or At Least Someone)

Now onto trying to show how the Relational Algebra gives us ‘something’, ‘somebody’, ‘someone’, and so on.

When I talk about database relations in the following, I am, unless I state otherwise, talking about the abstract object, not those relations concretely realized in an RDBMS.

A brief explanation of the Relational Algebra:  Posit a world all of whose people are members of the set {John, Cliff, Charles, Genghis Khan, Leon Trotsky}.  Moreover, suppose that currently, the predicate:

 x is standing to the left of y

generates the Database Relation pictured below when all the members of this set are substituted for the parameters x and y:

Charles Genghis Khan
Dan Leon Trotsky
Cliff Genghis Khan

(The above picture, by the way, is just that — a picture of the Relation.  It is not the Relation itself.)  As indicated by the number 0 in the name, this Relation is a base Relation, i.e., what we have before any operations are applied to it.

The Relational Algebraic operation RESTRICT is a function that takes the Relation pictured above as input and produces another Relation as output.  For example, the following RESTRICTion, expressed in Tutorial D:

TO_THE_LEFT_OF where PERSON_ON_THE_LEFT = ‘Charles’;  (Yes, I’ve suddenly gone from the flesh and blood Charles as member of a set to the name ‘Charles’; God only knows what confusions this sudden shift will introduce.)

generates the Relation pictured below:

Charles Genghis Khan
Dan Leon Trotsky
Cliff Genghis Khan

The operation RESTRICT has given us a Relation comprising a single proposition expressed by the sentence ‘Charles is standing to the left of Genghis Khan.’  As indicated by the number 1, this is a Derived Relation, produced as output from a function that took as input the Base Relation.  The charcoal-grayed out portions of the picture are meant to convey that the derived relation is tied to the base relation in a way in which I will discuss later.

As with RESTRICT, the Relational Algebraic operation PROJECT takes the Base Relation as input and generates a Derived Relation as output.  The following RESTRICT and PROJECT operations, expressed in Tutorial D:


generates the Relation pictured below:

Charles Genghis Khan
Dan Leon Trotsky
Cliff Genghis Khan

whose body is the set containing the tuple or proposition expressed by the sentence “Charles is to the left of somebody.”

But wait — all we see in this picture is the value Charles.  (Or, more precisely, the name ‘Charles’ appearing as a set of black pixels on a screen.)  Isn’t this a tuple in a one-place relation?  And if it is, wouldn’t it be a proposition belonging to one-place relation, a proposition such as “Charles laughs”, or “Charles runs”, or “Charles eats”?

Well, if it were such, it could be any proposition belonging to a one-place relation.  The only way to constrain which proposition this tuple is to just one proposition is to place it in its context, the source from which it is derived, i.e., the base relation TO_THE_LEFT_OF.  By performing the Projection, we are for the moment blacking-out the identity of Genghis Khan, the person to whom Charles is to the left, so that we can focus on the identity of Charles.  But we haven’t forgotten that we are working with the relation TO_THE_LEFT_OF, so we know that Charles is to the left of somebody.  We haven’t suddenly switched to the relations LAUGHS, or RUNS, or EATS.

To turn for the moment for relations concretely implemented in an RDBMS running in some stuff made out of the same substance as the red paint on the Golden Gate Bridge, complete chaos would ensue, the world would become a topsy-turvey place, objects would start falling up, if, say, a Projection on EMPLOYEE_NAME in the EMPLOYEE (select EMPLOYEE_NAME from EMPLOYEE) would result, not in the set of people employed by the company (more precisely, the set of propositions ‘John, employee of Widgets_R_US’, ‘Jesse, employee of Widgets_R_US’, and so on), but the set of people designated to live on Mars one moment, the set of ambassadors to Vietnam the next moment, and the set of of Pulitzer Prize winners the third moment.

So the meaning of a Projection on an attribute (“column”) of a relation is constrained by the relation from which it is standing out (“projecting”), so to speak.  The derived relation never ceases to, well, derive its meaning from the base relation.  It never ceases to be a derived relation.  Charles never ceases to be one member of a pair whose member on his right is being ignored or blacked-out for the moment.

(Compare this argument with C.J. Date’s argument in LOGIC AND DATABASES, pp. 387-391.)

Let’s trace then what happens, in this relational model, when we plug in Charles to replace x in the predicate:

Person x, to the left of somebody

The ‘somebody’ is not a parameter — no argument gets plugged into it — but it along with the x indicate that the base relation we are dealing with is TO_THE_LEFT_OF.  It tells us that one of the ‘central participants in the situation’ is some person to the right.  The relevant Relational Algebra Operations — the relevant RESTRICT and the relevant PROJECT — are then performed to generate the proposition:

Charles, to the left of somebody.

According to the Closed World Assumption, a Relation contains all and only those tuples — those propositions — those states of affairs — that obtain, and for which plugging in arguments to the parameters of the predicate defining the Relation results in a true sentence.  Therefore, each tuple in the Relation is paired with the truth value TRUE, and of course, within the Range comprising the two truth values, only the truth value TRUE.

So the set of tuples in a Relation and the set of Truth Values is a function.  So, finally — if I may end this string of ‘therefores’ and ‘so’s’ (“Feel free to come to the point when you finally decide what it is, I hear someone say”), when a single tuple is selected, as was done when the RESTRICT and PROJECT were performed on the Relation TO_THE_LEFT_OF, we can see this as the application of the function on that tuple, an application which returns TRUE.  So (this really is the final ‘so’ — I promise) plugging in the argument ‘Charles’ into the parameter x in the predicate:

x is to the left of somebody

triggers a RESTRICT and PROJECT on the Relation TO_THE_LEFT_OF, which in turn constitutes a selection of a single tuple in that relation, which in turn returns TRUE, which lets us regard the predicate as a function returning TRUE when ‘Charles’ is plugged into the parameter marked by x.

Just so, when the RESTRICT and PROJECT fail to select a tuple, as it does when we substitute ‘John’ for x (John is standing to the right of everyone else, including Genghis Khan), FALSE is returned.

Voila!  We now we have somebody (or, as the case may be, nobody).

It is clear that the predicate:

x is to the left of y

can be treated the same way.

Treating verbs aka predicates relationally this way — that is, as functions implemented by Relations and operations on Relations — has two advantages over simply seeing them as functions in the way described by Kroch and Santorini.  First, we get a semantics for ‘somebody’, ‘something’, etc.  Second, we have a way of conceptualizing in terms of operations of the Relational Algebra the select that occurs when, to use the verb laughs as our example, Luke is selected and the truth value TRUE is returned.  The notion of select is no longer a primitive.


Updated on 05/10/2012 to correct an obvious oversight.

The Predicate As A Truth Valued Function

So far we have been modeling sentences in which nothing is left unspecified.  Chris invites AndrewLukas laughs.  How could we model, however, sentences such as Chris invited someone, Someone invited Andrew, Someone invited someone, Joe ate something, Someone laughed … sentences in which at least one of the “central participants in a situation” is left unspecified?  We can model these sentences, I think, by applying the Relational Algebra to them — or, more precisely, to the propositions that underlie them.  In this post, I start laying the groundwork for showing how we can use the Relational Algebra to model sentences containing ‘someone’, ‘anyone’, and the like.

Let me begin by outlining the key premise behind Relational Database Theory: 

Predicates generate propositions which are either true or false.  A given Database Relation comprises all and only the true propositions generated by a given predicate.  (This is the Closed World Assumption.)  We can apply various operations of the Relational Algebra to the propositions contained in a Database Relation.

The key premise in Relational Database Theory talks about predicates.  What, then, is a predicate?

What the database theorist C.J. Date calls a predicate is what Kroch and Santorini call, in the primer on Chomskyan linguistics quoted from in the post below (The Verb Considered As A Function) a verb.  Date explains what a predicate is better than I can, so let him speak (LOGIC AND DATABASES THE ROOTS OF RELATIONAL THEORY, Trafford Publishing, Canada, 2007, p. 11):

A predicate in logic is a truth valued function.

In other words, a predicate is a function that, when invoked, returns a truth value.  Like all functions, it has a set of parameters; when it’s invoked, arguments are substituted for the parameters; substituting arguments for the parameters effectively converts the predicate into a proposition; and we say the arguments satisfy the predicate if and only if that proposition is true.  For example, the argument the sun satisfies the predicate “x is a star,” while the argument the moon does not. 

Let’s look at another example:

x is further away than y

This predicate involves two parameters, x and y.  Substituting arguments the sun for x and the moon for y yields a true proposition; substituting arguments the moon for x and the sun for y yields a false one. 

The key premise mentions Database Relations.  What, then, is a Database Relation?

The concept of a Database Relation is an elaboration on the concept of a Relation as defined in mathematics.  In mathematics, a Relation is defined as the subset of the Cartesian Product of two or more sets.  (What a Cartesian Product is will be obvious from the example.)  For example, in the sets {John, Charles, Cliff, Dan} and {Leon Trotsky, Genghis Khan}, the Cartesian Product is { (John; Leon Trotsky), (John; Genghis Khan), (Charles; Leon Trotsky), (Charles; Genghis Khan), (Cliff; Leon Trotsky), (Cliff; Genghis Khan), (Dan; Leon Trotsky), (Dan; Genghis Khan)}.  If, now, we pick out a subset of this Cartesian Product by seeing who happens to be standing to the left of whom at the moment, we get this Relation:  { (Charles; Genghis Khan), (Cliff; Genghis Khan), (Dan; Leon Trotsky)}. 

In other words, our Relation is what we get when we start with the predicate:

x is standing to the left of y

and plug in values for x from the set {John, Charles, Cliff, Dan} and values for y {Leon Trotsky, Genghis Khan}, throw away all the false propositions that result, and keep all of the true propositions.

Let me go out on a limb, then, and say that a proposition (remember, our key premise mentions propositions) is a tuple, that is to say, an ordered pair (for example, (Charles, Genghis Khan) ) in a Relation.  (Please, pretty please, don’t saw this limb off.) 

This means then that a proposition is a state of affairs ala R.M. Chisholm.  For example, the proposition Charles is standing to the left of Genghis Khan is the state of affairs comprising the flesh and blood Charles standing to the left of the flesh and blood Genghis Khan.  Propositions as states of affairs are the meaning of sentences… But I digress.

Back to Relations. 

A Database Relation, I have said, is an elaboration of a Mathematical Relation.  A Database Relation comprises a Heading consisting of ordered pairs of (Name Of Type; Type) and a Body consisting in a set of ordered pairs (Name Of Type, Value).  A type is a set, for example, the set of integers, the set of words in a given language, the set of people, the set of cities in the world, and so on.  A value of a type is a member of the set identical with that type.  I will leave name undefined. 

A Database Relation is an abstract object;  it is either an object really existing in some Platonic Heaven someplace or it is a fiction, depending upon which theory of abstract objects is the correct one.  Database Relations form the conceptual skeleton of databases concretely implemented by an RDBMS (Relational Database Management System) functioning inside a physical computer, but at least at the moment I am not talking about physical computers and the software they run.  I am talking about the abstract object, something that has the same status as the number 3 or the isoceles triangle. 

Why do I want to talk about Database Relations rather than Mathematical Relations?  It will be easier in the  posts that (hopefully) will follow to illustrate the Relational Algebra operations Projection and Restriction.  I know how to apply these operations to Database Relations; I am not sure how to apply them to Relations simpliciter.   Projection and Restriction are the Relational Algebra operations which, I claim, will give us a model for sentences such as Joe ate something. 

I’ve laid the groundwork for such a model; now let me go on to produce the model.

The Verb Considered As A Function

From Kroch’s and Santorini’s Syntax of Natural Language:

I embraced the summer dawn

 From the point of view of a simple formal semantics, the verb laugh is a function from entities to truth values, as illustrated in (1). Entities that laugh are associated with the value T(rue); entities that don’t with the value F(alse). In the world described in (1), Beatrice, Gary, Lukas, and Tina laugh, and Chris and Eva don’t.

By convention, entities are indicated by boldface, sets are enclosed in curly brackets, and ordered pairs are enclosed in angle brackets. It is also conventional to indicate denotations of expressions by enclosing the expressions in special square brackets. These special brackets are not part of the HTML character set, so we use two ordinary square brackets instead.
(1) [[ laugh ]] = { Beatrice T,
Chris F,
Eva F,
Gary T,
Lukas T,
Tina T }

Laugh can combine with a single argument, which denotes an entity. Intuitively, we can think of arguments as the central participants in a situation. Combining laugh with an argument (say, Lukas) has a syntactic effect and a corresponding semantic effect. The syntactic effect is to yield the sentence in (2a). (For simplicity, we disregard the past tense morpheme -ed here and in what follows.) The corresponding semantic effect is to apply the function in (1) to the argument; that is, to select the entity denoted by the argument in the function in (1) and to return the associated value. In the example at hand, the sentence comes out as true, as shown in (2b).

(2) a. Lukas laughed.
b. T

On the other hand, combining Chris with laughed yields Chris laughed with a truth value of F.

In addition to denoting simple functions, verbs can also denote recursive functions. For instance, a transitive verb denotes a function from entities to a second function, the latter of the same type as just described for the intransitive verb laugh (a function from entities to truth values). So the transitive verb invite might denote the function in (3).

(3) [[ invite ]] = { Chris Andrew T ) ,
David Andrew T ) ,
Eddie Andrew F ) ,
Chris Brian F ) ,
David Brian F ) ,
Eddie Brian T ) }

Combining invite with a theme argument (say, David) has the syntactic effect of yielding the phrase in (4a). As before, the corresponding semantic effect is to select the entity denoted by the argument in (3) and to return the associated values, as shown in (4b).

(4) a. invited David
b. [[ invited David ]] = { Andrew T ) ,
Brian F ) }

Further combining invited David with an agent argument (say, Andrew) yields the sentence in (5a) and the truth value in (5b). This second step in the derivation of a transitive sentence is exactly equivalent to the first and only step that is necessary in an intransitive sentence.

(5) a. Andrew invited David.
b. [[ Andrew invited David ]] = T

It is important to understand that the order of the arguments in (3) reflects derivational order (the order in which the arguments combine structurally), not their superficial linear order. Given purely semantic considerations, it is equally easy to write functions in which derivational order is congruent with linear order, and you are asked to do so in Exercise 3.1.

Verbs like laugh and invite are instances of one-place and two-place predicates, respectively. The term predicate here refers to a vocabulary item, with a focus on its capacity to combine with one or more arguments. The number of arguments that a predicate requires is its semantic valency.

If truth in hearts that perish

This simple formal semantics is a model of the verb laughs employing abstract objects such as functions, sets, denotations, truth values.  As a function, laughs associates, or is an association of, concrete, flesh-and-blood entity such as Chris or Lukas, with one or another of the abstract objects (T)rue or (F)alse.  Laughs has a parameter which can accept an argument (to use Date’s terminology); or to use the authors’ terminology, laughs can combine with an argument.  When combined with the name Lukas, the function laughs gets applied to the flesh-and-blood Lukas — that is to say, it selects this flesh-and-blood creature — and returns (T)rue.

If one is a Platonist they may be content with treating all the abstract objects mentioned here as existing and non-fictional:  functions and truth values exist as abstract, non-material objects just as abstract objects as the perfect triangle or the perfect square do.  If one is not a Platonist, he may still be content picturing all of these objects as if they existed, and hold out for the hope that there is, or will be, a way of treating all of these as fictions.

When considered as something that can accept (or ‘combine with’) arguments, a function is an abstract machine:  it accepts an input (the name Lukas), performs an ‘applies’ or ‘selects’ operation, and generates an output (here the truth value (T)rue).  The applying and selecting are abstract; that is, no particular, concrete operation is getting specified.  And I suppose this is how one produces an abstract operation:  name an operation, but omit any concrete implementation of that operation. 

Even the Platonist in me, however,  has some difficulty with the notion of abstract operations such as ‘applies’ and ‘selects’.  Tortured by a bee buzzing around in his bonnet, my inner Platonist feels compelled to utilize something like Plato’s Demiurge in the Timaeus to picture these operations.  Instead of Plato’s divine craftsman who shapes the world guided by his vision of the Forms, this Demiurge has something of a lower-level task of taking the string (or sounds, or hand-signals, or whatever) embodying the name Lukas, searching through the entities bearing that name (somehow the Demiurge has no problems with ambiguity), selecting one, seeing that this entity is indeed laughing, and returning a truth value.

This image of a Demiurge selecting entities and applying functions to them would have equal value for the Platonist and the fictionalist, at least if the Platonist hews to Plato.  For Plato regarded regarded his Forms (abstract objects) as real, but his Demiurge as just a myth, just a picture…in other words, a fiction. Likewise, our Demiurge, our all-seeing, untroubled-by-ambiguity selector of entities, is just a picture, a creature existing only in the realm of ‘as if’.  We need this picture as a psychological crutch to make up for that lack of any concrete implementation of the abstract operations which gets the bee in our bonnet buzzing. 

One side-note:  Santorini and Kroch have the function laughs returning both a truth value and a phrase (Lukas laughed).  But isn’t a function supposed to always return just a single value?