[TR-86] Matching should be an interface Created: 16/Jan/10  Updated: 05/Mar/10  Resolved: 26/Feb/10

Status: Resolved
Project: Terrier Core
Component/s: .matching
Affects Version/s: None
Fix Version/s: 3.0

Type: Improvement Priority: Major
Reporter: Craig Macdonald Assignee: Craig Macdonald
Resolution: Fixed  
Labels: None

Issue Links:
Block
is blocked by TR-60 Remove PonteCroft language modelling Resolved

 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}


 Comments   
Comment by Craig Macdonald [ 26/Jan/10 ]

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

Comment by Craig Macdonald [ 26/Jan/10 ]

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.
Comment by Craig Macdonald [ 28/Jan/10 ]

Tagging for 3.0

Comment by Craig Macdonald [ 17/Feb/10 ]

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

Comment by Craig Macdonald [ 26/Feb/10 ]

Committed to trunk.

Generated at Sun Jan 26 15:36:50 GMT 2020 using JIRA 7.1.1#71004-sha1:d6b2c0d9b7051e9fb5e4eb8ce177ca56d91d7bd8.