Limitations to manipulating order with INIT

This one is mostly for Emily, but I thought I’d post it here in case it’s of interest to anyone else.

So, I’m using INIT to manipulate the relative ordering of possessor and possessum in cases where they’re joined by head-comp. I’m also planning to use INIT to manipulate the order of a possessor/possessum-marking adposition and the thing it marks, which is its complement. The problem is that in some languages (specifically Fijian) the two phrase types have contradictory order, but the order of both must be controlled by a single INIT value – in the case of Fijian, the INIT value on the possessum-marker.

Here’s an example to show what I mean:

a    liga  i     Jone
the  hand  POSS  John
'John's hand'

The possessum-marking word i first combines with liga ‘hand’ via comp-head. This means that i must have the value [ INIT - ]. Then it needs to combine with Jone via head-comp, but in order to do that, it’d need to have the value [ INIT + ]. The choices I see are to either 1) fail to model this construction and just validate against this particular combination of features (which is admittedly going to be pretty rare), or 2) when these features arise in this combination, underconstrain the possessum-marking word (i in the Fijian case) for INIT, and then add warnings to the questionnaire to let the user know that while you’ll parse the strings they want to parse, you’ll end up parsing a lot of garbage too.

I suppose there’s also a third option of adding some new feature, like INIT but distinct from it, that governs attachment order in the very limited case of a marker word attaching to the thing it marks. I’m not sure what the arguments for and against that would be.

What’s the evidence that these are both head-comp structures?

So here is the argument for each structure:

  1. The phrase that connects possessor and possessum is head-comps (in this very particular case which you see in Fijian) because the possessum is marked and the possessor is not. This is the case I’d want to call head-mod, except heads can’t select for their modifiers, and so the possessum wouldn’t be able to ‘access’ the index value of the possessor and therefore correctly construct the poss_rel.

  2. The phrase that connects the marker word to the possessum is head-comps basically because it’s baked in as a head-comps analysis in all cases. Head-spec would probably also do the same work, but I’ve used head-comps for all these constructions. Having the marker be the head in a head-comps phrase allows it to carry the poss_rel and still have access to the indices of both the thing it marks and the other constituent.

In order to get this solved, I went with the option of just underconstraining the order of the marker in the case where there are differing orders for the major possessive phrase and the minor phrase consisting of the marker + possessum. This is such a rare case (that just happens to be found in Fijian) that it doesn’t seem to me to be worth it to majorly rework things to address it. The customization system will warn the user that things will be underconstrained. Let me know if this won’t work for any reason.

Plot twist! Turns out that even if you don’t constrain the possessum-marker’s INIT value, you STILL can’t model the facts of Fijian. Here’s the IGT again for reference:

a    liga  i     Jone
the  hand  POSS  John
'John's hand'

The problem is that the comp-head phrase (liga) (i) that consists of possessum + marker must act as the head in the head-comp phrase (liga i) (Jone). The comp-head phrase has the constraint [ INIT - ] on its head-dtr. Since INIT is a head feature, this means that the parent of comp-head phrase has the value [ INIT - ] as well. That means that when it comes to building the head-comp phrase liga i Jone, the head is constrained to be [ INIT - ], and so it will only build a comp-head phrase. This means that, even if the possessum-marking word i does not itself constrain the value of INIT, that constraint comes in from the phrase type in a way that doesn’t seem preventable to me.

Here’s my proposed way of dealing with this:

  1. Validate against cases where the major possessive phrase type is a head-comp phrase of some kind and a marker word on the possessum requires a different order.
  2. Report the real numbers for Fijian, then report the numbers if you do some order fudging in the test suite, so that I accurately represent both this shortcoming of the library and what gains would be made from being able to handle these order issues.
  3. Leave a real solution as future work, since it would require revamping the way all possession-marking words attach to the constituent they mark, which is a very far-reaching change and not realistically possible at this point. Additionally, if I switched from using head-comp to model the complex of possessive-marker + possessor/um to using head-spec, then this same issue might arise in cases where head-spec is used to model the major possessive phrase. (I’m not 100% sure there wouldn’t be a work around in this case, but it seems likely to be an issue.) The current arrangement actually keeps the small territory that can’t be modeled to a very small subset of actual, attested languages.

That sounds like a reasonable strategy. One last question from me though: How do you know this is possessum marking and not possessor marking?

Right, yes, that issue :slight_smile: So, I’m going mostly off of Dixon’s analysis here, and he says that that i is actually an affix on the possessum. Now, in cases where the possessum is followed by a classifier, that ‘affix’ shows up on the classifier instead, which seems like a clear argument for it being a clitic, to me, which is why I’m not analyzing this as an affix (which would be many times easier, turns out :slight_smile: ). But he doesn’t really argue for it being attached to the possessum rather than the possessor – he simply asserts that this is the case.

In that case, I’d suggest:

(1) Not supporting this particular combination (and checking for it in validation)
(2) Modeling Fijian as possessor marking, unless there’s evidence to the contrary