Labeled property graph

Your graph was built in the last concept, and it felt like the finish line. It is not. Saying "a graph" is not enough. There is more than one way to store the exact same fact, and the ways are not the same. Pick the wrong one and a whole set of questions gets hard to ask.

Take one small fact: freezer F-02 is a freezer, its warmest safe temperature is minus eighteen, and it cools shipment SH-9 since 2024. It is a simple fact. Now store it.

One way breaks that fact into a small pile of three-word statements. F-02 is a Freezer. F-02 has maxTempC minus eighteen. F-02 cools SH-9. Each statement is true. But none of them, on its own, is the freezer. You rebuild the thing by collecting its statements. That is roughly how RDF works: subject, then predicate, then object. It is triples, and only triples.

The other way keeps the freezer as one object that already knows what it is and what is true about it. That is the shape Fabric uses, and it has a name.

The same fact, two shapes

Here they are, side by side. On the left the freezer is a pile of triples. On the right it is one labeled node. Both hold the same information. They do not hold it the same way, and the difference matters.

In the triple pile, "Freezer" is just one more statement next to the others. The type of the thing and the facts about the thing are the same kind of row. That is neat, but it also means there is no single place that is the freezer. In the labeled node, the type is marked on the object itself, and the properties live inside it. You do not gather the freezer. You point at it.

Neither shape is wrong. RDF's triples are the base of the semantic web, and they fit together well across the open internet. But for a business graph that you own and query a lot, the labeled property graph tends to win on one thing: it puts a thing's type and a thing's facts in one place. So both the human and the query engine can grab them together.

A node is a label plus a bag. So is an edge.

The shape has two parts, and the neat part is that both parts repeat. A node is a label plus a property bag. An edge is a label plus a property bag too. The relationship is not a thin, nameless line between two things. It is its own thing, with a type and its own facts.

Look at the edge. [:COOLS {since: "2024"}]. That since does not belong to the freezer, and it does not belong to the shipment. It belongs to the link itself, to the cooling. In a labeled property graph the edge has a place to keep it. This is exactly the property-on-a-relationship idea from earlier, now shown in the storage shape that makes it natural.

That is also where RDF has to work harder. A plain triple can say F-02 cools SH-9, but a triple has three slots and they are all full, so there is no place to put since. To add one property to that relationship, you make a stand-in node and spend several triples describing it. The property graph gives the edge a label and a bag from the start, so the fact just goes in.

Click around and try it yourself. Pick the freezer, pick the edge, then switch how it gets stored.

Notice what happened when you inspected the edge in RDF. One relationship with one small property turned into a blank node and four statements. Same fact, more parts. That is the cost you pay when the model has no first-class place for an edge's own properties.

What Fabric stores under your ontology

The graph under a Fabric IQ ontology is a labeled property graph. This is not a detail you set up. It is the model, the same shape used by common graph databases, and it is why everything you built in the earlier concepts fits so well.

The mapping is direct. Each entity instance becomes a labeled node: the entity type is the label, and the properties you declared become the node's property bag. Each relationship instance becomes a labeled edge: the relationship type is the label, and any attributes on the relationship become the edge's property bag. Nodes and edges both carry properties, and both carry lineage, a link back to the row they came from.

Because the type and the properties sit together, a query can ask for them together. That is why the graph in Microsoft Fabric answers questions in GQL, the ISO-standard graph query language, where a pattern names a label and reads a property in one clause. A data agent, which is Fabric's name for an AI agent grounded in your data, walks these labeled edges and reads these property bags to reason over the knowledge graph. That is the GraphRAG loop you have been building toward. All of it runs over your OneLake tables in place, with no separate graph database. Microsoft is very firm on this point: the graph in Fabric supports the LPG model only, and RDF is not supported. So the shape on this page is not one option among several. It is the shape. As of July 2026 the graph engine itself is generally available, while the ontology item above it is still in preview, so treat that upper layer as still changing.

The one trap

Do not treat the relationship as a nameless wire. The most common mistake coming from tables is to think of an edge as just "these two ids match", a thin link with nothing to add. In a labeled property graph the edge is first-class: it has a type and it has its own facts. When a property describes the link and not either end, like when a treatment happened or since when a freezer has cooled a shipment, that property lives on the edge. Put it on a node and you have quietly put the fact in the wrong place.

So the graph stores nodes and edges, labels and properties. But there is a deeper split inside those edges. Some of them you stated directly from your data, and some of them the graph worked out for you. Next: asserted versus derived, the difference between a fact you loaded and a fact the graph figured out.