I was using 2.40 and upgraded to 2.41 too. On Nov 10, 2016 1:37 AM, "Rob Vesse" <[email protected]> wrote:
> Out of interest did you try upgrading to the latest version as well? > > Rob > > On 10/11/2016 01:17, "Jason Koh" <[email protected]> wrote: > > Thanks Rob. > > The query fix works much faster. It still takes 90 seconds but I think > it > is the query itself requires a large search. > > Thanks again. > > > With regards, > Jason Koh > cseweb.ucsd.edu/~jbkoh > > On Wed, Nov 9, 2016 at 2:03 AM, Rob Vesse <[email protected]> > wrote: > > > Jason > > > > Your query as written results in large cross products as far as I > can see. > > > > The middle section of your query which is outside of the unions > makes no > > reference to the previously bound sensor variable so the query is > forced to > > cross product all the sensors with all the rooms. > > > > A simple fix may be to move that section of the query to after the > final > > union. A better fix might be to move that portion of the query into > both > > branches of the final union. > > > > Please don’t remove prefixes from queries. It prevents people from > simply > > copying and pasting those queries into other tools directly for > analysis > > > > The other thing to consider is the version being used. There are > some > > improvements to property path handling in the just released 3.1.1 > which may > > also improve things. > > > > Rob > > > > On 09/11/2016 06:07, "Jason Koh" <[email protected]> wrote: > > > > Dear all, > > > > I am Jason Koh from Brick community (http://brickschema.org/). > > I try to run a SPARQL query on a graph, and it takes forever on > Fuseki. > > Environment: Windows 10, i5, 8 GB RAM > > Graph size: 4000 triples > > The query: > > ############ (prefixes are omitted here.) > > SELECT DISTINCT ?sensor ?room > > WHERE { > > { ?sensor rdf:type/rdfs:subClassOf* > brick:Zone_Temperature_Sensor > > . } > > UNION > > { ?sensor rdf:type/rdfs:subClassOf* > > brick:Discharge_Air_Temperature_Sensor . } > > UNION > > { ?sensor rdf:type/rdfs:subClassOf* brick:Occupancy_Sensor . > } > > UNION > > { ?sensor rdf:type/rdfs:subClassOf* brick:CO2_Sensor . } > > > > ?vav rdf:type brick:VAV . > > ?zone rdf:type brick:HVAC_Zone . > > ?room rdf:type brick:Room . > > > > ?vav bf:feeds+ ?zone . > > ?zone bf:hasPart ?room . > > > > {?sensor bf:isPointOf ?vav } > > UNION > > {?sensor bf:isPointOf ?room } > > > > } > > ####### > > > > Background knowledge: I would like to find all the sensors that > are > > subclass* of the above sensor types in all rooms. A sensor may > be a > > sensor > > of a room or VAV, which is equipment serving a room. > > > > Is this a just not reasonable query and should I divide it into > several > > queries such as one for rooms and one for sensors belonging to > the > > rooms? > > > > > > Short intro to Brick: It is a building ontology to describe > resources > > in > > buildings comprehensively. > > Github repo with ontology : > > https://github.com/BuildSysUniformMetadata/GroundTruth > > A webpage under construction : http://brickschema.org/ > > Paper: https://people.eecs.berkeley. > edu/~gtfierro/papers/brick.pdf > > > > Thank you. > > > > With regards, > > Jason Koh > > cseweb.ucsd.edu/~jbkoh > > > > > > > > > > > > > > > > > >
