Hello Mark, +1 for your second solution. I believe that is much more intuitive than calling a method afterwards to retrieve the prob for a Span. it is easier to use because the prob is delivered as part of the result and no user action is required to obtain it.
We could use this solution everywhere where a span gets returned. Jörn On Wed, May 7, 2014 at 2:18 AM, Mark G <giaconiam...@gmail.com> wrote: > I am currently working on a project in which we are using NER to to pass > toponyms into the GeoEntityLinker addon for geotagging and I am passing on > the locations, entities, and other info into SOLR for indexing. Over the > years I have noticed that the TokenNameFinder interface does not include > all the probs() methods that the NameFinderME has, and furthermore the Span > object does not have a double field for storing a prob for itself. Also > the sentenceDetector has a method called getSentenceProbabilities rather > than probs(). > When I pass the Spans into the GeoEntityLinker/EntityLinker I can't get the > probs anymore because they are not in the Span objects. I can always extend > Span and add the field, or keep a 2D array of the probs for each sentence, > but wanted to see what everyone thinks about > 1. adding the probs methods to the TokenNameFinder interface > 2. adding a prob field to Span (a double) > 3. Having the NameFinder return the prob with each Span so it doesn't have > to be set after the call to find() using the double[] of probs > 4. Have the sentencedetectorME return its spans with a prob, add probs() > method to the SentenceDetector interface, and deprecate the > getSentenceProbabilities... > > Thoughts? >
