Legend:

SparQL (and VSparQL) are RDF query languages. As such the statements available to the query engine must either be explicit in the original graph, or an inference process must produce the additional facts implied by the explicit statements. This inference process could be done by a description logic reasoner (or similar mechanism), and the implicit facts added to the queryable data source before the query is run, or the query itself could be written to do its own reasoning. Naturally there are pros and cons of each approach:

8

SparQL (and VSparQL) are RDF query languages. OWL graphs frequently contain logical implications not explicitly represented in the serialized RDF graph (no "fma:Heart hasMass True", this can be inferred as it is a property of a superclass). The statements available to a (V)SparQL query engine must either be explicit in the original graph, or an inference process must produce the additional facts implied by the explicit statements. This inference process could be done by a description logic reasoner (or similar mechanism), and the implicit facts added to the queryable data source before the query is run, or the query itself could be written to do its own reasoning. Naturally there are pros and cons of each approach:

9

9

10

10

* '''Using a DL reasoner:''' The main pro of using a DL reasoner is that it was researched, built, and refined for doing just this operation (inferring logical entailments). All of the rules for doing such logical inference are already encoded and efficiently implemented. A reasoner is likely to be both fast and correct at performing this task. The main con is that the reasoner figures out all logical entailments. Even though this step can be done off-line, when the query service is being initialized, this can still be a resource intensive operation. Many of the entailments may be irrelevant to a particular query.