文|蘇荨墨
編輯|蘇荨墨
前言
除了主要側重于認知 ERP 的記錄和分析的實驗工作外，我們還緻力于電生理學研究的軟體和硬體基礎設施的開發。
實驗工作通常非常耗時，并且在從資料記錄到最終解釋的各個處理階段都會産生大量實驗資料。
基于這一經驗，我們知道支援電生理資料語義描述的手段和改進這些資料存儲、管理和共享的軟體系統（至少在一個研究組内）有助于對這些資料的長期了解，并顯著提高研究效率。
當決定在更廣泛的社群内共享我們的資料、處理步驟和工作流程時，這一點變得更加重要。
資料的長期儲存、語義描述的品質和範圍以及資料共享本身等主題在社群中得到廣泛讨論。
電生理實驗過程中使用的各種實驗途徑、技術和方法、目标對象、硬體和軟體基礎設施等導緻領域内異構資料的積累。
資料模型在類型離得發展
分析傳統語義資料模型的使用基本上以下兩種資料模組化形式被廣泛使用：實體關系 (ERA) 模型和面向對象 (OO) 模型。
較新的形式主義，例如增強實體關系 (EER) 模型，僅結合了這兩種基本形式主義。
統一模組化語言 (UML) 是經典軟體工程中應用程式結構、行為、體系結構、業務流程和資料結構模組化最常用的語言。
UML 模型由三個主要類别（分類器、事件、行為）的模型元素組成，每個類别都可用于對被模組化系統中不同種類的個體事物進行陳述。
知識工程中定義對象類型和關系的模型與本體的發展有關。
在語義 Web 語言中，RDF 是資料交換的标準模型，RDFS 是一種在 Web 上表示簡單 RDF 詞彙表的語言，而 OWL 作為一種基于計算邏輯的語言，表示關于事物、事物組和事物的豐富而複雜的知識。
然而，語義網語言和技術在開發應用程式方面并不流行（Antoniou 和 van Harmelen）。
在經典的軟體工程學科中，基于腳本的語言在神經資訊學中的受歡迎程度一直在不斷上升（Garcia 和 Fourcaud-Trocm), 但這些語言一直不被認為适合開發大型系統。
是以，當我們要設計和實作一個大型的、健壯的、可靠的軟體系統時，面向對象系統仍然是首選。
有一個問題是我們如何利用軟體工程和知識表示學科中使用的模型的優勢，以及如果可能的話我們如何建構它們之間的映射。
通常，語義 Web 語言關聯面向對象世界中使用的三種類型的特征，它們在獨立于技術限制的概念層面上描述現實，即它們類似于 UML 表示。
它們還構成了事實基礎 (RDF) 的資料庫模式。最終它們由已實作的應用程式中的軟體工具處理，即它們是實作的一部分。
很難比較 UML 和 OWL，盡管兩者都是用于模組化的語言并且在結構上有一些相似之處，但它們具有不同的功能和不同的語義方法。
它們都有類、執行個體、繼承、允許定義基數限制等，另一方面，OWL 類被視為概念的标簽，而 UML 類被視為執行個體的模闆。
最實質性的差異涉及執行個體（OWL 中的個體）和屬性的含義，在 UML 中，任何類都是可以執行個體化的對象。這個過程有它的語義，比如為屬性指派。
此外，執行個體具有運作時語義，在OWL 中一個類就是一個類，沒有定義執行個體化過程，OWL 個體，域事物的辨別符，是獨立于類定義的。
如果 OWL 個人符合班級成員資格标準，那麼它就是班級成員，它是沒有狀态、存儲或運作時語義。
UML 屬性總是屬于一個類，而 OWL 屬性是獨立的實體。OWL 屬性是 double 類型；對象和資料類型屬性。
第一個将個人連結給到個人，第二個将個人連結給到資料值，對一個類範圍的了解也是不同的，UML 類在定義它們的程式内部工作，而 OWL 類提供在域之間共享類的特性。
OWL 類可以連結到類描述清單（而 OWL 屬性是獨立的實體。OWL 屬性是 double 類型；對象和資料類型屬性。
它描述了一個匿名類，即所有滿足該限制的個體組成的類，OWL 區分兩種屬性限制：值限制（例如，allValuesFrom、someValuesFrom）和基數限制 Dean 和 Schreiber。
較長的描述了UML和OWL的相關特性之間的關系。表中總結了所描述的差異的（表格1）并與相關的 Java 代碼一起顯示如圖所示（圖1）。
表1
圖1
資料中關系資料庫
着眼于傳統的資料資源和程式設計工具，特别是關系資料庫和面向對象的代碼，我們簡要描述了幾種将關系模式或面向對象的代碼映射到語義 Web 語言的方法和工具。
其中一些方法僅作為科學論文中發表的初步建議或原型存在，而其中一些方法已作為可用架構真正實施。
RDF 三元組可以表示為關系資料庫表中的一行，該表有兩列，對應于 RDF 三元組的主題和客體，表的名稱對應于 RDF 三元組的謂詞。
D2RQ（Bizer 和 Seaborne）平台是一個用于通路關系資料庫作為虛拟、隻讀 RDF 圖的系統。
它使用聲明性語言來描述關系資料庫模式和 RDF 之間的映射；關系資料庫的内容不會複制到 RDF 存儲中。
例如，D2RQ 平台提供了使用 SparQL 查詢非 RDF 資料庫的可能性是查詢語言，以 RDF 格式建立資料庫的自定義轉儲，并使用 Apache Jena API 通路非 RDF 資料庫中的資訊。
是一個從關系資料庫到 RDF 的資料轉換處理器，XML 模闆文檔定義了一組映射規則和查詢，用于擷取存儲在關系資料庫中的資料。
有一些方法和工具提供有限的可能性來将面向對象代碼的通用文法映射到 OWL 表示。
這些工具映射了 OWL 的基本特征，這意味着隻使用了 OWL 的基本語義表達能力。
描述OWL 類到 Java 接口的映射，映射到 Java 接口而不是公共 Java 類使得能夠表達 OWL 屬性的多重繼承。
随後又描述了反向轉換，其中描述了位于 Common Lisp 對象系統 (CLOS) 頂部的 OWL 處理器 SWCLOS3。
CLOS 允許 lisp 程式員開發面向對象的系統，而 SWCLOSS 允許程式員在軟體應用領域建構域和任務本體。
Java2OWL-S 是一個能夠直接從 JavaBeans 生成 OWL 的工具。它使用兩個轉換。
第一個轉換是從 JavaBeans 到 WSDL（Web 服務描述語言），此轉換的輸入由一個 Java 類構成，輸出是一個臨時 WSDL 檔案。
第二個轉換從 WSDL 檔案生成 OWL。關于單側轉換（從正常語言到語義Web 語言），這些具有共同語義表達能力的工具工作得相當令人滿意，因為面向對象代碼的語義表達能力低于OWL 語言的語義表達能力。
然而，在這些工具中，不可能使用額外的語義結構來豐富面向對象的代碼。
語義對象架構 (SOF)利用源代碼中的嵌入式注釋來描述類和屬性之間的語義關系。
eClass是一種改變 Java 文法以将語義描述嵌入到面向對象源代碼中的解決方案。
這些架構是以使用額外的語義豐富了輸入的面向對象代碼，但它們的使用很困難，因為它們需要修改的編譯器和 Java 解釋器。
架構在語義中的解釋
測試架構的缺點和限制，促使我們引入一個軟體原型，允許其使用者将額外的語義直接添加到 Java 面向對象的代碼中。
Java 代碼與傳統的資料存儲庫一起工作，允許将此代碼轉換為語義 Web 語言 OWL 的映射被提議并實作為一個庫，即語義架構。
該解決方案可供軟體工程師使用，而不僅僅是語義 Web 專家，它服務于開發使用面向對象系統并需要在 OWL 中提供輸出的開發人員/研究人員社群。
由于我們使用反射 Java 注釋（添加到 Java 源代碼并在運作時檢索的中繼資料）作為 Java 中的标準句法結構，是以這種方法也不會給使用者帶來對程式設計環境的額外要求。
此外，額外的語義甚至不需要由程式員直接寫入代碼，而是可以使用圖形使用者界面從非程式員那裡收集。
從性能和可用性的角度進一步讨論了所提出的方法，它通過 EEG/ERP 門戶中語義架構的內建以及在神經科學資訊架構 (NIF) 中的注冊得到驗證。
Javabean 到 OWL 的映射
Java 将資料存儲在 JavaBeans 2中，通常稱為 Plain Old Java Objects (POJO)。定義中描述了 JavaBean 表示到 OWL 本體的轉換。
該過程是将一組 JavaBeans J 轉換為滿足以下條件的本體。
清單 1中顯示了一個 JavaBean 到 OWL 構造的映射示例。
清單1
JavaBean Person有兩個屬性，researchGroups和firstname。第一個是與ResearchGroup類的關聯關系，而第二個是原子類型。
省略 Get/set 方法以保持可讀性，清單2顯示了這個類到 OWL 結構的基本序列化。
屬性firstname被序列化為DataTypeProperty，而屬性researchGroups被序列化為ObjectProperty。
清單2
盡管所描述的映射工作得相當令人滿意，但并未涵蓋描述的 OWL 概念。
當我們想要使用 OWL 的更多功能時，我們必須用額外的語義表達來豐富面向對象的代碼。
尋找一種合适的方法來擴充目前的面向對象代碼，我們決定采用基于使用 Java 注釋（MicroSystems）的初步想法（Jezek 和 Moucek）。
Java 注解有幾個好處，首先，它們可以作為一種特殊形式的文法中繼資料添加到 Java 源代碼中。
結語
其次，它們是反射性的，即它們可以嵌入編譯代碼中并在運作時檢索。
此外，Java Annotations 是 Standard Java Development Kit 的一部分；它們可以立即使用 Java 5.0 或更高版本進行處理。
最後，Java Annotations 在目前的軟體開發中使用（通過幾個常見的架構，例如 Spring、Hibernate、Java Persistent API）；是以，軟體開發人員可以毫無困難地使用此擴充。
清單3 給出了一個使用注解的例子。
清單3
Person類具有屬性firstname和researchGroups，如清單1 中所定義。
此外，添加了屬性dateofBirth ，firstname屬性定義了一個值，該值是通過使用@SomeValuesFrom注釋從值限制GivenNames中擷取的。
屬性dateofBirth定義為基數等于 1，屬性researchGroups定義為最小基數等于 1。
此外，類Person定義為等同于類TestedSubject使用注釋EquivalentClass。
這個 JavaBean 的序列化如清單4所示，類Person是owl:cardinality、owl:someValuesFrom和owl:minCardinality OWL 限制的子類。
清單4
我們選擇了具有類和或屬性範圍的概念（Jezek 和 Moucek，2011a）并定義了一組注釋，它們映射到相應的 OWL 結構（表 2）。
大多數建議的注釋都是可參數化的，參數值見表的表2個是例子；它們可以根據特定領域的需要進行更改。
表2
所描述的映射是作為一個名為 Semantic Framework的庫實作的。
它處理一組 JavaBeans 作為輸入，并生成一個本體文檔作為輸出。我們沒有從頭開始實施語義架構，而是擴充和內建了現有的工具。
該系統的核心是擴充的 JenaBean，它支援将通用 JavaBeans 綁定到 RDF/OWL 類和屬性。
它在内部使用 Jena 架構（Apache Jena）和 Jena RDF/OWL API 來持久化 JavaBeans。圖2顯示了語義架構的元件圖。
圖2
該模型被傳輸到第二個Ontology Model Creator子元件。該子元件使用本體模型工廠和Jena API建立本體模型方法。