Syntax I

A question I’ve gotten a couple of times is whether you always have an nP or whether you only have it “when you need it.” I’m sorry to report that the answer is that we always have it, whether we need it or not. Here’s the logic:

We need the nP in order to handle deverbal ditransitive nouns, such as “John’s gift of cheese to Mary”, for the same reasons that we needed a vP in order to handle ditransitive verbs, such as “John gave cheese to Mary”.

We incorporated nP into the Hierarchy of Projections, like vP: D > n > N.

At this point, that means that whenever we have an N, we always have an n just above it. It appears (again based on evidence from ditransitives) that N moves to n (just like V moves to v), so n always has a [uN*] feature.

And, so, we end up drawing pretty much every single DP with the full range of projections and movements, e.g., “cats” and “the book of poetry”

      DP                DP
    /   \             /   \
   D     nP          D     nP
∅indef  /  \        the   /  \
       n   <NP>          n    NP
      / \               /\   /  \
     N   n             N  n <N>   PP
   cats             book         /__\
                                 of poetry

As the trees grow taller, more possibilities appear to be available for where to adjoin things in the tree. So, let me quickly summarize what we have so far:

Within TP, we can adjoin adverbs and PPs to TP and to vP. The ones that are adjoined lower, to vP, are usually ones that describe the manner or sometimes frequency with which the event/state occurs (e.g., sloppily or often). The ones that are adjoined higher, to TP, are usually ones that describe the time the event/state occurs, or expresses an opinion of some sort about the event (e.g.,yesterday, or fortunately). Sometimes, but not always, these adjuncts are free to appear on either side of the phrase to which they adjoin. Adverbs are particularly flexible and can usually appear on either side of the TP or vP to which they are adjoined. PPs are less flexible and generally can only appear to the right of a vP, although they can appear on either side of a TP.

The by-phrase in a passive construction would be adjoined to the PassP, rather than to vP or to TP.

Within DP, we can adjoin adjectives and PPs to nP. Adjectives are generally to the left of nP, and PPs are generally to the right.

Nothing can be adjoined to DP.

Nothing can be adjoined to CP.

We have never seen anything that can be adjoined to NP or to VP, although in class there was some speculation that in order to explain the facts about the Italian DP, we might consider allowing adjectives to adjoin to NP as well.

Two things I want to mention here. First, the little n is quite a pain at times, because now that we have it, and it is incorporated into our Hierarchy of Projections for the DP, we simply always have to have it. We very rarely need it, but it is nevertheless required now, just like little v is in a verbal clause.

For the revisions of HW7, if you’re still working on those, you don’t need to do this, although you’re free to. For HW8, you do need to do this.

As an example of what a pain little n is, here is what Pat looks like now. It’s a DP (it can get a θ-role, e.g., Agent, and it can be a subject, so it is a DP), and according to our HoP, it must have an N, an n, and a D. Just as V always moves to v, so does N always move to n. So, a proper name like Pat comes out looking like this:

         DP
        /  \
       D    nP
  ∅proper   /  \
           n    <NP>
          / \
         N   n
       Pat

That is: Merge the N(P) Pat with n to form the nP. Move N up to adjoin to n. Merge the silent ∅_proper with nP to form a DP. This is now how even the simplest of DPs need to look. (The only exception is with pronouns, which are themselves just Ds).

Now, on to the second thing, the sentence John gave Mary a book. The verb here is a ditransitive, there are three θ-roles (Agent, Theme, Possessee), and all three DPs need to get their case checked. But what checks what? In class and in a previous blog post I indicated that with this kind of ditransitive, where there is no preposition to and where the meaning includes something like an abstract ‘have’ (John caused Mary to have the book), the V itself has a [ucase:acc] feature that checks one of them.

So, let’s put it together, and don’t forget that, regardless of the method you use to draw the tree, the theory says that these are built from the bottom up. As a first step, let’s build all of the DPs, just so we have them ready. To build a book, we Merge the N book with n to form nP, move N up to n, and then Merge that with the D a to form a DP. John and Mary are formed just the same way (just like Pat was above).

         DP
        /  \
       D    nP
       a    /  \
 [ucase:]  n    <NP>
          / \
         N   n
       book

After that, we first Merge a book with V, to form a V′. The V has a [ucase:acc] feature and once V and the DP a book are Merged, the [ucase:acc] feature of V can see the [ucase:] feature of a book and so it values it as accusative, and checks it, like so:

             V′
            /  \
          V     DP
 [ucase:acc]  /  \
       give  D     nP
             a    /  \
   [ucase:acc]   n    <NP>
                / \
               N   n
             book

Then, the DP Mary is Merged with this, to form a VP. Mary still has a [ucase:] feature that has to be checked. (I’ll start using [acc] to mean [ucase:acc] to save space.)

                VP
              /    \
            /        \
         DP           V′
        / \          /  \
       D   nP      V     DP
  ∅proper  / \   [acc]  /   \
[ucase:]  n <NP> give  D      nP
         / \           a     /  \
        N   n        [acc]  n    <NP>
     Mary                  / \
                          N   n
                        book

Next, according to the Hierarchy of Projections, we merge little v with this to form a v′. Little v has a [ucase:acc] feature, which at that point can see, value, and check the [ucase:] feature of Mary. Then, big V moves to little v.

             v′
           /    \
         /        \
       v           VP
      / \        /    \
     V   v      /       \
 [acc] [acc]  DP         V′
  give       / \        /  \
            D   nP   <V>    DP
       ∅proper  / \        /  \
        [acc]  n  <NP>   D     nP
              / \        a    /  \
             N   n    [acc]  n    <NP>
          Mary              / \
                           N   n
                         book

Next, the Agent (John) is Merged in, forming the vP. It, like any DP, has a [ucase:] feature that needs to be checked. This feature will be checked when we Merge T, which has a [ucase:nom] feature; at that point, the [ucase:nom] feature of T can see the [ucase:] feature of John, and so it values it and checks it.

         T′
       /    \
     /        \
    T          vP
[nom]        /    \
           /         \
         DP           v′
        /  \         /    \
       D   nP       /        \
  ∅proper  / \      v           VP
    [nom] n  <NP>  / \        /    \
         / \      V   v      /       \
        N   n  [acc] [acc]  DP         V′
     John       give       / \        /  \
                         D   nP    <V>    DP
                    ∅proper  / \         /  \
                     [acc]  n  <NP>    D     nP
                           / \         a    /  \
                          N   n     [acc]  n    <NP>
                       Mary               / \
                                         N   n
                                       book

And finally, John is moved to SpecTP, we Merge C, and we’re done. John gave Mary a book.

        CP
      /    \
     C       TP
     ∅     /    \
         /        \
       DP          T′
      /  \        /   \
     D    nP     T     vP
∅proper  / \   [nom]   /  \
 [nom] n  <NP>     <DP>    v′
      / \                /   \
     N   n              v       \
  John                 / \        VP
                      V   v       /   \
                  [acc] [acc]  DP       V′
                   give       / \      /  \
                             D   nP  <V>    DP
                        ∅proper  / \        /  \
                         [acc]  n  <NP>   D     nP
                               / \        a    /  \
                             N   n    [acc]   n    <NP>
                            Mary             / \
                                            N   n
                                          book

Let me just clarify something that quite a few people seem to done incorrectly on the homework. We’ve been talking a bit, here and there, about possessive constructions, like Their cheesecake or Pat’s lunch or The Man in the Yellow Hat’s monkey. In each of these constructions, there’s a possessor (the part before the ’s) and possessee (the part after the ’s).

It’s a bit hard to write about this because we have just added a level of complexity, with the PossP, although I’m trying to speak about the homework that was due prior to the introduction of PossP. However, the main point I wanted to make here is that the possessors in all of those examples just listed are the same kind of thing. They are interpreted as getting a Possessor θ-role.

But you wouldn’t say that Pat is a D, particularly not after having read the blog entry on ∅_proper a couple of days ago. And certainly The Man in the Yellow Hat is no D. It’s very clearly a whole DP. Like Pat. And, like their (in their cheesecake).

Generally, things that get θ-roles are DPs. There are exceptions to that generalization (a PP can get a Goal θ-role, and a TP or a CP can get a Proposition θ-role), but not many. So, Possessors are DPs.

It’s true that their as a pronoun is a D, rather like cheesecake is an N. And it’s true that you can say we linguists (are a jolly bunch), but that doesn’t mean the same thing as our linguists. In our linguists, their cheesecake, Pat’s lunch, etc., there is a possessor, and the possessor is in the specifier of DP. It is not the D itself. In possessive constructions, the D (head of the whole DP) is ∅_gen, and the possessor is in the specifier. So if you have a possessor in the DP, there must be an ∅_gen (or, perhaps, every).

(And, as of the most recent class, the possessor DP moves to that position from a lower specifier of PossP. So, we can add to the previous statement: Also, if you have a possessor in the DP, there must have been a PossP in whose specifier it is originally Merged.).

So, the version of their cheesecake as of when the homework was assigned/due, would be:

                DP
               /  \
             DP     D′
          their   /  \
                 D    NP
               ∅gen   cheesecake

And the version now that we have PossP as well, would be: (see, e.g., p. 274 in the textbook)

                DP
               /  \
             DP     D′
          their   /  \
                 D    PossP
               ∅gen   /  \
                   <DP>   Poss′
                          /  \
                       Poss   NP
                             cheesecake

Just a couple more notes about the previous homework. Some of you might have the word “linearization” written on your homework. If you see that, it means that one or more of your trees were drawn in such a way that the words wouldn’t be in the right order if you pronounce the structure as it was drawn. Remember, whenever a node has two daughter nodes, you draw the one that is pronounced first to the left of the one that is pronounced second.

A trickier point, that was brought to my attention earlier today, concerns the interaction of case and the “floating quantifier” all. Let me say at the outset here, there is—to my knowledge—no fully satisfying account of floating quantifiers. Some things you get for free, some things you have to stipulate. (Also, I’ll call all a D, rather than an N, since that’s what we’re considering it to be now).

The analysis that the book/handouts promotes is one in which all is a D that is unusual in that it takes a DP complement. So, it has the features [D] (because it is a D) and [uD*] (because it takes a DP complement). Here’s the sticky point: We also believe now that each and every D has a [ucase: ] feature that must be valued and checked. So, since they all is a DP with a DP inside, two different things need case checked. At this point, there are two routes we could take. One is to assume that the [ucase:nom] feature of T can check them both (given that neither of they all and all is closer to T than the other). The other is to assume that all (and both) is special not only in that it is a D with a [uD*] feature, but that it is a D without a [ucase: ] feature. It’s a tough call which is better. Out in the wider world of syntax, it is standardly assumed that there is a one-to-one relationship between case checkers and DPs (that is, the case checkers—T, v, P, etc.—each only ever value and check case on a single DP), which might sway us toward Route 2. At this point, we don’t derive this directly, although it will almost always turn out be one-to-one anyway. On the other hand, it is not clear that any harm will come to us if we take Route 1. In our system, already-checked features can check still-to-be-checked features (see recent blog note about this), and Route 1 allows us to keep the generalization that all Ds need case (that is, have a [ucase: ] feature) without exceptions.

I think I’ll leave it without a definitive resolution, but with maybe a hint of a preference for Route 1 in the context of this class. Until/unless there is a stated policy about which is the approach to use in this class, either one is fine. If you can at least see the issues involved here, that’s probably the important thing.

One thing I want to remind you of, even if it is perhaps a bit late in the day: Proper names are now DPs. Anything that can get a θ-role is a DP. But the name part itself is actually just an NP—see the handout and/or p. 260 in the Adger textbook.

The practical upshot of this is that pretty much any time you have occasion to draw a proper name, it will now have a structure like these:

       DP                DP                       DP
      /  \              /  \                     /  \
    D      NP          D     NP                D      NP
 ∅proper   Pat      ∅proper  New Jersey      ∅proper   Qdoba

I observe that there is an inconsistency between what Adger says on p. 262 and what I said in the recent blog entry about how the interpretable φ-features of an N can be used twice (once to check the uninterpretable φ-features on a D, and again to check the uninterpretable φ-features on T).

Adger suggests that the φ-features of N value and check the [uφ: ] feature of D, and then that checked feature of D values the [uφ: ] feature of T.

Adger’s claim is a little bit non-standard in the broader world of minimalist syntax, which is why I didn’t initially follow it. But here’s why he said that, and upon reflection, why I think we need to adopt Adger’s view of this. (With respect to the trees you’ve drawn so far, even on this homework, it isn’t going to make them look any different.)

We have already implicitly adopted the view that a checked uninterpretable feature can value another unchecked uninterpretable feature. The place we did that is in the mechanism for subject agreement. The way subject agreement works is that T has a [uφ: ] feature, and when T is merged, it sees the φ-features of the subject and is valued and thereby checked. But the second step is that this now-valued-and-checked [uφ:3sg] (for example) feature of T then turns around and (along with the interpretable [tense] feature on T) values the next [uInfl: ] feature down. So, we already do have a case where an already-checked feature checks another feature.

Given that, Adger’s approach on p. 262 is the most consistent way to think about how the [uφ: ] feature of T is valued. The φ-features of the N are not in fact used twice, they are used once to value and check the [uφ: ] feature of D, and the checked [uφ:…] feature of D then values and checks the [uφ: ] feature of T.

In the textbook (e.g., p. 261), Adger suggests a feature [unum: ] goes on Ds, which is how we ensure that the determiner agrees in number with the noun it takes as a complement.

In class (and earlier on the blog), I’ve been using [uφ: ] to accomplish essentially the same thing. Since number is one of the features included in the φ-features (person, number, gender), the use of [uφ: ] is more general (and, indeed, doesn’t refer to anything new).

The prediction I make (again, recall the light box) is that it would at least be possible for gender or person to make a difference in how a determiner is pronounced—at least in some languages. And, in fact, in Romance languages (for example), gender and number do both play a role in determining the pronunciation of the determiners.

So, use [uφ: ] and when you read the textbook and see Adger writing [unum: ], think “[uφ: ]” to yourself.

As for where [uφ: ] goes, the answer is essentially: on every D except pronouns. On any D that takes an NP complement, it will agree in φ-features, even you don’t see/hear it reflected in the pronunciation.

Just to clarify, since I’ve talked to a couple of people so far that have had some (perhaps momentary) confusion on terminology: Agreement features (person, number, gender) are often referred to as φ-features—that is, “phi features.” The role a DP plays in an event is determined by the θ-role it gets (that is, “theta role”). And ∅ represents something silent, which we will often call “null” or “zero”.

Just to be clear, even though each of these (∅, φ, θ) is drawn as a circle with a line through it, they have distinct names (null, phi, theta) and meanings, and you want to keep clear which one is which.

Here’s what happened in class last time: We looked at some constraints on the allowable shapes of noun phrases and worked up to the conclusion that what we had been calling noun phrases are actually headed by D. So, they’re DPs. Given that we now have DPs, with NPs inside, we have some things to clarify. There were a number of properties that we assumed held of noun phrases, but now we need to figure out which of those properties are properties of D and which are properties of the N inside.

Many of the properties we thought were of N are actually of D. So: it is DPs that get θ-roles (not NPs), DPs that need case (not NPs), DPs that can be moved to SpecTP to satisfy the [uD*] (”EPP”) feature of T. One thing that still belongs to N are the φ-features (person, number, gender): It is the noun staplers that is intrinsically plural in the DP those staplers.

Since it is DPs that need case, the [ucase: ] features go on the D (not on the N).

Notice that it is quite possible for a DP that gets one case to have other DPs inside it that get other cases. Every DP needs its case checked, and everything that can check case (T, v, P, and the special V that appears in double-object constructions) can only check the case feature on a single DP.

To give an example, here’s what my dessert would look like in the sentence My dessert is burning. The subject is my dessert and so the whole DP gets nominative case. But the possessor my gets genitive case. I’ll draw the top of the tree, with the case features (I am leaving out the [uφ: ] features, among others):

                  TP
                /    \
             DP        T′
           /    \      |  \
         DP      D'    T   ...
    pronoun    /   \   ^----------[T, uD*, ucase:nom, …]
 [D, φ:1sg,   D      NP
 ucase:gen]   ∅poss  dessert [N]
             [D,
             ucase:gen,
             ucase:nom]

(Side note) Ok, so we end up with two [ucase: ] features on the ∅_poss. That’s perhaps not the best aspect of this theory, we need to stipulate something that says that the one that determines the pronunciation of case is the one that was valued (or perhaps the last one that was checked). This came about because ∅_poss both checks the case of something else (the genitive pronoun) and needs its own case checked. So, this only arises when we have a D that can check the case of something else, and there are only a small number of those (basically, just ∅_poss and maybe every in the king’s every whim).

To clarify how the tree above came about, let me build the DP up step by step:

            D′
          /   \
        D      NP
     ∅poss  dessert [N]
   [D, φ:1sg,
   ucase:gen,
   ucase: ]

Then, we put in the possessor, a pronoun with the features [D, φ:1sg, ucase: ], and its [ucase: ] feature is valued and checked by the [ucase:gen] feature of ∅_poss.

             DP
           /    \
         DP      D′
    pronoun    /   \
 [D, φ:1sg,   D      NP
 ucase:gen]   ∅poss  dessert [N]
             [D,
             ucase:gen,
             ucase: ]

Then, the derivation continues: We merge this in with V burn, merge the result with v (unaccusative), merge the result with T, at which point the [ucase:nom] feature of T can see the still-unvalued [ucase: ] feature on ∅_poss, and so it checks and values it, and the whole DP my dessert moves to SpecTP to check the strong [uD*] (”EPP”) feature of T. The top of the tree would then look like the one I drew above.