Stardog Reasoner for Jena interface

[Jacobus Geluk]

Hi, I am using the Jena API's of Stardog and am getting unexpected results with a query that works from the command line. It seems that the QL reasoner that I configured with the ConnectionConfiguration class, which is set before doing the connect, does not work.

Do I need to use the Jena classes ReasonerFactory, ReasonerRegistry and so forth to make this work?

Is there an example?

Cheers

Jacobus

[Mike Grove]

On Tue, Dec 18, 2012 at 11:36 AM, Jacobus Geluk <jacobu...@refinery29.com> wrote:

Hi, I am using the Jena API's of Stardog and am getting unexpected results with a query that works from the command line. It seems that the QL reasoner that I configured with the ConnectionConfiguration class, which is set before doing the connect, does not work.

Do I need to use the Jena classes ReasonerFactory, ReasonerRegistry and so forth to make this work?

No.

 

Is there an example?

There is an example of executing queries with Stardog via the Jena API included in the distribution.  It does not show performing queries with a connection configured for reasoning, however, as long as the Connection is configured correctly, it should work with or without reasoning. 

Can you provide the code, data, and query you are using that displays the issue?

Cheers,

Mike

 

Cheers

Jacobus

--
-- --
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
 
 

[Jacobus Geluk]

This is the query that works, as executed from the command line:

SELECT DISTINCT

        ?mainTopic ?relatedTopic

WHERE {

        ?url

                a fo-site-abstract:URL ;

                skos:prefLabel "/hunger-games" ;

                fo-site-abstract:hasTopic ?mainTopic

        .

        OPTIONAL {

                ?mainTopic fo-site-abstract:hasTopic* | ^fo-site-abstract:hasTopic* ?relatedTopic .

                ?relatedTopic a fo-publisher:Topic .

                FILTER(?mainTopic != ?relatedTopic && ?relatedTopic != ?url)

        }

}

+---------------------------------+--------------------------------------------------+

|            mainTopic            |                   relatedTopic                   |

+---------------------------------+--------------------------------------------------+

| r29:Story-Book-The_Hunger_Games | r29:ProductDomain-Katniss_Side_Braids            |

| r29:Story-Book-The_Hunger_Games | r29:Event-The_Hunger_Games                       |

| r29:Story-Book-The_Hunger_Games | r29:Story-Movie-The_Hunger_Games                 |

| r29:Story-Book-The_Hunger_Games | r29:Story-BlogArticle-Hunger_Games_Katniss_Braid |

| r29:Story-Book-The_Hunger_Games | r29:Writer-Suzanne_Collins                       |

| r29:Story-Book-The_Hunger_Games | r29:Trend-Wearing_Braids                         |

+---------------------------------+--------------------------------------------------+

This is the result page of the same query executed from our code:

----------------------------------------------------------------
| mainTopic                       | relatedTopic               |
================================================================
| r29:Story-Book-The_Hunger_Games | r29:Writer-Suzanne_Collins |
----------------------------------------------------------------

The Connection definitely has reasoning configured. I was also thinking that i could perhaps be related to the special characters in the SPARQL path expression that I am using (^ and/or *)? Perhaps those characters are not passed through somewhere? It's the same database, same connection string, same query byte for byte.

[Jacobus Geluk]

I am also saying that because the row that was found, the writer, is only one hop away from the main topic, so it would be found even without the *-operator.

[Mike Grove]

I am happy to look into this if you can provide the code & data to reproduce.  If either are sensitive, please feel free to send them to me privately.

A simple modification of the JenaIntegration example to use QL reasoning with the same data & query as ReasoningExample (both from the examples/ in the distribution) yields the behavior I expect.  So reasoning with Stardog via Jena works.

Given the nature of your query, it's not likely I can work backwards from that to re-create the conditions to observe the behavior you are reporting.  But you should get the same results for a query against Stardog regardless of the API, so this is something I'd like to track down, whether it's an issue in the Jena bindings or an area in need of more documentation.

Cheers,

Mike

--

[Jacobus Geluk]

That will take some time as I have to isolate the problem and reproduce it then. Will keep you posted.

[Jacobus Geluk]

Ok, I mailed a test case to you. By the way, one other comment: why are the stored prefix/namespace combinations only working on the command line? If  I use "stardog namespace add" then I can leave out the PREFIX lines from my queries on the command line, but not when I execute the same query through the API.

[Mike Grove]

So I've managed to track this down, and there's a couple things to point out.

First, this has nothing to do w/ reasoning in Stardog via Jena.  Two, I think 1 result is the correct result.

What is happening is the property path in your query:

?mainTopic fo-site-abstract:hasTopic* | ^fo-site-abstract:hasTopic* ?relatedTopic .

is that ARQ, which handles the parsing when using Jena, interprets this (correctly) as:

?mainTopic (fo-site-abstract:hasTopic)* | ^(fo-site-abstract:hasTopic)* ?relatedTopic .

Which translates to this algebra:

(path ?mainTopic (alt (path* fo-site-abstract:hasTopic) (reverse (path* fo-site-abstract:hasTopic))) ?relatedTopic)

This is the algebra I would expect for that path.   Executing that algebra via Jena (native), Jena+Stardog, Stardog directly all yield the same, single result. 

I have opened an issue against Sesame's query parser that it is mis-handling the query when the clarifying parenthesis are not present.  When that is resolved, you'll get the same answers from Stardog regardless of which parser was used to send the algebra to our query engine.

Cheers,

Mike

[Jacobus Geluk]

Impressive. Thanks so much for figuring this out. When I add the parenthesis to the command-line SPARQL query and that gives 1 result indeed. But then I don't understand yet why I only get one result and not the expected 6 results, I thought the buggy version was the correct result. Will try to figure 

it out, it's my lack of experience with SPARQL I guess. Thanks so much.

Jacobus Geluk

Semantic Data Architect 

R29 is Hiring!  

30 Cooper Square, 4th Floor  

New York, NY 10003

NY Office 212.966.3112 | Mobile 347.293.9437 | Fax 212.966.3144

Sign Up  |  Follow Us  |  Like Us  |   Shop Refinery29