XML標記語義的示例分析

這篇文章主要為大家展示了“XML標記語義的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“XML標記語義的示例分析”這篇文章吧。

 1　引　言
近年來，隨著數(shù)字出版的發(fā)展、萬維網(wǎng)應(yīng)用的迸發(fā)以及電子商務(wù)領(lǐng)域的快速發(fā)展，我們?nèi)粘５纳鐣?、商業(yè)、文化、生活等方方面面都開始應(yīng)用閃標準化通用標記語言（Standard Generalized Markup Language，SGML）和可擴展標記語言（Extensible Markup Language，XML）的文本標記系統(tǒng)。SGML/XML是一種定義描述性標記語言的機器可讀技術(shù)。除去一些需要特別處理的部分，這種語言能清晰地定義文檔結(jié)構(gòu)及其潛在意義。SGML/XML發(fā)展速度很快，廣泛使用這種技術(shù)能夠支持高性能的文檔互操作處理和出版。
這種美好的愿望已經(jīng)部分實現(xiàn)了，SGML/XML的優(yōu)越性超出了人們的預(yù)期，但是SGML/XML文檔系統(tǒng)在功能性、互操作性、多樣性和可獲取性上仍有待提高。若不抓住這個機會，后果會非常嚴重：實業(yè)界已經(jīng)花費了高昂的財務(wù)成本，也失去了很多機會；在關(guān)鍵的安全應(yīng)用上還有可能導(dǎo)致一些災(zāi)難；對于殘疾人來說，這會阻礙他們平等地獲取當代社會文化和商業(yè)福利。此外，久已存在的一些問題也在不斷提醒我們，當下最好的數(shù)字文檔模型仍存在缺陷，至少是不夠完善的。
這些問題的根源在于，盡管SGML/XML能為文檔提供有意義的結(jié)構(gòu)，但是SGML/XML不能以系統(tǒng)的機器可處理的方式來表示文檔組件和主題之間的基本語義關(guān)系。SGML/XML支持對機器可讀的“語法”進行說明，但是它沒有提供解釋某種語法的語義內(nèi)涵的機制，所以一個SGML/XML詞匯的潛在意義到底是什么，還沒有辦法進行形式化表達。利用當下的SGML/XML甚至無法表達非常簡單的有關(guān)文檔標注系統(tǒng)的基本語義事實，這些事實通常是標記語言設(shè)計師預(yù)先設(shè)計的，但具體實現(xiàn)仍舊依賴于標記語言用戶和軟件。
這種表達功能的缺失使得SGML/XML用戶必須猜測標記語言設(shè)計師想到的但沒有形式化表達出來的那些語義關(guān)系。內(nèi)容開發(fā)者必須猜測設(shè)計者的意圖，在內(nèi)容編碼時依靠這些推斷開展工作，無法將自己的推斷和意圖清晰地表達給其他人或者傳遞給處理編碼內(nèi)容的應(yīng)用程序。軟件設(shè)計師也需要猜測標記語言設(shè)計師的可能意圖，并將這種猜想設(shè)計到軟件工具和應(yīng)用系統(tǒng)中。有時候二階的猜想是必須的：軟件設(shè)計師要猜測內(nèi)容開發(fā)者對標記語言設(shè)計師意圖的推斷。
很顯然，這些猜測是不完整的、易錯的和未經(jīng)證實的。而且，制作和實現(xiàn)過程都費時費力，功能性和互操作性也很差。為一般的自然語言文檔配備一個SGML/XML的說明書并不能完美地解決這個問題。當然，普通的自然語言文檔能給內(nèi)容提供者和軟件工程師提供一些提示，但是目前SGML/XML文檔還沒有通用的規(guī)則。不管怎么樣，普通的自然語言文檔不是機器可讀的形式，這就是我們要說的SGML/XML標記系統(tǒng)的問題。
與SGML和XML相關(guān)的機器可處理的語義描述方面的設(shè)想還未形成，這是目前工程領(lǐng)域的問題和未來發(fā)展障礙的根源，相關(guān)的語義學(xué)研究也很少，但是很多學(xué)者已經(jīng)開始關(guān)注此問題。W3CSchema方面的工作與此相關(guān)，但也只是覆蓋了這個問題中的很小一部分（比如數(shù)據(jù)類型）。W3C的“語義網(wǎng)”計劃也與此相關(guān)，但它是為了發(fā)展通用的基于XML的知識表示技術(shù)。我們的研究重點是文檔標記的語義，它隱藏在實際的文檔處理系統(tǒng)中。人們可能會說語義網(wǎng)的本質(zhì)就是設(shè)計語義標記，然而在本文中，我們認為解決以上問題還必須要深入考慮標記的本質(zhì)意義。
接下來，本文首先從歷史背景方面說明標記的意義問題（標記在文本處理方法的發(fā)展中扮演了有趣的角色）；其次，詳細描述是何種因素產(chǎn)生了形式語義標記需求，何種因素決定了語義需求；最后簡要介紹一項多個機構(gòu)正在參與實施的研究計劃——BECHAMEL標記語義計劃，該計劃正努力解決標記的語義問題。
 2　歷史背景  
文檔“標記”大概可以算作傳播系統(tǒng)的一部分，包括早期的書寫、抄寫出版和印刷，但是隨著數(shù)字文本處理和排版的發(fā)展，標記的使用變得自覺又常見，同時也成了系統(tǒng)開發(fā)中一個重要的創(chuàng)新領(lǐng)域。20世紀60年代到80年代是文檔標記系統(tǒng)全面系統(tǒng)化發(fā)展的時期，重點工作是提升數(shù)字排版和文本處理的有效性和功能性。20世紀80年代初期，人們依舊致力于研究標記的理論框架，并利用該框架支持高性能系統(tǒng)的開發(fā)。這方面的一些成果已經(jīng)發(fā)表，但大部分成果還只是記錄在工作文檔和各種標準形式的產(chǎn)品上。
在這個階段出現(xiàn)的一種觀點是，文檔作為一種智力成果，更適合被抽象為一系列對象（如章節(jié)、段落、公式等）的有序?qū)哟位Y(jié)構(gòu)模型，而不是一維文本字符流模型。字符流常夾雜著大量定義格式的編碼、描述設(shè)計布局的結(jié)構(gòu)（如頁碼、分欄、印刷行）、像素值矩陣，以及其他一些在不同的文檔處理及存儲系統(tǒng)中潛在的表達形式。有序?qū)蛹壗Y(jié)構(gòu)模型概括了兩種具有本質(zhì)差別的標注，分別是識別編輯文本對象（標題、章節(jié)等）的標注和說明版面要求的標注。前者的應(yīng)用已經(jīng)取得一些成果。諸如標題、章節(jié)、段落、方程式、引文之類的相關(guān)文檔元素能被分隔標記清晰地標示出來，之后通過映射給元素類型的規(guī)則來對元素進行間接處理。這種內(nèi)容和形式的分離，能夠以常見的組合經(jīng)濟的方式實現(xiàn)基礎(chǔ)層面的間接性和抽象化。在文檔處理的所有方面，這種分離形式有巨大而多樣的實用價值，更重要的是它似乎說明了“文檔到底是什么”這個問題。用于實現(xiàn)如此功能的描述性標記不只是標出了元素的范圍，也攜帶了文檔模型想要揭示的意義（如這段文本是一個章節(jié)）。
20世紀80年代初期，美國國家標準化局（ANSI/ISO）發(fā)布了很有影響力的SGML文檔標記元語法，并梳理了標記和文檔結(jié)構(gòu)方面之前所做的理論和分析工作。SGML為定義描述性標記語言提供了一種機器可讀的形式。作為一種元語法，SGML沒有定義標記語言，而是詳述了開發(fā)標記語言中的機器可讀的技術(shù)。這個定義的核心是一種類似于巴科斯-諾爾范式（Backus-Naur Form，BNF）的形式化表達機制。這一機制攜帶有用于定義類型化屬性及其取值的規(guī)則，以及其他一些用于進一步抽象化和間接化的設(shè)計（參見注釋中對文檔類型定義（Document Type Definitions，DTDs）和巴科斯-諾爾范式相似程度方面的總結(jié)）。從結(jié)構(gòu)上來說，SGML文檔是一種具備有序分支和帶標記節(jié)點的樹，它是其相應(yīng)的DTD的形式化產(chǎn)物。
經(jīng)過多年的分析和實踐，SGML背后的基本理念已經(jīng)眾所周知。利用元語法層面的行業(yè)級標準和詞表層面的本地化創(chuàng)新帶來的優(yōu)點，SGML的特有機制（類巴科斯-諾爾范式的元語法，類型化屬性／屬性值對，實體引用等）在應(yīng)用程序和工具方面得到了高效實現(xiàn)。SGML標記語言本身在發(fā)展中似乎也同時支持和優(yōu)化用于文檔系統(tǒng)設(shè)計、實施和利用的理想的工作流程。20世紀80年代中期到90年代初期，大量基于SGML的標注系統(tǒng)發(fā)展起來。
盡管SGML的發(fā)展得到很多關(guān)注，其想法也不錯，并在多個領(lǐng)域成功實施，但在最初的十年里，幾乎沒人使用它。導(dǎo)致這個結(jié)果的因素有很多，但最重要的還是SGML自身過于復(fù)雜，特別是SGML中包含了許多復(fù)雜的可選屬性，對應(yīng)的軟件可能根本沒必要對其實現(xiàn)，導(dǎo)致SGML軟件開發(fā)速度非常緩慢。更糟糕的是，如果文檔未經(jīng)DTD驗證，進一步的分析就不可能實現(xiàn)?？s寫控制意味著如果不考慮文檔語法，元素邊界都無法確定下來。另外，SGML還包含了一些其他屬性，它們會導(dǎo)致已有的語法分析工具不適用于形式語法，無法進行高效的語法分析。
在網(wǎng)絡(luò)出版和交流方面，SGML系統(tǒng)可應(yīng)用于HTML（超文本標記語言）方面。最初的HTML版本定義很松散，缺乏正式的語法說明。后來人們對HTML的SGMLDTD有了興趣，事實證明為已經(jīng)成為“正確”實踐的東西設(shè)計DTD是很困難的。更重要的是，由于在最初的HTML說明書中，供應(yīng)商隨意地把程序性標記（如<center>）添加到關(guān)鍵性的描述性標記中（如<title>），導(dǎo)致開發(fā)者和用戶同時忽略描述性標記和程序性標記的區(qū)別。HTML的描述性部分甚至不能很好地反映文檔的層級結(jié)構(gòu)，說明書不能提供樣式表語言來支持間接性。最后，SGML的機制無法擴展元素集和使用替換元素集，HTML文檔似乎不能被通用的SGML處理器（允許拓展和替換DTDs）處理，而只能被特定的HTML格式化程序處理，配合處理器中硬編碼的格式規(guī)則處理HTML標簽。
HTML后續(xù)的發(fā)展可以看作原有松散的HTML語言努力向SGML語言序列轉(zhuǎn)變的過程。如果有足夠的時間和資源來應(yīng)用那些成熟的文檔系統(tǒng)設(shè)計規(guī)則，那么這種轉(zhuǎn)變是可以實現(xiàn)的。不過，新成立的W3C機構(gòu)在采納新元素集合以及在Web應(yīng)用SGML上面臨很大的壓力。SGML的不足使其很難在Web上發(fā)揮SGML和描述性標記的優(yōu)勢。主要問題是SGML中存在大量多選特征、復(fù)雜的形式化語法，以及必須依賴DTD確定元素等。
為了確保HTML和其他相關(guān)技術(shù)能夠充分利用元語法的優(yōu)點，用戶能夠更便捷地開發(fā)和分享新的特定領(lǐng)域中的元素，文檔能夠不經(jīng)DTD索引就被解析為元素樹，SGML工具和應(yīng)用能夠協(xié)調(diào)發(fā)展，W3C創(chuàng)建了SGML的子集，希望能夠提供一個相對簡單的標準（無需進行選擇）、一些相對簡單的語法，以及一種無需DTD也能處理未經(jīng)驗證的文檔格式的方法，于是XML應(yīng)運而生。經(jīng)過一年半的發(fā)展，XML被W3C以推薦標準在1998年正式推出。
自1998年開始，新穎的XML標記語言呈現(xiàn)爆炸式增長，這種快速發(fā)展的勢頭一直持續(xù)到今天。這種爆炸式發(fā)展的原因在于：
（1）特定領(lǐng)域的新型標注系統(tǒng)的需要。隨著科學(xué)、醫(yī)學(xué)、商業(yè)、法律、工程和這些大型學(xué)科的特定領(lǐng)域中的網(wǎng)絡(luò)電子出版應(yīng)用的增長，新型標注系統(tǒng)需要開發(fā)。
（2）降低開發(fā)新型工具及其應(yīng)用成本和復(fù)雜程度。與SGML相比，解析XML更加簡單。
（3）XML標記支持與出版相關(guān)的信息處理與傳播過程，以及與出版無關(guān)的應(yīng)用。
值得慶幸的是，我們終于開發(fā)出有效又容易實施的技術(shù)，并以此來創(chuàng)造高性能的標記語言、數(shù)字文檔，以及與其他信息管理程序相融合的文檔處理和出版系統(tǒng)。特別需要指出的是，對文檔結(jié)構(gòu)中潛在意圖進行深加工的需求促進了新的系統(tǒng)功能的產(chǎn)生，同時也提出信息自動處理的需求，至少是不用大量人工干預(yù)的新需求。
 3　問　題  
不幸的是，已有的一些經(jīng)驗和反饋讓我們清醒地意識到，我們對描述性標記在傳達意義上的理解，以及目前的技術(shù)根本沒辦法滿足我們的期望。
20世紀80年代，文檔標記的系統(tǒng)化和體系化工作主要集中在三個方面。
（1）通用文檔模型的概念化。
（2）文檔標記語言相關(guān)的形式化規(guī)范、詞匯表和語法相關(guān)技術(shù)的開發(fā)。該文檔標記語言可以定義具體的文檔類，并對模型進行實例化呈現(xiàn)。
（3）標記語言的開發(fā)（如CALS、AAP、TEI、HTML等）。
使用描述性標記語言來識別和標注文檔的邏輯部分能清晰地傳遞以前只能以潛在形式存在的“意義”。至少程序性標記的意義可以十分明確、清晰，并適用于機器處理。
很多人將XML文檔稱為“自描述數(shù)據(jù)”。雖然早期有一些不同的聲音（參見Mamrak，最重要的是Raymond和Tompa的觀點），但在描述性標記發(fā)展的最初階段，文檔研究人員的熱情漸漸消失，似乎大多數(shù)人覺得沒必要再探索更費力的文檔表示方法。定義清晰的SGML標記語言表達了文檔結(jié)構(gòu)的潛在意義，使其能充分、有效地用于機器處理。本文的一位作者曾經(jīng)參與寫過這樣一句話，“最后，我們應(yīng)當清楚地知道，對于相互競爭的標記系統(tǒng)來說，描述性標記不僅是最好的方法，而且是人們可以想到的最好方法”。
20世紀90年代的經(jīng)驗表明，這份自信有些盲目。從實際的角度來看，今天的情況有了很大改善，但互操作性和功能性上的一再失敗表明，在為文檔提供潛在意義及計算機可處理形式方面，SGML/XML并沒有真正成功。在SGML/XMLDTD中，元素和屬性的精確度同其他相似的文檔類型定義中的精確度無法匹配，部分內(nèi)容也不是形式化的，需要推斷的地方并沒有唯一肯定的答案。但是定性地來說，人們對文檔的認識與SGML出現(xiàn)之前不同，那個時候人們對文檔結(jié)構(gòu)意義的認識來自于對那些相對隱晦不明的線索的反思。
DTD的本質(zhì)屬性解釋了出現(xiàn)上述情況的原因：DTD僅僅顯示一個詞匯表及其對應(yīng)的語法，并不表示詞匯之間的語義關(guān)系。一般意義上的“標題”元素是否用<title>表示，<title>是否與我們平常所說的“標題”概念類似，這些都不能由DTD決定。DTD只能表明有一個特定的元素，它的標簽是字符串“title”，該標簽可能會與其他元素一起使用，這些元素的定義方式都一樣。所以，使用標記語言來標注文檔的內(nèi)容開發(fā)人員和軟件設(shè)計人員需要通過文本中與“title”相關(guān)的自然語言及其在上下文中的使用方式簡單地推斷<title>標簽表示的意義。也許最初的語言設(shè)計者也無法系統(tǒng)嚴格地定義<title>的意義。
當然，這夸大了實際情況。從某種意義上說，在標記語言開發(fā)人員提供的純自然語言文檔中，每個標記的意義基本可以表達清楚。但是，即使是工業(yè)和學(xué)術(shù)領(lǐng)域中標記格式最好的DTD文檔，也沒有從根本上解決問題。
設(shè)計一款反映標記語言中語義關(guān)系的軟件時，語言設(shè)計人員必須能夠?qū)⑽臋n中各部分之間的關(guān)系表示清楚；之后軟件工程師必須能夠（搜索、查找、打開）使用這個標記語言文檔，并設(shè)計應(yīng)用程序來表現(xiàn)其優(yōu)點。這兩個步驟都無法用機器進行驗證，可信度無法保證。如果要人工參與的話，就會有礙高性能網(wǎng)絡(luò)文檔處理和發(fā)布系統(tǒng)的發(fā)展。所以我們需要一個機制保證標記語言設(shè)計人員能夠詳細地、形式化地指定語義關(guān)系，還能被應(yīng)用程序讀取加工，并完成自我配置，無需一個個地人工參與。
下面我們來看一些具體的語義關(guān)系。這些關(guān)系或多或少地存在潛在的實用價值，但目前它們無法方便系統(tǒng)地得以利用，因為尚無標準的機器可處理的表現(xiàn)形式。事實上，許多關(guān)系至關(guān)重要，軟件設(shè)計師常以特定的方式推斷它們在文檔中的存在，并構(gòu)建特定的系統(tǒng)對其加以利用。
類關(guān)系。SGML/XML中不包含用以表達元素、特征或特征值中類的層級結(jié)構(gòu)或類成員關(guān)系的通用結(jié)構(gòu)。類是目前軟件工程主流結(jié)構(gòu)中最基本和最實用的模塊。我們不能說，段落是一種結(jié)構(gòu)上的元素（isa關(guān)系），或者所有結(jié)構(gòu)元素都是可編輯的元素(ako關(guān)系)。兩種基本的SGML/XML設(shè)計有時可以按照屬性/值實現(xiàn)基礎(chǔ)分類（具體可以使用“type”和“class”這兩種屬性）。這種分類技術(shù)尚不夠成熟，SGML和XML沒能提供更好的機制來控制和限制其使用。在實際應(yīng)用中，許多文檔類型設(shè)計師都采用類的層級結(jié)構(gòu)來進行設(shè)計。XML Schema提供了類關(guān)系的清晰聲明，但它本身并不能在語義上說明這些復(fù)雜類型與其他復(fù)雜類型到底有哪些區(qū)別。
繼承關(guān)系。在許多標記語言（例如TEI和HTML4.0）中，某些屬性會被包含元素所繼承，某些情況下被包含的文本內(nèi)容也會繼承這些屬性。例如，如果一個元素的屬性/值符號為“l(fā)ang="de"”，這表明這一段文本是德語，那意味著它的所有子元素屬性都是德語。但是DTD沒有提供正式說明用以指定哪些特征可以被繼承。而且，這樣的繼承關(guān)系并不是固定不變的，有時也會因為包含元素的二次定義而改變。繼承的方式也有很多種，有些涉及元素的屬性，有些涉及屬性的屬性，另一些則涉及文本和元素的內(nèi)容。例如，如果標記表示一個句子是德語，這意味著句子中的所有單詞（除非特殊情況）都是德語。同樣地，所有單詞短語中標記了刪除屬性的就刪掉，標記了重點屬性的就強調(diào)，將一部分內(nèi)容標記為一個段落，就意味著這部分內(nèi)容中的所有單詞（或元素）都屬于這個段落。無法指定DTD繼承哪些屬性，也不能指定其繼承邏輯（包括規(guī)則錯誤）。軟件設(shè)計師經(jīng)常對特定標記語言中的這些關(guān)系進行推理（判斷正誤），然后在其開發(fā)的工具和應(yīng)用程序中加以實現(xiàn)。
語境關(guān)系和引用關(guān)系。在許多標記語言中，即使某元素有一個固定的意義用于標記相同元素類型，這個元素也可能會因為上下文關(guān)系的不同而表示不同的含義。例如，某些文本的標記為“<title>”，其具體所指還要依賴文本的結(jié)構(gòu)位置?！?lt;head>”下的“<title>”是指對象“<document>”的標題，而“<chapter>”下的“<title>”是指這一章節(jié)部分的標題。判斷其為何種標題的標準并不存在。參考文獻中包含“<title>”元素的情況更復(fù)雜一些，這里的標題是文章外部的一個實體。類似這樣的關(guān)系不能用DTD表示，但可由軟件設(shè)計師推理得出，這對滿足文本的高效自動化處理很有必要（如果每個意義都用不同的通用標識符表示，那只能解決一小部分這樣的問題。因為仍然有必要說清楚屬性的二元特征，提供可解析的表達方式來定位屬性應(yīng)用的對象）。
所指中的本質(zhì)變化。有一種類似的但意義更加模糊的情況存在，同一對象有多種屬性，每種屬性都是用同樣的格式指向同一個指代物，但必須仔細解釋以確保其所指的明確性。例如，一個特定元素實例有以下三個特性：它是一個定理，它是德語寫的，它是字跡模糊的。這樣簡單直接的謂詞描述表示的是同一個東西(或元素實例)嗎？這樣表示知識足夠穩(wěn)健嗎?實際上它的意思是這樣的，這些抽象的句子是德語寫的，它們表達的命題是定理，它們的具體表現(xiàn)樣式是模糊不清的。嚴格來說，沒有哪個東西擁有所有這些特性。
完全同義和部分同義。標記語言的完全或部分同義是一種極為重要的語義關(guān)系，而用于描述這種同義關(guān)系的機制缺失造成嚴重的異質(zhì)性問題。使用單一標記語言也許能消除完全同義，但是隨著標記語言種類的增加，完全和部分同義仍舊是標記語言之間難以表示又重要的關(guān)系。目前我們還沒有合適的計算機可處理的形式化方法記錄不同標記語言中的元素、屬性和屬性值的同義性。建構(gòu)形式（見下文）可以記錄多數(shù)完全同義的情況，但部分同義卻很難記錄，在實際應(yīng)用中部分同義現(xiàn)象更為常見。由類包含關(guān)系表示的部分同義問題在解決異質(zhì)性問題上還有很長的路要走。
 4　BECHAMEL計劃  
BECHAMEL標記語義計劃起源于20世紀90年代末，由Sperberg-Mcqueen（W3C／MIT）和其他機構(gòu)的研究人員合作完成，他們來自文化科系、語言與信息技術(shù)部門機構(gòu)、卑爾根大學(xué)研究基金會（Bergen University Research Foundation）、伊利諾伊大學(xué)香檳-厄巴納分校的圖書情報研究生院電子出版研究小組。此計劃的名稱由所有合作者所在城市名稱的縮寫形成（Bergen, Norway; Champaign, Illinois; Esp?ola, NewMexico）。
BECHAMEL計劃的研究目標如下。
（1）定義與文檔標記語義密切關(guān)聯(lián)的表示和推論問題，開發(fā)一種所有語義感知文檔處理系統(tǒng)都必須解決或面對的問題分類法和描述法。
（2）研究常見標記語言的屬性和語義關(guān)系，評估規(guī)范的知識表示技術(shù)（如語義網(wǎng)絡(luò)、框架、邏輯、形式語法和產(chǎn)生式規(guī)則）的適用性。為了對這些關(guān)系和屬性建模，還要考慮它們在知識表示上的充分性、優(yōu)雅性、簡約性和計算效率等。
（3）開發(fā)并測試形式化的、機器可讀的表示框架，在這種框架需要能夠表示標記語言的語義。
（4）探索語義表示技術(shù)的應(yīng)用形式，如支持轉(zhuǎn)碼、信息檢索、可獲得性增強等。目前我們關(guān)心的重點是支持文檔數(shù)據(jù)庫實例的語義推理，因為我們相信這是應(yīng)用知識表示技術(shù)最好的著力點。
（5）與人文計算研究領(lǐng)域的數(shù)字圖書館內(nèi)容編碼計劃合作，聯(lián)合軟件工具開發(fā)人員，進行語義表示方案的大規(guī)模測試。
早期的Prolog實驗臺已經(jīng)全面發(fā)展成為一個知識表示原型平臺，用于表示結(jié)構(gòu)性文檔中的事實和推理規(guī)則。該系統(tǒng)允許分析人員指定某些事實（如通用標識符和屬性值），并將其與語義實體和屬性有關(guān)的推論性事實分開。
該系統(tǒng)還提供了一個抽象層，使得標記的意義能夠以機器可讀的和可執(zhí)行的形式明確表達。在此基礎(chǔ)上可以根據(jù)文檔組成部分進行推論，包括那些模糊的結(jié)構(gòu)，如層次重疊的組成部分。我們已經(jīng)開發(fā)出一個謂詞集合，能夠模仿W3C的文檔對象模型中用于節(jié)點層級結(jié)構(gòu)導(dǎo)航的方法，并且可以在文檔類型定義中檢索各種屬性取值和有關(guān)信息。這樣就能明確區(qū)分解析器分析的語法信息，分析人員表達的文檔語義。
初步的研究結(jié)果顯示語義推理識別的復(fù)雜性以及語境不確定理解的復(fù)雜性。這個雛形推理系統(tǒng)證明有關(guān)標記的自動推理是可行的，并且Prolog的規(guī)則可以處理非單調(diào)性和情景模糊性等復(fù)雜情況。進一步的研究可以參考引文。
 5　標記的語義建模  
文檔標記的語義是能夠被標記語言用戶理解的抽象結(jié)構(gòu)、屬性和關(guān)系，標記及其語法隱含著這種語義線索。標記的語義可以借助知識表示技術(shù)通過明確結(jié)構(gòu)、關(guān)系和屬性來構(gòu)建相應(yīng)的計算化模型。

參考如下XML標記文檔的片段

熟悉結(jié)構(gòu)

化標記的讀者自然知道文檔元素中的標簽P代表段落，該段落有一個標題，標題元素之后的段落內(nèi)容形成了文本主體，它從標題元素之后開始，并在段落結(jié)束標簽之前結(jié)束。標簽的意義和用法并不一目了然，所以作者或讀者可以參考標記集合的說明文檔

明顯的標記是為方便人類讀者而設(shè)計的。這些標記并不能借助文檔語法分析器，從數(shù)據(jù)結(jié)構(gòu)中抽取出來。正如圖1所示，解析樹（樣式表程序員所用）展示了頭部、引文以及引文前后的文本，這些部分每個都是段落的獨立子節(jié)點，但解析樹沒法展示以下特征：頭部是整個段落的一個屬性，文本是內(nèi)容結(jié)構(gòu)中的兩個部分，引文嵌入在文本內(nèi)部。
事實上，數(shù)據(jù)結(jié)構(gòu)本身并沒有段落和引文之分或與之相關(guān)的東西。數(shù)據(jù)結(jié)構(gòu)僅僅是關(guān)聯(lián)信息的圖型結(jié)構(gòu)，就像一個有著“段落”取值的通用標識符。程序應(yīng)當能推斷出文檔意義與使用標簽之間的一致性，并能在樹形結(jié)構(gòu)從一種形式轉(zhuǎn)換為另一種形式時利用這種知識。但是，這種轉(zhuǎn)換（例如，通過XSLT、DSSSL或者類似C++的程序語言進行轉(zhuǎn)換）依靠的是語義推理，而不是顯性的編碼

圖2展示了如何通過利用語義知識來豐富和增強語法樹。利用知識表示技術(shù)能夠在更高的層面上將整體和部分之間的關(guān)系進行編碼，更適合計算機處理。此圖展示了一種傳統(tǒng)的語義網(wǎng)絡(luò)表示方法，當然其他的方法也正在發(fā)展中，包括框架表示法、規(guī)則表示法、形式語法以及基于邏輯的表示法等。語義網(wǎng)計劃（本文第八部分）的發(fā)展甚至能為標記語言本身提供合適的表示方法。問題的關(guān)鍵在于，要為無法由傳統(tǒng)的XML/SGML解析器建模和執(zhí)行的抽象概念、關(guān)聯(lián)和約束建立一個層次體系。
在機器可讀的文件（如DTD或者語法結(jié)構(gòu)）里的編碼知識能夠被用于驗證文檔的語義約束，為應(yīng)用程序提供更強大的文檔模型。這些更有表現(xiàn)力的表示方法為更好的文檔處理系統(tǒng)的設(shè)計和實現(xiàn)提供了強有力的支持。
6　應(yīng)　用
近年來，許多新技術(shù)的發(fā)展使得常規(guī)的結(jié)構(gòu)化標注越來越盛行。這些技術(shù)在信息管理中主要強調(diào)以下幾個方面的問題。
轉(zhuǎn)換和聯(lián)合。對于SGML/XML開發(fā)人員來說，最常見的工作就是設(shè)計轉(zhuǎn)換形式，從一種應(yīng)用語法轉(zhuǎn)換到另一種應(yīng)用語法。這樣做是為了創(chuàng)建新型文件表示方式，或者方便其存儲于數(shù)據(jù)庫中。有時候，開發(fā)人員需要整合或調(diào)整大型的數(shù)字文檔集合，每個數(shù)字文檔都由一種無法進行互操作的標記語言表示。不考慮轉(zhuǎn)換的范圍大小，常規(guī)的解決方式是使用一種在語法解析樹上起直接作用的轉(zhuǎn)換程序語言。源文件分析中產(chǎn)生的樹結(jié)構(gòu)轉(zhuǎn)換成目標語言的樹結(jié)構(gòu)實例。轉(zhuǎn)換之后的樹被序列化成新的文檔實例、圖形或音頻。
信息孤島。這個問題與上述的轉(zhuǎn)換問題很相似，但是其目標不是將一個形式的文檔轉(zhuǎn)換為另一種形式的文檔，而是允許分布存儲的文檔或文檔片段能夠向系統(tǒng)用戶提供一個通用的透明訪問接口。盡管沒必要將文檔從一種標記語言逐字逐句地轉(zhuǎn)換成另一種標記語言，但是系統(tǒng)必須能夠保證文檔內(nèi)容表面上看起來是無縫融合的，盡管文檔的編碼可能差別很大。
可獲得性。創(chuàng)作工具逐漸接受了結(jié)構(gòu)化標記，這已經(jīng)成為視覺障礙用戶獲取數(shù)字文檔的福音。聲明性標記使得人們能夠借助屏幕閱讀器或盲文顯示器進行閱讀，并在助記符幫助下進行推斷，而不是利用圖形線索。但是，目前這樣的應(yīng)用需要依賴用戶自身的能力或界面軟件，基于獨立的標簽內(nèi)容或語法得出的結(jié)構(gòu)性推論。正如標簽集文檔中描述的一樣，標記語法約束及標記的意義和使用都嚴格地依賴于文檔作者的可信性。遺憾的是，作者經(jīng)常會誤用標簽，最糟糕的例子就是在web頁面上使用“頭部”標簽來標記某些特別的版式。
安全處理。發(fā)展更有表達力的標記模式語言（比如W3C的XML Schema語言）的部分動力是人們認識到標記錯誤、誤用和濫用的后果遠比糟糕的格式化輸出要嚴重得多。聲明性標記不僅用于電子商務(wù)，也用于安全信息領(lǐng)域，比如醫(yī)療記錄和航空工業(yè)。這些領(lǐng)域的開發(fā)人員不但要確保數(shù)字文檔的語法結(jié)構(gòu)規(guī)范，也要確保其遵守某些安全協(xié)議，以保證文檔的安全處理、存儲、傳輸和表示。
7　標記語義的優(yōu)點
目前BECHAMEL計劃的調(diào)研結(jié)果顯示，標記語義能夠通過以下幾種方式解決上述問題。
聲明性的、機器可讀的語義描述。就目前的實際情況而言，結(jié)構(gòu)化標記語言設(shè)計師用自然語言文本表達了標簽的意義，明確了其合適的使用方式。形式化的標記語義體系使得本體之間的聯(lián)系能被計算機程序清晰地表達，并實現(xiàn)自動化處理。
假設(shè)的驗證。在沒有形式化標簽集的文檔環(huán)境中，擁有標記語義解釋能力的系統(tǒng)提供了一種測試猜測和驗證假設(shè)的環(huán)境。在這種環(huán)境中，未公開的標記語言用戶會對那些他認為在文檔數(shù)據(jù)庫中持續(xù)應(yīng)用的屬性和規(guī)則進行推測。之后文檔處理軟件就會檢索那些與假設(shè)規(guī)則兼容或不兼容的文檔元素。
語義約束的增強。支持有效性驗證的解析器不僅能夠像常規(guī)語義解析器一樣完成語法驗證，也能夠在發(fā)現(xiàn)或編寫語義的過程中同時驗證這種猜測，這樣的解析器同樣能夠加強語義約束。這項操作同假設(shè)驗證一致，但是在這種情況下，語義約束是已知且規(guī)范的。
優(yōu)化的更有表現(xiàn)力的APIs。使用SGML和XML應(yīng)用程序轉(zhuǎn)換或表示數(shù)字文檔時，都會使用標記語義。但是只有在執(zhí)行程序時，更高級別的屬性和關(guān)聯(lián)才會顯示出來。形式化的、機器可讀的語義會豐富應(yīng)用程序的接口，加快軟件設(shè)計速度，隨著標記語言的發(fā)展和變化，這些軟件維護起來也能更加方便和安全。
8　相關(guān)工作
針對上述挑戰(zhàn)和問題，還有很多其他的文檔處理技術(shù)、標準和研究計劃。接下來我們梳理一下試圖解決這些問題的現(xiàn)有想法。
語義網(wǎng)。語義網(wǎng)指的是眾多相互聯(lián)系的研究和標準化工作，就像當下一些有關(guān)標記和知識表示技術(shù)的想法。最核心的當屬W3C的資源描述框架，當然也包括其他的技術(shù)，比如ISO的主題圖技術(shù)。語義網(wǎng)的范圍很廣，目標宏大，旨在利用通用知識表示技術(shù)來完善標記語言，從而“促進人類知識的全面發(fā)展”。語義網(wǎng)的研究和標準化不同于當下的想法：不是對特定領(lǐng)域進行語義描述，而是實現(xiàn)對所有領(lǐng)域的知識進行語義標注。當前研究的目標特別盯在“文檔標記語義”上，而非“通用的語義標記”。語義網(wǎng)技術(shù)的進步會讓我們利用語義網(wǎng)標記語言對標記的語義進行編碼成為可能。
W3C的文檔對象模型。文檔對象模型是一個應(yīng)用程序接口，是對XML文檔進行分析后生成的層級式數(shù)據(jù)結(jié)構(gòu)。人們想設(shè)計能為標記語義提供各種接口的系統(tǒng)，類似于DOM所提供的標記語法相關(guān)的形式，最終能夠形成“語義DOM”，對W3C的語法DOM形成補充。
W3C的Schema。XML Schema是一門基于XML的語言，能夠替代傳統(tǒng)的DTDs，用于約束XML文檔。DTDs的局限性推動了這門語言的發(fā)展，這些局限同我們在BECHAMEL計劃中面對的問題是類似的。Schema允許文檔類設(shè)計師定義復(fù)雜的數(shù)據(jù)類型，就像在高級程序語言里面的做法一樣。但是，為了對標簽集建檔中的所有關(guān)系和約束進行編碼，我們還需要比當下的XML Schema更強大的表達形式。超媒體／時基結(jié)構(gòu)語言（Hypermedia/Time based Structuring Language，HyTime）的架構(gòu)形式。適應(yīng)性廣泛的架構(gòu)技術(shù)來自于這樣一種認識，即不同的標記語言應(yīng)用程序常常通過樣式各不相同但語義上等價的結(jié)構(gòu)進行編碼。架構(gòu)形式允許文檔類設(shè)計師將其自有的特定元素實例映射到更通用的各種架構(gòu)實例上，這些架構(gòu)實例更便于在不同的應(yīng)用程序之間進行映射。這些映射的確表示了語義知識的約束形式，有利于解決上述轉(zhuǎn)換和集成上的挑戰(zhàn)。BECHAMEL計劃在某種程度上就是要建立一個比架構(gòu)形式表達更多語義關(guān)系的模型。

以上是“XML標記語義的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！