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

Reply via email to