Skip to content

Deprel of list item enumerators #1027

Description

@nschneid

In lists like "1. an item 2. another item" or "it depends on (a) first condition, (b) second condition, (c) third condition", it is not obvious how the list item marker—which we can call an enumerator because it indicates the position in a sequence—should attach.

The list docs currently note the "de facto" approach described in #156, which is to call it nummod.

@manning in #156 (comment)

These kind of list structures occur quite a bit in the English Web Treebank, and we have discussed them. The one thing that seems very clear is that the content and not the marker of each item should be the head. De facto, we have also been using nummod – regardless of whether it is numerals or roman numerals or letters – for the dependency. But, we don't want to make a strong argument for that. It just seemed the least bad thing to do by the time we discussed this case, after the UD 1.0 dependency set was frozen.

(That is, earlier we had introduced the list dependency to have something for organizing the items of lists and had started using appos for joining the items of key-value pairs in lists like "Name: Stuart Smith", but it seemed like these couldn't also be appos, and they are a form of numbering, so, it seemed the least bad choice at the time. Better suggestions for the future welcome! But we probably do want to be careful about introducing too many extra relations for paralinguistic elements.)

But the nummod docs say explicitly that it is for an expression to "modify the meaning of the noun with a quantity", and "a number that serves as a label for an entity rather than denoting quantity is not nummod".

The core group discussed and determined that discourse is the better label for attaching list item enumerators. I will update the guidelines to reflect this.

(Bullets are treated separately from enumerators: they are tagged PUNCT and therefore must attach as punct. A proposal to change the tag to SYM and uniformly attach list item markers as discourse was discussed, but did not attract enough support to amend the current rule about bullets.)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions