以正則表達式進行資料結構化

第三章裁判書資料集建置

第二節以正則表達式進行資料結構化

資料結構化與資訊擷取的意義在於，將本來對於電腦程式而言難以理解或不具特定意義的資料，轉化為可以解讀與應用的資訊，從而再轉化成需要的資料形式甚至進一步為資料特徵之表彰。本節說明本文如何進行資料結構化，第三節則說明資訊擷取方法。

選取了 439 件裁判後，為了進行後續的統計分析，本文係利用正則表達式，

將每件裁判予以「分段」，分為標題部、主文部、實體內容部以及標尾部共四部分。範例如下表 2，示意了本文將裁判分段後的具體範圍。

表 2 裁判全文區分範圍範例

標題部包含了審判法院、裁判字號、原告/被告（聲請人/相對人）、訴訟代理人、關係人乃至其他人等各自的全名或是經遮蔽後的代號等，囊括所有涉入本案審判過程者的相關訊息。除此之外，有時在主文出現前會有一段引言，由法院說明此裁判所涉主要內容，除表述方式不同外，實際上多與案由相類甚至相同。

標題區塊之起始與終結的正則表達式構思為，多數完整裁判結構中的起始部分是以羅列審判法院、裁判年度與字號，隨後該裁判類型屬於民事、刑事、行政中其一，以及是判決或者裁定之類型（臺灣 OO 地方法院民事判決），再接著向下若干行數才是羅列本案當事人以及其他關係人之明確訊息。接著在主文標籤出現前，會由一段前言說明本案事件性質，其中即夾雜有案由或相類似之敘述。故本區塊之正則表達式略為：檔案起始標號…主文標籤。

主文部包含了法院裁判結果之扼要重述，在給付類型裁判即為強制執行之依據，故而法院常尋求簡單而明確、具體的內容，且必須當事人能夠清楚得知之處。在裁判書中常會以標籤明示主文之起始，直至「事實與理由」等裁判內文部分之開始，兩者中間所夾者即為裁判主文。故本區塊之正則表達式略為：主文標籤…裁判內文標籤。

實質內容部包含裁判內文，也就是整個裁判書的實質內容部分，但實際組成可能有數種組合，通常較完整之情形要包括程序事項、法院審酌事實、見解及理由，而事實與理由之詳細組成亦有可能進一步區分程序與實體、本訴與反訴。在此因為重點是區分裁判不同部分，只要是「事實與理由」之後到裁判日期前的段落，即屬於裁判內文。故本區塊之正則表達式略為：事實與理由標籤…裁判日期行。

須注意者，本文為了再進一步解析裁判內文，亦即細分出原告主張、被告主張、法院判斷的不同部分，在分段落時依據裁判書上表現出內文架構的項目編號，例如「壹、一、（一）」等，從編號形式來判斷段落的階層。舉例言之，下表 3 的實質內容部之中，有「壹、原告主張」「貳、被告抗辯」「參、本院得心

證之理由」，因「壹、貳、參」屬於相同類別的次序編號，且「壹、原告主張」

的段落到「貳、被告抗辯」之間，並未出現其他編號，系統便會判定「貳、被告抗辯」與「壹、原告主張」屬於同階層但是互不隸屬的平行段落。另一方面，

「參、本院得心證之理由」之後，出現了「一」這樣不同形式的編號，系統將判定此情況下，「一」即可是「參」段落的附屬階層。匹配段落標號之正則表達式略為：單行起始標號編號。

標尾部包含了裁判日期、法官姓名、書記官姓名。其特徵在於一般裁判書之結尾部分會以兩行裁判日期行中夾有法官姓名以及當事人不服提起救濟的不變期日，然後在第二行裁判日期後才列出書記官姓名。標尾區塊的正則表達式略為：

裁判日期…法官姓名…裁判日期…書記官。

透過以上的正則表達式將裁判書概略切分為不同區塊後，資料就達到了本文在自動化編碼甚或是斷詞處理所需的結構化需求。能夠鎖定特定部分來擷取特定資訊，並且透過關鍵字組合條件進一步根據擷取的資料來自動化編碼。

表 3 裁判全文半結構化資料範例

<lawyer_pattern>○○○律師</lawyer_pattern>

<lawyer_pattern>○○○律師</lawyer_pattern>

上列當事人間請求○○○等事件，經本院於中華民國○○○年○月○日言詞辯論終結，判決如下：

</preface>

</header>

<main>

准○○○○○○。

○○其餘之訴均駁回。

本訴訴訟費用由○○負擔百分之○，餘由○○負擔。

</main>

<body>

<facts_and_reasoning>

<level0>壹、原告主張：

</level0>

<level0>貳、被告答辯：

</level0>

<level0>參、本院得心證之理由：

</level0>

</facts_and_reasoning>

</body>

</footer>

</context>

在文檔中以資訊技術分析我國離婚贍養費相關裁判 (頁 34-39)

第三章 裁判書資料集建置

第二節 以正則表達式進行資料結構化

第三章裁判書資料集建置

第二節以正則表達式進行資料結構化