Terrier Core

Matching should be an interface

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.0
  • Component/s: .matching
  • Description:
    Hide
    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}
    Show
    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}

Issue Links

Activity

Hide
Craig Macdonald added a comment - 26/Jan/10 11:01 PM

Easier to do if LMMatching was moved into common before doing this.

Show
Craig Macdonald added a comment - 26/Jan/10 11:01 PM Easier to do if LMMatching was moved into common before doing this.
Hide
Craig Macdonald added a comment - 26/Jan/10 11:28 PM

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.
Show
Craig Macdonald added a comment - 26/Jan/10 11:28 PM 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.
Hide
Craig Macdonald added a comment - 28/Jan/10 2:45 PM

Tagging for 3.0

Show
Craig Macdonald added a comment - 28/Jan/10 2:45 PM Tagging for 3.0
Hide
Craig Macdonald added a comment - 17/Feb/10 10:40 PM - edited

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

Show
Craig Macdonald added a comment - 17/Feb/10 10:40 PM - edited 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
Hide
Craig Macdonald added a comment - 26/Feb/10 6:01 PM

Committed to trunk.

Show
Craig Macdonald added a comment - 26/Feb/10 6:01 PM Committed to trunk.

People

Dates

  • Created:
    16/Jan/10 3:42 PM
    Updated:
    05/Mar/10 5:32 PM
    Resolved:
    26/Feb/10 6:01 PM