Re: Re: Weird sparql problem

On Tue, 2022-11-15 at 13:13 +0200, Mikael Pesonen wrote: > For example this also hangs (or is slow) > > (?lit) text:query (skosxl:literalForm  "\"fever\"" "lang:en" ) . > ?c skosxl:prefLabel|altLabel [skosxl:literalForm ?lit] you can check if https://github.com/apache/jena/pull/1616 helps for thi

Re: Weird sparql problem

ttnxyg0kvq69p [2]: http://daslab.seas.harvard.edu/reading-group/papers/volcano.pdf From: Mikael Pesonen Date: Tuesday, 8 November 2022 at 11:04 To: users@jena.apache.org Subject: Re: Weird sparql problem Both your suggestions for rewriting the query worked. I'm lost with the reasons, but for f

Re: Weird sparql problem

at 11:04 To: users@jena.apache.org Subject: Re: Weird sparql problem Both your suggestions for rewriting the query worked. I'm lost with the reasons, but for future cases, breaking problematic queries with {} is they way to go? On 04/11/2022 11.25, rve...@dotnetrdf.org wrote: > So yes as s

Re: Re: Weird sparql problem

code . ?c    skosxl:prefLabel  _:b0 .     FILTER EXISTS {  ?c    skos:inScheme lsu:SNOMEDCT_US }    } Hope this helps, Rob From: Lorenz Buehmann Date: Thursday, 3 November 2022 at 11:12 To: users@jena.apache.org Subject: Re: Re: Weird sparql problem tdbquery --explain --loc  $TDB_LOC 

Re: Re: Weird sparql problem

optimiser making a bad guess at the appropriate order in which to evaluate the triple patterns within the BGP but without the larger query context or the algebra all we can do is guess. Rob From: Mikael Pesonen Date: Tuesday, 1 November 2022 at 12:53 To: users@jena.apache.org Subject: Re: W

Re: Weird sparql problem

{ "298314008" } _:b0 lsu:code ?sct_code . ?cskosxl:prefLabel _:b0 . FILTER EXISTS { ?cskos:inScheme lsu:SNOMEDCT_US } } Hope this helps, Rob From: Lorenz Buehmann Date: Thursday, 3 November 2022 at 11:12 To: users@jena.apache.org Subject: Re

Re: Weird sparql problem

the larger query context or the algebra all we can do is guess. Rob From: Mikael Pesonen Date: Tuesday, 1 November 2022 at 12:53 To: users@jena.apache.org Subject: Re: Weird sparql problem Diferent case, but again hanging makes no sense to user, whatever are the technical reasons.    VAL

Re: Re: Weird sparql problem

vember 2022 at 11:12 To: users@jena.apache.org Subject: Re: Re: Weird sparql problem tdbquery --explain --loc $TDB_LOC "query here" would also work to see the plan - maybe also increase log level to see more: https://jena.apache.org/documentation/tdb/optimizer.html Another question, d

Re: Re: Weird sparql problem

iate order in which to evaluate the triple patterns within the BGP but without the larger query context or the algebra all we can do is guess. Rob From: Mikael Pesonen Date: Tuesday, 1 November 2022 at 12:53 To: users@jena.apache.org Subject: Re: Weird sparql problem Diferent case, but again h

Re: Weird sparql problem

suggests this may be the optimiser making a bad guess at the appropriate order in which to evaluate the triple patterns within the BGP but without the larger query context or the algebra all we can do is guess. Rob From: Mikael Pesonen Date: Tuesday, 1 November 2022 at 12:53 To: users@jena.apach

Re: Weird sparql problem

From: Mikael Pesonen Date: Tuesday, 1 November 2022 at 12:53 To: users@jena.apache.org Subject: Re: Weird sparql problem Diferent case, but again hanging makes no sense to user, whatever are the technical reasons. VALUES ?sct_code { "298314008" } ?c skosxl:prefLabel [ lsu:code

Re: Weird sparql problem

On 02/11/2022 07:35, Lorenz Buehmann wrote: I think if you use BIND( "298314008" AS ?sct_code ) it would work for the second query? Looks the the query optimizer does the join in wrong order @Andy? May be. may be now - no way to tell from the report. We don't know what the data looks li

Re: Weird sparql problem

@jena.apache.org Subject: Re: Weird sparql problem Diferent case, but again hanging makes no sense to user, whatever are the technical reasons. VALUES ?sct_code { "298314008" } ?c skosxl:prefLabel [ lsu:code ?sct_code ] returns one row immediately, but VALUES ?sct_code { "2983

Re: Weird sparql problem

BIND( "298314008" AS ?sct_code )    ?c skosxl:prefLabel [ lsu:code ?sct_code ]; skos:inScheme lsu:SNOMEDCT_US takes a long time also, about 8 minutes (all previous are also slow but finish) On 02/11/2022 9.35, Lorenz Buehmann wrote: I think if you use BIND( "298314008" AS ?sct_code ) it

Re: Re: Weird sparql problem

I think if you use BIND( "298314008" AS ?sct_code ) it would work for the second query? Looks the the query optimizer does the join in wrong order @Andy? On 01.11.22 13:52, Mikael Pesonen wrote: Diferent case, but again hanging makes no sense to user, whatever are the technical reasons.  V

Re: Weird sparql problem

Diferent case, but again hanging makes no sense to user, whatever are the technical reasons.  VALUES ?sct_code { "298314008" }    ?c skosxl:prefLabel [ lsu:code ?sct_code ] returns one row immediately, but  VALUES ?sct_code { "298314008" }    ?c skosxl:prefLabel [ lsu:code ?sct_code ]; skos:in

Re: Re: Weird sparql problem

Hi, comments inline On 17.10.22 14:35, Mikael Pesonen wrote: This works as a separate query, but not in a the middle, since ?s gets new values instead of binding to previous ?s. { select ?t where { ?s a ?t .  } limit 10}   ?t skos:prefLabel ?l In the middle of what? Subqueries will be eval

Re: Weird sparql problem

This works as a separate query, but not in a the middle, since ?s gets new values instead of binding to previous ?s. { select ?t where { ?s a ?t .  } limit 10}   ?t skos:prefLabel ?l On 17/10/2022 14.56, Mikael Pesonen wrote: ?s a ?t .   ?t skos:prefLabel ?l returns 3 million triples. Maybe

Re: Weird sparql problem

?s a ?t .   ?t skos:prefLabel ?l returns 3 million triples. Maybe it's related to this? On 21/09/2022 9.15, Lorenz Buehmann wrote: Weird, only 10M triples and each triple pattern returns only 1 binding, thus, the size is tiny - honestly I can't think of anything except for open connections,

Re: Weird sparql problem

Fresh start of the server didn't help. I'll try in a fresh 4.6.1 install in few days. BR On 21/09/2022 9.15, Lorenz Buehmann wrote: Weird, only 10M triples and each triple pattern returns only 1 binding, thus, the size is tiny - honestly I can't think of anything except for open connection

Re: Re: Weird sparql problem

Weird, only 10M triples and each triple pattern returns only 1 binding, thus, the size is tiny - honestly I can't think of anything except for open connections, but as you mentioned, running the queries with only one triple pattern works as expected, so that too many open connections shouldn't

Re: Weird sparql problem

On 15/09/2022 17.48, Lorenz Buehmann wrote: Forgot: - size of result for each triple pattern? Might affect if hash join can be used. It's one row for each. - your hardware? Normal server with 16gigs mem. - is it just the first query after starting Fuseki? Connections have been closed?

Re: Weird sparql problem

Hi, thanks for looking into this. On 15/09/2022 17.44, Lorenz Buehmann wrote: Fuseki with in-memory backend or TDB? TDB2. Which version? 4.3.2 How large is the dataset? Not that I see how this simple query with a single join should lead to a timeout, but any numbers are usually helpful

Re: Weird sparql problem

Forgot: - size of result for each triple pattern? Might affect if hash join can be used. - your hardware? - is it just the first query after starting Fuseki? Connections have been closed? Note, there was also a bug in a recent Jena version, but only with TDB and too many open connections. I

Re: Weird sparql problem

Fuseki with in-memory backend or TDB? Which version? How large is the dataset? Not that I see how this simple query with a single join should lead to a timeout, but any numbers are usually helpful. Did you try the query without defining the default graph but using a graph pattern, i.e. SEL

Weird sparql problem

This returns one row fast, say :C1 SELECT * FROM WHERE {   a ?t .   #?t skos:prefLabel ?l } and this too: SELECT * FROM WHERE {   # a ?t .   :C1 skos:prefLabel ?l } But this always hangs until timeout SELECT * FROM

Re: sparql problem

General comment: it is a good idea to validate the data before trying to load the data. If there is an error in the data a long way into the file, the bulk loader has already been domign some wokr so i So if the data can have errors, it is useful to do a check by reading it with "riot" first b

Re: sparql problem

As the error message indicates, white spaces are not allowed in IRIs - you have to percent encode white spaces On 18.12.20 04:55, Murphy wrote: > 11:39:07 ERROR riot:: [line: 2415, col: 40] Bad character in IRI > (space): > org.apache.

Re:Re: sparql problem

hi，I have configured the latest version jena and fusekiboth are 3.17.0 as required as you said, but the following problems had arisen： 1. I run the conmand： >tdbloader.bat --loc="D:\ZhouProgram\jena\tdb" >"D:\ZhouProgram\jena\ttl\kgdata.ttl"d it shows: 11:39:06 INFO

Re: sparql problem

Hi there, > apache-jena-fuseki-3.5.0 That's quite old - the current version is 3.17.0 Upgrading would be a good idea just in case. Are there any messages in the server log file? It is going to be difficult to pin down an encoding issue (if that is what it is) because by the time we get this

sparql problem

Hello, when I query in Fuseki like this: PREFIX : SELECT * WHERE { ?s ?p ?o. } #query1 It can return the many results ,one of the results is: :口腔毛滴虫病rdf:type:症状 when I query like this: PREFIX : SELECT * WHE

Re: SPARQL problem

On 02/10/13 17:44, Michael Brunnbauer wrote: Hello Andy, On Wed, Oct 02, 2013 at 05:18:24PM +0100, Andy Seaborne wrote: Could you raise a JIRA please so this does not get lost? https://issues.apache.org/jira/browse/JENA-553 I guess it is OK if I go to JIRA directly in the future without pos

Re: SPARQL problem

Hello Andy, On Wed, Oct 02, 2013 at 05:18:24PM +0100, Andy Seaborne wrote: > Could you raise a JIRA please so this does not get lost? https://issues.apache.org/jira/browse/JENA-553 I guess it is OK if I go to JIRA directly in the future without posting to the list ? Regards, Michael Brunnbaue

Re: SPARQL problem

Could you raise a JIRA please so this does not get lost? Thanks Andy On 02/10/13 13:33, Michael Brunnbauer wrote: Hello Andy, On Mon, Sep 30, 2013 at 12:33:57PM +0100, Andy Seaborne wrote: http://www.brunni.de/sparql_turing_machine.txt http://www.brunni.de/searchsparqlendpoints.txt

Re: SPARQL problem

Hello Andy, On Mon, Sep 30, 2013 at 12:33:57PM +0100, Andy Seaborne wrote: > >http://www.brunni.de/sparql_turing_machine.txt > >http://www.brunni.de/searchsparqlendpoints.txt Those queries do not work any more after updating from Fuseki 0.2.5 to 1.0.0. It seems to be related to the WITH keyword

Re: SPARQL problem

On 29/09/13 19:13, Michael Brunnbauer wrote: Hello Andy, On Sat, Sep 28, 2013 at 09:02:04PM +0100, Andy Seaborne wrote: ?ep a void:sparqlEndpoint SERVICE SILENT ?ep { ... then ?ep is not bound if the federation fails. That a failure causes a match with unbound variables is expected but th

Re: SPARQL problem

Hello Andy, On Sat, Sep 28, 2013 at 09:02:04PM +0100, Andy Seaborne wrote: > > ?ep a void:sparqlEndpoint > > SERVICE SILENT ?ep { ... > > > >then ?ep is not bound if the federation fails. That a failure causes a > >match > >with unbound variables is expected but that ?ep is also unbound in thi

Re: SPARQL problem

On 28/09/13 14:42, Michael Brunnbauer wrote: Hello Andy, On Sat, Sep 28, 2013 at 11:12:28AM +0100, Andy Seaborne wrote: Inner part: BIND ('X' as ?ep) This is evaluated separately because BIND ends the graph pattern ? Another question: If I do something like ?ep a void:sparqlEndpoint SE

Re: SPARQL problem

Hello Andy, On Sat, Sep 28, 2013 at 11:12:28AM +0100, Andy Seaborne wrote: > Inner part: > BIND ('X' as ?ep) This is evaluated separately because BIND ends the graph pattern ? Another question: If I do something like ?ep a void:sparqlEndpoint SERVICE SILENT ?ep { ... then ?ep is not bound i

Re: SPARQL problem

On 28/09/13 09:58, Michael Brunnbauer wrote: hi all I wonder if something is wrong with this query or with Fuseki 0.2.5. All variables except ep2 are bound in the result: Yes - that's what I expect. select ?ep ?ep2 ?s ?p ?o where { BIND ('X' as ?ep) { select (?ep as ?ep2) ?s ?p ?o wh

SPARQL problem

hi all I wonder if something is wrong with this query or with Fuseki 0.2.5. All variables except ep2 are bound in the result: select ?ep ?ep2 ?s ?p ?o where { BIND ('X' as ?ep) { select (?ep as ?ep2) ?s ?p ?o where { ?s ?p ?o } limit 1 } } I tried it also with BIND (?ep as ?ep2) instead of