You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Jason Koh <jb...@eng.ucsd.edu> on 2016/11/09 06:07:06 UTC
One SPARQL query takes forever in Fuseki.
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
Re: One SPARQL query takes forever in Fuseki.
Posted by Jason Koh <jb...@eng.ucsd.edu>.
I was using 2.40 and upgraded to 2.41 too.
On Nov 10, 2016 1:37 AM, "Rob Vesse" <rv...@dotnetrdf.org> wrote:
> Out of interest did you try upgrading to the latest version as well?
>
> Rob
>
> On 10/11/2016 01:17, "Jason Koh" <jb...@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
>
> On Wed, Nov 9, 2016 at 2:03 AM, Rob Vesse <rv...@dotnetrdf.org>
> 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" <jb...@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
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
Re: One SPARQL query takes forever in Fuseki.
Posted by Rob Vesse <rv...@dotnetrdf.org>.
Out of interest did you try upgrading to the latest version as well?
Rob
On 10/11/2016 01:17, "Jason Koh" <jb...@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
On Wed, Nov 9, 2016 at 2:03 AM, Rob Vesse <rv...@dotnetrdf.org> 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" <jb...@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
>
>
>
>
>
>
Re: One SPARQL query takes forever in Fuseki.
Posted by Jason Koh <jb...@eng.ucsd.edu>.
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 <rv...@dotnetrdf.org> 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" <jb...@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
>
>
>
>
>
>
Re: One SPARQL query takes forever in Fuseki.
Posted by Rob Vesse <rv...@dotnetrdf.org>.
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" <jb...@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