A true Semantic Web knowledge base system must scale both in terms of number of ontologies and quantity of data. It should also support reasoning using different points of view about the meanings and relationships of concepts and roles. We present our DLDB3 system that supports large scale data integration, and is provably sound and complete on a fragment of OWL DL when answering extensional conjunctive queries. By delegating TBox reasoning to a DL reasoner, we focus on the design of the table schema, database views, and algorithms that achieve essential ABox reasoning over an RDBMS. The ABox inferences from cyclic axioms are materialized at load time, while other inferences are computed at query time. Instance data are directly loaded into the database tables. We evaluate the system using synthetic benchmarks and compare performances with other systems. We also validate our approach on data integration using multiple ontologies and data sources.
The Semantic Web is growing and clearly scalability is an important requirement for Semantic Web systems. Furthermore, the Semantic Web is an open and decentralized system where different parties can and will, in general, adopt different ontologies. Thus, merely using ontologies, does not reduce heterogeneity: it just raises heterogeneity problems to a different level. Without some form of alignment, the data that is described in terms of one ontology will be inaccessible to users that ask questions in terms of another ontology. Our ontology, perspective semantics provides a framework to integrate data sources using different ontologies. This framework uses only standard OWL axioms and hence would not add any additional reasoning complexity to the knowledge base system. Another unique feature of this framework is that different viewpoints regarding the integration (or mapping) could coexist in one knowledge base system, even when they are contradictory. We think this is important for the Semantic Web, which is inherently distributed and inconsistent.
Based upon this framework, we built DLDB3, a scalable Semantic Web knowledge
base system that allows queries from different points of view. DLDB3 has major
improvements over DLDB2 [
The kinds of cycles that lead to incompleteness in a database view approach like
DLDB include transitive axioms and property restrictions where the same class appears
on both sides of a general concept inclusion axioms (e.g. ∃P.C " C). Wang et al. [
In what follows, we first introduce ontology perspectives. We then present the DLDB3 system’s reasoning algorithms, architecture, design and implementation with a focus on how the reasoning is achieved and perspectives are supported. Finally we evaluate the system using benchmarks as well as multi-ontology data sets and queries. 2
In prior work, we have defined ontology perspectives which allows the same set of data
sources to be viewed from different contexts, using different assumptions and
background information [
Each perspective is based on an ontology, hereafter called the basis ontology or base of the perspective. By providing a set of terms and a standard set of axioms, an ontology provides a shared context. Thus, data sources that commit to the same ontology have implicitly agreed to share a context. When it makes sense, we also want to maximize integration by including data sources that commit to different ontologies.
We now provide informal definitions to describe our model of the Semantic Web. A Semantic Web space W is a pair #O, S$, where O is a set of ontologies and S is a set of data sources. An ontology O in O is a four-tuple #C, R, T , E $, where C is a set of concepts; R is a set of roles; T is a TBox that consists of a set of axioms; E ⊂ O is the set of ontologies that are extended by O. Note extension is sometimes referred to as inclusion or importing.
An ancestor of an ontology is an ontology extended either directly or indirectly by it. If O2 is an ancestor of O1, we write O2 ∈ anc(O1). Note the ancestor function returns the extension closure of an ontology, which does not include the ontology itself.
For ontology extension to have its intuitive meaning, all models of an ontology
should also be models of every ontology extended by it. Here we assume that the models
of T are described by the semantics of OWL, for example see [
Definition 1 A data source s is a pair #A, O$, where A is an ABox that consists of a set of formulas and O is the ontology that s commits to. A model of s is a model of both A and O.
When a data source commits to an ontology, it has agreed to the terminology and definitions of the ontology. It means that for data source s = #As, Os$, all the concepts and roles that are referenced in As should be either from the ontology Os or anc(Os).
We now define an ontology perspective model of a Semantic Web space. This definition presumes that each ontology can be used to provide a different viewpoint of the Semantic Web.
Definition 2 (Ontology Perspective Model) An interpretation I is an ontology perspective model of a semantic web space W = #O, S$ based on O ∈ O (written I|=OW ) iff: 1) I is a model of O and 2) for each s = #As, Os$ ∈ S such that Os = O or Os = anc(O), I is a model of s.
Based on this definition, entailment is defined in the usual way, where W|=Oφ is read as “W O-entails φ”.
Theoretically, each O-entailment relation (perspective) represents a set of beliefs about the state of the world, and could be considered a knowledge base. Thus, the answer to a Semantic Web query must be relative to a specific perspective. We now define a Semantic Web query.
Definition 3 Given a Semantic Web Space W = #O, S$, a Semantic Web query is a pair #O, ρ$ where O ∈ O is the base ontology of the perspective and ρ is a conjunction of query terms q1,....., qn. Each query term qi is of the form x:c or #x, y$:r, where c is an atomic concept and r is an atomic role from O or ancestor of O and x, y are either individual names or existentially quantified variables.
An answer to the query #O, ρ$ is θ iff for each qi, W|=Oθqi where θ is a substitution for the variables in ρ.
We argue that our perspectives have at least two advantages over traditional knowledge representation languages. First, the occurrence of inconsistency is reduced compared to using a global view, since only a relevant subset of the Semantic Web is involved in processing a query. Even if two ontologies have conflicting axioms, the inconsistency would only be propagated to perspectives based on common descendants of the conflicting ontologies. Second, the integration of information resources is flexible, i.e. two data sources can be included in the same perspective as long as the ontologies they commit to are both being extended by a third ontology. 3
Our approach was inspired and based on the work of Description Horn Logic (DHL)[
The DHL language and its mapping to other formalisms has been described in detail in
[
Concepts are defined as D ::= A|D1 ! D2|∀R.D C ::= A|∃R.C|C1 ! C2|C1 $ C2 Where A denotes atomic concept.
The axioms have form: C % D R1 % R2 R+ % R means R is a transitive property F unc(R) means R is a functional property 1
Roles are defined as R ::= P |P − Where P denotes atomic role.
The assertions have form: a : C (a, b) : R where a, b are named individuals.
Translation input Translate to Trans(A, x) A(x) Trans(C % D, x) Trans(C, x)→ Trans(D, x) Trans(C1 ! C2, x) Trans(C1, x) ∧ Trans(C2, x) Trans(C1 $ C2, x) Trans(C1, x) ∨ Trans(C2, x) Trans(∃R.C, x) Trans(R, x, y) ∧ Trans(C, y) Trans(∀R.D, x) Trans(R, x, y) → Trans(D, y) Trans(R1 % R2, x, y) Trans(R1, x, y) → Trans(R2, x, y) Trans(R+ % R) Trans(R, x, y) ∧ Trans(R, y, z) → Trans(R, x, z) Trans(P −, x, y) Trans(P, y, x) Trans(P, x, y) P(x, y)
The DL constructors and axioms can be recursively mapped to First Order Logic rules. By applying Lloyd-Topor transformation to rewrite rules with conjunctions in the 1 This feature will be handled separately in our system, and will not be translated into horn rules. head and disjunctions in the body, we can ensure the resulting rules are all horn rules. The equivalences can be rewritten into two subsumptions. 3.2
Our approach uses a relational database to store, manage and retrieve instance data. For each predicate P (class or property) that is defined in an Ontology, we create a dedicated table Ptable to store the explicit facts. In order to reflect the perspective, we use PtOable to represent the explicit or materialized facts of P that committed to ontology O or anc(O). Note in actual implementation, PtOable doesn’t have to be a real table in the database, it can be implemented as a filter of ontology commitment on top of Ptable. When facts are stored as tuples in the database, their “provenance” or “source” information are also preserved in the form of the identifier of the ontology they commit to. We use PvOiew to represent all instances of P , explicit or implicit, from the perspective based on O. For convenience, we define extensional disjunctive normal form. Definition 4 A logical formula in first order logic is in extensional disjunctive normal form (E-DNF) if and only if it is a disjunction of one or more conjunctions of one or more atoms, where all predicates correspond to extensional tables.
Algorithm 1 shows how the reasoning is conducted in our approach. First, we convert axioms in a given ontology into a set of horn rules using the translation function defined above. Note the DL axioms can be reasoned and enriched by a DL reasoner, but it is not necessary in our algorithm. Then for a set of horn rules with a common head, we convert them into a single FOL rule, where the left hand side is in E-DNF. This conversion is processed recursively by applying Modus Pones in a reverse direction until all predicates are primitive (correspond to extensional tables). Next, we separate acyclic portion of disjuncts from the cyclic portion. For acyclic rules, we create view for the head’s predicate using straightforward translation from rule to SQL, where conjunctions correspond to joins on common variables and disjunctions correspond to UNION in SQL. Each ontology has a distinct view for each predicate defined by it or one of its ancestors. Periodically when data is being loaded, we use Algorithm 2 to handle cyclic rules left from Algorithm 1. During the computation, we materialize new tuples in the tables so that the computation does not need to be invoked at query time. The materialization would also set the ontology commitment information to be the ontology that invokes this round of computation, such that these “derived” facts can be correctly managed using perspectives. When answering extensional conjunctive query #O, ρ$ as defined in section 2, each predicate P is directly translated into a view PvOiew that not only contains the implicit facts through subsumptions, but also the explicit and materialized facts in the underlying table.
Theorem 1 Given a knowledge base consists of ontologies and data sources in DHL, the reasoning algorithms described above is sound and complete w.r.t any Semantic Web Query #O, p$.
PROOF. (Sketch) When we load an ontology O, the axioms of O and anc(O) are used to generate database views for the perspective based on O. This is consistent with the Algorithm 1 Load an ontology into the knowledge base LOADONTOLOGY(O) 1: Translate axioms in O and anc(O) into a set of horn rules H 2: Initialize sets F, F*, each holds a set of FOL rules 3: for each predicate P in H do 4: Convert the set of horn rules whose heads’ predicate is P to L, where the body of L is a
E-DNF FOL formula 5: for each disjunct B in L such that one of the predicates is P but with different arguments do 6: remove B from L and add B as a disjunct into the body of L∗ where the head of L∗ is also P 7: F = F $ L, F ∗ = F ∗ $ L∗ 8: end for 9: end for 10: for each FOL rule L ∈ F do 11: create view PvOiew as a SQL expression that joins the conjuncts and unions the disjuncts.
Each predicate A in the body of L is translated into AtOable. 12: end for
FIXPOINTCOMPUTE(F ∗, O)
1: repeat
2: for each FOL rule L∗ in F ∗, where the head’s predicate is P do
3: Translate the body of L∗ into SQL query q, where each predicate A are replaced by
views AvOiew
4: Execute q, add new tuples into PtOable
5: end for
6: until A fix point has reached, which means none of the iterations generates new tuples
Ontology Perspective Model in 2. It has been shown in [
DLDB3 is a knowledge base system that combines a relational database management system with additional capabilities for partial OWL reasoning. It is freely available as an open source project under the HAWK framework 2.
The DLDB3 core consists of a Load API and a Query API implemented in Java. Any DL Implementation Group (DIG) compliant DL reasoner and any SQL compliant RDBMS with a JDBC driver can be plugged into DLDB3. This flexible architecture maximizes its customizability and allows reasoners and RDBMSs to run as services or even clustered on multiple machines.
It is known that the complexity of complete OWL DL reasoning is NEXPTimecomplete. Our pragmatic approach is to trade some completeness for performance. The overall strategy of DLDB3 is to find the ideal balance of precomputation of inference and run-time query execution via standard database operations. The consideration behind this approach is that DL reasoners are optimized for reasoning over ontologies, as opposed to instance data.
Following our algorithm described in the last section, creating tables corresponds to the definition of classes or properties in ontology. Each class and property has a table named using its URI.
Normally, the ’sub’ and ’obj’ fields are foreign keys from the ’ID’ field of the class tables that are the domain or range of the property, respectively. However, if the property’s range is a declared data type, then the ’object’ field is of the corresponding data type (RDF and OWL use XML Schema data types). Currently DLDB3 supports integer, float and date in addition to string.
DLDB3’s table schema is different from the vertical (also called “schema-oblivious”)
approach [
We think the table design of DLDB3 has two advantages over the vertical approach. First, it will contain smaller tables than the vertical scheme. Second, it preserves the data types of the properties and hence can directly and efficiently answer queries involving numeric comparison, such as finding individuals whose ages are under 21. Compared to the traditional relational model, where properties correspond to columns, multi-valued properties (attributes) in DLDB3 don’t need to be identified at ontology design time.
In addition to the basic table design, some details should be taken into account when implementing the database schemas for the system. First, we need a scheme for naming the class and property tables. Note, using the full URI will not work, because these URIs often exceed the RDBMS’s limits on the length of table names. However, the local name is also insufficient because many ontologies may include the same local name. So we assign a unique sequence number to each loaded ontology. Then each table’s name is a class or property’s local name plus its ontology’s sequence number. This is supported by an extra table:
ONTOLOGIES INDEX(Url, SeqNum) that is used to register and manage all the ontologies in the knowledge base. The sequence number will be assigned by the system when an ontology is first loaded into the database.
Since each row in the class tables corresponds to an instance of the class, an ’ID’ field is needed here to record the ID of the instances. The rest of the data about an instance is recorded using the table per property (a.k.a. decompositional) approach. Each instance of a property must have a subject and an object, which together identify the instance itself. Thus the ’sub’ and ’obj’ fields are set in each table for property.
Sometimes it is important to know which document a particular statement came from, or how many documents contain a particular statement. We support this capability by including a ’Src’ field in each class and property table. Together with other fields, it serves as the multiple-field primary key of the table. In other words, the combination of all the information of one record identifies each instance stored in the knowledge base. In order to support perspectives described in section 2, the ontology to which the individual data commits is also needed. Thus an ’Onto’ field is include in the tables. This field is used to record the committed ontology from Algorithm 1 and 2. An example of class and property tables might be: STUDENT:1(Id, Src, Onto) TAKESCOURSE:1(Sub, Obj, Src, Onto)
In order to shrink the size of the database and hence reduce the average query time, DLDB assigns each URI a unique numeric ID in the system. We use a table: URI INDEX(Uri, Id) to record the URI-ID pairs. Thus, for a particular resource, its URI is only stored once; its corresponding ID number will be supplied to any other tables. Since the typical URI is often 20-50 characters long and the size of an integer is only 4 bytes in the database, this leads to a significant savings in disk space. Furthermore, query performance is also improved due to the faster joins on integers instead of strings and the reduced table size. By discriminating the DataType properties and ObjectType properties, the literals are kept in their original form without being substituted by ID numbers. The reason why we don’t assign IDs to literals is 1) literals are less likely to be repeated in the data; and 2) literals are less likely to be joined with other tables because they are never used as database keys.
Unsurprisingly, the tradeoff of doing the URI-ID translation is an increase in load time. We use a hash table to cache URI-ID pairs found recently during the current loading process. Since URIs are likely to repeat in one document or neighboring documents, this cache saves a lot of time by avoiding lookup queries when possible.
When DLDB3 loads an ontology, it uses Algorithm 1 to do reasoning. Note if there are instance data in the ontology, they are processed in the same way as if they come from a data source which commits to this ontology.
It is worth noting that DLDB3 uses a DL reasoner to make inferences on DL axioms before these axioms are translated into horn rules. In result, although the horn rules implemented in the DLDB3’s relational database system correspond to a subset of DHL, DLDB3 does support reasoning on DL ontologies richer than DHL. For example, the axioms A " B 'C and A " ¬B are both beyond the expressiveness of DHL. However, the DL reasoner will compute and return A " C assuming A and C are both atomic classes. Unfortunately, it is difficulty to characterize this expressivity formally since some other axioms involving disjunction or negation are not supported.
In general, data loading in DLDB3 is straight-forward. Each rdf:type triple inserts a row into a class table, while each triple of other predicates inserts a row into a role table corresponding to the predicate. If a data document imports multiple ontologies, the value of the ’Onto’ field is decided by the ontology that introduces the term that the table corresponds to. However, DLDB3 materializes certain inferences at data load time, as discussed in the next sections.
This subsection focuses on precomputations that simplify reasoning at query time. These ABox reasoning routines along with the rule-based reasoning algorithm make the system complete on a significant subset of OWL DL.
OWL does not make the unique names assumption, which means that different names do not necessarily imply different objects. Given that many individuals contribute to the Web, it is highly likely that different IDs will be used to refer to the same object. Such IDs are said to be equal. A Semantic Web knowledge base system thus needs an inference mechanism that actually treats them as one object. Usually, equality is encoded in OWL as (a owl:sameAs b), where a and b are URIs.
In DLDB3, each unique URI is assigned a unique integer id in order to save storage space and improve the query performance (via faster joins on integers than strings). Our approach to equality is to designate one id as the canonical id and globally substitute the other id with this canonical id in the knowledge base. The advantage of this approach is that there is effectively only one system identifier for the (known) individual, nevertheless that identifier could be translated into multiple URIs. Since reasoning in DLDB3 is based on these identifiers instead of URIs, the existing inference and query algorithms do not need to be changed to support equalities.
However, in many cases, the equality information is found much later than the data that it “merges”. Thus, each URI is likely to have been already used in multiple assertions. Finding those assertions is especially difficult given the table design of DLDB3, where assertions are scattered into a number of tables. It is extremely expensive to scan all the tables in the knowledge base to find all the rows that use a particular id, especially if you consider that the number of tables is equal to the number of classes plus the number of properties. For this reason, We use auxiliary tables to keep track of the tables that each id appears in.
Often times, the knowledge on equality is not given explicitly. Equality could result from inferences across documents: owl:FunctionalProperty, owl:maxCardinality and owl:InverseFunctionalProperty can all be used to infer equalities. DLDB3 is able to discover equality on individuals using a simple approach. If two URIs have the same value for an owl:InverseFunctionalProperty, they are regarded as representing the same individual. A naive approach is to test for this event every time a value is inserted into an inverse functional property table. However, this requires a large number of queries and potentially a large number of update operations. In order to improve the throughput of loading, we developed a more sophisticated approach which queries the inverse functional property table periodically during the load. This happens after a certain number of triples have been loaded into the system. The specific interval is specified by users based upon their application requirements and hardware configurations (we used 1.5 million in our experiment). This approach not only reduces the number of database operations, but also speeds up the executions by bundling a number of database operations as a stored procedure. DLDB3 also supports the same approach on owl:FunctionalProperty. 4.3
Although Algorithm 1 deals with cyclic axioms in general, our implementation handles two categories differently. Class and Property Equalities is a form of cyclic axioms. However, they do not need fix point computation in our algorithm since they are solved during the atom expansion process. The fundamental difference between these equalities and other forms of cyclic axioms such as the transitive property is that they do not involve self-joinings or iterative procedures. They simply require that we synchronize the subsumptions between two equivalent terms. For named classes and properties, this synchronization has been taken care of by the DL reasoner.
In actual implementation, transitive properties are obvious cyclic axioms and hence they do not need to be identified by translating into FOL rules. Our solution is to periodically run an algorithm that self-joins the view (not the table) on the transitive property iteratively until a fixed point is reached. This algorithm also takes care of the perspectives, which allows different ontologies to independently describe a property as transitive or not. The other forms of cyclic axioms are handled by repeating iterations until no new tuples are generated. For new tuples generated during the iterations, their ’onto’ field is set to the value of the ontology that invokes this round of fix point computation (as shown in Algorithm 2). 4.4
Normally, DHL allows universal restrictions on the right hand side. Domain and range axioms are both special cases of universal restriction (( " ∀P.C and ( " ∀P −.C, respectively). The reasoning algorithm would include such rules and their corresponding SQL expressions in the view definition of classes. Our initial implementation experience shows this kind of axioms can lead to efficiency issues at query time. In particular, when the property involved has many triples, this leads to inference of class membership for a large number of instances. However, since OWL-DL requires that every instance has a type, these inferences are possibly redundant with explicit information on the knowledge base. Note, explicit universal restrictions that involve specific classes on the left hand side usually are not as bad as domain and range, simply because the join would reduce the number of facts that need to be compared with existing facts.
In order to improve the query efficiency, DLDB3 handles domain and range axioms at load time. Following the same translation method that translate the Horn rules into SQL expressions, we execute these expressions periodically during load time and effectively materialize the new facts into the corresponding tables. Then at query time, there is no need to invoke the inferences for domain and range axioms. Our initial analysis has shown that this special treatment for domain and range axioms can improve the overall performance of the system, considering the same domain or range class could be queried over and over. Note this special handling would not alter the soundness and completeness of the reasoning algorithm. 4.5
The query API of DLDB3 currently supports SPARQL encodings of conjunctive queries as defined in section 2. During execution, predicates and variables in the query are substituted by table names and field names through translation. Depending on the perspective being selected, the table names are further substituted by corresponding database view names. Finally, a standard SQL query sentence is formed and sent to the database via JDBC. Then the RDBMS processes the SQL query and returns appropriate results.
Since we build the class and property hierarchy when loading the ontology, there is no need to call the DL reasoner at query time. The results returned by the RDBMS can be directly served as the answer to the original query. We think this approach makes the query answering system much more efficient than conducting DL reasoning at query time. To improve the query performance. DLDB3 system independently maintains indexes without the intervention from database administrators. 5
The C-OWL work [
Our work differs from deciding the conservative extensions [
In order to improve the scalability of ABox reasoning, a number of “tractable
fragments” of OWL have been proposed and studied. Compare to DHL, DL-Lite [
In recent years there has been a growing interest in the development of systems that
will store and process large amount of Semantic Web data. The general design goal of
these systems is often similar to ours, in the sense that they use some database systems
to gain scalability while supporting as much inference as possible by processing and
storing entailments. However, most of these systems emphasize RDF and RDF(S) data
at the expense of OWL reasoning. Some systems resemble the capabilities of DLDB3,
such as KAON2 [
We evaluated DLDB3 using LUBM [
Note UOBM only provides datasets in four sizes and has no publicly available data generator. The largest dataset, UOBM-30 has 6.6 million triples. In our experiment, DLDB3 can load 130 million triples from LUBM(1000,0) with 24 hours and be complete on all the queries in LUBM.
The smaller diagram on Figure 1 shows the load time of KAON2 and SwiftOWLim on UOBM. These two systems are memory based so that they are fast at loading. However, their scalability are limited by the memory size. KAON2 could not finish reasoning on UOBM-10 in our experiment. SHER, SOR and DLDB3 all use a backend RDBMS and hence would scale better than memory based systems. DLDB3 is faster on loading than SOR and SHER. It is reasonable for SOR since it materializes all inferred facts at load time. For reasons that we cannot explain, SHER failed to load datasets larger than UOBM-5. SOR did not finish the loading of UOBM-30 within a 72 hours period in our experiment.
Figure 2 shows the average query response time (average on 14 queries) for all systems on UOBM. DLDB3 is faster than KAON2 and SHER on all datasets, and keeps up with SwiftOWLim as the size of the knowledge base increases. The standard deviation on query response times gives no surprise: DLDB3 has higher variation than SwiftOWLim. For DLDB3, all the queries can be finished under 4 minutes across the datasets.
As shown in Table 2, DLDB3 is complete on 11 out of the 14 queries in UOBM. Two of the queries (Q12 and Q14) are not complete due to cardinalities. Another query (Q13) involves inference using negation. SwiftOWLim is incomplete on only one query (Q13); SOR is incomplete on two queries (Q12 and Q14) and SHER is only complete on 6 queries.
Q1 - Q11 Q12 Q13 Q14
DLDB3 100% 80% 96% 0%
SOR 100% 63% 100% 63%
SwiftOWLim 100% 100% 96% 100%
Both LUBM and UOBM only have a single ontology in their test dataset, which means
they cannot be used to test the system’s capability on data integration. In addition,
both benchmark ontologies contain no cycles besides transitive properties. In order to
empirically validate our implementation on perspectives and cyclic axiom handling, we
used a synthetic data generator to generate a multi-ontology test dataset. The details
about the data generator is described in [
The experiment set-up was the same as the UOBM benchmark described above. KAON2 and DLDB3 were tested using this multi-ontology dataset. Since KAON2 is proved to be sound and complete on DHL, the results of KAON2 is used as reference. In order to verify the correctness of DLDB3, each test queries was issued using different perspectives. For a query #O, ρ$, the reference result sets were collected by loading the ontologies and data sources that are included in the perspective model based on O (see definition 2) into KAON2, and then issue the conjunctive query ρ to KAON2.
All the query results from DLDB3 match the references from KAON2. This experiment has shown that DLDB3 is sound and complete w.r.t the logical consequences defined in section 2, and correctly implements the algorithm that handles cyclic axioms.
We also did some initial analysis on the scalability of the perspective approach. Figure 3 shows that as the number of ontologies included (though mappping) in the perspective increases, the query response time would increase. However, more ontologies bring more results to the query, which at large extent justifies the increase of response time.
Fig. 3. Number of Ontologies V.S. Avg. Number of Query Results
On the other hand, as shown in Figure 4 the depth of the mapping (the maximum length of the mapping chain from the query term to the term that data commits to) only has small impact on the query response time. Again, when compared with the number of results, the increase of query response time is justified. Overall, we have seen that the
Fig. 4. Depth of Mapping V.S. Avg. Number of Query Results query performance of DLDB3 would degrade gracefully as the depth or breadth of the perspective increases, but largely due to the gaining of new results through integration. 7
In this paper we present our DLDB3 system, which takes advantage of the scalability of relational databases and the inference capability of description logic reasoners. Our scalable querying answering algorithm is guaranteed to be sound and complete on DHL. Our evaluation shows that DLDB3 scales well both in load and query comparing to other systems. It has achieved a good balance between scalability and query completeness. Based on ontology perspectives which use existing language constructs, DLDB3 can support queries from different view points. Real-world data using multiple ontologies and realistic queries show that DLDB3 has achieved this capability without any significant performance degradation.
Although we believe our work is a first step in the right direction, we have discovered many issues that remain unsolved. First, to ensure the freshness of data, we plan to support efficient updates on documents. Second, we will investigate query optimization techniques that can improve the query response time. Third, we will evaluate our system’s capability on perspectives more extensively and comprehensively using real-world datasets. 8
This material is based upon work supported by the National Science Foundation (NSF) under Grant No. IIS-0346963. The authors would like to thank Tim Finnin of UMBC for providing access to the Swoogle’s index of URLs. Graduate students Abir Qasem also contributed to the evaluations in this paper.