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
    




Reply via email to