I've expected that the framework does not allow constructing invalid queries -
sorry for bug suspicion then ;)
I've debugged my script in Eclipse and inspected the structure of the correct
query in order to rewrite my code. There were two problems - I had an
ElementNamedGraph as a top element of a query but there has to be an
ElementGroup around it (this resolved differences in dots after triple
patterns.); and mainly I've used NodeValueNode instead of ExprVar by mistake in
one place.
BTW what is the difference between ElementPathBlock and ElementTriplesBlock ?
Is it that in the former it is possible to use property paths when using SPARQL
1.1 ?
Thanks for pointing me towards the problem.
Regards,
Svatopluk Šperka
On Aug 6, 2011, at 10:04 PM, Andy Seaborne wrote:
> What's queryFor( sg )?
>
> It is possible to construct, programmatically, bad queries. These might
> result in legal strings (but a different query).
>
> Scala's fine but please provide a complete, minimal example.
>
> TDB has an in-memory version for easy testing. It uses all the TDb
> machinery, just has RAM-based disk storage (and it's slow - it copies a lot
> to get true semantics).
>
> The dots don't change the semantics but if you see them after Query.toString,
> then you proably have a constructed query that is bad.
>
> Andy
>
>
>
> On 05/08/11 18:33, Svatopluk Šperka wrote:
>> Hi,
>>
>> I am using Jena's TDB as a storage for data from my analysis. I use
>> jena.update.GraphStore to access it because I have to modify contained quads
>> beside adding them. Now, I have this problem that I need to find a graph in
>> TDB with a query that is built by using constructs from jena.sparql.syntax.
>> But I can't.
>>
>> The curious and important fact is that if I take that constructed query and
>> transform it into a string and create a new query object from this string,
>> it works. The following code does not show that exactly - I've assigned the
>> value of query.toString from previous run to the variable query1.
>>
>>
>> In scala it looks like this:
>>
>> println( graphStore.toString )
>>
>> val query = queryFor( sg ) // this constructs a query by using
>> jena.sparql.syntax
>> val query1 = QueryFactory.create( "SELECT ?g WHERE { GRAPH ?g {
>> ?v1<http://t.st#p1> ?v2 . FILTER notexists {?s ?p ?o . FILTER ( ( ?s !=
>> ?v1 ) || ( ( ?p !=<http://t.st#p1> ) || ( ?o != ?v2 ) ) ) } }}" ) // the
>> exact same query created from string
>>
>> println( "query:\n"+query.toString( jena.query.Syntax.syntaxSPARQL_11 ) )
>> println( query1.toString( jena.query.Syntax.syntaxSPARQL_11 ) )
>>
>> val plan = QueryExecutionFactory.createPlan( query, graphStore )
>> val plan1 = QueryExecutionFactory.createPlan( query1, graphStore )
>>
>> val result = plan.iterator
>> val result1 = plan1.iterator
>>
>> println("hasNext built query: "+result.hasNext+" from-string query: "+
>> result1.hasNext )
>>
>>
>>
>>
>>
>> Output of this part of the script when run:
>>
>> // contents of the graphStore
>> (dataset
>> (graph
>> (triple<http://fit.vutbr.cz/qa#g-1> <http://fit.vutbr.cz/qa#t> 1)
>> )
>> (graph<http://fit.vutbr.cz/qa#g-1>
>> (triple _:-5e688aa4:1319ac49d09:-7ffe<http://t.st#p1>
>> _:-5e688aa4:1319ac49d09:-7ffd)
>> ))
>>
>> // string representation of built query
>> query:
>> SELECT ?g
>> WHERE
>> { GRAPH ?g
>> { ?v1<http://t.st#p1> ?v2 .
>> FILTER notexists {?s ?p ?o .
>> FILTER ( ( ?s != ?v1 ) || ( ( ?p !=<http://t.st#p1> ) || ( ?o !=
>> ?v2 ) ) )
>> }
>> }}
>>
>> // string representation of from-string query (dots after triple patterns
>> are missing … ? )
>> SELECT ?g
>> WHERE
>> { GRAPH ?g
>> { ?v1<http://t.st#p1> ?v2
>> FILTER notexists {?s ?p ?o
>> FILTER ( ( ?s != ?v1 ) || ( ( ?p !=<http://t.st#p1> ) || ( ?o !=
>> ?v2 ) ) )
>> }
>> }
>> }
>>
>> hasNext built query: false from-string query: true // built query has not
>> found a match, from-string query has
>>
>>
>>
>> Right now, I'm sidestepping the problem by doing QueryFactory.create(
>> queryFor( sg ).toString( jena.query.Syntax.syntaxSPARQL_11 ) ), i.e. by
>> converting a query to string and back to query - and it works. That shows
>> that there is a problem somewhere in the jena.sparql.syntax, probably.
>>
>> If there is a better way to programmatically construct queries, please give
>> me a clue. However, I would like to avoid algebra because it's kind
>> difficult for me to imagine complex queries in it - but if there is not
>> another way then I will fight ;)
>>
>> Anyway, I'm pretty sure that there's a bug somewhere and I'm definitely not
>> satisfied with the current solution so I'll be more than happy to help (but
>> I can't provide the whole source code).
>>
>>
>> Thank you very much in advance !
>>
>>
>>
>> Regards,
>>
>> Svatopluk Šperka
>>
>>
