Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
Even as RDF has become ubiquitous in enterprises and across the web, its awkward handling of reification — the ability to refer to other statements in a graph — has limited its wider adoption.
RDF 1.2 addresses this with the reifier: a new element that lets you attach provenance, confidence, and source directly to a relationship — including claims you’re tracking but not asserting as true.
We talked about:
- Ora and Adrian’s extensive experience and backgrounds in the RDF community
- how the need to better handle reification led to the development of RDF 1.2
- the W3C’s use of the term “recommendation,” which many/most people would think of as a “standard”
- the recent advancement of the RDF Concepts and Abstract Syntax and RDF Semantics specifications to “candidate recommendation” status
- the new RDF triple term – and how it permits references to RDF statements that have not been asserted
- some of the details that made reification difficult in prior versions of RDF: verbosity, inability to scale, etc.
- how the ability to reason on data distinguishes RDF graphs from labeled property graphs
- the high quality of the RDF 1.2 W3C working group and their confidence that their work has accounted for all of the important considerations that might arise
- the challenges of dealing with the needs for both backward and forward compatibility
- how committee specifications like RDF 1.2 compare with less collaborative vendor specifications
- how RDF saves BMW millions of lines of code when reasoning over car features
- how standards-setting has evolved over time, from codifying existing practices 30 years ago to more proactive approaches today
- Adrian’s appreciation for the working group volunteer contributors and how they exemplify the values of open standards, open source, and open data
- Ora’s observation about the truly open and transparent nature of the working group and the many benefits open standards, including the ability to avoid vendor lock-in
Ora’s bio
Dr. Ora Lassila has been working on the Semantic Web since 1996, first exploring possibilities for knowledge representation on the Web—work that launched the W3C RDF activity—and later pursuing his ideas about using autonomous agents on the Web—something that became the original Semantic Web vision as articulated in the 2001 Scientific American article he co-authored. All this was preceded by several years of research work on knowledge representation, ontologies, agents, planning, and other classical AI technologies.
He is currently an Associate Director of Data Engineering and Governance at Accenture, working on topics like ontologies and knowledge graphs. He is also the co-chair of the current W3C RDF & SPARQL Working Group that is defining the next version of the RDF standard.
His prior positions include Principal Technologist (in the Neptune graph database team) at AWS, Managing Director (Head of Ontology Engineering) at State Street, Research Fellow (Head of Agent Research) at Nokia Research, and Project Manager at Carnegie Mellon University, among several others.
Dr. Lassila’s knowledge representation software flew onboard the NASA Deep Space 1 probe to the Asteroid Belt in the 1990s. He is also a Grand Prize Winner of the Obfuscated C Code Contest. He received his Ph.D (D.Sc) and M.Sc degrees at the Helsinki University of Technology.
Connect with Ora online
Adrian’s bio
Adrian Gschwend is the founder of Qlevia AI, an operational knowledge platform for enterprise AI, designed to help organizations turn complex, evolving data landscapes into reliable, real-time systems.
For more than a decade, Adrian has focused on making knowledge graphs scale, both technologically and in real-world applications. As an engineer, he has worked hands-on with enterprises and public institutions to solve complex data integration challenges, building systems that reflect how businesses actually operate and evolve over time.
Adrian has a strong background in open source and open data, contributing to large-scale government platforms in Switzerland and Europe, as well as working with organizations such as BMW. He also serves as co-chair of the World Wide Web Consortium RDF 1.2 Working Group.
His perspective is that while AI has advanced rapidly, most organizations still operate on fragmented and disconnected data. He is focused on closing that gap by building systems where data, context and decision-making come together into a reliable operational layer that adapts with the business.
Connect with Adrian online
- email: adrian at qlevia dot com
Resources mentioned in this interview
- RDF 1.2 Concepts and Abstract Data Model
- RDF 1.2 Semantics
- The Semantic Web, Scientific American, May 2001
Video
Here’s the video version of our conversation:
https://youtu.be/VlRsTyHDdY8
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 50. The standards that make the World Wide Web work are built on the volunteer labor of experts like Ora Lassila and Adrian Gschwend. Ora and Adrian co-chair the working group that is bringing a powerful new capability to the W3C RDF standard. In previous versions of RDF, reification has been a verbose and complex process. RDF 1.2 introduces a new rdf:reifies property that simplifies and streamlines the ability to refer to other triples in a graph as first-class objects.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 50 of the Knowledge Graph Insights Podcast. I am really delighted today to welcome to the show Ora Lassila and Adrian Gschwend. Sorry, Adrian. My German is horrible at this point, but Ora’s just started a new job at Accenture. That’s really exciting. Maybe we’ll talk a little bit more about that. Most people know him as like a longtime Neptune person at AWS. Adrian is the also well-known long time at Zazuko and now is the CEO at Qlevia. Anyhow, welcome to both of you. Maybe Ora, start with you. Tell the folks a little bit more about what you’re up to these days.
Ora:
Yeah, thanks, Larry. Well, you pretty much said the important part, I’m just in the process of having switched jobs, but I am also the co-chair of the RDF and SPARQL Working Group at W3C, and have been that for quite some time now. That’s, I guess, the important part here. Of course, I’ve had long history with RDF and started this whole thing back in the late ’90s.
Larry:
Yeah, that’s a little bit of an understatement to say that you’ve been involved a little while, but we can talk more about that later. Adrian…
Adrian:
Thank you, Larry. Happy to be here as well. Yeah, so well known probably for Zazuko, for a lot of the open source tools we do in the RDF knowledge graph domain. Some people know me for Qlever and QLeverize as well, where I’m a chief commercial officer right now. Qlevia, is basically my try to not have to talk about graphs anymore, so I want to scale the technology but solve problems, and for the first time venture funded, so that will be the next hopefully fantastic years.
Larry:
Oh, that’s exciting. Looking forward to hearing more about that, and I neglected as I introduced you, the reason you’re here is that you’re co-chairs of this committee.
Adrian:
True.
Larry:
Yeah, so one of you talk a little bit about, and maybe Ora, the history of the project and how the need to upgrade to 1.2 came about.
Ora:
Right. Well, so we go all the way back to the first version of RDF. In the late 90s, it introduced something that we call reification, which basically lets you talk about RDF statements, so RDF graphs are all about statements, where you say things like, “Adrian’s nationality is Swiss.” That would be like a statement, but then sometimes you need to talk about the statements themselves. So if, for example, if I wanted to say, “Adrian believes that the moon is made of cheese,” I don’t necessarily want to say the moon is made of cheese, but I want to talk about the fact that Adrian might think this way. And so, reification was a mechanism to accommodate something like this. Interestingly, if you look at the draft versions of the first RDF specification, the reification kind of started out fairly close to the top of the specification, and in consecutive version, it moves further and further back. I always think that, once it got published, it became sort of the most misunderstood and most hated part of RDF in many ways.
Ora:
It’s a little cumbersome and misunderstood, because I think people took some of the stuff too literally, but over the years, people have suggested various ways of “fixing this,” and a little over 10 years ago, there was a paper called Reification Done Right that was written by a couple of my former AWS colleagues. That got people sort of reengaged with the idea of reification really should be fixed somehow, and it turned into a community group at W3C, called RDF Star. Community groups at W3C have this kind of like a lightweight process. They cannot produce specifications. They can only produce final reports, which can then be input to working groups at W3C, which can be chartered to produce actual WTC recommendations. When I say recommendation, for those listeners of yours who don’t know, recommendation is the term that W3C uses for something that some other organizations might call a standard. I think that sort of originally the term implies that W3C has no enforcement authority of any kind. People implement the recommendations if they think that they’re a good idea and that they promote interoperability.
Larry:
Interesting. I always wondered, because the authority before, as a candidate recommendation, I always thought that was kind of odd language, but that explains that.
Ora:
Right, so the end goal here is to produce something or publish something that’s called a recommendation, and then that would be an official W3C standard for all intents and purposes. We’re now in the what? Fourth year of running what originally was called the RDF Star Working Group, but we’re now called the RDF and SPARQL Working Group. The term RDF Star has been dropped, and what we are working on is, first of all, RDF Version 1.2 and also SPARQL Version 1.2. So those are the things that will come out of this working group. I guess we’re here now, because a few weeks ago we went with the first two specifications. We proceeded to what W3C called a candidate recommendation stage, which is the milestone where we indicate that all the internal reviews W3C have been concluded. W3C has these, what they call horizontal reviews, where things are scrutinized for security, accessibility, and the overall sort of compatibility with the idea of the web architecture.
Ora:
Now, basically, we are soliciting for public comment and implementation experience of the new specifications. The two specifications that are in this stage now are called RDF Concepts and Abstract Syntax, and the other one is called RDF Semantics. The semantics document is basically the formal logic based semantics of RDF, and the concepts basically introduces everything in RDF. These documents that we’re producing, they are essentially next versions of the RDF 1.1 counterparts, so they not only introduced the new things that we’ve been working on, but also include all the old stuff. There were things where we had to kind of tighten the language a little bit from things that I feel the RD 1.1 work should have included, but didn’t, and then we had to do things like that. We took the work of the RDF Star community group and ran with that. Some of that changed actually quite a bit from the community group days. Then, we were also chartered to kind of fix things and do minor sort of housekeeping work, so there are some other new things that got introduced as a consequence.
Larry:
Yeah. One of the main things, like there were a surprisingly small number of new vocabulary items added to the spec, the main one being, and maybe one of you can talk a little bit about the new RDF Reifies property. That was sort of like the whole point of this, it sounds like, was to deal better with reunification. Is that sort of the one place where that all kind of rolls up, the ability to reify more elegantly?
Ora:
Adrian, do you want me to give a quick explanation and you can add to that? So actually, the big deal that we introduced is something called a triple term, so the RDF abstract syntax, so the meta-model of RDF, consists of terms and then statements. Terms can be IRI references, formerly known as URI references. They can be blank nodes, and they can be literal. This was in RDF 1.1, and we introduced one new kind of term, which we call triple term, which basically, in many ways, behaves a lot like a literal, but it’s sort of a representation of an entire triple, an entire statement.
Ora:
A triple term can then be matched to things in the graph, and so now the ability to talk about triple terms gives us the ability to talk about statements, but there are some interesting twists in this. Technically, speaking, triple terms can only appear in the object position of another triple, and there is a property that allows us to take, let’s say, an IRI reference or a blank node and use that as the identifier of a triple term. Then, once the triple term is given an identifier, that is sort of like an occurrence of that triple term. Then, that identifier can be used to make new statements about triples. Normally, if you are authoring RDF, let’s say using the turtle syntax, you do not actually see the RDF reifies a property, because we provide syntactic shorthand, sort of synthactic sugar for the usage of this.
Ora:
Now, what comes with this idea of triple terms is that triple terms and the RDF reifies relation let you talk about triples, independent of whether those triples have been asserted or sort of have been included in your graph or not. That allows me to say things like, so if I have a triple that says, “Moon is made of cheese,” or sort of moon has material cheese, I can talk about that without actually asserting that, because asserting things in RDF basically means that we believe they’re true. If I put that in my graph, the moon has material cheese, then basically it says that I offer that as ground truth, but I may want to talk about the sort of confused illusions that Adrian has about the moon, and so I may want to have that triple. I may want to talk about that without asserting that.
Larry:
I feel like we should give Adrian a chance to defend himself as a moon cheese believer. No, but seriously, I’m wondering if there are other examples, because that’s a really clear example, that ability to refer to the triple statement itself. That must afford all kinds of other opportunities. That’s probably what drove the whole need for tidying up reification. Is that correct?
Ora:
Sure. Adrian can add to this if you have your favorite examples.
Adrian:
Let me just take a step back. I think you mentioned before, Ora, that initially reification was an important part. I started with RDF probably 12-ish years after you, so back then, when you looked at RDF as an outsider, you didn’t see that anytime soon. When you actually started looking into it, at some point you found this very strange thing called RDF reification, where they explained to you that you now have to do triples about triples by basically saying, “This is the subject. This is the predicate. This is the object I’m talking about.” I mean, as someone which started with RDF from an engineering perspective, this sounded extremely verbose, extremely expensive for triple stores, and extremely annoying for querying, right? So, my natural reaction to reification in that form is like, “I’m never going to touch that. That doesn’t look like something I would use in the real world.”
Ora:
And you would not have been alone in this.
Adrian:
Exactly, and I think that’s exactly it, right? A lot of people dismiss that, because it was simply too complicated, too expensive. Remember, scaling RDF was hard, right? We didn’t have Qlever back then. You tried to avoid a lot of triples, and this added a ton of triples to your graph basically, not speaking about it’s not fun SPARQL-ing it, basically. So, with what we have right now, we can finally have that thing in an object position. This is super, super important. As Ora said, we can identify it and then start talking about it like this would be a blank node identifier. It’s very, very similar to that. So, then we can start to make constructs that were expensive, but then again, as Ora said as well, in the end, we will most likely either use a front end for creating this data, or if we have to write it manually, we’ll use serializations like turtle.
Adrian:
We will use the syntactic sugar in turtle, and we will use the syntactic sugar in SPARQL. That makes it a lot easier to query, and I think, for me, that’s what most people will take away from RDF 1.2 if they want to use reification. They get an easy, understandable, at least comparably understandable way of talking, like making statements about statements, which is extremely powerful. Then, last but not least, does the triple exist or not mainly has implication on reasoning. That’s maybe also interesting to explain to people, so if the statement does not occur in your triples itself, it would not be used for reasoning, so then you can make this weird statement about me thinking that the moon is made of cheese, but it wouldn’t have any reasoning implications, so you wouldn’t figure out that the moon is a dairy by definition then when you would reason. That wouldn’t happen.
Larry:
There is some complicated and precise math that underlies a lot of this, right? That permits that precise reasoning. Are you the right person to ask about that, Adrian, like the role of that, how important that is to the foundation of the model?
Adrian:
I would just like a very, very short remark, and Ora can answer the hard questions afterwards. I recently was in the call with Pat Hayes, and he talked about reasoning, and he made a super, super nice statement. He basically said, “The whole reason why we talk about these things and created RDF is that we can reason on data. That’s the reason why we don’t have just strings.” This was something which is so obvious when someone like Pat Hayes states it, but I never saw it that way. I think this is, for me, the big differentiator to labeled property graphs.
Adrian:
There are tons of differences, but that’s the most important one. You cannot reason on something like labeled property graph, because it’s not made for that. It’s just strings. So, in RDF, we do have this feature, and when you have this feature, this has a ton of implications, as we learned with OWL and the ongoing discussion between SHACL and OWL is part of that. When do you use what? So, this was very, very important in the RDF star working group as well, or now RDF 1.2 spec. We talked a lot about these implications, and we had to make sure that we get that right.
Ora:
Yeah, this is exactly right. I think that when I talk with people about labeled property graphs, and people say, “Well, we can reason over label property graphs.” And of course that’s true, but then you’re reinventing everything, and the RDF was built for reasoning. An RDF was built for interoperability and the interoperability of reasoning, and so we could imagine, for example, introducing some kind of a rule engine that does things for your labeled property graph, but then you would be inventing that and ignoring the fact that it took us years and years to reach agreement on how some of these things would work.
Ora:
Larry, when you said there is some sophisticated and complicated math underneath this, I would say that it’s very precise. It’s not necessarily that complicated. The good news is that most people don’t really have to so much worry about this. We’ve kind of done the hard work for you, and at this point I have to say a few things about the working group itself. We have managed to assemble the absolute pinnacle of RDF expertise in this working group. We, basically, have the people we need to pull this off, and that includes people who we can trust will get the formal semantics correct. This has taken a while, mostly because, first of all, we have 20 plus people meeting once a week, and they all have their own ideas about what should be done. W3C process requires that we reach a consensus on these, so we try not to compromise, but we try to reach consensus.
Ora:
Yes, I suppose there are complicated things, but the complications really arrive or sort of happen because we want to keep things simple. I think that this working group has had all the discussions that need to be had so that once we are done with this, the day after, we won’t get these comments like, “Well, did you not even consider this?” I’m pretty confident now that I can say, “Yes, we did consider that,” whatever that is. We’ve had so many different kinds of discussions about how RDF should evolve, and I’m confident that once the standard is completed, we have a very nice result.
Larry:
Yeah. I think it was before we went on the air, I think you were talking about some of the challenges, that one of them is like to do this really precisely right, you have to be off in the future someplace. You have to predict, you have to anticipate every possible. With 20 of the best RDF people in the room, is there a good example of some issue that you really had to chew on to resolve?
Ora:
Well, I mean, I think a lot of how this whole, this RDF reifies relation works took a lot. I mean, literally weeks and weeks, if not months and months of discussions, sometimes very heated discussions. For several months now, we have been in a position where all the big things have been settled, and we’re just basically cleaning up details now, and there are a lot of details. So, interoperability is hard. Backward compatibility is hard. We are still working a little bit on, the W3C would like us also to consider forward compatibility, which I find to be an extremely hard idea. I mean, backward compatibility, you know what you have to be compatible with.
Ora:
The forward compatibility requires one of two things; either the people who came before you have to have had great forethought in how some standard might evolve, or you need a time machine so that you can go back and change things in the past, and we have neither at this point, unfortunately. There are some details of RDF 1.1 that were left unspecified, and we’re in the process of fixing those, but on the other hand, we have almost 30 years of work on RDF and people building RDF-based systems. It’s not that simple to go and change things without invalidating large bodies of work or large amounts of effort that have come before us, so this is a tricky task. We have to tread very lightly.
Larry:
As you’re talking, you’re reminding me of your co-author Juan Sequeda’s frequent comments about, “This is socio-technical work,” and it sounds like there’s a lot of that people stuff in this as well.
Ora:
There is a lot of people stuff, but then when it comes to a standard, ultimately this comes down to some really, seemingly, small technical details, which turn out not to be so small.
Adrian:
But that was interesting for me, because as I said, I was not involved in the earlier standards, and I think only by working with this group, I became aware of how much thought is put in the RDF specifications. We said several times, both Ora and me, if you don’t use RDF, you have to reinvent it poorly at some point, and I think this couldn’t be more true. You have, Ora said, 20 plus people spending three, four years just in this iteration, basically once a week, at least an hour, many of them, many more hours on the specs themselves, so if I would summarize it, I would say the group went through all the pain, so you don’t have to, right? That you can actually use it.
Adrian:
You can trust us that we did think about some things, and that we tried to get the things right, and you can really build on top of that. I think other groups completely underestimate what it actually means to build a standard. I don’t want to point fingers, but there are specs which are basically specs by vendors, and this leads to a ton of problems on implementations. In RDF, we have those as well. We’ve noticed that in SPARQL, there are some edgy, hairy edge cases, like EXISTS, for example, which the group spent probably weeks in a team of SPARQL experts as well, of addressing this. This is just one part of the SPARQL spec, so you can imagine what this means if you skip this, if you just build something without this effort. You will never have a reflected standard like that, and you will run into a ton of problems that you didn’t see coming, basically.
Larry:
Yeah, that’s so true. I’ve seen examples of it. I’m wondering, because I’m sort of an RDF evangelist and a standards advocate, and I would love it. Do either of you have a really good story? Because that’s such a hard thing to convey like, “We did all this hard work in the background, so you don’t have to worry about it, but here’s an example of something that went haywire, that if somebody hadn’t…” Does that make sense that is there a really good use case or example, that shows the benefits of all this hard, behind-the-scenes work?
Adrian:
I really love the example, so two years ago, we did an event at Roche in Basel, where Hanan Q from BMW came and showed her use case about, basically, using reasoning on the cars for addressing features in cars. Cars that you buy today have a ton of features. Depending on which ones you buy, you get them enabled, so most of them are in the car. You might not get them if you didn’t pay for them, and she said she’s doing reasoning on the car, using RDF, because it saves me literally millions of lines of code that someone would have to write and maintain.
Adrian:
I think that’s such a nice example. I see the same with large language models. I think large language models work so beautifully with RDF, because it’s declarative, because a lot of the heavy work is basically offloaded to engines, to declarative systems, and we wouldn’t have that without that standard. We wouldn’t be able to do, I don’t know, 80% of the things that we do. In a labeled property graph, you would have to write so much code to do the same thing, so for me, that alone is simply a reason for the standard, and there are many, many more.
Ora:
And standards are interesting, particularly when it comes to RDF, because back in the ’90s when we started this work, the nature of standardization was very different. Basically, industry got together to codify something that was already established practice, so standards never came about introducing new stuff. Standards were all about, “Oh. We’ve been doing this for a long time. Now we understand how to do this, so let’s agree on a few ground rules.” But RDF is sort of the cornerstone and building block of the semantic web, and semantic web in itself is kind of like a team sport. I mean, you can play alone, but it makes less sense.
Ora:
Semantic web is really about interchange of information, interoperability, and things like that, and so the first RDF standard was really about establishing kind of rules of the game for this team sport so that more work could be done. People often don’t understand this, that we did a lot of this work, that somebody would now have to do and get a lot of people together to agree on things. Over the past 30 years, we’ve on and off improved the RDF standard to kind of tighten things, clarify things, and sometimes introduce new features, and this 1.2 version is going to be yet another step in this journey.
Larry:
Nice. Well, hey, I just looked at the clock. I know Adrian has to run in just a couple of minutes, and we also should wrap up, but before we wrap up, is there anything at last that either or both of you would like to either revisit from the conversation or just make sure that we share before we wrap up? Adrian, since you have to go, I’ll ask you first.
Adrian:
I think what I absolutely loved, Ora mentioned it, I mean, it’s year four now. We are still on average 15 people once a week in this call. We have people behind the scenes that commit every week a ton of changes in the specs. People, some of them, unfortunately, left us, like Gregg Kellogg, which passed last September, but we have many, many others, Andy Seaborne, so many names. Have a look at the contributors in the specs.
Adrian:
It’s so nice to see that these people dedicate so much of their private time into this specification again, that we don’t have to, that we can benefit from it. This is beautiful. This is what open standards, open source, open data, all this stuff is about. I think open source, open data, open standards belong together, and we need these people. It lives from these people, and it will generate a ton of value for enterprises as well that use that in their business. Sometimes I think people under-appreciate that, and I’m happy to promote that a bit and say it’s a nice thing to do. You should join us when we are crazy enough to do RDF 2.0, which at some point we will have to do.
Larry:
I will certainly help you recruit people, but yeah, and I appreciate that. I appreciate that so much, Adrian. Ora, anything last from you?
Ora:
Yeah. I want to emphasize more on this idea of openness. I mean, not only is the end result going to be an open standard, but we’ve done the work, out in the open, and so all of this work that we’ve done on, and we have 20-plus documents that we’re working on, many of which are in the so-called recommendation track of W3C, all of these, there are GitHub repos for these, and you can go see what’s happening. The archive of the mailing list is out in the open, and all of this, we have a fantastic degree of transparency in this, so this is truly an open standard.
Ora:
Open standards are really great, because they prevent things that organizations often don’t consider upfront, but then later on kind of get bit by. So, vendor lock-in, for example, so you choose somebody’s system and then you realize later on that you don’t like it, but now you’re kind of stuck. Open standards are way out of this. SPARQL endpoint. You have a graph database with a SPARQL endpoint. Switching database engines is not that hard. Your data is compatible with many different tools. It’s interchangeable and allows you to build open systems, rather than closed systems that come with all the trouble of being stuck with something.
Larry:
Nice. I love it. When you mentioned both the enterprise and the vendor examples, it’s a good reminder that this really is just about codifying a bunch of, not just, but largely about codifying a bunch of lessons learned over the years in these standards. That’s just awesome. Hey, one very last thing for each of you. What’s the best way to connect? If folks want to follow you online or connect, where can folks find you?
Adrian:
For me, find me on LinkedIn. Message me there or send an email to adrian@qlevia.com.
Larry:
Thanks. Ora.
Ora:
Yeah, I hate to say I actually don’t remember, off the top of my head, what my new email address is, my professional email addresses, but find me on LinkedIn. Send me a message on LinkedIn. I’m the only Ora Lassila on LinkedIn.
Larry:
Nice. Well, thank you both so much, and thanks so much for your work on this standard, and thanks for taking the time to talk with me. I really appreciate it.
Adrian:
Thanks, Larry. This was fun.
Ora:
Thanks.
