<commit_before>---
layout: base
title:  'Working Group on Enhanced Dependencies'
udver: '2'
---

# Working Group on Enhanced Dependencies

(Summary of discussions between <NAME>, <NAME>, <NAME>, <NAME>, <NAME> and <NAME>)

General objective of the working group:

* clarify status of enhanced dependencies
* provide modified guidelines sufficiently in advance, for people to use them for next v2.2 version 
  (cf. not decided yet: whether enhanced deps are included in the UD shared task of spring 2018)

Note: Within a v2 release, there cannot be major modifications of the current enhanced guidelines, but we do also include in this page discussion from a broader perspective

**Content:**

* [Discussion on status of enhanced dependencies](#discussion-on-status-of-enhanced-dependencies)
* [Treatment of semantically void syntactic dependencies ?](#treatment-of-semantically-void-syntactic-dependencies)
* [Proposed additional cases of enhanced edges](#additional-cases-of-enhanced-edges)
* [Neutralizing syntactic alternations](#neutralizing-syntactic-alternations)

**Main points to decide:**

* whether or not to leave the possibility to mark semantically void syntactic dependencies
* whether or not to neutralize (some) syntactic alternations
* consider obligatory control only, or leave the possibility to include arbitrary control too
* other??

## Discussion on status of enhanced dependencies 

The current UD documentation introduces enhanced dependencies as a way to facilitate shallow understanding tasks.
In order to define the next scope of enhanced dependencis, we should make more explicit their linguistic / practical status, starting from the current enhanced guidelines (enhanced v2.1).

1. Enhanced dependencies aim at easing natural language understanding tasks, meaning either constructing full semantic representations, or simply making explicit some sort of semantic information useful for downsteam tasks.

2. Yet, guiding the enhanced dependency design by purely practical concerns (i.e. adding/droping/renaming relations and modifying structures so that the resulting graphs are maximally useful for downstream tasks such as relation extraction) does not seem a valid option, because the exact downsteam tasks for UD users are unknown.

3. Moreover, existing semantic representations are maybe even more numerous than syntactic ones, so it seems that the enhanced dependencies should remain primarily syntactic (at least within v2), and make as few assumptions as possible about the nature of the semantic representations.

This leads to considering that enhanced dependencies (at least within v2) do remain a syntactic representation rather that a semantic one, and that they primarily include modifications that can help semantic interpretation, but that are syntactically constrained. 

This rules out (at least within v2) the semantically more ambitious objective to recover argument structure of predicates (as e.g. in DM).

This also implies that enhanced UD use grammatical functions/relations, not semantic roles (which would require predicate sense disambiguation anyway).
(From Joakim: we want to remain neutral with respect to the nature of semantic roles, so that people can define syntax-semantics interfaces for different frameworks. Siva Reddy’s work on UDepLambda defines an interface to lambda calculus with neo-Davidsonian representations. Others want to map to FrameNet or PropBank roles. I think it is best if we make as few assumptions as possible about the nature of the semantic representations)


To encompass both these constraints and the current enhanced dependencies (v2.1), enhanced dependencies could be viewed as aiming to (from Joakim):
1. Add syntactically conditioned constraints on semantic interpretation that are left implicit in the basic dependencies. Examples: control relations and co-reference in relative clauses, possibly also coordination scope.
2. potentially repackage information that is already available in basic dependencies to make it more easily accessible for downstream applications. Example: subtyping obl and advcl relations with adpositions and subordinate conjunctions.
<commit_msg>Update enhanced.md<commit_after>---
layout: base
title:  'Working Group on Enhanced Dependencies'
udver: '2'
---

# Working Group on Enhanced Dependencies

(Summary of discussions between <NAME>, <NAME>, <NAME>, <NAME>, <NAME> and <NAME>)

General objective of the working group:

* clarify status of enhanced dependencies
* provide modified guidelines sufficiently in advance, for people to use them for next v2.2 version 
  (cf. not decided yet: whether enhanced deps are included in the UD shared task of spring 2018)

Note: Within a v2 release, there cannot be major modifications of the current enhanced guidelines, but we do also include in this page discussion from a broader perspective

**Content:**

* [Discussion on status of enhanced dependencies](#discussion-on-status-of-enhanced-dependencies)
* [Treatment of semantically void syntactic dependencies ?](#treatment-of-semantically-void-syntactic-dependencies)
* [Proposed additional cases of enhanced edges](#additional-cases-of-enhanced-edges)
* [Neutralizing syntactic alternations](#neutralizing-syntactic-alternations)

**Main points to decide:**

* whether or not to leave the possibility to mark semantically void syntactic dependencies
* whether or not to neutralize (some) syntactic alternations
* consider obligatory control only, or leave the possibility to include arbitrary control too
* other??

## Discussion on status of enhanced dependencies 

The current UD documentation introduces enhanced dependencies as a way to facilitate shallow understanding tasks.
In order to define the next scope of enhanced dependencis, we should make more explicit their linguistic / practical status, starting from the current enhanced guidelines (enhanced v2.1).

1. Enhanced dependencies aim at easing natural language understanding tasks, meaning either constructing full semantic representations, or simply making explicit some sort of semantic information useful for downsteam tasks.

2. Yet, guiding the enhanced dependency design by purely practical concerns (i.e. adding/droping/renaming relations and modifying structures so that the resulting graphs are maximally useful for downstream tasks such as relation extraction) does not seem a valid option, because the exact downsteam tasks for UD users are unknown.

3. Moreover, existing semantic representations are maybe even more numerous than syntactic ones, so it seems that the enhanced dependencies should remain primarily syntactic (at least within v2), and make as few assumptions as possible about the nature of the semantic representations.

This leads to considering that enhanced dependencies (at least within v2) do remain a syntactic representation rather that a semantic one, and that they primarily include modifications that can help semantic interpretation, but that are syntactically constrained. 

This rules out (at least within v2) the semantically more ambitious objective to recover argument structure of predicates (as e.g. in DM).

This also implies that enhanced UD use grammatical functions/relations, not semantic roles (which would require predicate sense disambiguation anyway).
(From Joakim: we want to remain neutral with respect to the nature of semantic roles, so that people can define syntax-semantics interfaces for different frameworks. <NAME>’s work on UDepLambda defines an interface to lambda calculus with neo-Davidsonian representations. Others want to map to FrameNet or PropBank roles. I think it is best if we make as few assumptions as possible about the nature of the semantic representations)


To encompass both these constraints and the current enhanced dependencies (v2.1), enhanced dependencies could be viewed as aiming to (from Joakim):

1. Add syntactically conditioned constraints on semantic interpretation that are left implicit in the basic dependencies. Examples: control relations and co-reference in relative clauses, possibly also coordination scope.
2. potentially repackage information that is already available in basic dependencies to make it more easily accessible for downstream applications. Example: subtyping obl and advcl relations with adpositions and subordinate conjunctions.

{'fraction_non_alphanumeric': 0.04398370086289549, 'fraction_numerical': 0.004793863854266539, 'mean_word_length': 5.414296694850115, 'pattern_counts': {'":': 0, '<': 16, '<?xml version=': 0, '>': 16, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '884838', 'n_tokens_mistral': 1902, 'n_tokens_neox': 1751, 'n_words': 1108}