Details
Major
Description
Some sub-classes of Matching are over complicated because Matching loads indices etc. We need to refactor here - the basic Matching instance should do less.
Having it as an interface would be one direction:
{code}
public interface Matching
{
public ResultSet match(String queryNumber, MatchingQueryTerms queryTerms) throws IOException;
}
{code}
A minimal abstract class would be another.
{code}
public abstract class Matching
{
Index index;
public Matching(Index _index) { this.index = _index; }
public abstract ResultSet match(String queryNumber, MatchingQueryTerms queryTerms) throws IOException;
}
{code}
Having it as an interface would be one direction:
{code}
public interface Matching
{
public ResultSet match(String queryNumber, MatchingQueryTerms queryTerms) throws IOException;
}
{code}
A minimal abstract class would be another.
{code}
public abstract class Matching
{
Index index;
public Matching(Index _index) { this.index = _index; }
public abstract ResultSet match(String queryNumber, MatchingQueryTerms queryTerms) throws IOException;
}
{code}
Attachments
Issue Links
- is blocked by
-
TR-60 Remove PonteCroft language modelling
-
- Resolved
-
Activity
DSMs are a pertinent question. If they are always dealt with, then Matching should probably be an abstract class.
Should DSMs exist in all scenarios?:
- Should TRECResultMatching and similar apply DSMs?
- How do DSMs apply in a DAAT setting? For instance, proximity stuff can be done in a single pass using a DAAT strategy. However, we need to reformulate MatchingQueryTerms for this.
Tagging for 3.0
This is progressing nicely. I have taken nicola's full TAAT implementation as the default matching implementation.
Hierarchy is:
Matching(interface)
/ \
basematching oldmatching
/
taat.Full
All other real matching strategies would be at the level of taat.Full
Committed to trunk.
Easier to do if LMMatching was moved into common before doing this.