We have no specified way to indicate what type of relation a coreference relation is (anaphora, cataphora, split antecedents, coreferring noun phrases) or what type an entity in a coreference chain is (pronoun, nominal, name, demonstrative). Both of these are used in WebLicht's TCF which in addition has ways to specify tagsets for types and relations.
The relations are expressed between pairs of elements in a coreference chain, which is something that we cannot express naturally because we do not have pairs but a list of mentions.
Some options with partial solutions:
Express the type on Markable. This would make this type again follow use of the term amongst coreference people, yet we had decided a while ago to have Markable follow the more general term from the markable versus non-markable perspective in annotations. Note that when we introduce this sense of Markable we did not have Region yet (calling it Span instead), we could use Region for those case where we want a generic markable.
Come up with a scheme for expressing relations on Coreference. This could for example be a list called relationTypes which would be triples of relation, source markable identifier and target markable identifier. Or we could assume that the target of the relation is always to the representative.
Introduce a CoreferenceRelation type which could store the relation type as well as meta data on the tagset.
Introduce CoreferenceMarkable as a subtype of Markable.
We have no specified way to indicate what type of relation a coreference relation is (anaphora, cataphora, split antecedents, coreferring noun phrases) or what type an entity in a coreference chain is (pronoun, nominal, name, demonstrative). Both of these are used in WebLicht's TCF which in addition has ways to specify tagsets for types and relations.
The relations are expressed between pairs of elements in a coreference chain, which is something that we cannot express naturally because we do not have pairs but a list of mentions.
Some options with partial solutions:
Express the type on
Markable
. This would make this type again follow use of the term amongst coreference people, yet we had decided a while ago to haveMarkable
follow the more general term from the markable versus non-markable perspective in annotations. Note that when we introduce this sense ofMarkable
we did not haveRegion
yet (calling itSpan
instead), we could useRegion
for those case where we want a generic markable.Come up with a scheme for expressing relations on
Coreference
. This could for example be a list calledrelationTypes
which would be triples of relation, source markable identifier and target markable identifier. Or we could assume that the target of the relation is always to the representative.Introduce a
CoreferenceRelation
type which could store the relation type as well as meta data on the tagset.Introduce
CoreferenceMarkable
as a subtype ofMarkable
.