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)的存储结构