Notes on computational linguistics.pdf - UCLA Department of ...

Stabler - Lx 185/209 2003
children(Parent, Children) :- subtree(Parent, _/Trees), children(Trees, 1, Parent, Children).
children([], _, _, []).
children([Tree|Trees], I, Parent, [n(I,Tree,Parent)|Children]) :- I =< 3, I1 is I+1, children(Trees, I1, Parent, Children).
% siblings(Node, Siblings) is true iff Siblings is a list of siblings
% of Node. The version presented here only works with unary and
% binary branching nodes.
siblings(Node, []) :- root(Node). % Node has no siblings if Node is root
siblings(Node, []) :- children(_, [Node]). % Node has no siblings if it’s an only child
siblings(Node, [Sibling]) :- children(_, [Node, Sibling]).
siblings(Node, [Sibling]) :- children(_, [Sibling, Node]).
5.2 Categories and features
(8) With these notions, we can set the stage for computing standard manipulations of trees, labeled with
X-bar style categories:
x(Category,Barlevel,Features,Segment)
where Category is one of {n,v,a,p,…}, Barlevel is one of {0,1,2}, Features is a list of feature
values, each of which has the form Attribute:Value, and Segment is - if the constituent is not a
proper segment of an adjunction structure, and is + otherwise.
So with these conventions, we will write x(d,2,[],-)/ -hamlet instead of dp/[hamlet/[]].
(9) The following definitions are trivial:
category(Node, Category) :- label(Node, x(Category,_,_,_)).
barlevel(Node, BarLevel) :- label(Node, x(_,BarLevel,_,_)).
features(Node, Features) :- label(Node, x(_,_,Features,_)).
extended(Node, EP) :- label(Node, x(_,_,_,EP)).
no_features(Node) :- features(Node, []).
(10) There are at least two ways of conceptualizing features and feature assignment processes.
First, we can treat features as marks on nodes, and distinguish a node without a certain feature from
nodes with this feature (even if the feature’s value is unspecified). This is the approach we take in this
chapter. As we pointed out above, under this approach it is not always clear what it means for two
nodes to “share” a feature, especially in circumstances where the feature is not yet specified on either
of the nodes. For example, a node moved by Move-α and its trace may share the case feature (so that
the trace “inherits” the case assigned to its antecedent), but if the node does not have a specified case
feature before movement it is not clear what should be shared.
Another approach, more similar to standard treatments of features in computational linguistics, is to
associate a single set of features with all corresponding nodes at all levels of representations. For
example, a DP will have a case feature at D-structure, even if it is only “assigned” case at S-structure or
LF. Under this approach it is straightforward to formalize feature-sharing, but because feature values
are not assigned but only tested, it can be difficult to formalize requirements that a feature be “assigned”
exactly once. We can require that a feature value is assigned at most once by associating each assigner
with a unique identifier and recording the assigner with each feature value. 20 Surprisingly, it is an
open problem in this approach how best to formalize the linguist’s intuitions that a certain feature
value value must be set somewhere in the derivation. If feature values are freely assigned and can be
checked more than once, it is not even clear in a unification grammar what it means to require that a
feature is “assigned” at least once. 21 The intuitive idea of feature-checking is more naturally treated in
a resource-logical or formal language framework, as discussed in §9.
(11) To test a feature value, we define a 3-place predicate:
20The problem of requiring uniqueness of feature assignment has been discussed in various different places in the literature. Kaplan
and Bresnan (1982) discuss the use of unique identifiers to ensure that no grammatical function is filled more than once. Stowell
(1981) achieves a similar effect by requiring unique indices in co-indexation. Not all linguists assume that case is uniquely assigned;
for example Chomsky and Lasnik (1993) and many more recent studies assume that a chain can receive case more than once.
21In work on feature structures, this problem is called the ANY value problem, and as far as I know it has no completely satisfactory
solution. See, e.g. Johnson (1988) for discussion.
64