Hi Hugh, I used the isql CLI provided by Virtuoso to run the queries and to my knowledge premature termination of query evaluation by Anytime does not apply there. (Please correct me if I am mistaken.)
Regards, Markus On 16/01/15 02:41, Hugh Williams wrote: > Hi Markus, > > I ran the query against our LOD Cloud Cache server hosting 60+billion > LOD datasets (http://lod.openlinksw.com) including the LGD datasets, > and found the query with Filter A returned 4 results as you indicated > returning immediately. Running the query with Filter B it takes > appreciably longer to run and on first execution gave a timeout error > indicating partial results would be returned, running it again it then > 2 results, on the third execution it returned 4 results same as with > Filter A . So it would appear the Virtuoso Anytime [1] [2] query > feature is coming into play and returning partial results, thus have > you tried running the query with Filter B multiple times in succession > to see if more results are returned ? see: > > http://lod.openlinksw.com/sparql?default-graph-uri=&qtxt=PREFIX+rdfs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%3E%0D%0APREFIX+ogc%3A+%3Chttp%3A%2F%2Fwww.opengis.net%2Font%2Fgeosparql%23%3E%0D%0APREFIX+geom%3A+%3Chttp%3A%2F%2Fgeovocab.org%2Fgeometry%23%3E%0D%0APREFIX+wgs%3A+%3Chttp%3A%2F%2Fwww.w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23%3E%0D%0APREFIX+lgd%3A++%3Chttp%3A%2F%2Flinkedgeodata.org%2F%3E%0D%0APREFIX+lgdo%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Fontology%2F%3E%0D%0APREFIX+lgdm%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Fmeta%2F%3E%0D%0APREFIX+lgd-tr%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Ftriplify%2F%3E%0D%0APREFIX+lgd-geo%3A+%3Chttp%3A%2F%2Flinkedgeodata.org%2Fgeometry%2F%3E%0D%0APREFIX+dcterms%3A+%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0D%0A%0D%0A%0D%0ASELECT+%3Fname%2C+%3Fwkt%2C+bif%3Ast_distance%28%3Fwkt%2C+%3Fcentroid+%29+AS+%3Fdistance%0D%0AFROM+%3Chttp%3A%2F%2Flinkedgeodata.org%3E+%7B%0D%0A+++%3Flgd+a+lgdo%3ACity%3B%0D%0A+++rdfs%3Alabel+%3Fname%3B%0D%0A+++ge om%3Ageometry+%5Bogc%3AasWKT+%3Fwkt+%5D.%0D%0A%0D%0A+++BIND+%28+bif%3Ast_point%2810.447683%2C+51.163375%29+AS+%3Fcentroid+%29%0D%0A%0D%0A+++%23+choose+one+of+the+two+lines+below%3A%0D%0A+++%23+FILTER+%28+bif%3Ast_distance%28%3Fwkt%2C+%3Fcentroid%29+%3C%3D+100+%29+%23+use+this+predicate+for+query+A%0D%0A%0D%0A+++FILTER+%28+bif%3Ast_intersects+%28%3Fwkt%2C+%3Fcentroid%2C+100%29+%29+%23+use+this+predicate+for+query+B%0D%0A%0D%0A+++FILTER+%28+langMatches%28lang%28%3Fname%29%2C+%27%27%29+%29%0D%0A+++FILTER+NOT+EXISTS+%7B+%3Flgd+a+lgdm%3AWay.+%7D%0D%0A%7D%0D%0A&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on > > or short link: > > http://bit.ly/1Cdl5rU > > [1] http://docs.openlinksw.com/virtuoso/anytimequeries.html > [2] > http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTricksAnytimeSPARQLQuery > > Best Regards > Hugh Williams > Professional Services > OpenLink Software, Inc. // http://www.openlinksw.com/ > Weblog -- http://www.openlinksw.com/blogs/ > LinkedIn -- http://www.linkedin.com/company/openlink-software/ > Twitter -- http://twitter.com/OpenLink > Google+ -- http://plus.google.com/100570109519069333827/ > Facebook -- http://www.facebook.com/OpenLinkSoftware > Universal Data Access, Integration, and Management Technology Providers > >> On 14 Jan 2015, at 17:38, Markus Ackermann >> <ackerm...@informatik.uni-leipzig.de >> <mailto:ackerm...@informatik.uni-leipzig.de>> wrote: >> >> >> Hi, >> >> testing some geospatial SPARQL queries using a build of the latest commit >> from the developt/7 branch (thus VOS OpenSource 07.10.3211)on the >> LinkedGeoData Dumps from Sep 9 2014 ([1]) I encountered unexpected >> discrepancy >> between the selectiveness of st_intersects versus giving an upper >> bound to >> the distance between points calculated using st_distance. >> >> I used the following query: >> >> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> >> PREFIX ogc: <http://www.opengis.net/ont/geosparql#> >> PREFIX geom: <http://geovocab.org/geometry#> >> PREFIX wgs: <http://www.w3.org/2003/01/geo/wgs84_pos#> >> PREFIX lgd: <http://linkedgeodata.org/> >> PREFIX lgdo: <http://linkedgeodata.org/ontology/> >> PREFIX lgdm: <http://linkedgeodata.org/meta/> >> PREFIX lgd-tr: <http://linkedgeodata.org/triplify/> >> PREFIX lgd-geo: <http://linkedgeodata.org/geometry/> >> PREFIX dcterms: <http://purl.org/dc/terms/> >> >> >> SELECT ?name, ?wkt, bif:st_distance(?wkt, ?centroid ) AS ?distance >> FROM <http://linkedgeodata.org> { >> ?lgd a lgdo:City; >> rdfs:label ?name; >> geom:geometry [ogc:asWKT ?wkt ]. >> >> BIND ( bif:st_point(10.447683, 51.163375) AS ?centroid ) >> >> # choose one of the two lines below: >> # FILTER ( bif:st_distance(?wkt, ?centroid) <= 100 ) # use this >> predicate for query A >> # FILTER ( bif:st_intersects (?wkt, ?centroid, 100) ) # use this >> predicate for query B >> >> FILTER ( langMatches(lang(?name), '') ) >> FILTER NOT EXISTS { ?lgd a lgdm:Way. } >> } >> >> Using the query A (with filter by st_distance(...) <= 100), I get >> fourcities in my result set. >> Using query B, however, I only get threeout of the fourcities as result. >> >> Please see the Github gist at [2]for details. >> >> All of the four cities that should appear have distances from the >> centroid significantly under >> 100 units, so it shouldn't just be a floating point precision issue or >> something along that lines. >> >> As far as I understand the SQL MM standard and VOS documentation >> st_distance(?a, ?b) <= 100)and st_intersects (?a, ?b, 100)should be >> equivalent predicates >> provided that ?a and ?b are POINT geometries, right?If so, then this >> seems to be a bug. >> Just want to confirm my understanding before creating Github issue on >> this. >> >> >> Regards, >> >> Markus Ackermann >> >> >> >> [1]http://downloads.linkedgeodata.org/releases/2014-09-09/ >> >> [2] https://gist.github.com/neradis/01cb99080baf6e29cde6 >> >> ------------------------------------------------------------------------------ >> New Year. New Location. New Benefits. New Data Center in Ashburn, VA. >> GigeNET is offering a free month of service with a new server in Ashburn. >> Choose from 2 high performing configs, both with 100TB of bandwidth. >> Higher redundancy.Lower latency.Increased capacity.Completely compliant. >> http://p.sf.net/sfu/gigenet >> _______________________________________________ >> Virtuoso-users mailing list >> Virtuoso-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtuoso-users > ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users