 |
 |
On Tue, May 29, 2012 at 4:22 PM, Ravi Shankar <[log in to unmask]> wrote: We were currently leaning towards open-source triple stores. As far as > inferencing goes, I suspect we will be doing at least transitive closures > on rdfs:subClassOf and rdfs:subPropertyOf properties. I will look into > TinkerPop. Are you currently using it, and for what purpose? I am also > curious about what types of data model changes did you have to do to > improve your rdf store's performance. > There are some interesting results on implementing these entailments for Quest - http://obda.inf.unibz.it/protege-plugin/quest/quest.html See: http://www.inf.unibz.it/~calvanese/papers/rodr-calv-KR-2012.pdf They use pre-processing of the T-box to assign a numeric id to each class, then compute which ranges correspond to all the subclasses of a particular class. The benchmarking is rather preliminary, and the LUBM results are mixed, but the one result that that they give for an experiment on data from from *Resource Index* is interesting. The RI dataset uses the hierarchical data from a large number of biomedical ontologies and uses text minding to associate classes from those ontologies with documents from a corpus. The quest experiment used as subset of this data (clinicaltrials.gov). The ontologies had 3 million concepts and 2.5 million sub-class assertions. The annotation process generates a very large volume of data. For the resource used in this experiment, the Clinical Trials.gov (CT) collection, the annotation process generates 181 million ABox assertions (i.e., data triples), corresponding to 14 GB of data Note that given the limited expressivity of the TBox used by this application, we can avoid query reformulation w.r.t. the TBox by storing data using a Semantic Index. We stored the data in a DB2 9.7 DB hosted in a Linux virtual machine with 4x2.67 Ghz Intel Xeon processors (only one core was used) and 4 GB of RAM available to DB2. We issued several queries, the one we describe here is q(x) <- DNA Repair Gene(x)^Antigen Gene(x)^Cancer Gene(x). The selectivity of the query is high, returning a total of 2 distinct resources. The performance of each technique is as follows: (a) when rewriting w.r.t. T in CNF form the result is one SQL query with 467874 disjuncts, when rewriting in DNF (as UCQ-based rewriters do), the result is a union of 467874 SPJ queries; none of these queries is executable by DB2 with our system setup; (b) when we rewrite the query using the Semantic Index technique, the result is a single SQL query involving 3 range disjunctions; the query requires 3.582s to execute (0.082s if the DB is warm, e.g., the indexes have been preloaded); the time required to compute the semantic index is 27s; the size of the semantic index 4 GB; (c) if the ABox is expanded and we execute the original query, the execution requires 3 s (0 s if warm). With respect to the cost of the expansion, LePendu et al. indicate that a straightforward expansion of the CT resource requires 7 days, and generates 140 GB of data and, after a careful optimization of the process (including data partitioning, parallelization, etc.) this time can be reduced to 40 minutes. Given these results, we believe that the Semantic Index is possibly a better option than data expansion, due to the drastic cost of the latter. Moreover, it scales to dimensions in which pure query reformulation may be impossible.