Pros and cons of the CoNLL style file format

[bguil]

Context: Preliminary discussions before WG1 day of UniDive (7 February 2024 in Naples). See here for more details.

---

The purpose of this discussion is to gather opinions on the pros and cons of the CoNLL style file format.

[dan-zeman]

Pros of CoNLL-U:

• A de-facto standard, which means:
  • Many people know it
  • There are many tools around that can process it
• It is extremely easy to process, so writing a new tool is quick. Many tasks can be achieved even with simple shell tools, such as grep
• The basics are very easy to learn by newcomers (although details of language-specific features, attributes in MISC etc. may be complex)
• Long-term perspective of staying THE format of UD. (If there is ever a version 3 of the UD guidelines, there are chances that the (already existing) CoNLL-U-Plus format will be promoted to the UD format; but it is extremely unlikely that something radically different from CoNLL-style formats will be chosen.)

[bguil]

Thanks @dan-zeman for your comments.
A few cons:

• The core part of a CoNLL-like file (encoding of dependency trees) is easy to process, but but less so when considering multiple extensions.
  • introduction of special lines in CoNLL-U for multi-word tokens
  • extension of the format to handle graphs instead of trees (Enhanced UD and Deep-sequoia have taken different incompatible ways of doing this)
• Although the UD validation script can help, the current format is not fully specified
  • The MISC column is overloaded. It is now difficult to process it in a meaningful way for all UD treebanks
  • The comment lines (starting with #) are under-specified and therefore used inconsistently in different treebanks

I think the currrent situation can be improved by using CoNLL-U-Plus (with more constraint column definitions). This format also covers the CUPT format currently used in MWEs annotation of Parseme.

Another option would be to use a more standard file encoding such as JSON, where we would not have to deal with the use of special characters (#, |, =, _, TAB) and their escaping. It would also be easier to make it evolve with new annotations.

[dan-zeman]

Another option would be to use a more standard file encoding such as JSON, where we would not have to deal with the use of special characters (#, |, =, _, TAB) and their escaping. It would also be easier to make it evolve with new annotations.

Every format has its special characters :-)
Including JSON.