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<String,Integer> edgeTypeCounts = new HashMap<>();
final Map<String,Pair<Annotation>> 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<Annotation> as the map key, but more than one
relation type between two annotations would cause problems. Or an ugly
Map<type,Collection<Pair<Annotation>>> in which the pairs are constantly added
to the collection ...
Sean
________________________________________
From: Finan, Sean <[email protected]>
Sent: Wednesday, October 27, 2021 10:15 AM
To: [email protected]
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<String,Pair<Annotation>> getEdgeAndNodes(JCas jcas ) {
final Collection<BinaryTextRelation> relations = JCasUtil.select( jcas,
BinaryTextRelation.class );
if ( relations == null || relations.isEmpty() ) {
return Collections.emptyMap();
}
final Map<String,Pair<Annotation>> 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 <[email protected]>
Sent: Wednesday, October 27, 2021 6:21 AM
To: [email protected]
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
