Open buvnswrn opened 11 months ago
Filter Inside Optional works but we have to take care of the scoping. Outer scope variables will not work inside the optional Part
Correct code with optional and bind.
PREFIX pomdp-ns:<http://www.dfki.de/pomdp-ns#>
PREFIX pomdp-ns1:<http://www.dfki.de/pomdp-ns/>
PREFIX pomdp-ns-data:<http://www.dfki.de/pomdp-ns/POMDP/data/>
PREFIX rdfs:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ajan-math-ns:<http://www.ajan.de/ajan/functions/math-ns#>
CONSTRUCT {
pomdp-ns:Observation pomdp-ns:attributes ?attributes .
pomdp-ns:Observation pomdp-ns:for_hash ?for_hash .
?attributes pomdp-ns1:_person_id ?person_id .
?attributes pomdp-ns1:_pose ?poseNode .
?for_hash rdfs:value "person_id" .
?for_hash rdfs:value "pose" .
?poseNode pomdp-ns:type ?poseType .
?poseNode rdfs:value ?keypoint9.
?poseNode rdfs:value ?keypoint10 .
?poseNode rdfs:value ?keypoint11 .
?poseNode rdfs:value ?keypoint12 .
?keypoint9 rdfs:x ?xvalue9 .
?keypoint10 rdfs:x ?xValue10 .
?keypoint11 rdfs:x ?xValue11 .
?keypoint12 rdfs:x ?xValue12 .
?keypoint9 rdfs:y ?yValue9 .
?keypoint10 rdfs:y ?yValue10 .
?keypoint11 rdfs:y ?yValue11 .
?keypoint12 rdfs:y ?yValue12 .
}
WHERE{
pomdp-ns:ObservationModel pomdp-ns:attributes ?attributesNode .
?attributesNode pomdp-ns1:_person_id ?person_id .
pomdp-ns:current_action rdfs:value ?action .
BIND(BNODE() as ?attributes) .
BIND(BNODE() as ?for_hash) .
OPTIONAL {
pomdp-ns:current_action rdfs:value ?action .
FILTER(?action = pomdp-ns1:Action_perceive) .
BIND(pomdp-ns-data:Point_9 as ?keypoint9) .
BIND(pomdp-ns-data:Point_10 as ?keypoint10) .
BIND(pomdp-ns-data:Point_11 as ?keypoint11) .
BIND(pomdp-ns-data:Point_12 as ?keypoint12) .
BIND(pomdp-ns:pandasDataFrame as ?poseType)
BIND(BNODE() as ?poseNode) .
BIND(RAND() as ?xValue9) .
BIND(RAND() as ?yvalue9) .
BIND(RAND() as ?xValue10) .
BIND(RAND() as ?yvalue10) .
BIND(RAND() as ?xValue11) .
BIND(RAND() as ?yvalue11) .
BIND(RAND() as ?xValue12) .
BIND(RAND() as ?yvalue12) .
}
OPTIONAL {
BIND(rdfs:nil as ?poseNode) .
FILTER(?action != pomdp-ns1:Action_perceive) .
}
}
Since rdf:nil is directly converted without any parsing, we can use the one below
PREFIX pomdp-ns:<http://www.dfki.de/pomdp-ns#>
PREFIX pomdp-ns1:<http://www.dfki.de/pomdp-ns/>
PREFIX pomdp-ns-data:<http://www.dfki.de/pomdp-ns/POMDP/data/>
PREFIX rdfs:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX ajan-math-ns:<http://www.ajan.de/ajan/functions/math-ns#>
CONSTRUCT {
pomdp-ns:Observation pomdp-ns:attributes ?attributes .
pomdp-ns:Observation pomdp-ns:for_hash ?for_hash .
?attributes pomdp-ns1:_person_id ?person_id .
?attributes pomdp-ns1:_pose ?poseNode .
?for_hash rdfs:value "person_id" .
?for_hash rdfs:value "pose" .
?poseNode pomdp-ns:type ?poseType .
?poseNode rdfs:value ?keypoint9.
?poseNode rdfs:value ?keypoint10 .
?poseNode rdfs:value ?keypoint11 .
?poseNode rdfs:value ?keypoint12 .
?keypoint9 rdfs:x ?xvalue9 .
?keypoint10 rdfs:x ?xValue10 .
?keypoint11 rdfs:x ?xValue11 .
?keypoint12 rdfs:x ?xValue12 .
?keypoint9 rdfs:y ?yValue9 .
?keypoint10 rdfs:y ?yValue10 .
?keypoint11 rdfs:y ?yValue11 .
?keypoint12 rdfs:y ?yValue12 .
}
WHERE{
pomdp-ns:ObservationModel pomdp-ns:attributes ?attributesNode .
?attributesNode pomdp-ns1:_person_id ?person_id .
pomdp-ns:current_action rdfs:value ?action .
BIND(BNODE() as ?attributes) .
BIND(BNODE() as ?for_hash) .
BIND(IF(?action = pomdp-ns1:Action_perceive, BNODE(), rdfs:nil) as ?poseNode) .
BIND(pomdp-ns-data:Point_9 as ?keypoint9) .
BIND(pomdp-ns-data:Point_10 as ?keypoint10) .
BIND(pomdp-ns-data:Point_11 as ?keypoint11) .
BIND(pomdp-ns-data:Point_12 as ?keypoint12) .
BIND(pomdp-ns:pandasDataFrame as ?poseType)
BIND(RAND() as ?xValue9) .
BIND(RAND() as ?yvalue9) .
BIND(RAND() as ?xValue10) .
BIND(RAND() as ?yvalue10) .
BIND(RAND() as ?xValue11) .
BIND(RAND() as ?yvalue11) .
BIND(RAND() as ?xValue12) .
BIND(RAND() as ?yvalue12) .
}
SELECT query with OPTIONAL is anticipated to fail, especially in the observation model. This is because the observation model updates the beliefs externally outside the pomdp_py framework. So, there might be some synchronization issues in loading the graph data and then querying on top of it or using some parallel pattern match (still not known what the issue is here since they cannot be reproduced in debug mode).
Potential Fix: Write a select query that does not have OPTIONAL. This can be done by formulating the RDF to have the necessary data with default values such as rdfs:nil or something similar. If there is a single resource pattern being unmatched or unavailable, then the the query fails.
Even in other models it is safer to avoid using OPTIONAL within SELECT query, but if its unavoidable to use OPTIONAL, then make a default entry to the RDF data and ensure that the resource URI is available. If the resource URI used in the pattern is available, and something like FILTER is used, OPTIONAL behaves normally without resulting in any failure. So, AVOID MATCHING URI THAT IS NOT ALWAYS PRESENT IN THE RDF DATA.