In Spanish, in constructions like He has a brother named Brian, the past participle must agree with the complement of the original verb, in this case, to name. So, Someone (doesn’t matter who) named the brother Brian, so Brian is the complement of name, and ultimately named and brother must agree in number and gender:
(1) Tiene un hermano llamado Brian
Has a brother:masc named.masc Brian
"He has a brother named Brian." [spa]
The grammar currently overgenerates and will admit any combination of genders here. I am trying to decide where the right place is to add constraints.
I believe the desired tree is this one:
Everything is properly linked and the gender of hermano (brother) is properly specified.
But unfortunately, the grammar also happily produces the same kind of tree for the ungrammatical (2):
(2) Tiene una hermana llamado Brian
Has a sister:fem named.masc Brian
Intended: "He has a sister named Brian." [spa]
In the tree, the third V in the unary chain is the past participle rule, and in that structure, the AGR value is still easily accessible:
But then the first complement of the verb gets dropped, the top V in that chain is the optcomp rule. I am not sure whether this makes sense, or maybe that is the problem. If the complement needs to be realized through something other than the head-complement rule, then it should either be dropped or slashed. In the ERG, in the similar construction, it will be dropped, and the tree will look similar, with an AdjPart phrase formed from the VP named Brian and the resulting AP then modifying brother.
But if the complement is dropped, then is it a reasonable thing to try and hold on to the agreement information of that dropped complement? One issue is, the PNG values are appropriate for AGR structures of type _individual but verbs have events and those do not have PNG. So I am not quite sure how to propagate the agreement features starting at that top V node which is the optcomp.
The optcomp phrase has a feature called LSYNSEM which I haven’t seen before. Maybe I could use that? But like I said, I don’t know what it is for, originally. Below first a very large picture showing the geometry and then the LSYNSEM more closely. It is a HEAD feature:
I can constrain the values of this LSYNSEM thing to the head daughter’s of the optcomp rule:
I can then constrain the adj-participle phrase to identify these agreement values with its own and this way I get rid of the tree. The question is, what is this LSYNSEM and am I trying to use it properly? Does anyone know anything about LSYNSEM?