[LFG] Thoughts on Distributive Attributes -- NOT a conference announcement (!!)

[Avery Andrews]

Here I'll break a tradition of using the LFG list only for conference announcements, and post some thoughts, about 'distributive attribute' from Dalrymple and Kaplan (2000) (and earlier work), defined in Dalrymples's 2001 book (p 158) as:

If a is a distributive feature and s is a set of f-structures, then (s a)=v iff (f a)=v for all f-structures f that are members of the set s.

I think there are some issues about what this means and exactly how it is supposed to work, which we can start considering by contemplating the solution algorithm of Kaplan & Bresnan 1982:273-274 and how it might be modified to manage distribution, and things do not seem to be entirely unproblematic.

For one thing, in the algorithm as written, I see nothing about sets and their membership, which would be an issue perhaps for 'NP-splitting' of adjuncts in a language such as Warlpiri.  But setting that aside for some other time, there are further problems with distribution and hybrid objects.  Suppose we're trying to parse 'John likes and respects Susan'.  We might first get f_1 as the f-structure correspondent of the subject, and then f_2,f_3, f_4 for S, VP and first V, all respectively, equated by the ^=v annotation.  So that the latter three would be labels for a single object of type `f-structure', with a SUBJ attribute, but then we see 'and', and learn that actually we are dealing with a coordinate V and therefore that the f_2, ... f_4 are labelling to a hybrid object, and that there is a new f_5 labelling to one of its members.

The reanalysis of the V as part of a coordinate V rather than as an immediate daughter of VP might be seen as a typical kind of step in c-structure parsing, but we also have to do something about SUBJ, which needs to distribute, as was first put in as a daughter of S and then sister of VP.

It seems to me that LFG has an implicit idea that the solution algorithm (for the f-structure from a given c-structure) should be 'monotonic' (ill-defined as this term may be), and that therefore we do *not* want to reassign SUBJ as something other than an attribute of the f-structure of S, but, rather, think of 'hybrid object' as a subtype of 'f-structure', so that when we learn that the f-structure labelled f_2,3,4 is a hybrid object, we want to in effect 'copy' the SUBJ attribute onto each member, as it is appears, starting with f_5. Of course we don't want to make actual copies, especially of the value of SUBJ, but perhaps copy references/pointers to the attribute-value pair,
which would be shared.

But for constraining specifications, the situation is a bit different. It might be the case that the attribute has been specified independently in each member; then to evaluate a constraint such as (^ CASE)=c ACC for the entire structure, we need to examine the CASE value in  each member, since it won't necessarily be the case that the CASE attribute has yet been written into the top level of  the hybrid object.

This structural difference does look a bit disturbing, and one way to eliminate would be to 'erase' the upper references to distributed attribute-value pairs at some point after the defining equations are solved, or alternatively do a 'distributive attibute check' before checking the constraining equations.  But I think doing nothing is also viable.


A final and very different issue is what happens if you want to say that a composite attribute such as CONCORD CASE is distributive, while CONCORD NUM is not; things seem to me to be even messier if you allow this, so perhaps it should be forbidden. It seems to me that the INDEX/CONCORD distinction is well motivated, although perhaps not beyond all reasonable doubjt, but this does not require that both kinds of agreement involve distinct upper level attributes; for example INDEX could exist while the traditional CONCORD attributes were each on their own, not contained in CONCORD, which would then not exist.


-          Thoughts welcome

  Avery Andrews
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/lfg/attachments/20171008/2d8373e4/attachment.htm>