Category Archives: Closed World Assumption

Semantic Arguments vs. Adjuncts (Revised)

This is a version of the post below, revised so as to try to eliminate a number of confusions.

The Wikipedia article Argument (linguistics) starts its discussion of the argument/adjunct distinction by asserting that an argument is what is demanded by a predicate to complete its meaning, while an adjunct is not so demanded.  For example, if someone asks me “What is Joe eating?” my answer would be drastically incomplete if I replied “eats.”  My answer would still be drastically incomplete if I supplied just one argument, ‘Joe’, to say ‘Joe eats.’  Only when I supply a second argument, say, ‘a fried egg’, would my reply not create a sense of a question ludicrously left hanging and an answer simply not given.  The predicate _eats_ has two parameters ( shown here as ‘_’) demanding two arguments, such as  ‘Joe’ and ‘a fried egg’ for my reply to make any sense.

( This example, of course, is my own; I am offering it (maybe tendentiously?) in order to make drawing certain conclusions more natural. )

‘[I]n the kitchen’, however, is an adjunct, since nothing would be left ludicrously left hanging in the air were I to leave that phrase out of the proposition “Joe eats a fried egg in the kitchen.”  The predicate eats does not have a parameter demanding something like ‘in the kitchen’ as an argument.

This criterion — i.e., what is demanded by a predicate to complete its meaning … henceforth I will call this the ‘demands criterion’ — runs into trouble when one notices that sometimes eats demands two arguments, but sometimes demands just one.  One might say:  “Joe goes into the kitchen.  Joe is ravenous.  Joe sees food.  Joe eats.”  ( Imagine a novelist or short-story writer working in a certain style.)  The argument ‘a fried egg’ is not demanded in this particular piece of discourse.

But if ‘a fried egg’ is an argument, not an adjunct to eats, it would seem one would  have to abandon the ‘what is demanded by a predicate to complete its meaning’ criterion and find another criterion for what is to count as an argument and what is to count as an adjunct.  This a contributor (doubtlessly not the same person who put forward the ‘demands’ criterion) to the Wikipedia article cited above tries to do.

But if one wants to retain the demands criterion, they (I am intentionally using ‘they’ as a genderless singular pronoun) can assert that two different predicates, each with a different number of parameters, may get invoked when someone utters  ‘eats’ in a stretch of discourse.  Sometimes the one-place predicate _ eats is invoked, sometimes the two-place predicate _eats_.   Which predicate one uses is optional, depending upon what they feel is called for by the situation and what they want to do with the predicate.  Sometimes the context forces one to use, for example, the two-placed predicate (for example, in answer to the question ‘Joe is eating what?’; sometimes which predicate one invokes is purely a matter of choice.

If all of the predicates demand a certain argument (for example, ‘Joe’ in ‘Joe eats’), what is so demanded is an argument that is not also an adjunct.  If not all of the predicates demand a given argument (‘fried egg’, ‘in the kitchen’), that argument is an adjunct.  In this way, the demands criterion is rescued.

I picture the relations formed by these predicates as follows:

One-place relation formed by _eats:

EATS
PERSON_EATING
PERSON( NAME(‘Joe’) )
PERSON( NAME(‘Khadija’) )
PERSON( NAME(‘Juan’) )
PERSON( NAME(‘Kha’) )
PERSON( NAME(‘Cliff’) )

Here the key is, of course, PERSON_EATING.  The ellipses ‘…’ indicate all the further tuples needed to make this relation satisfy the Closed World Assumption.  (The Closed World Assumption states that a relation contains all and only those tuples expressing the true propositions generated by completing the predicate with the relevant argument(s).)

Two-place relation formed by _eats_:

EATS
PERSON_EATING FOOD_ITEM_BEING_EATEN
PERSON( NAME(‘Joe’) ) FOOD_ITEM( NAME(‘This fried egg’) )
PERSON( NAME(‘Khadija’) ) FOOD_ITEM( NAME(‘This souffle’) )
PERSON( NAME(‘Juan’) ) FOOD_ITEM( NAME(‘This fajita’) )
PERSON( NAME(‘Kha’) ) FOOD_ITEM( NAME(‘This bowl of Pho’) )
PERSON( NAME(‘Cliff’) ) FOOD_ITEM( NAME(‘This plate of Thai food with a 5-star Thai-spicy rating’) )

Here the relation formed by _eats_ is a subtype of the supertype formed by _eats.  That is to say, PERSON_EATING is a unique key in this relation, but it is also a foreign key to the PERSON_EATING attribute of the relation formed by _eats.

This means of, course, that in each tuple there is just one thing that the person is eating.  This constraint would be natural enough if one restricts the now of the present tense eats enough so that only one thing could possibly be getting eaten, for example, the egg one piece of which Joe is now bringing to his mouth via a spoon.  But, of course, if one stretches out this now enough so that our hypothetical author could write:   “Joe goes into the kitchen.  Joe is ravenous.  Joe eats a fried egg, an apple, and a salad,” one could not treat the one-place relation as a subtype of the two-place relation.  I think the solution in this case would be to treat what gets eaten as a meal, a meal comprising one or more items.  The meal then could be treated relationally the way an order and its order-items get treated, the orders going into one relation, and orders and order-items going into another, with the orders and order-items together comprising a unique key.

The predicate _eats_ _ (as in ‘Joe eats the fried egg in the kitchen’) can be treated the same way.  And so on for any number of possible adjuncts that a predicate might accept.

If I can get away with this move, then, an adjunct would be any argument that is 1) accepted by a predicate in which the corresponding relation is a subtype of another relation, and 2) the parameter which takes that argument corresponds to an attribute in the subtype relation which is not a foreign key of the supertype relation.  An adjunct then is one kind of argument.  Non-adjunct arguments (arguments that are just arguments, arguments simpliciter) correspond to a unique key in a supertype relation; adjuncts in turn are arguments not corresponding to any attributes in the subtype relations that are foreign keys to that unique key in the supertype relation.

Notice how this treatment of arguments vs. adjuncts (that is to say, arguments that are just arguments and arguments that are also adjuncts) corresponds to the way “optional (nullable) columns” in SQL tables get turned into actual relations, which cannot contain “null values”:

SQL Table (what is eaten is an optional or “nullable value”):

EATS
PERSON_EATING FOOD_ITEM_BEING_EATEN
Joe  Fried egg
Khadija
Juan
Kha Bowl of Pho
Cliff
 …

Here PERSON_EATING is a not-null column, and FOOD_ITEM_BEING_EATEN is a “nullable” column.

This looks like a single relation with an optional parameter (FOOD_ITEM_BEING_EATEN).  So if one both accepts the demands criterion and takes the  SQL table as their cue, PERSON_EATING would be an argument because it is not optional, i.e., always demanded and FOOD_ITEM_BEING_EATEN would be an adjunct because it is optional.  But then one has no way of accounting for when FOOD_ITEM_BEING_EATEN isn’t optional — for example in answering the question ‘what is Joe eating’?  (Compare with the COMMISSION column in the EMP table of Oracle’s sample SCOTT schema when the employee is a salesman.)  One would either have to try to explain away — an impossible task? — the times when eats surely seems to demand not one, but two arguments, or they would have to give up the demands criterion as the way to distinguish between arguments and adjuncts.

But of course SQL is confused.  The SQL table above is mushing together two different relations, the relation formed by _eats and the relation formed by _eats_.  Disentangle the two relations, and you get a two-fer.  You get rid of the nulls, and you also rescue the demands criterion for distinguishing between arguments simpliciter and arguments that are adjuncts.

When you disentangle the relations, you can see that what is optional, when one is talking about adjuncts, is not the attribute value (e.g., fried egg), but which predicate one invokes when they say eats.  To put it a different way, the attribute value is optional only because the predicate is.

I submit, then, that treating a verb as invoking different predicates whose corresponding relations are involved in subtype/supertype relationships does away with the confusing situation that challenges the demands criterion:  i.e., the initially confusing fact that sometimes an argument seems to be demanded for the verb, and sometimes it seems not to be.

Today’s homage to Plato’s SYMPOSIUM is Channing Tatum (aka Magic Mike) again, as in the previous post.

Channing_Tatum_BlackAndWhite

How can anyone get anything done with such beauty walking the earth?

Advertisements

The Predicate Returns A Relation

We have seen that the predicate:

x is to the left of y

is mapped to the truth value TRUE when Charles is substituted for x and Genghis Khan is substituted for y.  The Relation TO_THE_LEFT_OF comprises all true propositions and only true propositions that get generated when values are substituted for x and y.  So the predicate is a function whose range is the truth value TRUE for every proposition that is included in the relation, and FALSE for every proposition that is not included in the relation.

I think, however, that we would get a slightly simpler account if we see the predicate as a function returning Relations comprising the single proposition TRUE, or the single proposition FALSE.  In the Relational Algebra, we would get a relation comprising the single tuple (and therefore proposition) TRUE if, after doing the Restriction that gives us:

Charles is to the left of Genghis Khan.

we then projected on the null set of attributes (“columns”).  We would then end up with Chris Date’s TABLE_DEE, that is, the Relation with cardinality 0 (o attributes, that is, 0 “columns”) and a single tuple.  TABLE_DEE is the Relation that corresponds to (I guess I should say ‘is identical with’) the weird classical logic proposition TRUE.  The predicate returns the proposition TRUE wrapped in the Relation TABLE_DEE when the Charles and Genghis Khan substitution is made.

Correspondingly, when John is substituted for x and Genghis Khan is subsituted for y, so that we get:

John is to the left of Genghis Khan.

the Restriction selects no tuple in the Relation TO_THE_LEFT_OF.  We then have a Derived Relation with a cardinality of 2 (i.e., the Relation has 2 “columns”) holding the null set of tuples.   If we then project on the null set of attributes, we end up with a Relation of cardinality 0 comprising 0 tuples.  Chris Date calls this Relation TABLE_DUM, and it holds the tuple, that is to say, the proposition FALSE.  The predicate returns the proposition FALSE wrapped in the Relation TABLE_DUM when the John and Genghis Khan substitution is made.

Thinking of the predicate as returning either TABLE_DEE or TABLE_DUM simplifies things a bit, because it means we never have to leave the Relational Algebra when modeling the predicate.  Everything gets explained in terms of just one set of operations, the operations of the Relational Algebra.

 

 

 


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.