是否可以使用本體來為數據轉換器生成代碼？

Question

給定三個主要的競爭應用程序，每個應用程序針對相同的問題域實現略有不同的數據模式，因此我面臨着實現以下任務：

1. “規范”數據架構，足以表示所有3個應用程序的要素的交集以及其他詳細信息（元數據）
2. 用於在這三個應用程序和規范架構之間進行（雙向）數據交換的轉換器

我目前如何完成任務

規范架構是使用XSD定義的，與3個應用程序之一的數據架構非常相似，我們稱其為A。這使得與A的數據交換變得微不足道。 為了允許與應用程序B和C進行雙向數據交換（在A中創建某些狀態，將其加載到B中，在B中更改它，將更改后的狀態加載到A中），我嘗試將A中的簡單狀態映射到更復雜的狀態B / C中的狀態可以在反向映射中識別和解構。

示例：在A中，可以簡單地將對象“鏡像”為固有的幾何變換，而在B和C中，我們必須引入一個“鏡像子空間”，其中嵌入了各個對象。 該“鏡像子空間”在A中也可用。因此，在轉換B-> A時，我們必須決定是否必須將數據中找到的“鏡像子空間”映射到A中的“鏡像子空間”上，或者將其映射為“鏡像子空間”。替換為對象的固有幾何變換。 我目前通過專門標記那些僅在轉換A-> B期間引入的“鏡像子空間”來實現。

為什么我想改變自己的方法

• 大多數模式映射都是非常瑣碎的（A中對象的名稱只是映射到B中對象的名稱），因此我要避免手工編寫很多瑣碎的代碼。 我想象如果給定數據方案之間的形式化映射，就可以生成這種瑣碎的代碼。
• 對於映射的非平凡部分（如上面所述），我希望將來會發生很多變化，僅僅是因為它看起來是如此武斷。 在許多情況下，將A中的狀態映射到B / C中更復雜的狀態的特定約定有時可能會陷入死胡同。 例如，用戶可能有必要更改“鏡像子空間”標簽，因此可能需要用於標識轉換工件的另一種方法。 我認為正式的映射可能是透明管理這些約定的工具。 也許推理者甚至可以自動發現不連貫，不一致的映射。 這也可能使我可以更輕松地與域專家和用戶討論映射。

問題

• 從我讀到的有關本體論的文章中，我有一種印象，即我想要的是本體論。 這個對嗎？
• 據我了解，使用本體描述映射也將要求我在本體中表達數據方案本身（因此，“映射到”的關系可以引用A中的類型，引用B中的類型）。 由於這些方案是從長期存在的應用程序中提取的，因此它們並不總是一致的。 例如，應用程序中的“功能”可能導致某些狀態具有您希望從其組成的語義中獲得的不同語義。 現有工具可以幫助我管理這些復雜性嗎？
• 我希望我需要在本體內部使用一些額外的機制來描述類似內容（如上例所示）“永久鏡像子空間”與“耗散鏡像子空間”之間的區別（兩種類型+特殊關系重新連接它們？） 。 這會做很多努力嗎？ 可用的本體語言是否提供了一些開箱即用的表達方式？
• 本體的這種應用是本體的常見應用還是特例？ 您知道為該應用程序提供服務的公司嗎？
• 您建議使用哪些工具來創建本體？ 我假設沒有可用於上述代碼生成的現成工具。 那么您將如何處理代碼生成任務？

Answer 1

抽象類型系統，一組接口和轉換規則定義為本體創建的子集，稱為元模型。 元對象設施（MOF）是一個示例：

MOF接口和MOF模型可用於為數據庫，數據倉庫，模型轉換和倉庫管理域定義特定的元模型。

MOF的IDL轉換功能將單個類映射到兩個接口。 可以定義到備用接口表示形式的轉換，例如Java的接口。

在行業領導者之間，關於類，類型和接口的概念的定義存在分歧，並且可能永遠存在分歧。 作為特定於域的建模環境，只要MOF清楚MOF中Class的含義，它就應該不受此類問題的影響。

主題圖是另一個：

將知識提取到一個獨立的層中，並在該知識層進行處理，並且將反饋回路返回到源頭，這似乎並不是最直接，最有效的方法。 此過程與作者堅持使用Word的發布工作流類似，但是發布者需要XML。 兩種格式之間的往返轉換效率不高，但有時是必需的。 此外，這種間接級別正是為我們提供了以一種可以隨着時間的推移而保留的方式來處理知識的能力和自由，而不論源信息（特別是處理系統）發生了什么。 描述信息，鍵入主題，創建關系，管理多語言對等物的所有工作仍在進行。 由於已對其進行獨立管理，因此升級系統僅意味着與舊系統斷開連接，然后重新連接至新系統。

對比了使用主題地圖超過20年的經驗教訓：由於技術進步的迅速發展，信息技術的成功使我們不知所措。 尋找緊迫的下一件大事使我們對我們所做工作的基本本質的思考能力變得模糊。 信任，可靠性，高質量的概念仍然是我們企業取得長期成功的關鍵。 我們需要適應我們正在處理的信息呈現本身的方式的不斷變化的性質。 這僅僅是個開始。 當我們創建主題地圖標准時，我們創建了一個事實證明是沒有問題的解決方案：可以跨組織合並知識網絡。 盡管有很多期望並為此付出了很多努力，但這並不能滿足用戶的足夠需求。 但是，我們還提出了信息源與知識管理層之間的獨立性概念。 長期來看，這可能仍然存在，即使這個想法曾經以主題地圖的名稱出現的事實可能被遺忘了。

參考文獻

• InfoGrid Web圖形數據庫：詞匯表，分類法，詞庫，本體和元模型之間有什么區別？

• 元對象工具（MOF）規范（pdf）

• 現在主題圖

• 主題圖簡介

• TM4J-Java主題圖

• 使用OpenDDS進行代碼生成，第一部分:: OCI

• Paws-適用於AWS（Amazon Web Services）API的Perl SDK-metacpan.org