關於本體編程的實現

臨近期末，我有一門課程的期末項目是做一個教育領域的本體應用系統，所以最近經常思考本體在這樣一個系統中所起的作用，以及該如何?。（本體是否只能在web環境下發揮作用，使用本體描述一個獨立系統的模型是否值得？）

假設要做的是選課系統，很容易看出系統裡應該有這些對象：課程、學生、教師，它們之間互有聯絡。現在的問題是，本體、Java類和資料庫各扮演怎樣的角色？我目前想到的方法有以下幾個：

1. 在本體（owl）裡建立這些類和關係，在Java裡建立同樣的Bean類，運行時系統把本體裡的individuals轉換為Java類的執行個體，也就是在記憶體裡得到一個Java執行個體的集合，選課的各種操作就是對這個集合的修改，退出系統時再進行反向轉換，把修改反映到本體裡。在這樣的實現方法中，本體實際上扮演了資料庫的角色，所以當資料（individuals）很多的時候，效率會很成問題。（Protege的owl編輯工具提供了從本體產生EMF模型代碼的功能，雖然目前還是alpha版，這也許將成為同步兩種模型的不錯選擇。）

2. 對上面的方法進行修改，讓本體不儲存individuals，對Java執行個體集合的修改最終反映到關聯式資料庫裡（利用hibernate不會很困難），運行時系統直接從資料庫裡取得資料轉換為Java執行個體。這樣的實現可以解決效率問題，但和傳統應用區別不大，本體的作用幾乎為零。
3. 另一種比較極端的做法是只用本體維護類和individuals，Java方面沒有任何與應用有關的模型，系統一開始把本體讀入記憶體以rdf圖的方式存在，選課操作轉換為對此圖的修改（利用Jena等API）。這個方法存在兩個問題，一是效率，二是Java代碼的可讀性下降，這就相當於直接使用JDBC而不是hibernate對資料庫操作的區別。

在solo項目裡我使用的是第一種方式，各方面效果還可以接受，但本體的作用發揮得很不夠。這是很重要的方面，因為如果和傳統項目沒有區別，辛辛苦苦引入本體又是為了什麼，特別是對本體推理的功能，我想最關鍵的問題還是要找出最適合應用的本體，定義本體的確是一門學問。

Update：IBM Alphaworks也提供了一組本體工具（包括Orient、EODM和RStar），對EMF的支援應該不錯。今天初步試了一下Orient，它只支援RDF(S)，而不支援OWL，所以無法滿足課程項目的要求，Orient的目前版本還有一些小bug，除已知的那些以外，我把.ontology檔案輸出為ecore模型總是不成功，而輸出為rdf是可以的。

Update：推薦一個關於本體和模型驅動的投影片，主要內容是介紹應該如何利用UML的可視化編輯功能和元模型的擴充功能來構造本體，這裡面介紹了相當多的相關概念（其中很多我甚至沒聽說過），以及它們出現的原因，比較有利於我們理清思路。