<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Hashing and Merging Heuristics for Text Reuse Detection</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Faisal Alvi</string-name>
          <email>alvif@kfupm.edu.sa</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Mark Stevenson</string-name>
          <email>mark.stevenson@sheffield.ac.uk</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Paul Clough</string-name>
          <email>p.d.clough@sheffield.ac.uk</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>King Fahd University of Petroleum &amp; Minerals</institution>
          ,
          <country country="SA">Saudi Arabia</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Sheffield</institution>
          ,
          <country country="UK">United Kingdom</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2014</year>
      </pub-date>
      <fpage>939</fpage>
      <lpage>946</lpage>
      <abstract>
        <p>This paper describes a joint software entry by King Fahd University of Petroleum &amp; Minerals and the University of Sheffield for the text-alignment task at PAN-2014. We employ the three steps of seeding, extension and filtering for text alignment. For seeding we use character n-grams with a variant of the RabinKarp Algorithm for multiple pattern search. We then use an elaborate merging mechanism with several cases to combine the individually found seeds. A short filtering step is then used to remove extraneous passages. This approach scored plagdet scores of 0.65954 and 0.73416 on test corpora 2 and 3 during the final test run.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1 Introduction</title>
      <p>
        Text Reuse Detection has been a part of plagiarism detection at the PAN Competition
since inception as text alignment [
        <xref ref-type="bibr" rid="ref5 ref6">5,6</xref>
        ] in 2012-14 and as extrinsic plagiarism detection
earlier. For the year 2013, the text alignment task consisted of finding passages of reused
text in five different types of obfuscated document pairs: no plagiarism, no obfuscation,
random obfuscation, translation obfuscation and summary obfuscation. Since the
training corpus for PAN-2014 text alignment is the same as in 2013, it could be inferred that
similar obfuscation types could be in use in 2014.
      </p>
      <p>
        Several approaches have been employed by participants for text alignment
including character n-grams, word n-grams and their variants, along with various similarity
metrics. Three distinct stages in participants’ approaches have been identified in PAN
Overview paper for 2013 [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]: (1) seeding, (2) extension, and (3) filtering.
      </p>
      <p>
        For our current year’s (2014) entry, our submitted software also consists of these
three stages of seeding, extension/merging and filtering. In the seeding stage we use
character n-grams after post-processing and apply a variant of the Rabin-Karp
Algorithm [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] for multiple pattern search [
        <xref ref-type="bibr" rid="ref3 ref4">3,4</xref>
        ] to find matching seeds. We then classify
pairs of matching seeds within source and suspicious documents into four classes:
containment, overlap, near-disjoint and far-disjoint. We then use case-by-case merging to
combine pairs of various classes. Finally, we apply filtering to remove short passages
in order to exclude false positives. Our approach has shown mid-range results for the
2013 and 2014 training and test corpora.
      </p>
    </sec>
    <sec id="sec-2">
      <title>The Approach</title>
      <p>As outlined in the first section our approach consists of 3 phases: seeding, extension and
filtering along with some preprocessing. An overview of the resulting software appears
in the block diagram as shown in Figure 1. The language of the software was java.</p>
      <sec id="sec-2-1">
        <title>Pairs file</title>
      </sec>
      <sec id="sec-2-2">
        <title>Sort according</title>
        <p>to source files
...........
n
p
a
m
h
s
a
h
i
t
l
u
M</p>
      </sec>
      <sec id="sec-2-3">
        <title>Apply hashing to generate a hashmap</title>
        <p>of char n-grams with (key, value)
pairs as (char n-gram, position pair)</p>
        <sec id="sec-2-3-1">
          <title>SEEDING</title>
        </sec>
        <sec id="sec-2-3-2">
          <title>EXTENSION / MERGING</title>
        </sec>
      </sec>
      <sec id="sec-2-4">
        <title>List(s) of position pairs</title>
      </sec>
      <sec id="sec-2-5">
        <title>Apply rule-based merging based on pre-defined classes for each position pair list</title>
      </sec>
      <sec id="sec-2-6">
        <title>Remove short matches</title>
      </sec>
      <sec id="sec-2-7">
        <title>Write output to XML file</title>
        <sec id="sec-2-7-1">
          <title>FILTERING and OUTPUT</title>
          <p>
            Initially the ‘pairs’ file is sorted according to the source file by file number. Since one
source document may be linked to several suspicious documents, a single hashing of
source document is repeatedly used for finding matches in corresponding suspicious
documents. Furthermore, during hashing, all punctuation, whitespace and non-printable
characters are removed. This is done as two perfectly reused strings (one in the source
document and other in the suspicious one) could go undetected because of an unequal
amount of spaces, punctuation and/or other characters.
Seeding is defined as “Given a suspicious document and a source document, matches
(so-called “seeds”) between the two documents are identified using some seed
heuristic.... By coming up with as many reasonable seeds as possible, the subsequent step of
extending them into aligned passages becomes a lot easier”. [
            <xref ref-type="bibr" rid="ref6">6</xref>
            ]
          </p>
          <p>
            For seeding, or identifying exact matches of character n-grams between two
documents, we use Rabin-Karp Algorithm [
            <xref ref-type="bibr" rid="ref2">2</xref>
            ] for multiple pattern search [
            <xref ref-type="bibr" rid="ref3 ref4">3,4</xref>
            ]. This is done
by first placing all character n-grams (for a particular value of n) into a multiple valued
hashtable, and then finding matches for character n-grams of the suspicious document
from the hashtable. Due to hashing, the search time of this is reduced from O(source
size susp size) to O(source size + susp size) - a substantial saving over naïve string
search. However, we employ several optimizations and simplifications to the
RabinKarp Algorithm in java as follows:
1. We use java’s built-in java.util.hashmap collection, which in-turn utilises
java’s built-in hashCode() method as a hash function, that ensures a unique hash
value for each unique character n-gram.
2. Since several strings are repeated in a document at different locations, use of a
single-valued hashtable will inevitably lead to collisions - hence we use a
multiple valued hashtable called a multihashmap to store these, as shown in Figure 2. A
multihashmap can be created by some modifications to the original hashmap
provided in java. For example, the character 20-gram "symptomsofarrhythmia"
appears several times in a source document and it is recorded each time with new
locations as a value.
3. For each n-gram its location is stored as a 3-tuple (start location, end location, size)
in the multihashmap. Some book-keeping is done to keep track of whitespace and
other ignored characters in the location(s), while the size parameter keeps track of
actual size.
          </p>
          <p>Once the multihashmap for a particular source document is created, we make a run of
each suspicious file to find the matching character n-grams. The output is a list of pairs
of 3-tuples: one from the source file and the other from the suspicious file.
source-document01999 (2013 Test Corpus 2)
Mutiple Valued Hash Map
What are the symptoms of
arrhythmias? The effects on the
body are often the same,
however, whether the heartbeat
is too fast, too slow, or too
irregular. Some symptoms of
arrhythmias include, but are
not limited to: weakness
The symptoms of arrhythmias may
resemble other conditions.</p>
          <p>KEY
char n-gram
symptomsof
arrhythmia
theeffects
onthebodya</p>
          <p>VALUE
(start, end, size)
(x1, y1, size1),
(x2, y2, size2),
(x3, y3, size3).</p>
          <p>.......</p>
          <p>For example after the algorithm is run on a source file with the corresponding
suspicious file, the output would be a list of the form:</p>
          <p>List of 3-tuple pairs = f(x1; y1; s1) ! (a1; b1; s′1); (x2; y2; s2) ! (a2; b2; s′2); : : :g
In the list above, the entry (x1; y1; s1) ! (a1; b1; s′1) means that the text in the
source file from position x1 to y1 of size s1 is aligned with the text in the suspicious file
from location a1 to b1 of size s′1. It may be noted that y1 &gt; x1 and b1 &gt; a1, furthermore
s1 y1 x1, s′1 b1 a1.
2.3</p>
          <p>Extension
Once the list of matching pairs is generated between a pair of source and suspicious
documents, the next step is the extension or merging of these matches into contiguous,
aligned passages. This is done by combining seeds or matches that satisfy certain
criteria both in the source and suspicious documents into larger matches. We identify four
distinct categories of matches as follows based on their vicinity towards each other.</p>
          <p>Consider two matching pairs (x1; y1; s1) ! (a1; b1; s′1), (x2; y2; s2) ! (a2; b2; s′2)
where (x1; y1; s1) indicates text from position x1 to position y1 of size s1 in the source
document, and (a1; b1; s′1) indicates the corresponding text from position a1 to b1 of
size s′1 in the suspicious document. In order to merge these pairs in each of the source
and suspicious documents, we identify four categories of matches as follows:
1. Containment: Containment is the relationship between two matches within the
same document when the text-positions of one match are fully contained within
the text-positions of the other. More formally, the match (x2; y2; s2) is contained
within (x1; y1; s1) if x2 x1, y2 y1 and the size s1 s2.
2. Overlap: Two matches (x1; y1; s1) and (x2; y2; s2) overlap if some, but not all
textpositions of the first one are contained within the text-positions of second match.
More formally, the match (x1; y1; s1) overlaps (x2; y2; s2) if y2 y1 x2 x1
i.e., x2 lies between x1 and y1, y1 lies between x2 and y2.
3. Near-Disjoint: Two matches are near-disjoint, if they are close enough to be
combined into a single chunk of text, i.e. separated by a small number of characters, but
have no overlapping text-positions. More formally if (x1; y1; s1) and (x2; y2; s2)
are two matches such that 0 x2 y1 gap, where the parameter gap depends
on the particular features of the training corpus, then the matches may be
categorized as near-disjoint.
4. Far-Disjoint: Two matches (x1; y1; s1) and (x2; y2; s2) are far-disjoint if they are
separated by such a large number of characters that they cannot be adequately
merged into a single chunk of text. In this case x2 y1 &gt; gap.</p>
          <p>Containment:
x2 &gt;= x1, y2 &lt;= y1</p>
          <p>Overlap:
y2 &gt;= y1 &gt;= x2 &gt;= x1
x1
x1</p>
          <p>Near-disjoint:
x2 - y1 &lt;= gap
x2
y2</p>
          <p>y1
gap
y1
x2
y2
x1
x1
x2
y1</p>
          <p>gap
Far-disjoint:
x2 - y1 &gt; gap
Strategy for Merging The overall strategy for merging is based on the idea that two
matching pairs that have either one of the containment, overlap or near-disjoint
relationship can be merged towards forming a larger 3-tuple. 3-tuples that are far-disjoint
cannot be merged. Furthermore, if two mapping pairs of 3-tuples have a different
relationship in the source and suspicious documents then these tuples may be combined
according to their respective categories. However, in a particular case of 3-tuples, i.e.,
when the 3-tuples have a near-disjoint relationship in one document and overlap or
containment relationship in the other document, then no merging may be carried out. This
is because it is a likely case of term-repetition, a situation in which a term is repeated
within one of the documents, but it may mistakenly map to a large portion of text in the
other document.</p>
          <p>Figure 3 shows the four categories, while Table 1 gives a case-by-case listing of the
merging strategies that we used for merging.
2.4</p>
          <p>Filtering
After seeding and merging, the next step is filtering. For PAN-2014 training corpus, it
was observed that short passages, typically less than 200 characters resulted in a lot of
false positives. Hence all passages which were less than 200 characters in the source
document aligned with passages less than 100 characters in the suspicious document
were removed. The final output was then written to the XML files.</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Results</title>
      <p>Setup
The first step before testing was to select the values of the parameters n and gap for
character-n-grams and the gap size. Since this was a first time participation for us, one
of the goals of our approach was to ensure at least a 90% precision while getting a
high value of recall. After testing through a range of values, n = 20, gap = 200 was
found to be the most suitable since, this set of values ensured at least 90% precision on
all training corpora, while giving the highest values for the overall plagdet score and
recall.
3.2</p>
      <p>
        Training Corpora
We tested our approach on three corpora [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] for training: PAN-2014 training corpus,
PAN-2013 test corpus 1 and PAN-2013 test corpus 2. Figure 4 gives a graphical
representation of the results on the three corpora. The scores ranges obtained were as follows:
(a) Overall plagdet scores: 0.6 – 0.7 for each corpus,
(b) No-plagiarism scores: approximately full score 1.0 for each corpus,
(c) No-obfuscation scores: &gt; 0.9 for each corpus,
(d) Random obfuscation scores: 0.4 – 0.5 for each corpus,
(e) Translation obfuscation scores: 0.5 – 0.6 for each corpus,
(f) Summary obfuscation scores: &lt; 0.1 for each corpus.
      </p>
      <p>These results imply that our approach based on hashing and merging heuristics gives
very good plagdet scores for no plagiarism and no obfuscation cases, mid-range scores
for random and translation obfuscations, and marginal scores for summary obfuscation.
2014 Training Corpus
2013 Test Corpus 1
2013 Test Corpus 2
1.0
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0.0</p>
      <p>Overall No Plagiarism</p>
      <p>No Random Translation Summary</p>
      <p>Obfuscation Obfuscation Obfuscation Obfuscation
For the final testing, the final software was uploaded on 30/April/2014 and test runs on
all three test corpora were done on 16/May/2014. No errors were found during the runs,
and hence exactly a single run was done on each of the test corpora. Results of runs
on test corpora 2 and 3 have been published and are listed in Table 2, while results of
test corpus 1 runs were made available to the participants only (as it was the early bird
corpus). It can be observed from Table 2 that the overall plagdet scores are inline with
those obtained for the training corpora earlier.</p>
      <p>Currently, performance results of the software according to various obfuscation
types are not available on the test corpora. However, it is expected that these results
will be in agreement with the training corpora results too.
In this work, we used hashing and merging heuristics on character n-grams for text
reuse detection. Our approach scored a mid-range performance on PAN-2014 test
corpora. From the training corpora, it was obvious that while the approach scored very well
in no plagiarism and no obfuscation types, there was room for improvement for
translation and random obfuscations. Furthermore, a completely new approach may need to
be devised for the marginal summary obfuscation scores.</p>
      <p>Several directions of future work arise from here. For the current approach, a better
detection with improved recall can be achieved if a more fine-grained merging
mechanism is adopted with further sub-cases. Likewise, an improved granularity would also
help in improvising detection score, by confining matches to only the necessary number.</p>
      <p>
        On a different level, we can devise new approaches by using a variety of
mechanisms such as character skip grams [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] or other natural language processing
mechanisms for a more indepth processing. This could provide new insights into text reuse
detection, especially on random, translation and summary obfuscations.
Acknowledgements. Faisal Alvi would like to acknowledge the support provided for
this work by the Deanship of Scientific Research at King Fahd University of Petroleum
&amp; Minerals (KFUPM) under Research Grant RG-1113-1 &amp; 2.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Järvelin</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Järvelin</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Järvelin</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          <article-title>: s-grams: Defining Generalized n-grams for Information Retrieval</article-title>
          .
          <source>Information Processing Management</source>
          <volume>43</volume>
          (
          <issue>4</issue>
          ),
          <fpage>1005</fpage>
          -
          <lpage>1019</lpage>
          (
          <year>Jul 2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Karp</surname>
            ,
            <given-names>R.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rabin</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Efficient Randomized Pattern-Matching Algorithms</article-title>
          .
          <source>IBM Journal of Research and Development</source>
          <volume>31</volume>
          (
          <issue>2</issue>
          ),
          <fpage>249</fpage>
          -
          <lpage>260</lpage>
          (
          <year>March 1987</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Moraru</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Andersen</surname>
            ,
            <given-names>D.G.</given-names>
          </string-name>
          :
          <article-title>Exact Pattern Matching with Feed-forward Bloom Filters</article-title>
          .
          <source>Journal of Experimental Algorithmics</source>
          <volume>17</volume>
          ,
          <issue>3</issue>
          .4:
          <issue>3</issue>
          .
          <fpage>1</fpage>
          -
          <issue>3</issue>
          .4:
          <issue>3</issue>
          .18 (
          <year>Sep 2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Muth</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Manber</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          :
          <article-title>Approximate Multiple Strings Search</article-title>
          .
          <source>In: 7th Annual Symposium, Combinatorial Pattern Matching</source>
          . pp.
          <fpage>75</fpage>
          -
          <lpage>86</lpage>
          . Lecture Notes in Computer Science, Springer (
          <year>1996</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Potthast</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gollub</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hagen</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Graßegger</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kiesel</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Michel</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oberländer</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tippmann</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Barrón-Cedeño</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gupta</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rosso</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stein</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Overview of the 4th International Competition on Plagiarism Detection</article-title>
          . In: Forner,
          <string-name>
            <given-names>P.</given-names>
            ,
            <surname>Karlgren</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            ,
            <surname>Womser-Hacker</surname>
          </string-name>
          ,
          <string-name>
            <surname>C</surname>
          </string-name>
          . (eds.)
          <source>Working Notes Papers of the CLEF 2012 Evaluation Labs (Sep</source>
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Potthast</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gollub</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hagen</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tippmann</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kiesel</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rosso</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stamatatos</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stein</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Overview of the 5th International Competition on Plagiarism Detection</article-title>
          . In: Forner,
          <string-name>
            <given-names>P.</given-names>
            ,
            <surname>Navigli</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            ,
            <surname>Tufis</surname>
          </string-name>
          ,
          <string-name>
            <surname>D</surname>
          </string-name>
          . (eds.)
          <source>Working Notes Papers of the CLEF 2013 Evaluation Labs (Sep</source>
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Potthast</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stein</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Barrón-Cedeño</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rosso</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>An Evaluation Framework for Plagiarism Detection</article-title>
          .
          <source>In: 23rd International Conference on Computational Linguistics (COLING '10)</source>
          . pp.
          <fpage>997</fpage>
          -
          <lpage>1005</lpage>
          (
          <year>Aug 2010</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>