I was doing some research on the systems mentioned here to determine what to use in an implementation. What I found was that Stardog has explicitly held off on conforming to RDF 1.2 until standardization completes. So in May 2026, it seems Stardog does not give you RDF 1.2 hybridization. Stardog gives you its own edge-property syntax (<<:s :p :o>> style, descended from the original 2014 Hartig/Thompson RDF*), which is semantically close to but not identical to the standardized RDF 1.2 design. Is that right?
Stardog offers RDF* right now. They (and other graph vendors) are waiting for SPARQL 1.2 to be finalized before offering RDF 1.2. Both will be rolled out once both standards are official. RDF* is close but you are correct, not the same.
Not at all but it’s not exactly a migration from RDF*. It’s a migration from 1.1 to 1.2. 1.1 is backwards compatible with 1.2 so that part makes the upgrade a non issue. There’s only a handful of changes which are all added capabilities— not changes to the logic and spec overall.
The added is the reification capabilities and directional language tags. Adding those capabilities should be easy.
Because the SPARQL update is trailing behind in approval activities, makes sense to wait.
Hello, Honestly, I wondered if you’d tackle this challenge – even if you have already approached it - what you’ve done with brio in this article and a remarkable historical part.
But I don’t know what to do now...Kidding.
However, « ...the difference between “Alice knows Bob, and this edge has weight 0.9” (LPG) and “the source S claims that Alice knows Bob, though we do not assert it” (RDF 1.2)... ».
So, doesn’t it remain a CWA and isn’t it better to give it a weight in any case, notwithstanding Shacl ?
Hi Marc- ah yes. I am writing a follow-up to this piece.
Keep in mind, the very nature of knowledge is that we cannot assume everything to be true or false. We must allow for expansion and contraction and to accept unknowns. 😉
Weights in LPGs can represent capacities, distances or collections of attributes.
I’ll try my best to explain here:
A weight does not give you that. 0.9 on an LPG edge does three jobs and conflates all of them:
1) it asserts the edge exists 2) it attaches a degree, and 3) it implies a confidence without recording whose, measured how or even against what. To annotate the relationship in LPG you must first assert it — the edge has to be in the graph to carry the property. So the moment you write weight 0.9, you have already committed to Alice knowing Bob; the number is decoration on a fact you can no longer withhold. RDF lets you attach the degree to the claim rather than to the world where S asserts this at 0.9, T asserts the contrary at 0.4, both first-class statements you can query and adjudicate. In LPG those are two competing edges or one overwritten property.
SHACL gives you scoped, local closure at the validation layer — for the purpose of this shape, treat cardinality as closed — while the base graph stays open-world. You get closed-world data quality guarantees exactly where you declare them and open-world semantics everywhere else. LPG hands you global CWA whether the domain warrants it or not.
So “better to give it a weight in any case” holds only when the single question is strength of association in a closed dataset you own. As soon as provenance, source disagreement or unendorsed third-party claims enter — which may happen with most real integrations — the weight is doing too many jobs but recording none of them. And the standard LPG fix, reifying the claim as an intermediate Claim node linked to Alice, Bob, and S, is just RDF reification rebuilt by hand, at the cost of the native edge-traversal speed that was LPG’s entire argument. And with LPGs, this is manual. When you need this expressiveness, LPG ends up emulating RDF in order to render descriptive logic.
Looks like a duck, quacks like a duck but doesn’t swim like a duck and isn’t really a duck 🦆
Which can become expensive and complex for lack of standardization and interoperability.
I notice I made a mistake in my former post : « So, doesn’t it remain a CWA... ». I meant OWA but you have understood.
If you introduce Shacl, it is indeed a decisive piece in the game :). Your explanation is subtle and detailed and I thank you for that. Almost a private course :) and great point.
But I suspected that you had a slight preference for RDF over ducks, uh… LPGs.
Great article! Thank you! I believe there's yet another angle to the story. I feel that the majority just choose the most easily available tool out there. Today it is Neo4j that makes LPG the default choice for many. This year the MATCH statement from both GQL and Cypher is coming to Postgres and it may change the go-to solution but this will still elevate the mind share of LPGs.
Yes it’s the easier path or what I noted in the article as “developer ergonomics”. Sure—LPG is easiest. But certainly not descriptive logic. Ontology /RDF graphs introduce descriptive logic and semantics. So the default may be LPGs for ease but that does not make for a descriptive and logical system that can reason and support inference.
Choosing the graph type according to ease is a choice that prioritizes ease over expected output and enablers.
Sincerest thanks again Ms Talisman from all of our “Weirdo” SoundCloud INDEX (via Discord) .Au & “The Uk” dearest friends, especially SamAO’s bestie. 🙏🙏🙏
I have a distant memory of using the word reify in my first postgraduate essay in 1995 - my first degree is in Latin. My tutor corrected it to deify. Still slightly jarring.
Love the history bit. For folks who are interested in more part of history, check out the article I wrote with Prof Claudio Gutierrez on the history of Knowledge Graphs
Yes, a really excellent article and clear explanation of this tech discipline and its (somewhat tortuous;-) history, with helpful guidance and recommendations. Thank you!
PS- i assume you are connected with this tech community (Kurt Cagle et al) over on LinkedIn? You will find a resonant audience and knowledge network, if you are not already plugged in. Keep up the great work and sharing!
Thank you, David! Yes—Kurt’s a great friend and we have written a little together. He made a great appearance for an AMA for a Knowledge Graph Academy cohort I teach :)
Good article! What is often forgotten and still exists as a niche is the Object Database Management System (OODBMS). I worked from 1997 to 2006 with Versant, Objectivity, and ObjectStore. 2000-2006 at Versant proper, we had a very diverse client base worldwide, but it kind of died out. I think it was due to the massive investments in DB2 and Oracle. So even if we were very fast, it wasn't only a technical factor.
These databases mapped well to OOP, and we had already handled distributed graphs spanning many servers around 1998 (telecom networks).
I used Neo4j and TinkerPop implementations, including SQLG, in production; it has a bit of an OODBMS vibe. I do miss the extreme control we had with Versant (and others). I could read a whole subgraph of N levels in one network call.
Thank you, Per;) Maybe it’s time to bring that back? But I do think Oracle has revived some of the OODBMS but not customer facings I’ll look back through my research
I was doing some research on the systems mentioned here to determine what to use in an implementation. What I found was that Stardog has explicitly held off on conforming to RDF 1.2 until standardization completes. So in May 2026, it seems Stardog does not give you RDF 1.2 hybridization. Stardog gives you its own edge-property syntax (<<:s :p :o>> style, descended from the original 2014 Hartig/Thompson RDF*), which is semantically close to but not identical to the standardized RDF 1.2 design. Is that right?
Stardog offers RDF* right now. They (and other graph vendors) are waiting for SPARQL 1.2 to be finalized before offering RDF 1.2. Both will be rolled out once both standards are official. RDF* is close but you are correct, not the same.
Thanks. Do you think it is going to be tough to migrate from RDF* to RDF1.2?
Not at all but it’s not exactly a migration from RDF*. It’s a migration from 1.1 to 1.2. 1.1 is backwards compatible with 1.2 so that part makes the upgrade a non issue. There’s only a handful of changes which are all added capabilities— not changes to the logic and spec overall.
The added is the reification capabilities and directional language tags. Adding those capabilities should be easy.
Because the SPARQL update is trailing behind in approval activities, makes sense to wait.
Hello, Honestly, I wondered if you’d tackle this challenge – even if you have already approached it - what you’ve done with brio in this article and a remarkable historical part.
But I don’t know what to do now...Kidding.
However, « ...the difference between “Alice knows Bob, and this edge has weight 0.9” (LPG) and “the source S claims that Alice knows Bob, though we do not assert it” (RDF 1.2)... ».
So, doesn’t it remain a CWA and isn’t it better to give it a weight in any case, notwithstanding Shacl ?
Hi Marc- ah yes. I am writing a follow-up to this piece.
Keep in mind, the very nature of knowledge is that we cannot assume everything to be true or false. We must allow for expansion and contraction and to accept unknowns. 😉
Weights in LPGs can represent capacities, distances or collections of attributes.
I’ll try my best to explain here:
A weight does not give you that. 0.9 on an LPG edge does three jobs and conflates all of them:
1) it asserts the edge exists 2) it attaches a degree, and 3) it implies a confidence without recording whose, measured how or even against what. To annotate the relationship in LPG you must first assert it — the edge has to be in the graph to carry the property. So the moment you write weight 0.9, you have already committed to Alice knowing Bob; the number is decoration on a fact you can no longer withhold. RDF lets you attach the degree to the claim rather than to the world where S asserts this at 0.9, T asserts the contrary at 0.4, both first-class statements you can query and adjudicate. In LPG those are two competing edges or one overwritten property.
SHACL gives you scoped, local closure at the validation layer — for the purpose of this shape, treat cardinality as closed — while the base graph stays open-world. You get closed-world data quality guarantees exactly where you declare them and open-world semantics everywhere else. LPG hands you global CWA whether the domain warrants it or not.
So “better to give it a weight in any case” holds only when the single question is strength of association in a closed dataset you own. As soon as provenance, source disagreement or unendorsed third-party claims enter — which may happen with most real integrations — the weight is doing too many jobs but recording none of them. And the standard LPG fix, reifying the claim as an intermediate Claim node linked to Alice, Bob, and S, is just RDF reification rebuilt by hand, at the cost of the native edge-traversal speed that was LPG’s entire argument. And with LPGs, this is manual. When you need this expressiveness, LPG ends up emulating RDF in order to render descriptive logic.
Looks like a duck, quacks like a duck but doesn’t swim like a duck and isn’t really a duck 🦆
Which can become expensive and complex for lack of standardization and interoperability.
I notice I made a mistake in my former post : « So, doesn’t it remain a CWA... ». I meant OWA but you have understood.
If you introduce Shacl, it is indeed a decisive piece in the game :). Your explanation is subtle and detailed and I thank you for that. Almost a private course :) and great point.
But I suspected that you had a slight preference for RDF over ducks, uh… LPGs.
Yes, ducks 😂
Great article! Thank you! I believe there's yet another angle to the story. I feel that the majority just choose the most easily available tool out there. Today it is Neo4j that makes LPG the default choice for many. This year the MATCH statement from both GQL and Cypher is coming to Postgres and it may change the go-to solution but this will still elevate the mind share of LPGs.
Yes it’s the easier path or what I noted in the article as “developer ergonomics”. Sure—LPG is easiest. But certainly not descriptive logic. Ontology /RDF graphs introduce descriptive logic and semantics. So the default may be LPGs for ease but that does not make for a descriptive and logical system that can reason and support inference.
Choosing the graph type according to ease is a choice that prioritizes ease over expected output and enablers.
Suberb.
Sincerest thanks again Ms Talisman from all of our “Weirdo” SoundCloud INDEX (via Discord) .Au & “The Uk” dearest friends, especially SamAO’s bestie. 🙏🙏🙏
John 🤠🦋
25th May 2026
Super article! Detailed and approachable.
I have a distant memory of using the word reify in my first postgraduate essay in 1995 - my first degree is in Latin. My tutor corrected it to deify. Still slightly jarring.
This should be required reading for today's CS students. A great piece of scholarship, Jessica; thank you!
Thank you, Dima!
Love the history bit. For folks who are interested in more part of history, check out the article I wrote with Prof Claudio Gutierrez on the history of Knowledge Graphs
https://cacm.acm.org/research/knowledge-graphs/
Yes, a really excellent article and clear explanation of this tech discipline and its (somewhat tortuous;-) history, with helpful guidance and recommendations. Thank you!
PS- i assume you are connected with this tech community (Kurt Cagle et al) over on LinkedIn? You will find a resonant audience and knowledge network, if you are not already plugged in. Keep up the great work and sharing!
PSS- ok, i see you there as well!👍👊
https://www.linkedin.com/pulse/choosing-right-graph-jessica-talisman-zvftc
Thank you, David! Yes—Kurt’s a great friend and we have written a little together. He made a great appearance for an AMA for a Knowledge Graph Academy cohort I teach :)
Will see you on LI!
Good article! What is often forgotten and still exists as a niche is the Object Database Management System (OODBMS). I worked from 1997 to 2006 with Versant, Objectivity, and ObjectStore. 2000-2006 at Versant proper, we had a very diverse client base worldwide, but it kind of died out. I think it was due to the massive investments in DB2 and Oracle. So even if we were very fast, it wasn't only a technical factor.
These databases mapped well to OOP, and we had already handled distributed graphs spanning many servers around 1998 (telecom networks).
I used Neo4j and TinkerPop implementations, including SQLG, in production; it has a bit of an OODBMS vibe. I do miss the extreme control we had with Versant (and others). I could read a whole subgraph of N levels in one network call.
Thank you, Per;) Maybe it’s time to bring that back? But I do think Oracle has revived some of the OODBMS but not customer facings I’ll look back through my research