Another question about relationship extractors
Hi (probably Sean), are the default model.jars for the *CausesBringsAboutRelationExtractorAnnotator* and the *ManagesTreatsRelationExtractorAnnotator* not part of the cTakes sources?I looked through the source at all pipers and all unit tests and on the net and I didn't find references to the usage of these annotators. When I run with them, they are definitely looking for models of their own, and there is code to do the training, but this is an area that's still a mystery to me. Are these models proprietary to U of Colorado which is where the source seems to come from? Peter
followup question
Hi Sean, I've been doing a bit of reading on propbanks, framesets, etc in relation to what I'm seeing in the CAS when I turn on some of the relation extractors that do work (in contrast to the ones I mentioned before that are missing a model). Is it safe to say that these extractors are mostly experiments used to validate semantic approaches proposed back in the day, and that there isn't yet much code that pulls these relations out in any user-friendly way? By user-friendly I mean creating a simpler "edge object" that simply joins two identified events in a way that hides all the intermediate collections of structures generated by these relation extractors and their dependencies. Peter
Re: Another question about relationship extractors [EXTERNAL]
Hi Peter, I guess you're asking why there is annotator code for all the relations but only released models for location_of and degree_of (severity)? The simple reason is those are the only two that we felt were accurate enough to release. We had an annotated training corpus with all the relations, but some relation types did not have enough instances to train accurate models with the methods of the time. We're circling back pretty regularly to discuss whether newer methods might be able to do better with less data, we'll try to keep in touch about that. Thanks Tim On Wed, 2021-10-27 at 11:35 +0200, Peter Abramowitsch wrote: * External Email - Caution * Hi (probably Sean), are the default model.jars for the *CausesBringsAboutRelationExtractorAnnotator* and the *ManagesTreatsRelationExtractorAnnotator* not part of the cTakes sources?I looked through the source at all pipers and all unit tests and on the net and I didn't find references to the usage of these annotators. When I run with them, they are definitely looking for models of their own, and there is code to do the training, but this is an area that's still a mystery to me. Are these models proprietary to U of Colorado which is where the source seems to come from? Peter
Re: followup question [EXTERNAL]
Hi Peter,
To your question:
>there isn't yet much code that pulls these relations out in any user-friendly
>way?
the answer is mostly no. The relation-related code in ctakes is mostly for
experimentation and not utilization.
Annotations/Events and Relations are translated in a few places into other node
and edge formats.
For instance, the ctakes-fhir module has a fhir reader and writer that utilize
cas relations to create an extension in a fhir Element that consists of the
relation type and a fhir Reference to the fhir Element representing the
relation target annotation/event.
Elsewhere they are thrown into various visual output types, such as the
PropertyTextWriter, PrettyTextWriter and HtmlTextWriter in ctakes-core.
There isn't any code that I know of that would do something like:
Map> getEdgeAndNodes(JCas jcas ) {
final Collection relations = JCasUtil.select( jcas,
BinaryTextRelation.class );
if ( relations == null || relations.isEmpty() ) {
return Collections.emptyMap();
}
final Map> edgeNodes = new HashMap<>();
for ( BinaryTextRelation relation : relations ) {
final Annotation argument1 = relation.getArg1().getArgument();
final Annotation argument2 = relation.getArg2().getArgument();
edgeNodes.put( relation.getCategory(), new Pair( argument1, argument2 )
);
}
return edgeNodes;
}
But if that works then use it.
Sean
From: Peter Abramowitsch
Sent: Wednesday, October 27, 2021 6:21 AM
To: dev@ctakes.apache.org
Subject: followup question [EXTERNAL]
* External Email - Caution *
Hi Sean, I've been doing a bit of reading on propbanks, framesets, etc in
relation to what I'm seeing in the CAS when I turn on some of the relation
extractors that do work (in contrast to the ones I mentioned before that
are missing a model).
Is it safe to say that these extractors are mostly experiments used to
validate semantic approaches proposed back in the day, and that there isn't
yet much code that pulls these relations out in any user-friendly way? By
user-friendly I mean creating a simpler "edge object" that simply joins
two identified events in a way that hides all the intermediate collections
of structures generated by these relation extractors and their dependencies.
Peter
Re: followup question [EXTERNAL] [SUSPICIOUS]
Oops, looking at what I jut wrote:
edgeNodes.put( relation.getCategory(), new Pair( argument1, argument2 )
);
would definitely NOT work. This might be better, though a little more tedious:
final Map edgeTypeCounts = new HashMap<>();
final Map> edgeNodes = new HashMap<>();
for ( BinaryTextRelation relation : relations ) {
final String edgeType = relation.getCategory();
final int typeCount = edgeTypeCounts.computeIfAbsent( edgeType, i -> 0
);
edgeTypeCounts.put( edgeType, typeCount + 1 );
final Annotation argument1 = relation.getArg1().getArgument();
final Annotation argument2 = relation.getArg2().getArgument();
edgeNodes.put( edgeType + "_" + typeCount, new Pair( argument1,
argument2 ) );
}
But then you would need to strip "_"{index} from all of the edges.
Alternatively you could use Pair as the map key, but more than one
relation type between two annotations would cause problems. Or an ugly
Map>> in which the pairs are constantly added
to the collection ...
Sean
From: Finan, Sean
Sent: Wednesday, October 27, 2021 10:15 AM
To: dev@ctakes.apache.org
Subject: Re: followup question [EXTERNAL] [SUSPICIOUS]
* External Email - Caution *
Hi Peter,
To your question:
>there isn't yet much code that pulls these relations out in any user-friendly
>way?
the answer is mostly no. The relation-related code in ctakes is mostly for
experimentation and not utilization.
Annotations/Events and Relations are translated in a few places into other node
and edge formats.
For instance, the ctakes-fhir module has a fhir reader and writer that utilize
cas relations to create an extension in a fhir Element that consists of the
relation type and a fhir Reference to the fhir Element representing the
relation target annotation/event.
Elsewhere they are thrown into various visual output types, such as the
PropertyTextWriter, PrettyTextWriter and HtmlTextWriter in ctakes-core.
There isn't any code that I know of that would do something like:
Map> getEdgeAndNodes(JCas jcas ) {
final Collection relations = JCasUtil.select( jcas,
BinaryTextRelation.class );
if ( relations == null || relations.isEmpty() ) {
return Collections.emptyMap();
}
final Map> edgeNodes = new HashMap<>();
for ( BinaryTextRelation relation : relations ) {
final Annotation argument1 = relation.getArg1().getArgument();
final Annotation argument2 = relation.getArg2().getArgument();
edgeNodes.put( relation.getCategory(), new Pair( argument1, argument2 )
);
}
return edgeNodes;
}
But if that works then use it.
Sean
From: Peter Abramowitsch
Sent: Wednesday, October 27, 2021 6:21 AM
To: dev@ctakes.apache.org
Subject: followup question [EXTERNAL]
* External Email - Caution *
Hi Sean, I've been doing a bit of reading on propbanks, framesets, etc in
relation to what I'm seeing in the CAS when I turn on some of the relation
extractors that do work (in contrast to the ones I mentioned before that
are missing a model).
Is it safe to say that these extractors are mostly experiments used to
validate semantic approaches proposed back in the day, and that there isn't
yet much code that pulls these relations out in any user-friendly way? By
user-friendly I mean creating a simpler "edge object" that simply joins
two identified events in a way that hides all the intermediate collections
of structures generated by these relation extractors and their dependencies.
Peter
Question about Relation Extractors
Thanks Sean and Tim for the background & code on these annotators & models. Just looking at how the EventTimeRelationAnnotator works, I think the internal representation would be a bit different, but I get the gist of it for sure. Unless I'm using outdated code The "actual data" is captured in the SemanticRoleRelations, Predicate, and the Semantic Arguments. Strangely, the BinaryTextRelation is declared in the CAS but never actually used. I found a couple of good resources on this: https://aclanthology.org/W04-2412.pdf https://aclanthology.org/D08-1008.pdf https://web.stanford.edu/~jurafsky/slp3/slides/22_SRL.pdf Peter
