支持語義標注的辦公文檔格式擴展方法

范博珩，李寧，田英愛

(北京信息科技大學 計算機學院,北京 100101)

隨著各類文檔數量日益增多以及傳播日益廣泛，人們希望計算機能夠自動處理和理解文檔，而這些一般需要通過語義標注來實現。語義標注是指利用本體(ontology)或詞匯表(vocabulary)對文檔的特定內容添加語義標記，標識出與之對應的概念或實體，并且建立起標注內容與本體之間的聯系。語義標注是文檔的核心技術之一[1]。語義標注的結果使文檔具有了語義元數據，使得機器可以自動理解和處理文檔，也便于文檔信息的共享和有效利用，可以高效實現文檔的語義檢索、內容提取和自動分類等智能化處理。

近年來，Web上的語義標注研究成果十分豐富，Google、Yahoo和Yandex等公司共同創建了一個共享詞匯表——Schema.org[2]。在線商店將schemas標記嵌入至描述產品的超文本標記語言(hypertext markup language，HTML)頁面中，以使搜索引擎能夠輕松識別產品價格并為網站增加流量[3]。經過語義標注后得到的產品結構化數據也為產品分類、產品匹配、推薦系統、產品知識圖譜等新興研究領域的發展提供了支持。

然而，文本不僅僅來自HTML文檔，也來自辦公文檔、版式文檔以及復雜混合格式的文檔。其中，僅有少數研究針對辦公文檔進行語義標注。Tallis[4]提供了一套針對DOC格式的文檔半自動化標注系統Semantic Word，Carr等[5]提出了WICKOffice系統，Fink等[6]開發了一個Word插件，用戶可使用SmartTag和自定義XML標記對文檔中的生物醫學領域的專業術語進行手工標注。但這些標注系統無法支持標準的辦公文檔格式，也無法支持多源語義標注。

辦公文檔語義標注之所以研究成果較少，大多因辦公文檔的復雜性所致。在對辦公文檔進行語義標注時，需要滿足以下的條件：1)能夠在文檔格式中記錄語義元數據；
2)能夠支持OOXML(office open XML)、ODF(open document format)、UOF(unified office document format)等主流辦公文檔格式標準；
3)能夠經受對語義元數據的編輯和修改；
4)能夠在文檔編輯過程中保持文檔內容與語義元數據的同步一致；
5)能夠支持多源語義標注，即允許同一標注內容對應多個本體或詞匯表。正是因為流式文檔語義標注的復雜性，至今尚未見到在辦公文檔中進行語義標注的成熟方法。

針對上述問題，本文提出一種在辦公文檔中支持語義標注的方法，包括對辦公文檔格式的擴展，標注規則的設計以及在主流辦公軟件中支持語義標注的方法。本文的成果已經被團體標準T/CESA 1176—2021《信息技術 電子文檔語義元數據嵌入方法》[7]所采納。

目前雖然辦公文檔語義標注的研究較少，但仍有一些相關的成果可以借鑒。例如，HTML中文本的存儲方式與辦公文檔相似；
PDF(portable document format)中也有成熟的語義標注技術。因此，這些研究均可為本文提供參考。

在HTML中，語義標注的具體形式主要以嵌入式為主，標注結果作為相關元素的屬性加以記錄。Tittel等[8]在關于中世紀法語的HTML網頁內容中嵌入RDFa(resource description framework in attributes)標記的詞匯，將網頁中的實體與詞匯表中的概念和屬性對應起來；
Beno等[9]構造了Doc2RDF，能夠自動對法律領域的HTML文本進行標注；
Salem等[10]在Beno研究的基礎之上，實現了標注多個領域的HTML文本的功能；
Mbouadeu[11]、Albukhitan等[12]利用深度學習的方法自動標注HTML文檔，并使用microdata或microformats將標注結果記錄于原文檔中。

在PDF中，語義標注的具體形式主要以分離式為主，標注結果存放在PDF文檔的單獨數據塊中，并與原文檔建立關聯。Eriksson[13]、Kim等[14]通過使用可擴展元數據平臺(extensible metadata platform，XMP)[15]技術在PDF文檔中建立內容與本體的映射關系。

上述研究中，嵌入式標注結果易于管理且能保證語義元數據與文檔內容同步，但是會給原文檔格式帶來一定的影響。與之相比，分離式標注結果需要單獨進行存放，難以保證語義元數據與文檔內容同步，但是對原有文檔格式的影響較小。本文采用嵌入式標注方法對辦公文檔進行語義標注。

在幾種嵌入式語義標注技術中，RDFa[16]具有更強的表達力與適用性[17]，能夠支持多詞匯表。因此，鑒于RDFa應用在HTML流式文檔中的諸多優點，本文基于RDFa對辦公文檔格式OOXML進行擴展，以使辦公文檔中可以加入語義元數據標記。目前OOXML格式在辦公文檔中應用最廣，以之為研究對象具有典型意義，其他基于XML的辦公文檔格式標準ODF和UOF等與之類似，本文的方法也同樣適用。

采用RDFa對OOXML進行語義標注前，首先需要分析HTML和OOXML的文檔結構。下面以圖1中的新聞為例加以說明。

圖1 一個新聞的例子

對于一篇HTML文檔，文檔的主體內容通過組合不同的塊級元素和行內元素進行顯示。塊級元素如div、p等通常表示文本段落或片段，而行內元素如span等則通常用來更細粒度地分割局部文本。RDFa是萬維互聯網聯盟(World Wide Web Consortium)W3C制定的標準，它能夠在這些元素中增加下列屬性：

@vocab：當前所用的默認詞匯表；

@typeof：資源的概念(類型);

@property：某類型所具有的屬性。

RDFa不會影響HTML的瀏覽。使用RDFa對HTML進行語義標注如圖2所示。

圖2 RDFa在HTML中的標注示例

圖2中，有兩個標注內容，即“新聞社”和“東非”，它們分別為詞匯表Schema.org中表示組織(typeof="Organization")和地點(typeof="Place")的兩個實體名稱(property="name")。

與HTML格式不同，OOXML文檔的存儲基于ZIP壓縮打包格式[18]，文檔的主體內容記錄在文件包內的document.xml文件中。段落在OOXML格式中均以段落元素p存儲，是構成文檔的基本單元。p下包含段落屬性元素pPr和句元素r，段落中的文本根據式樣的不同會形成多個句(run)。r下包含句屬性元素rPr和文本元素t。句中的文本記錄在t下。語義元數據主要在段落或句一級進行標注。

可以借鑒RDFa在HTML中的用法，將RDFa屬性嵌入到t或其他元素中，如圖3所示。

圖3 RDFa在OOXML中的標注示例

雖然對于上述的一般情況，這種基于RDFa對OOXML進行擴展的方式是可行的，但是OOXML畢竟與HTML不同，OOXML主要用于辦公文檔編輯，其文檔數據與語義信息存在較為復雜的對應關系，可能導致以下問題。

1) OOXML中語義標注的范圍可能與文本元素的范圍不一致，具體體現在兩個方面：

① 單一文本可能對應多個語義標注內容，如上例中的“埃塞俄比亞”、“肯尼亞”等地名實體出現在同一個t下，而由于t已是構成文本的最小單元，因此無法為不同的實體指定不同的RDFa屬性，參見圖4；

圖4 文本元素中包含多個實體的OOXML源碼

② 一個待標注內容可能分散在多個句或文本之中，在Microsoft Word等辦公軟件中，往往會自動把中英文文本和數字分在不同的句中，難以獲得一個完整的標注，如上例中的“2月14日”會放在多個句元素和文本元素中，參見圖5。

圖5 實體分散成多個句元素和文本元素的OOXML源碼

2) 對于一般用戶來說，HTML僅供瀏覽，不需進行編輯。而OOXML則要能支持編輯，因而嵌入了語義元數據的文檔需要能夠被辦公軟件打開和編輯。另外，嵌入的語義元數據需要具備魯棒性，經得起反復編輯。

上述問題，需要專門設計流式文檔的語義標注規則，并找到辦公軟件支持語義標注的方法。

為解決前文所述的問題，本文專門設計了用于辦公文檔標注的結構模型。標注模型如圖6所示。

圖6 標注模型結構

該標注模型用XML Schema來描述，根元素為“metadata”，該元素具有@ID、@Seq和@Begin三個屬性，也可使用任何RDFa的屬性。

對于單一文本對應多個語義標注內容的情況，可將文本元素中的多個待標注內容分別放入多個metadata元素節點進行描述，并將相關的文本設為metadata元素的內容。以圖4中的“埃塞俄比亞”、“肯尼亞”和“蝗災”為例，其標注的結果如圖7所示。

圖7 單一文本對應多個語義標注內容的標注方法

圖7中，“埃塞俄比亞”和“肯尼亞”為詞匯表Schema.org中的地點(typeof="Place")名稱(property="name")，“蝗災”為詞匯表Schema.org中的事件(typeof="Event")名稱(property="name")。

對于一個待標注內容分散在多個句或文本之中的情況，可以通過指定metadata元素中@ID和@Seq兩個屬性，將多個語義標注內容按順序進行組合。@ID為標注實體的編號，@Seq為標注的順序號，@ID結合@Seq可以實現同一實體的多段標注。@Begin指示某一標注的開始或結束。

例如，對應圖5的情況，“2月14日”為事件的發生日期，在一些詞匯表中，日期進一步分解為年、月、日，因此，“2月14日”要按兩個實體來標注，即“2月”和“14日”。

圖8 一個待標注內容分散在多個句或文本之中的標注方法

圖8中，1～4行以及5～8行描述的兩個metadata元素節點具有同樣的@ID，表示它們共同標注一個日期元數據。第1行的metadata元素節點其屬性Begin="true",第4行的metadata元素節點其屬性Begin="false",它們具有同樣的@Seq屬性(Seq="1")，表示是詞匯表Schema.org中事件(typeof="Event")的發生日期(property="startDate")的第一部分標注內容，對應兩個句中的文本“2”、“月”。同理，5～8行表示事件發生日期的第二部分標注內容，對應兩個句中的文本“14”、“日”。

在OOXML格式的文檔中添加RDFa屬性得到擴展的OOXML文檔，稱之為語義文檔。然而這種擴展將導致文字處理軟件無法正常打開和編輯語義文檔。本文提出了一種解決方法，即通過預處理和后處理方法實現語義文檔與普通辦公文檔之間的無縫切換。

4.1 語義文檔的預處理轉換

預處理時，利用辦公文檔中的批注機制作為文字處理軟件中記錄語義元數據的載體，將語義文檔中標注的語義元數據存儲至批注元素中。辦公文檔中的批注是附加在文檔內容片段上的注釋信息。批注與辦公文檔中的文本、圖片等內容獨立顯示并相互關聯。同時，用戶在編輯文檔內容時，也能夠直接編輯和修改批注，對于編輯具有很好的魯棒性。因此，采用批注來存儲語義元數據，可以支持用戶在編輯過程中對語義元數據進行編輯和修改，也可保持在編輯過程中語義元數據的同步一致。

在OOXML打包文件中的document.xml內，批注由commentRangeStart、commentRangeEnd和comment-Reference三種元素描述。其中，commentRangeStart和commentRangeEnd確定批注的起始位置和結束位置，表示批注的范圍；
commentReference與OOXML打包文件中的comment.xml內的comment元素的內容相關聯，用于在文字處理軟件中顯示批注的內容。在一個批注中，上述4個元素具有相同的屬性@ID。例如，圖1中的“東非”添加批注后，document.xml中將會呈現如圖9的結構。

圖9 document.xml中的批注引用

在comment.xml文件中的批注結構如圖10所示。

圖10 comment.xml中的批注引用

為能夠區分一般的批注和包含語義元數據的批注，本文采用特殊的用戶名稱用于語義元數據批注。未來，建議為文檔批注增加一個特殊的類型，用于在辦公文檔中記錄語義元數據。但是這要通過標準制定組織改進相關的標準。目前，采用特殊用戶名的方式也是完全可以的，其前提是該用戶只可進行語義標注，不能進行一般的批注。

預處理算法的核心思想是找到每一個語義標注內容的范圍，即語義元素metadata的范圍，以此來確定批注的范圍，并根據記錄的語義元數據確定批注的內容。在確定批注范圍時，會出現兩種情況：1) 單一文本下具有多個語義標注實體；
2) 標注實體由多個文本描述。對于情況1，需要調整文檔結構，復制多個r和t元素節點并保證每個t下只包含一個metadata元素節點，以符合OOXML添加批注的標準格式。對于情況2，則直接根據兩個metadata元素節點確定批注范圍即可。本文采用如下算法進行語義文檔的預處理轉換。

Algorithm1:CreateCommentNodeInput:m as metadata, r as range, u as userOutput:c as the comment node1 Function CreateCommentNode(m,r,u)2 Create a new comment node c;3 c.content ← n.metadata; // n is the semantic node in r4 c.range ← Range(t); // t is the text node in r;Range(t) means get range of t5 c.user ← "dsm";// Set user of c as "dsm"6 Output c;7 End Function

Algorithm2:ForwardTransformInput:D as the semantic documentOutput:D as the transformed document in the standard format1 Function ForwardTransform(D)2 Letc-list be the comment list to be added into D;3 c-list ← null;4 For each paragraph p in D5 For each run node r in p6 Ifr contains multiple semantic nodes Then7 Split r into multiple nodes r-list,each of which contains a single semantic node;

8 End If9 End For10 End For11 For each semantic node n in D12 Ifn spans multiple text nodes Then13 Group the text nodes of same semantics into one segment;14 For each text segment s which n spans15 c ← CreateCommentNode(n.metadata,Range(s),"dsm");16 Add c into c-list;17 End For18 Else // n spans single text node t19 c ← CreateCommentNode(n.metadata,Range(t),"dsm");20 Add c into c-list;21 End If22 End for23 Add c-list into D;24 Output D;25 End Function

算法1用來生成批注元素，包括批注的范圍和內容。算法2是預處理算法的流程。算法2中，步驟2～3聲明待添加的批注元素集合并賦值為空。步驟4～22是生成語義批注的過程。其中，步驟4～10用于調整文檔結構，對應前文所述確定批注范圍的第一種情況。步驟11～22中，若標注實體由多個文本描述，即前文所述的第二種情況，則執行13～17步驟。確定標注實體的起始和結束位置后，調用算法1生成語義批注，否則根據步驟4～10調整好的文檔結構，直接調用算法1生成語義批注。步驟23～25輸出轉換完成的文檔。

4.2 語義文檔的后處理轉換

后處理的目的與預處理相反，核心思想是找到辦公文檔每一個帶有語義元數據的批注及其范圍，以此來確定語義標注的內容和范圍。在進行后處理轉換時，首先要找到語義元數據批注的所有元素，即批注范圍元素和批注內容元素。在確定語義標注范圍和內容時，同樣會出現兩種情況：1) 實體由單一文本描述；
2) 實體由多個文本描述。對于情況1，將實體放入metadata元素節點進行描述，批注的內容放至metadata屬性中。對于情況2，需要添加兩個metadata元素節點，設置相應的@Begin，并分別將其插入在批注起始位置后和批注結束位置前。批注的內容放至@Begin值為true的metadata屬性中。本文采用如下算法進行語義文檔的后處理轉換。

Algorithm3:BackwardTransformInput:D as the document in the standard formatOutput:D as the semantic document1 Function BackwardTransform(D)2 For each comment node c in D3 Ifc.user is "dsm"Then4 Letn be the semantic node;5 Ifc spans multiple text segment Then6 n.id ← GenerateID();// Generate ID7 n.metadata ← c.content;8 Insert n at the first text node;9 Add end tag of n with n.id at the end of c.range;10 Else // c spans single text node t11 n.id ← GenerateID();12 n.metadata ← c.content;13 Insert n at t;14 End If15 Remove c;16 End If17 End For18 Output D;19End Function

在算法3中，步驟2～17是添加語義元素metadata的過程。步驟3根據批注用戶名判斷該批注是否為語義批注，若判定為真則執行步驟4～15。步驟5～14用于添加語義元素metadata的位置和內容。其中，若實體由多個文本描述，即前文所述第二種情況，則執行步驟6～9，將批注內容賦值給@Begin值為“true”的語義元素metadata的屬性中，并在實體文本的結束位置添加@Begin值為“false”的語義元素；
否則，執行步驟11～13，將批注內容賦值于語義元素metadata的屬性中，并將metadata插入至文本元素t下。步驟18～19輸出轉換完成的文檔。

本文基于C#和winform窗體設計器實現了一個辦公文檔語義標注工具，具有語義標注、預處理轉換和后處理轉換3個功能。以圖1的新聞為例，根據前述辦公文檔語義標注方法進行標注。

圖1的新聞案例中涉及多個實體對象，如“2月14日”、“新聞社”、“蝗災”等。應用本文的方法進行實體標注時，需要根據對象的性質從Schema.org詞匯表中選擇合適的類型，同時還要選擇合適的屬性。以新聞示例的正文第一段為例，標注結果如圖11所示。

圖11 語義標注后的擴展OOXML文檔示例

上述擴展的OOXML文檔經過預處理轉換，生成標準的OOXML文檔，圖12展示了辦公軟件Microsoft Word打開該文檔后的編輯界面。從圖12中可以看到，語義文檔中的語義元數據在Word文檔中以批注的形式呈現，每個語義批注對應一個命名實體，允許用戶按批注方式進行編輯。同時，也允許用戶在Word文檔中的任意位置添加語義批注。

圖12 Microsoft Word中打開經過預處理的文檔示例

圖12的文檔經過后處理轉換后，可以生成新的語義文檔。圖13展示了“新聞社”、“東非”、“埃塞俄比亞”3個實體在新的語義文檔中的標注示例。

從圖13中可以看到，“新聞社”、“東非”、“埃塞俄比亞”3個實體的標注方式與圖11不同，這是因為在進行前一步的預處理轉換時，將同一文本元素t下的多個語義標注實體分配了多個r和t元素，調整了文檔結構，使每一個語義標注實體對應一個r和t。圖13與圖11文檔的語義邏輯是一致的。

圖13 后處理轉換生成的語義文檔示例

語義文檔可使用Google結構化測試工具或者RDFa.info[19]驗證器檢測RDFa語法的正確性，并可使用GRDDL(gleaning resource descriptions from dialects of languages)[20]或W3C的RDFa解析器從中提取出RDF三元組結構的語義元數據，生成Turtle、RDF/XML或N-Triples等文件。圖14為解析的結構化數據。由圖14可知，語義文檔可以通過RDFa.info測試工具驗證。以檢測到的“Event”為例，“Event”有兩條數據，即語義文檔中標注的事件名稱(name)“蝗災”及事件發生的時間(startDate)“2月14日”。

圖14 文檔結構化數據

基于RDF數據，可進一步使用RDFa.info生成知識圖譜。圖15為圖11部分語義標注內容對應的知識圖譜。

圖15 基于文檔語義元數據生成的知識圖譜

上述結果表明，本文提出的方法能夠成功實現辦公文檔的語義標注，方便計算機對文檔的知識提取。

本文的方法適用于其他以XML為基礎的辦公文檔格式，比如ODF和UOF。在版式文檔格式中，國內的OFD(Open Fixed-layout Document)也可被本文的方法所支持。這3種文檔格式標準的XML Schema框架與OOXML十分相似，因此本文的方法可以擴展到上述的3種文檔格式中，具有通用性。此外，本文采用RDFa作為語義標注技術，能夠實現多個詞匯表的標注，具有很強的語義表達能力。用戶可以選擇不同的詞匯表對文檔中的實體進行標注，標注后文檔所蘊含的語義信息也會不同。

本文以流式文檔的典型格式OOXML為研究對象，詳細分析了OOXML格式與HTML格式在文本描述方面的差異性。在此基礎上，提出了流式文檔語義格式擴展方法。針對流式文檔格式特點，設計了特定的語義標注規則。同時，提出通過預處理和后處理實現語義文檔與辦公文檔之間無縫切換的方法，以保證標注后的文檔經過預處理能夠被文字處理軟件支持，經過后處理能夠使帶有語義批注的辦公文檔重新形成語義文檔。實驗證明，使用本文的標注方法能夠增強辦公文檔的語義表示能力，便于計算機對文檔的自動理解和處理。

本文主要針對OOXML格式的辦公文檔進行語義標注，后續可擴展到ODF、UOF等格式，為更多的辦公文檔格式增加語義標注的支持能力。本文的標注對象是文檔中的文本，尚未考慮其他對象，比如圖像、表格、公式等元素的語義標注，它們的結構更加復雜，需要進一步研究和完善標注方法，使得標注內容更加全面。此外，可考慮利用自然語言處理技術實現自動化或交互式的語義標注，提高標注的效率。