Forum Discussion
Ontology Path Query returns incorrect
Microsoft Fabric Ontology (Preview) - Possible Relationship Resolution Bug
Title
Ontology Path Query returns incorrect VisitOccurrence records by matching entity key values instead of configured relationship mappings.
Environment
Microsoft Fabric, Ontology (Preview), OMOP CDM dataset, Lakehouse tables, Entity Types: Person and VisitOccurrence.
Objective
Create a relationship Person -> person_has_visit -> VisitOccurrence using visit_occurrence.person_id -> person.person_id.
Test Data
Person table contains person_id values 10 and 12. VisitOccurrence contains: (10,1001), (12,2001), (12,2002), (12,2003).
Expected Relationships
Person(10)->VisitOccurrence(1001); Person(12)->VisitOccurrence(2001), VisitOccurrence(2002), VisitOccurrence(2003).
Entity Configuration
Person entity key: person_id. VisitOccurrence entity key: visit_occurrence_id. Both entities bound directly to their corresponding key columns.
Relationship Configuration
Relationship name: person_has_visit. Origin entity: Person. Target entity: VisitOccurrence. Mapping table: visit_occurrence. Mapping: Person key mapped to person_id column; VisitOccurrence key mapped to visit_occurrence_id column.
Expected Result
Path Query for Person(12) should return VisitOccurrence IDs 2001, 2002 and 2003.
Actual Result
Path Query returns an incorrect VisitOccurrence record. Earlier testing returned VisitOccurrence(12), whose properties showed person_id = 3. Therefore Person(12) was linked to a visit belonging to Person(3).
Why This Appears To Be A Bug
The source data contains no relationship between Person(12) and VisitOccurrence(12). The graph output appears inconsistent with both the configured relationship and the source data.
Troubleshooting Performed
Recreated VisitOccurrence table with a minimal dataset; rebound entity types; verified entity keys; recreated relationship; published ontology; used unique non-overlapping IDs to eliminate ambiguity.
Possible Causes
1. Relationship instances not regenerated after binding changes. 2. Ontology using stale/cached relationship data. 3. Path Query traversing using entity key/label equality instead of generated relationship instances. 4. Graph Explorer resolving nodes incorrectly.
Request To Fabric Team
Please confirm how relationship instances are materialized, whether Path Query uses relationship instances or labels/keys, whether ontology relationship data is cached after rebinding, and whether this is a known issue in Ontology Preview.
1 Reply
Thanks for providing such a detailed write-up and the troubleshooting steps you've already completed.
Based on your description, this does sound like a potential issue in the Ontology Preview rather than a configuration problem. If the relationship is defined as:
Person.person_id -> VisitOccurrence.person_id
and the target entity key is visit_occurrence_id, then a path query for Person(12) should only return the visit occurrences whose person_id = 12. It should never return a visit simply because its visit_occurrence_id happens to equal 12.
Since you've already:
Verified the entity keys.
Recreated the entities and relationship.
Tested with a minimal dataset.
Used non-overlapping IDs to eliminate ambiguity.
...it does suggest either:
A stale relationship index or cache that wasn't rebuilt after republishing.
An issue in how relationship instances are materialized.
A bug in the Path Query engine or Graph Explorer when resolving relationships.
Given that Ontology is still in Preview, this is exactly the type of behavior Microsoft is looking to identify and address. I'd recommend opening a support ticket and providing the minimal reproducible dataset and ontology configuration, as it will be much easier for the product team to investigate.
It would also be helpful if the Fabric team could clarify:
Whether relationship instances are rebuilt automatically after entity or relationship changes.
Whether Path Query traverses persisted relationship instances or resolves relationships dynamically.
Whether there are any known caching limitations in the current Preview.
From what you've described, I would expect the configured relationship mapping to take precedence over any matching key values, so the behavior you're seeing does appear inconsistent with the expected ontology model.
