coref on top of entities

28 views
Skip to first unread message

Seth Kulick

unread,
Jan 14, 2025, 10:14:39 AM1/14/25
to incepti...@googlegroups.com
Hi,

I'm looking at using inception for an annotation project, and I have a question about the best way to handle coreference annotation. The needs of the annotation project are:

(1) entity annotation
(2) some intra-sentence relations on top of entities
(3) coreference on entities that may go across sentences.

While (1) and (2) are easy to set up, the problem with using the built-in coref layer, either as a linked list or not, is that it cannot be specified as being on top of an entity the way that relations are.  So after doing entity annotation, when it comes time to doing coref, the annotator would need to select each entity involved as a Span for the coref chain, which would be duplicates of the spans already used for the entity annotation.  That seems like extra work and error prone.   Is there a way to make coref spans be on top of the entities?   

There are two workarounds that I can see:

(a)  Fake coref by making it a relation on top of entities, and then use post-processing to tie  together the different coref chains.   A problem with this approach is that there can only be one relation layer on top of entities, and I'm already using an intra-sentence relation on top of entities. I could make another label, "coref" for that relation and allow it to go across sentences, which is not ideal for reasons I won't go into here (to avoid making this too long).  A separate relation layer on top of entities, just for coref, can be done with the experimental feature ui.cross-layer-relations-enabled=true, but I'm hesitant to use an experimental feature for a current project.   How stable would that be to use?  

(b) Use kb-linking instead of coref, so coref is done by just linking to the appropriate entry in the kb for each entity.  There are various problems with this as well, since there are coref chains linking together nominals and pronouns, without a proper name.  (Also trying to keep this short and won't go into this in detail). 

Any suggestions/comments welcome!

thanks,

Seth



Richard Eckart de Castilho

unread,
Jan 14, 2025, 10:22:46 AM1/14/25
to incepti...@googlegroups.com
Hi Seth,

I'll respond inline below.

> On 13. Jan 2025, at 16:47, Seth Kulick <skul...@gmail.com> wrote:
>
> I'm looking at using inception for an annotation project, and I have a question about the best way to handle coreference annotation. The needs of the annotation project are:
>
> (1) entity annotation
> (2) some intra-sentence relations on top of entities
> (3) coreference on entities that may go across sentences.
>
> While (1) and (2) are easy to set up, the problem with using the built-in coref layer, either as a linked list or not, is that it cannot be specified as being on top of an entity the way that relations are. So after doing entity annotation, when it comes time to doing coref, the annotator would need to select each entity involved as a Span for the coref chain, which would be duplicates of the spans already used for the entity annotation. That seems like extra work and error prone. Is there a way to make coref spans be on top of the entities?

Chain layers cannot be combined with span layers. Chain layers are inherently an amalgamation of spans and relations that cannot be separated.
Furthermore, chain layers are not supported in INCEptION as well as span and relation layers. For example, they cannot be curated, recommenders do not work for them, and agreement does not work for them.

I am regularly thinking that I might relegate chain layers to experimental status and disable them by default - but so far that idea has not been turned into practice (yet)...

> There are two workarounds that I can see:
>
> (a) Fake coref by making it a relation on top of entities, and then use post-processing to tie together the different coref chains. A problem with this approach is that there can only be one relation layer on top of entities, and I'm already using an intra-sentence relation on top of entities. I could make another label, "coref" for that relation and allow it to go across sentences, which is not ideal for reasons I won't go into here (to avoid making this too long). A separate relation layer on top of entities, just for coref, can be done with the experimental feature ui.cross-layer-relations-enabled=true, but I'm hesitant to use an experimental feature for a current project. How stable would that be to use?

The functionality hasn't seen much practical use so far, so there may very well be quirks.

If you do not want to try the cross-layer functionality, you could also "fake" the coref relations using a link feature on your entity layer.
Link features are less powerful than relations (i.e. can only have a simple role label and not arbitrary features), but they are supported at a similar level as spans and relations when it comes to curation, agreement, etc.

That said, if you go for cross-layer and have feedback, that feedback would be very welcome :)

> (b) Use kb-linking instead of coref, so coref is done by just linking to the appropriate entry in the kb for each entity. There are various problems with this as well, since there are coref chains linking together nominals and pronouns, without a proper name. (Also trying to keep this short and won't go into this in detail).

KB linking is a viable option too. If you do not need a direct relationship between e.g. a pronoun and its noun mention, why not?

Cheers,

-- Richard

Seth Kulick

unread,
Feb 25, 2025, 3:31:03 PM2/25/25
to incepti...@googlegroups.com
Thanks for your reply. One followup question. We're going with the
option of using a link feature from the entity to another entity as
its antecedent. It displays the antecedent in the info for the
entity when it is selected, which is good. It also draws the dashed
line between the entity and the antecedent. Since this often spans
multiple lines, and there are several such antecedent/entity links
made on a page, it quickly fills up with lots of dashed lines across
the sentences. The dashed lines showing the links become hard to
read, and they aren't really needed, since the antecedent info is
shown in the in info for the entity. Is there any way to turn the
lines off between the link and the entity?

thanks,

Seth
> --
> You received this message because you are subscribed to the Google Groups "inception-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to inception-use...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/inception-users/8F14CC18-A6CB-417F-99A5-AD481EF39B63%40gmail.com.

Richard Eckart de Castilho

unread,
Feb 25, 2025, 4:16:40 PM2/25/25
to incepti...@googlegroups.com
Hi,

> On 25. Feb 2025, at 21:30, Seth Kulick <skul...@gmail.com> wrote:
>
> The dashed lines showing the links become hard to
> read, and they aren't really needed, since the antecedent info is
> shown in the in info for the entity. Is there any way to turn the
> lines off between the link and the entity?

An option to hide arcs is currently only available on relation layers.
You could open a feature request to allow hiding arcs of link features.

https://github.com/inception-project/pycaprio/issues/new/choose

If you are not tied to the brat visualization mode, you might consider
switching to the HTML (Apache Annotator) view via the preferences dialog
(cog wheel on the annotation page) or the annotation panel in the
project settings. This editor does currently not support displaying arcs
at all - it will only visualize spans.

-- Richard

Seth Kulick

unread,
Feb 25, 2025, 5:27:50 PM2/25/25
to incepti...@googlegroups.com
Thanks for the suggestion of the HTML view. That's quite nice. The
only problem is that it doesn't seem to respect the line/sentence
boundaries and collapses it all to one block of running text.

I'm working with documents that have been preloaded with annotations
and prepared in UIMA CAS XMI (XML 1.0) format. While the HTML view
shows the preloaded entity spans fine, and has the Token information,
the Sentence information is not reflected in the display - ie, the
newline characters in the sofaString are just ignored (which I guess
kind of makes sense, being an HTML doc.) I tried redoing the .xmi
documents so that the sofaString has both CR and LF separating each
line instead of just LF, but that didn't have any effect.

I am using inception 34.5.

thanks,

Seth
> --
> You received this message because you are subscribed to the Google Groups "inception-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to inception-use...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/inception-users/EED903C6-5B6B-418E-91AE-DBCA1638D67C%40gmail.com.
Reply all
Reply to author
Forward
0 new messages