StanfordNLP OpenIE: Obtaining best triples to match demo - stanford-nlp

Question

I'm using StanfordNLP OpenIE for the purpose of extracting simpler sentences from more complex sentences by identifying triples using OpenIE. The simpler sentences are necessary to improve the performance on downstream NLP tasks for question/answering.
Here are my default properties:
properties = '{"annotators":"tokenize,ssplit,pos,lemma,ner,depparse,natlog,openie","outputFormat":"json"}'
Here is my test sentence:
text = 'The patient was placed in the left lateral position and monitored continuously with ECG tracing, pulse oximetry monitoring, and direct observations.'
Whether I use the docker NLP server or run from the downloaded Java distribution, I get the following result (which makes sense):
patient | was placed in | lateral position
patient | monitored continuously | ECG tracing
patient | pulse | oximetry monitoring
patient | was placed in | left lateral position
patient | was | placed
patient | was placed in | left position
patient | monitored | ECG tracing
patient | was placed in | position
However, if I run the same test sentence on the demo page at http://corenlp.run/, the Brat visualization appears to return a more concise set of triplets:
patient | monitored continuously | ECG tracing
patient | pulse | oximetry monitoring
patient | was placed in | left lateral position
I've experimented with each OpenIE annotation option listed here:
https://nlp.stanford.edu/software/openie.html#Questions, but have failed to produce this more concise result.
Is there an option available for this? If not, any algorithm for obtaining this result would be appreciated.
Thanks

Answer 1

When I try corenlp.run, I get the same expanded set of triples, if you hover over each entity:
You can, however, always collapse them into fewer triples by just taking the widest possible subject+object+relation scopes. There are a few ways to do this:
Most flexible: if you call the OpenIE annotator programmatically, the relation triple keeps the sentence+token offset of each of its arguments, which you can use to determine the widest spanning arguments for each extracted relation.
Heuristically, you can simply ignore relation extractions that are subsets of other extractions.
the QA_SRL output format will actually do option (1) for you, to conform to an evaluation that penalizes "duplicate" relation extractions.
However, in many situations it's also harmless/preferable to keep more extractions around. Each of the extractions should be "true", in the sense that they're entailed from the source sentence -- some are just more specific than others.