Uploaded image for project: 'Terrier Core'
  1. Terrier Core
  2. TR-86

Matching should be an interface

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: .matching
    • Labels:
      None

      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}

        Attachments

          Issue Links

            Activity

            Hide
            craigm Craig Macdonald added a comment -

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

            Show
            craigm Craig Macdonald added a comment - Easier to do if LMMatching was moved into common before doing this.
            Hide
            craigm Craig Macdonald added a comment -

            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
            craigm Craig Macdonald added a comment - 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
            craigm Craig Macdonald added a comment -

            Tagging for 3.0

            Show
            craigm Craig Macdonald added a comment - Tagging for 3.0
            Hide
            craigm Craig Macdonald added a comment - - 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
            craigm Craig Macdonald added a comment - - 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
            craigm Craig Macdonald added a comment -

            Committed to trunk.

            Show
            craigm Craig Macdonald added a comment - Committed to trunk.

              People

              • Assignee:
                craigm Craig Macdonald
                Reporter:
                craigm Craig Macdonald
              • Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: