owl存儲

⑴ owl文件轉換為csv

首先打開需要轉換的Excel表格，點擊左上角的office按鈕，選擇另存為里的其他格式，然後選擇CSV（逗號分隔）。
CSV又稱為逗號分隔值，是一種通用的、相對簡單的文件格式。CSV是一個字元序列，不含必須像二進制數字那樣被解讀的數據，以純文本形式存儲表格數據。它可在程序之間轉移表格數據，被用戶，商業和科學廣泛應用。
最廣泛的應用是在程序之間轉移表格數據，而這些程序本身是在不兼容的格式上進行操作的。因為大量程序都支持某種CSV變體，至少是作為一種可選擇的輸入或者輸出格式。例如，一個用戶可能需要交換信息，從一個以私有格式存儲數據的資料庫程序，到一個數據格式完全不同的電子表格。最可能的情況是，該資料庫程序可以導出數據為CSV，然後被導出的CSV文件可以被電子表格程序導入。

⑵ 大哥我的OWLA128支持什麼格式的視頻啊具體參數幫我說哈好嗎

存儲容量128MB，支持音頻格式MP1、MP2、MP3、WMA、WMV、WAV、ASF，電池類型內置可充鋰電，介面類型USB，2.0，頻響范圍20Hz-20KHz，錄音功能支持，移動存儲支持，FM收音功能有，復讀功能支持，線控無，歌詞,歌名同步顯示長度（mm）57寬度（mm）38.5厚度（mm）11.5，，七種音效模式，隨機附USB2.0線,充電器,立體聲耳機,音視頻連接線,驅動光碟,說明書可選配件無

⑶ 圖譜只有圖嗎

知識圖譜源於語義網，將自然語言文本中描述的知識按照三元組的方式進行描述與表示，從而讓計算機可以進行存儲、計算與應用。其主要數據模型是RDF數據模型。由RDFS於OWL提供模式（schema）的描述方法並支持推理。知識圖譜可以認為是以RDF或屬性圖表示的知識數據本身。其可以用圖資料庫存儲也可以用其他資料庫存儲。2000年的時候Neo4j為了解決多媒體關系系統中schema 經常會發生重大變化的問題，提出了用圖的方式進行數據的組織、存儲與應用。經過發展於2010年正式提出了屬性圖模型。屬性圖數據模型跟RDF數據模型的起源於發展是兩條線，只不過因為屬性圖更加易於理解並且通用（更接近通用的圖抽象方法）知識圖譜也可以用屬性圖模型存儲。知識圖譜中常用的RDF模型可以認為是圖在語義方向的一種特種模型。

⑷ OWL本體文件如何存儲到資料庫

安裝好必要的軟體並配置好開發環境

Eclipse

MysqlServer5.5-win32

jena2.6.4

protege4.3

mysql-connector-java-5.1.35（MySQL的JDBC）

1.利用MySQL創建一個資料庫：createdatabasemilitary_ontology;

2.打開Eclipse，新建一個Java工程，起名為military_ontology。(File-New-JavaProject,輸入名字military_ontology，點擊next)

3.新建工程的同時，分別導入Jena包和MySQL的JDBC。（點擊Libraries-點擊AddExternalJARs，分別加入JDBC和Jena中全部.jar文件，C:和G:Jenalib目錄中，點Finish）

4.在工程military_ontologysrc目錄下新建一個Java文件（New-Class），名字為military_ontology.java；

5.在military_ontology.java中開始編寫以下代碼：

packagemilitary_ontology;

importjava.io.*;//導入IO包的所有類

importjava.sql.SQLException;//導入SQL有關異常處理包

importcom.hp.hpl.jena.db.*;//導入jena鏈接資料庫的包

importcom.hp.hpl.jena.rdf.model.*;//導入jena有關模型的包

importcom.hp.hpl.jena.ontology.OntModel;//導入OntModel包

importcom.hp.hpl.jena.ontology.OntModelSpec;//導入OntModelSpec包

ModeldefModel=null;

if(connection.containsModel("militaryDB"))//判斷名為militaryDB的模型是否已經存在數據

{

defModel=maker.openModel("militaryDB",true);//數據存在則打開此模型

System.out.println("打開已存在的模型");

}

else

{

defModel=maker.createModel("militaryDB");//數據不存在則創建此模型

System.out.println("創建一個新模型");

}

OntModelSpecspec=newOntModelSpec(OntModelSpec.OWL_MEM);

OntModelDBModel=ModelFactory.createOntologyModel(spec,defModel);

//將臨時模型轉換成本體模型（OWL格式），其中spec參數表示該模型是在內存中存在的。

FileInputStreamread=null;//定義並初始化文件輸入流變數read

try

{

Filefile=newFile("g:/畢業設計/軟體/本體實例/Ontology1428926241032/Ontology1428926241032.owl");

read=newFileInputStream(file);//讀入OWL本體文件

}

catch(FileNotFoundExceptione)//抓取讀入文件異常

{

e.printStackTrace();

System.out.println("未找到要存儲的本體文件，請檢查文件地址及名稱");

}

System.out.println("已將本體文件轉換為位元組流文件。");

InputStreamReaderin=null;//定義並初始化輸入流轉換變數in

try

{

in=newInputStreamReader((FileInputStream)read,"UTF-8");//將位元組流文件轉換為UTF-8編碼

System.out.println("已將位元組流文件轉換為UTF-8編碼。");

}

catch(UnsupportedEncodingExceptione)//抓取轉換異常

{

e.printStackTrace();

System.out.println("不支持上述字元集。");

}

defModel.read(in,null);//將流文件讀入資料庫模型

defModel.commit();//將模型保存到資料庫中

System.out.println("數據轉換執行完畢，已將本體文件存入資料庫。");

try

{

in.close();

System.out.println("已將位元組流文件關閉。");

}

catch(IOExceptione)//抓取輸入輸出異常

{

e.printStackTrace();

System.out.println("無法關閉位元組流文件。");

}

try

{

connection.close();//關閉連接

System.out.println("已將連接關閉。");

}

catch(SQLExceptione)

{

e.printStackTrace();

System.out.println("連接無法關閉。");

}

}

catch(RDFRDBExceptione)

{

System.out.println("出現異常");

}

System.out.println("已將本體文件持久化到資料庫中，無異常");

}

}

執行程序之後，本體被存入MySQL資料庫中。資料庫會生成以下幾張表：

jena_g1t0_reif存儲經過處理的本體數據

jena_g1t1_stmt存儲了本體的數據信息

jena_graph存儲每一個用戶圖的名字和唯一標志符

jena_long_lit存儲陳述表中不便於直接存儲的長字元創常量

jena_long_uri存儲陳述表中不便於直接存儲的長資源URI

jena_prefix存儲URI的前綴。前綴只存儲一次，節省空間

jena_sys_stmt存儲了本體的元數據信息

主要數據存在兩個表中。

1)military_ontology.jena_g1t1_stmt存儲了本體的數據信息

2)military_ontology.jena_sys_stmt存儲了本體的元數據信息

⑸ 存儲到MySQL資料庫中的owl文件怎麼查看

將ShowRecord.owl文件存儲到MySQL資料庫中，資料庫叫Jena，在Eclipse中創建工程OperaOntology，代碼如下：
import Java.io.*;
import java.sql.SQLException;
import com.hp.hpl.jena.db.*;
import com.hp.hpl.jena.ontology.OntClass;
import com.hp.hpl.jena.rdf.model.*;
public class OperaOntology {
public static final String strDriver = "com.mysql.jdbc.Driver";
public static final String strURL = "jdbc:mysql://localhost:3306/jena"; // localhost的後面要直接寫冒號，再寫3306；
public static final String strUser = "root";
public static final String strPassword = "root";
public static final String strDB = "MySQL";
public static void main(String[] args){
try {
DBConnection connection = new DBConnection(strURL, strUser, strPassword, strDB);
System.out.println(connection);
// 創建連接時，第四個參數需要指定所用的資料庫類型；也就是說strDB的值應該是「MySQL」
try {
Class.forName("com.mysql.jdbc.Driver");
System.out.println("驅動程序已經安裝。");
} catch (ClassNotFoundException e){
System.out.println("ClassNotFoundException, Driver is not available");
}
System.out.println("資料庫連接成功。");
// 從此處開始讀入一個OWL文件並且存儲到資料庫中；
ModelMaker maker = ModelFactory.createModelRDBMaker(connection); // 使用資料庫連接參數創建一個模型製造器
Model defModel = maker.createModel("ShowRecord"); // 創建一個默認模型，命名為CostumeModel，因為我要存入的OWL文件名是Costume
FileInputStream read = null;
try{
File file = new File("e:/ontologies/ShowRecord.owl");
read = new FileInputStream(file);
}catch (FileNotFoundException e){
e.printStackTrace();
System.out.println("未找到要存儲的本體文件，請檢查文件地址及名稱");
}
System.out.println("已將本體文件轉換為位元組流文件。");
InputStreamReader in = null;
try {
in = new InputStreamReader((FileInputStream)read, "UTF-8");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
System.out.println("不支持上述字元集。");
}
System.out.println("已將位元組流文件轉換為UTF-8編碼。");
defModel.read(in,null);
try {
in.close();
} catch (IOException e){
e.printStackTrace();
System.out.println("無法關閉位元組流文件。");
}
System.out.println("已將位元組流文件關閉。");
defModel.commit();
System.out.println("數據轉換執行完畢，已將本體文件存入資料庫。");
try{
connection.close();
} catch (SQLException e){
e.printStackTrace();
System.out.println("文件無法關閉。");
}
} catch (RDFRDBException e){
e.printStackTrace();
System.out.println("出現異常");
}
System.out.println("已將本體文件持久化到資料庫中");
}
}
以上步驟成功完成以後，我登錄到MySQL的界面查詢工具查看Jena資料庫的表，點擊「Catalogs「

⑹ 語義信息的存儲

無論是知識庫還是服務的語義描述都需要具有良好的組織和存儲，以支持高效推理和服務檢索發現。目前對於本體的存儲方法基本有三種(李勇等，2008):

(1)純文本，如 OWL 文件。由於 XML 的信息組織和存儲方式結構復雜，而且存在冗餘等，基於其上的查詢檢索效率通常會比較低。純文本的方式適合本體比較小的時候，不適合本體大規模應用的情況。

(2)資料庫: 是一種比較好的持久化存儲方式，最大好處是便於查找，可存放大本體，查詢效率高，特別在 I/O 效率上。但是資料庫方式存在本體查詢語言到 SQL 的轉換問題，需要藉助於第三方中間件或自定義實現。

(3)專門的管理工具: 比如說 OMM(Ontology Middleware Mole)支持對 RDF、OWL 的存儲管理，還提供各種介面，可以使用查詢語言對 RDF 或者 OWL 進行查詢。綜合對比這三種本體存儲方式，由於關系資料庫存儲幾十年的技術積累，以及它的海量存儲特點而成為了許多研究者的首選。

5.4.3.1 本體的關系資料庫存儲模式

由於本體模型和關系模型的差異，目前存在多種在關系模型中存儲本體的方法，其主要可以分為以下四類(陶皖等，2007; 陳光儀，2009)。

5.4.3.1.1 水平模式

該模式只在資料庫中保留一張通用表，表中列為本體中的屬性。整個本體庫中定義了多少個屬性，這張表就有多少個列，具體如圖 5.28 所示。本體中的每個實例對應該表中的一條記錄。這種存儲模式結構簡單，執行查詢操作比較方便。但是該通用表包含了大量的列，而現有的資料庫系統對一張表中列的個數都是有限制的，所以該模式無法存儲規模較大的本體。而且表中的數據過於稀疏。由於每個實例對應關系表中的一行，如果其在某些屬性列上沒有值，那麼必須將對應的屬性值設置為空，這將導致大量空欄位的出現，不僅浪費存儲空間，而且增加了索引維護的代價。另外該通用表中一個實例的屬性和屬性值只能是一對一，而實際情況往往是一對多，因此無法存儲具有這種特徵的本體。隨著應用中本體的進化，還需要時常更新通用表中的列，重新組織表結構，這將耗費極大的系統代價。

圖 5.28 水平存儲模式

5.4.3.1.2 垂直模式

垂直模式包含一張三元組表，表中的每條記錄都對應一個 RDF 三元組(主語，謂詞，賓語)，具體如圖 5.29 所示。因此這種模式下，需要將本體中的所有信息都以 RDF 三元組的形式表示出來。Protege(2002)中便是使用了這種存儲模式將本體存儲於資料庫中。這種模式設計簡單，並且結構穩定。如果本體進行了更新，只需修改表中相應的元組即可。另外，該模式通用性好，因為現有的本體模型都可以轉換為 RDF 模型表示。但是這種模式的可讀性較差，若對本體信息進行查詢，那麼設計對應的 SQL 語句比較麻煩。除此之外，由於所有信息都存放在三元組表中，導致任何一個本體信息查詢都必須遍歷整個數據表，特別是那些需要進行表連接的查詢，使得查詢效率非常低，這是這種模式最大的不足之處。

圖 5.29 垂直存儲模式

5.4.3.1.3 分解模式

該模式與水平模式和垂直模式的一個顯著的區別是它使用了若干張表，其基本思想是將資料庫進行模式分解。根據分解的對象不同，現有的採用分解模式的方法有兩種。①基於類的分解模式，即為本體中的每個類都創建一張單獨的表，表名為類名，表的列為類的屬性，具體如圖 5.30 所示。這種模式結構清晰，但是很難適應本體動態變化的情況，因為隨著本體中類或者屬性的變化，表結構都要隨著變化。②基於屬性的分解模式，即為本體中的每個屬性創建一張單獨的表，表名為屬性名，每個表都包含兩個列，分別代表RDF 三元組中的主語和賓語，具體如圖 5.31 所示。在該模式中對類的隱含實例的查詢代價很大，而且在現有的這兩種分解模式的方法中，隨著本體的變化都要不斷的創建和刪除表，而在資料庫系統中創建和刪除表的效率很低。

圖 5.30 按類分解模式

圖 5.31 按屬性分解模式

5.4.3.1.4 混合模式

該模式通常將上述幾種模式進行混合使用。例如，Pan 等(2003)提出這樣一種將基於類的分解模式與基於屬性的分解模式混合的存儲模式，即在本體中定義一個類就為該類創建一個表(創建方法類似於基於類的分解模式)，在本體中定義一個屬性就為該屬性創建一個表(創建方法類似於基於屬性的分解模式)。然而，與基於類的分解模式不同的是，該混合模式在類對應的表中不記錄相應實例的所有信息，而只記錄實例的 ID。實例在各個屬性上的取值則分別記錄在各屬性對應的表中，所以和基於屬性的分解模式類似，該模式在屬性對應的表中仍然需要兩列: 主語和賓語。對於本體類數目不多的情況下，這種模式在簡單檢索的情況下，運行得很好。但是，如果本體的類比較多，這種方式就會存在一些問題，例如: 資料庫無法容納這么多表，或者效率低下。

針對上述四種模式，陳光儀(2009)從四個方面對適用場合、查詢和更新效率、結構清晰以及易理解性、可擴展性四個方面對他們進行了綜合對比(表 5.4):

表 5.4 不同存儲模式的綜合對比

(修改自陳光儀，2009)

通過上述對本體存儲模式的闡述及之間的綜合對比發現，本體存儲模式除了應該具有盡量高的規范化程度(例如滿足第三範式或 BCNF 范圍等)，還應該滿足以下三個原則。

(1)模式結構易於理解。該原則是為了便於本體查詢的實現。如果模式結構不直觀，會給查詢語句的設計帶來困難。例如，垂直模式不滿足該要求，它將所有的信息都採用三元組的形式存儲在一張表中，不容易理解表中元組的含義，加重了本體查詢設計的負擔。

(2)模式結構穩定。即本體的變化不會引起資料庫表結構的變化。因為本體是不斷進化的，如果設計的模式結構會隨著本體的變化而變化，資料庫系統對其維護代價太大。現有的水平模式、分解模式和混合模式都不滿足該要求。

(3)查詢效率高。該原則是評價各種存儲模式的一個重要指標。因為本體中不僅包含大量的數據，而且查詢中還經常需要進行表連接。例如在現有的垂直模式和基於屬性的分解模式中，那些涉及表連接的查詢效率非常低。

目前在基於資料庫的本體存儲的實踐上，一些學者開展了相關的研究工作:

燕雲鵬(2007)和陳光儀(2009)提出了類似的針對於針對 OWL 的本體資料庫的混合本體存儲模式(圖 5.32，5.33)。可以看出這種模式是以基於屬性的分解模式與垂直模式的混合體，具有較好的擴展性。但是存在的問題是效率不夠高，所有的類存儲在一個表中，所有的實例也存儲在一個表中，這種方式的檢索效率比較低。另外存儲實例的表(Instance，Proterty，Value)中欄位 Value 必須存儲許多種不同類型的數值，比如有的是文本型，而有的卻是數值型，使得數據不夠清晰。此外，在針對幾何體這種復雜的地理對象，這種欄位就比較難以存儲。

圖 5.32 本體的資料庫混合存儲模式(據燕雲鵬，2007)

ebRIM(ebXML Registry Information Model)是一個主流的信息注冊模型，已成為事實上的標准，得到了 OGC 等支持。OGC 已經實現了基於 ebRIM 的目錄服務，並推薦其作為目錄服務的實現規范。但是目前基於 ebRIM 的目錄服務只支持普通的基於關鍵字的檢索。為此，一些學者已經開始研究如何擴展 ebRIM 實現對語義信息特別是 OWL 的注冊。Dogac 等(2004)提出了如圖 5.34 所示的一種通過將 XML 形式存儲的 OWL 文件轉換為以資料庫形式存儲，使得查詢檢索更加快速，管理維護也更加方便。為了能在 ebRIM 存儲復雜的地理空間信息對象，一些學者開展了基於 ebRIM 的地理擴展方面的研究工作。樂鵬(2007)在其論文中提出了兩種擴展方式: ① 從類 「ExtrinsicObject」 派生了「CSWExtrinsicObject」來描述那些不是 ebRIM 自身定義的元數據對象。比如類 「Dataset」繼承了 「CSWExtrinsicObject」來描述空間數據集。②對 ebRIM 已有的類別增加 「Slot」。每一個從 「RegistryObject」繼承下來的類均允許添加 「Slot」。ebRIM 中的 「Service」類可以用來描述空間服務，但是已有的屬性不足以描述空間網路服務。因此，通過添加「Slot」到 「Service」類中以定義從 ISO 19119 派生的屬性。如圖 5.35 所示為經擴展後的ebRIM 高層模型圖，其中 灰 色 填 充 的 矩 形 框表示 擴 展 的對 象 類。該 模 式 與 前 面 燕 雲 鵬(2007)和陳光儀(2009)提出的模式相比，本質上差別不大，也是以基於屬性的分解模式與垂直模式的混合體，只不過是基於標準的 ebRIM 注冊模型，並且將其中的分類系統相關的類單獨以兩張表存儲。該模式也具有很好的擴展性，也存在同樣的一些問題。

圖 5.33 本體的資料庫混合存儲模式(據陳光儀，2009)

海洋信息網格技術與應用

續表

5.34 OWL 元素到 ebRIM 元素的映射(Dogac et al.，2004)

5.4.3.2 基於多分解策略的混合存儲模式實現

對知識庫以及服務語義注冊信息的存儲的實現上，本書在現有的研究成果的基礎上，結合本體組織構成及特點等實際需求，提出了一種基於多分解策略的混合關系資料庫存儲模式。

該方法的指導思想是: 先按類對其中的數據專題、數據模式、處理模型等進行類的分解，然後結合屬性的特性進行基於屬性的分解。其中基於類的分解中，可能粒度的大小不一，可能是一個類或者具有相關或相似的一些類劃分為一張表存儲; 而基於屬性的剖分，也並不是所有具有該屬性的類以一個表存儲，而可能是只針對一個類也單獨組織為一張表，其具體思路如下:

圖 5.35 經擴展的 ebRIM 高層模型圖(據樂鵬，2007)

(1)類的分解: 因為本研究的存儲模型不是為了實現一個通用的本體存儲模型，而是為了實現一個服務於海洋信息服務領域的本體存儲模型。海洋信息服務領域必然會牽涉到一些對象，比如對服務、模型、參數等對象，並且對這些對象的認識也基本上確定(也就是說這些對象類所具有的屬性及之間的關系基本明確)，所以沒必要像上面幾種實現方案那樣因為不能預知都有哪些類，各類都有哪些屬性而將所有的實例的組織按垂直方式進行存儲，也沒有必要有一些表(比如獨立的屬性表，屬性的作用域和值域表等); 而有必要針對海洋信息服務領域內的這些類的信息內容獨立出一些表: 對於海洋專題，地理名實體、處理模型、數據模式等海洋信息檢索發現中常用的對象，則有必要進行分開存儲，否則必然使得結構不清晰，且檢索查詢效率低。

(2)對於專題、空間形態以及模型功效等只是簡單的分類系統，所具有的屬性少，而且今後存在派生新的種類的可能，因此必須具備一定的擴展性。針對這類數據。它們的存儲方式是(ClassID，ParentClassID，ClassType)，其中 ClassType 標注本體類是屬於專題(比如 「海流」)或者其他。

(3)對於取值不唯一的屬性，且大部分類或實例都具有的屬性，則採用基於屬性的分解模式。比如對於別名屬性(hasAliasName)，有可能一個類實例具有多個別名，這種情況下，則採取基於屬性的組織方式。該表的形式是:(OntologyID，AliasName)，其中OntologyID 可以是本體類的 ID，也可以是本體實例的 ID，還可以是本體屬性的 ID，因為類、實例和屬性都可以有別名。

(4)對於復雜的屬性，採取大二進制存儲的方式。比如對於地名實例的空間覆蓋范圍，則不考慮其實際內部是包含多少個組成部分，統一按一個 shape 存儲在資料庫中。當然這里藉助了 ArcGIS 的 GDB 的 FeatureClass 矢量數據模型，並對於不同空間形態的則採用了多張表(點狀地名類、線狀地名類、面狀地名類)，其組織方式是(GeoNameObjec-tID，shape)。同樣，對於模型本體中的內部流程本體，也採用了大二進制方式存儲，將整個流程 XML 描述文件，作為一個整體存放於欄位中，其大體組織方式為(ModelID，FlowXML)。

(5)本研究採用 ArcGIS 的 GeoDatabase 作為存儲模型。本體類(ontClass)的存儲結構如圖 5.36 所示，資料庫的總體組織結構如圖 5.37 所示。

圖 5.36 本體類(onClass)的存儲結構