Re: bottom-up semantics

2019-02-02 Thread Lorenz B.
> ?loc :workLocationVolume ?bvol .?loc :locatedInWork ex:Work1 ; >:startVolume ?startvol . > FILTER ((?bvol = ?volnum && NOT EXISTS {?loc :workLocationEndVolume > ?evol}) || (?bvol <= ?volnum && EXISTS {?loc :workLocationEndVolume > ?evol FILTER (?evol <= ?volnum)})) > > In terms of

Re: bottom-up semantics

2019-02-01 Thread Élie Roux
Hello, Thanks for your answer > (conditional > (bgp > (triple ?loc :locatedInWork ex:Work1) > (triple ?loc :startVolume ?startvol) > ) > (bgp (triple ?loc :endVolume ?endvol))) Am I right in understanding that in that case ?loc

Re: bottom-up semantics

2019-02-01 Thread David Jordan
= 2 && ?endvol >= 2) || > (!BOUND(?endvol) && ?startvol = 2)) > > which works fine, but is slow to the extreme (about 8s) due to the > very large amount of triples with the :endVolume property. Now, I > understand the slow performance is sort of expected due what'

Re: bottom-up semantics

2019-02-01 Thread Martynas Jusevičius
ol . > OPTIONAL { ?loc :endVolume ?endvol . } > FILTER ((BOUND(?endvol) && ?startvol <= 2 && ?endvol >= 2) || > (!BOUND(?endvol) && ?startvol = 2)) > > which works fine, but is slow to the extreme (about 8s) due to the > very large amount of triple

bottom-up semantics

2019-02-01 Thread Élie Roux
he :endVolume property. Now, I understand the slow performance is sort of expected due what's referred to as the bottom-up semantics of SPARQL. My understanding is that the first thing that will get evaluated will be ?loc :endVolume ?endvol which will return a huge amount of results. Here are a few questi