Ok first of all you're referring to the final merging
(AggregateNameFinder) and not the multiple dictionaries where no merging
occurs...anyway let's deal with this at the moment. let's see...
- Two names can be identical and have the same type or a different type
Well if the type is different the spans are not identical (equal) so
you keep both and do some reasoning over them (see below).
If they type is the same and the spans cover the same text then they are
equal so you only keep one of them.
- Two names have intersecting spans
It is very unlikely that both are correct so in the simplest case of
keeping them both you may lose some precision. However considering how
often that could happen it becomes unimportant. Or you could do some
reasoning (see below) again if they have the same type. If they don't
have the same type then why not keep them both again?
- One name is contained in another like this:
<START:A> a b<START:B> c<END:B> d<END:A>
well, this is exactly the same case as before conceptually. If they have
the same type it's very likely that one is wrong.You can do the same
sort of reasoning as above. If they don't there is no way to know with
confidence what to do so i say keep them both.
the reasoning i'm referring to is simply to *trust the dictionary* (if
one exists). If one doesn't exist and one is trying to merge results
from several maxent models for example, then we cannot make an informed
decision. It is only the dictionary that can provide facts. all the rest
are probabilities...
Jim
Hi all,
in one of the jiras we started a discussion about merging the output
of multiple name finders and which conflicts exist.
Lets move it back to the dev list.
The merging code needs to handle these cases:
- Two names can be identical and have the same type or a different type.
- Two names have intersecting spans like this:
<START:A> a b<START:B> c<END:A> d<END:B>
- One name is contained in another like this:
<START:A> a b<START:B> c<END:B> d<END:A>
Depending on the use case and merging logic it might be resolved
differently.
Jörn
