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.