This paper presents a tool that helps developers to design and implement storage models for OWL ontologies. This tool uses xml both to represent the knowledge given by the ontology, and de¯ne the rules that generate the storage model. It presents a graphical interface that helps developers to use it. The storage models created by this tool will be used in our research studies.
OWL language [
On the other hand, the database research community has successfully developed a wide theory corpus and a mature and e±cient technology to deal with large and persistent amounts of information. Due to the size of the Semantic Web ontologies (very large ontologies with very large amount of instances), we think that it will be necessary to use database technology in order to provide persistence to the knowledge described by the ontologies, and scalability to the queries and reasoning on this knowledge.
Unfortunately, the application of database technology to reason with instances of OWL ontologies is not a trivial matter. Databases work with a closedworld assumption, while ontology systems apply an open-world assumption. In a database, instances are accepted only if they fully comply with the de¯nitions and constraints stated in the schema, while ontology systems accept instances as long as they do not explicitly contradict the knowledge already in the ontology, without requiring that all expected data be present. This must be taken into account in order to implement the reasoning mechanisms using database technology.
Our research objective is to study di®erent storage models for OWL ontologies. E±cient Storage models for OWL ontologies are necessary for the future of the Semantic Web. The complex reasoning mechanisms that should be implemented for the Semantic Web applications will need optimized storage model in order to be e±cient and scalable. Therefore, we must de¯ne knowledge storage methods beyond a simple correspondence with a database logical schema. That is, it is necessary to de¯ne both a physical knowledge representation and access path (indexes) in order to access the knowledge e±ciently. We believe this to be an open research issue that should be studied.
To do so, we have developed a tool that helps us to design and implement
these storage models, which will be used in our research studies. In this paper we
present this tool. The tool is built as a plugin for the Prot¶eg¶e [
In the past few years there has been an groing interest in the development of
systems for storing large amounts of knowledge in the Semantic Web. Firstly,
these systems were oriented to RDF storage [
DLDB is a knowledge base that extends a relational database management system (RDBMS) with additional capabilities for making OWL inferences. The main objective of this system is to study how description logic reasoning mechanisms can be combined with an RDBMS, in order to support extensional queries on OWL documents. Ontologies are stored using Microsoft Access as RDBMS. Speci¯cally, the system stores RDF in a relational database. Ontologies are stored creating a table for each class or property de¯nition. The class hierarchy is stored in the system using views. The view of a class is de¯ned recursively, and consists of the union of its table and all the views of its direct sub-classes. Therefore, the view of a class includes the instances of that class plus the inferred instances using the taxonomic reasoning mechanism. The sub-property relationship is stored in a similar way. The system is optimized for medium size ontologies (hundreds of classes and properties). The system provides an API, implemented in java, to query the database. It supports conjunctive queries in a format similar to KIF (http://www.cs.umbc.edu/kse/kif/kif101.shtml). The query is translated to SQL and is sent to the database using JDBC. The query is evaluated by the RDBMS which returns the results. The reasoning mechanisms are implemented using the FaCT reasoner coupled to the RDBMS. FaCT only supports Tbox reasoning; therefore DLDB only implements those reasoning mechanisms which can be reduced to concept subsumption (concept and property taxonomy reasoning). These reasoning mechanisms are implemented by pre-computing the class/property hierarchy and storing it in the database using views. Using FaCT, we obtain the sub-classes/sub-properties of a given class/property needed to generate the views. The system does not support other OWL reasoning mechanisms.
DLP is a proposal for combining rules with ontologies in the Semantic Web.
It is based on logical databases, since they provide a declarative knowledge
representation language and persistent data storage. DLP de¯ne a mapping between
a description logic (DL) subset and logic programs (LP). This intersection
between DL and LP, called DLP (Description Logic Programs), covers RDF schema
completely, and part of OWL. In [
Instance Store (IS) is an approach to a restricted form of Abox reasoning that combines a description logic reasoner with a database. The Instance Store can only deal with free-role Aboxes, ie Aboxes that do not contain any axioms asserting role relationships between pairs of individuals. Ontologies are described using OWL. Instance Store only o®ers persistence to the Abox. Abox assertions are stored in a relational database. An identi¯er (ids) is assigned to each description (concept) and a table stores individuals and the ids of their associated description. Another table contains description ids and all the primitive concepts in the ontology which subsume them. The primitive concepts which are equivalent to, parent of and child of a given description are also stored in a table. Instance Store provides an API written in Java. This API contains a retrieval method that retrieves all the instances of a given concept. The query is translated to SQL and is sent to the relational database. Instance Store does not provide Tbox reasoning mechanisms. That is, it is not possible to reason about the structure of the ontology. The only Abox mechanism is, as we said above, instance retrieval.
If we observe the storage model, all systems choose a database which will ensure the persistence of the knowledge, and the scalability to the queries on this knowledge. However, the logical models that represent the ontologies are not completely re¯ned, and are usually naive representations of the Tbox. Furthermore, no systems take into account the physical representation of the knowledge base, and thus do not choose the best storage structures or an e±cient access path (indexes).
Our proposal is not a system to store OWL ontologies. It is a tool for helping developers to create a storage model for OWL ontologies. The tool assists you to de¯ne how your model will represent the di®erent OWL ontology elements in the chosen storage model. 2.1
A tool for Storing OWL Ontologies The development of tools for storing and querying ontologies is a ¯eld currently under investigation. The necessity of new advanced reasoning mechanisms that allow us to infer knowledge to be used in Semantic Web applications entails the development of e±cient storage models in order to implement these reasoning mechanisms e±ciently.
Our main research objective is that reasoning/querying in a knowledge base may be scalable and e±cient. We want to ful¯l these requirements not in a general case but in the Semantic Web environment. We believe that, in this context, we will ¯nd a fairly large amount of instances and we are convinced that, in the Semantic Web, not only reasoning on concepts is necessary, but also reasoning at the instance level and e±cient instance retrieval. We would also like to allow queries and even more the combination of reasoning and querying procedures. In order to achieve this, we need to study di®erent storage models for OWL ontologies. We believe that a speci¯c physical representation of the instances of the ontology, and an ad hoc index structures will be necessary. Both representation and index will depend on the expressiveness of the query language and the reasoning implemented. Therefore, the solution will not be unique, but rather a trade-o® between expressiveness and e±ciency.
In this paper we present a tool that helps us to generate di®erent (physical) storage models, which will be used in our research studies. The tool is built as a plugin for the Prot¶eg¶e tool. We exploit the features of Prot¶eg¶e in order to manipulate OWL ontologies easily. Figure 1 shows the architecture of the tool. The storage model generation has two phases. First, the OWL ontology is parsed in order to obtain all the information it contains. This process generates several XML ¯les. We have chosen XML because programming with Java and XML is very easy. The use of RDF or RFDS could be also an option, but there are more tools for managing XML than RDF. We will consider changing to RDF in the next versions of the tool.
In the second phase, the ontology information stored in these XML ¯les is shown to the user in a graphical way, using the Prot¶eg¶e interface. The storage model is de¯ned by means of several con¯guration ¯les. These are also XML ¯les. The model developer has to create these ¯les, which contain the rules de¯ning a concrete storage model. The storage model is shown graphically together with the ontology. The developer selects the storage rules that he/she wants to apply. Finally, using all this information the particular storage model for the Data Base Management System (DBMS) selected is generated.
OWL Ontologies Parser. This component uses the Prot¶eg¶e API to generate four XML documents for each OWL ontology. These XML ¯les are: { classes.xml: Stores all the information about named classes de¯ned by the ontology. This information includes name, superclasses, subclasses and properties. { properties.xml: Stores all the information about properties de¯ned by the ontology. This information includes name, type, domain, range, whether the property is transitive or symmetric and whether the property has an inverse property. { restrictions.xml: Stores all the information about restrictions de¯ned by the ontology. This information includes name, type, restricted class, etc. { instances.xml: Stores all the information about instances de¯ned by the ontology. This information includes name, type, properties, etc.
Storage Model generator. This component shows the information de¯ned in the con¯guration ¯les. The developers chose which rules they want to apply and the storage model is generated. Both rules and implementation of these rules are de¯ned in a con¯guration ¯le. We de¯ne three kinds of rules: { Default rules. By applying these rules a default storage model is generated.
These rules must be applied all together. { Generic rules. These rules are applied to the default storage model in order to modify it. They are de¯ned for all elements in the ontology that ful¯l the rule antecedent. For example, all classes, all properties, etc. { Parametric rules. These rules also are applied to the default storage model.
However, they are de¯ned for a speci¯c element of the ontology, which must be speci¯ed by the developer before the rule application.
Con¯guration ¯les. All information about the storage model is de¯ned using several con¯gurations ¯les. These ¯les are xml ¯les. The tool allows us to modify the ¯les using the graphical interface. It is also possible to create a new storage model and all its associated ¯les. The Models.xml ¯le contains all the possible storage models that are de¯ned. It stores the model's name, and the name of the rest of the ¯les that de¯ne the model. These ¯les de¯ne the storage model rules and the implementation of each rule in a speci¯c DBMS. The same storage model can be implemented using di®erent DBMS. Furthermore, it is really easy to modify an existing storage model. The only we have to do is to modify the rules in the con¯guration ¯les. This allow us to create easily two physical implementations for the same storage model in order to study the performance of a reasoning mechanism using both implementations.
The tool also provides a component that implements the necessary functions which recover the information about the ontology by accessing the xml ¯les that represent it. For example, the name of the classes or properties de¯ned by the ontology. This component can be used by all developers that want to de¯ne a new storage model, due to this information being necessary independently of the desired storage model. These functions will be used for implementing the rules. 3
In order to demonstrate our tool, we have developed a model that stores OWL ontologies in relational databases. Speci¯cally, it uses Oracle as DBMS. It is a simple example to illustrate the use of the tool. In this chapter we will show brie°y the con¯guration ¯les for this particular model. The aim of this section is not to present a new storage model but to present how, and how easy, it is to use and to con¯gure our tool.
The default storage model is based on the di®erent proposals for storing
RDF in relational databases [
The xml syntax to specify the default rule that stores each class in a table is shown in ¯gure 2. A default rule consists of a name, an antecedent, a consequent and a text. When the developer selects a rule in the graphical interface, the content of the text tag is shown in order to give him or her information about what the rule does.
Each default rule is implemented in Oracle. The implementation ¯le speci¯es how each rule must be implemented. For implementing the previous default rule we used the get-classes-name function to recover all the classes de¯ned by the ontology, and for each class we execute the SQL sentence de¯ned in ¯gure 3, where classname is each of the names that the function returns.
Once the default storage model is created, we can apply generic and parametric rules. In our case, we had de¯ned generic rules that create indexes for some tables. For example, the rule in ¯gure 4 create an index for the range column of the table that represents a property, if there is a restriction de¯ned for this property. A generic rule has the same structure as a default rule.
Finally, we de¯ned some parametric rules. These rules are applied to a speci¯c element of the storage model. Thus, the structure of these rules is di®erent from the rest of the rules, because it is necessary to specify the parameters. When the developer chooses one of these rules, the values for the parameters must be given. This is also done using the graphical interface. Figures 5 and 6 show two parametric rules. The ¯rst one creates a Btree index for the speci¯ed column. The second one inserts the speci¯ed table in the speci¯ed cluster.
As previously mentioned, the graphical interface allows us to modify, insert and delete new rules in an existing model, and also create a new storage model from scratch. In ¯gure 7 the graphical interface of our tool is shown. This interface is currently in Spanish, but it is being translated to English. 4
In this paper, we present a tool that helps developers to design and implement storage models for OWL ontologies. This tool uses xml both to represent the knowledge given by the ontology, and to de¯ne the rules that generate the storage model. Using this tool it is possible to store the same OWL ontology using di®erent approaches, which allows us to compare them regarding the reasoning mechanisms performance. We also present an example of how to use this tool for storing an OWL ontology in a relational database.
We are currently developing a new plugin that allows us to access the ontology stored using our tool, in order to query and reason with it. This new plugin will provide a graphical interface to create the queries/reasoning mechanisms, and to execute them. It will also use xml ¯les to be con¯gured. 5
This work has been partially supported by the MCyT project TIC2002-04586C04-04.