Can reasoning help in query performance?

[Ajay Kamble]

Problem: 

I have a query which is becoming slow (takes 1.4 seconds on average) scans two levels. Here is a piece of bigger query,

  :thing :property :propertyThing .
  :propertyThing :type 'A' .

I am interested in only those :things whose :propertyThing have some special value (let's say A, B or C). The problem is that query needs to scan close to 2 million triples.

Probable Solution:

Since this is a query that will be executed on regular basis, I want a way to first tag :propertyThings that have expected value as :specialPropertyThings and second tag :things that have :specialPropertyThings as :thingHavingSpecialProperty.

There are couple of ways to do this. We can put this in data (static) or we can use reasoning to declaratively express this and at runtime only fetch :thingsHavingSpecialProperty. Is latter approach reasonable? If it can give good performance (less than 1 second) then we could potentially use it for many other scenarios.

Reasoning, Question 1:

Is it possible to declare owl rule based on literal values? For example,

:SpecialProperty

    owl:equivalentClass

    [   rdf:type owl:Restriction ;

        owl:onProperty :type ;

        owl:someValuesFrom ('A' 'B' 'C') ] .

:ThingWithSpecialProperty

    owl:equivalentClass

        [ rdf:type owl:Restriction ;

          owl:onProperty :property ;

          owl:hasValue :SpecialProperty  ] .

Reasoning, Question 2:

How can I say in owl rule that if :ThingsWithSpecialProperty has :property that belongs to class :SpecialProperty then tag it with a class. It seems that owl:hasValue is wrong.

[Evren Sirin]

Reasoning would not magically make a query go faster in the sense that
query time reasoning would expand the original query to include
additional query patterns. The benefit is simpler queries and easier
maintenance; i.e. when you have many inferences you need to make like
this.

In certain cases reasoning would speed things up because the schema is
kept in memory so expanded query can be generated without a scan. So
if you want to retrieve the instances of class X which have subclasses
Y and Z the expanded query would include Y and Z directly (a
corresponding scan would likely fetch the results from a cache so
exact speedup you get depends on the rest of the query).

In this case, it would be helpful to see the exact query you are
trying and its plan (output of query explain command) so we can
understand better what is taking time and how it can be improved.

Best,
Evren

> --
> -- --
> You received this message because you are subscribed to the C&P "Stardog"
> group.
> To post to this group, send email to sta...@clarkparsia.com
> To unsubscribe from this group, send email to
> stardog+u...@clarkparsia.com
> For more options, visit this group at
> http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[Ajay Kamble]

Is there any way to obfuscate query plan?

-Ajay

[Michael Grove]

On Wed, Mar 2, 2016 at 3:33 AM, Ajay Kamble <ajay.ri...@gmail.com> wrote:

Is there any way to obfuscate query plan?

Sure, you can obfuscate query [1] and data [2].

Cheers,

Mike

[1] http://docs.stardog.com/man/query-obfuscate.html

[2] http://docs.stardog.com/man/data-obfuscate.html