Re: [Tracker] Basic Reasoning

[Ivan Frade <ivan frade gmail com>]

Hi Anatoly,

On Mon, Jun 10, 2013 at 3:56 PM, אנטולי קרסנר <tombackton gmail com> wrote:

Hello Tracker team,

I'm writing software which needs to be able to do queries over the data
it generates. It needs to be able to test all the RDF data entered to
the database, including inferred data.

 Tracker is just as store and doesn't have any reasoner, but it is not completely stupid:
 

For example, if class B is a subclass of A, then I need the query
resolver to be able to detect that "subClassOf" is inverse of
"superClassOf"

  It understands subclasses. In this case, for example, asking for instances of A return instances of A and B.
 

and answer queries like "which subclasses does A have".

 Yes, that query is easy, the information is in the ontology but ONLY for direct subclasses, no transitivity.

 

And also for transitive relations, if the relation is A->B->C->D, be
able to detect that A->D.

 This is not done by Tracker. You need to manually write your queries to follow the hierarchy. Tracker doesn't add any transitivity, you need to query it explicitely.

 

Can Tracker do this reasoning? I mean, does it just store data "as is"
or it detects and understands inverse relations, transitive relations,
object types implied by relatio domain/range, etc.?

 Tracker understands those relations and can solve direct queries, but doesn't add any magic to follow transitivity. In other words, the SparQL query need to mention explicitely each relation it follows (but not the classes).

 Example:

class A with property aToB

class B with property bToC

 you can do a query like:

SELECT ?a ?c WHERE {

  ?a a A;

      aToB ?x;

      cToC ?c.
}

 Note how the properties are mentioned, but the class of ?x or ?c is not relevant.

 

If not, how can I do reasoning (necessary for user-defined queries)?

 Not sure why do you need the reasoner. What kind of queries do you want to solve? Our approach is to take the user parameters and translate it into a SparQl query. That query can be very complex but that is invisible to the user.

 For example, "Give me all possible details of a contact" is one "click" to the user, but internally is is complex query full of optionals... still is solved without a reasoner.

 Hope this has helped,

 Ivan