One SPARQL query takes forever in Fuseki.

Discussion:

Jason Koh

2016-11-09 06:07:06 UTC

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

Rob Vesse

2016-11-09 10:03:20 UTC

Permalink

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" <***@eng.ucsd.edu> 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

Jason Koh

2016-11-10 01:17:00 UTC

Permalink

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

Post by Rob Vesse
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
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
############ (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.
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

Rob Vesse

2016-11-10 09:37:04 UTC

Permalink

Out of interest did you try upgrading to the latest version as well?

Rob

On 10/11/2016 01:17, "Jason Koh" <***@eng.ucsd.edu> 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

Post by Rob Vesse
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
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
############ (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.
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

Jason Koh

2016-11-10 16:48:26 UTC

Permalink

I was using 2.40 and upgraded to 2.41 too.

Post by Rob Vesse
Out of interest did you try upgrading to the latest version as well?
Rob
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

Post by Rob Vesse
Jason
Your query as written results in large cross products as far as I

can see.

Post by Rob Vesse
The middle section of your query which is outside of the unions

makes no

Post by Rob Vesse
reference to the previously bound sensor variable so the query is

forced to

Post by Rob Vesse
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

Post by Rob Vesse
union. A better fix might be to move that portion of the query into

both

Post by Rob Vesse
branches of the final union.
Please donât remove prefixes from queries. It prevents people from

simply

Post by Rob Vesse
copying and pasting those queries into other tools directly for

analysis

Post by Rob Vesse
The other thing to consider is the version being used. There are

some

Post by Rob Vesse
improvements to property path handling in the just released 3.1.1

which may

Post by Rob Vesse
also improve things.
Rob
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.

Post by Rob Vesse
Environment: Windows 10, i5, 8 GB RAM
Graph size: 4000 triples
############ (prefixes are omitted here.)
SELECT DISTINCT ?sensor ?room
WHERE {
{ ?sensor rdf:type/rdfs:subClassOf*

brick:Zone_Temperature_Sensor

Post by Rob Vesse
. }
UNION
{ ?sensor rdf:type/rdfs:subClassOf*
brick:Discharge_Air_Temperature_Sensor . }
UNION
{ ?sensor rdf:type/rdfs:subClassOf* brick:Occupancy_Sensor .

}

Post by Rob Vesse
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

Post by Rob Vesse
subclass* of the above sensor types in all rooms. A sensor may

be a

Post by Rob Vesse
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

Post by Rob Vesse
queries such as one for rooms and one for sensors belonging to

the

Post by Rob Vesse
rooms?
Short intro to Brick: It is a building ontology to describe

resources

Post by Rob Vesse
in
buildings comprehensively.
https://github.com/BuildSysUniformMetadata/GroundTruth
A webpage under construction : http://brickschema.org/
Paper: https://people.eecs.berkeley.

edu/~gtfierro/papers/brick.pdf

Post by Rob Vesse
Thank you.
With regards,
Jason Koh
cseweb.ucsd.edu/~jbkoh