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 > > > > > >
