Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
Shortly after the semantic web was introduced, the demand for discoverable and shareable data arose in both research and industry.
Tom Plasterer was instrumental in the early conception and creation of the FAIR data principle, the idea that data should be findable, accessible, interoperable, and reusable.
From its origins in the semantic web community, scientific research, and the pharmaceutical industry, the FAIR data idea has spread across academia, research, industry, and enterprises of all kinds.
We talked about:
- his recent move from a big pharma company to Exponential Data where he leads the knowledge graph and FAIR data practices
- the direct line from the original semantic web concept to FAIR data principles
- the scope of the FAIR acronym, not just four concepts, but actually 15
- how the accessibility requirement in FAIR distinguishes the standard from the open data
- the role of knowledge graphs in the implementation of a FAIR data program
- the intentional omission of prescribed implementations in the development of FAIR and the ensuing variety of implementation patterns
- how the desire for consensus in the biology community smoothed the development of the FAIR standard
- the role of knowledge graphs in providing a structure for sharing terminology and other information in a scientific community
- how his interest in omics led him to computer science and then to the people skills crucial to knowledge graph work
- the origins of the impetus for FAIR in European scientific research and the pharmaceutical industry
- the growing adoption of FAIR as enterprises mature their web thinking and vendors offer products to help with implementations
- the roles of both open science and the accessibility needs in industry contributed to the development of FAIR
- the interesting new space at the intersection of generative AI and FAIR and knowledge graph
- the crucial foundational role of FAIR in AI systems
Tom’s bio
Dr. Tom Plasterer is a leading expert in data strategy and bioinformatics, specializing in the application of knowledge graphs and FAIR data principles within life sciences and healthcare. With over two decades of experience in both industry and academia, he has significantly contributed to bioinformatics, systems biology, biomarker discovery, and data stewardship. His entrepreneurial ventures include co-founding PanGenX, a Personalized Medicine/Pharmacogenetics Knowledge Base start-up, and directing Project Planning and Data Interpretation at BG Medicine. During his extensive tenure at AstraZeneca, he was instrumental in championing Data Centricity, FAIR Data, and Knowledge Graph initiatives across various IT and scientific business units.
Currently, Dr. Plasterer serves as the Managing Director of Knowledge Graph and FAIR Data Capability at XponentL Data, where he defines strategy and implements advanced applications of FAIR data, knowledge graphs, and generative AI for the life science and healthcare industries. He is also a prominent figure in the community, having co-founded the Pistoia Alliance FAIR Data Implementation group and serving on its FAIR data advisory board. Additionally, he co-organizes the Health Care and Life Sciences symposium at the Knowledge Graph Conference and is a member of Elsevier’s Corporate Advisory Board.
Connect with Tom online
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 35. With the introduction of semantic web technologies in the early 2000s, the World Wide Web began to look something like a giant database. And with great data, comes great responsibility. In response to the needs of data stewards and consumers across science, industry, and technology, the FAIR data principle – F A I R – was introduced. Tom Plasterer was instrumental in the early efforts to make web data findable, accessible, interoperable, and reusable.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 35 of the Knowledge Graph Insights podcast. I am really delighted today to welcome to the show, Tom Plaster. Tom is the managing director who leads the knowledge graph and FAIR practices at Exponential Data, which is a company in the Boston area, or he’s in the Boston area. So welcome Tom, tell the folks a little bit more about what you’re up to these days.
Tom:
Thanks, Larry. And great pleasure to be with you and the audience. So I’m now, just last week I hit a year at Exponential Data, after 12 and a half years at big pharma. And so, I came over to Exponential Data to lead the knowledge graph and FAIR data practices, and also to unite with our expertise around artificial intelligence. One of the things that I started to get really excited about with the knowledge graph conference over the last few years was the convergence of these two communities, and really how AI knowledge graphs and especially FAIR data, as a way of having curated trusted data for these applications, could be completely synergistic. And so that was really what brought me there. And when I joined, we were around 40 people. As I was leading this practice, we grew to about 240. And were recently acquired by Genpact.
Tom:
And so, now we’re now part of a much bigger organization bringing our strength of artificial intelligence, generative AI, knowledge graphs and FAIR data to this larger organization. So that’s been really my journey over the last year. And really wanted to bring these two technologies together. And one of the things that we’ve really found is how important FAIR data is to both sides of the equation. And so, this is really where trusted data, clean data, data that follows standards, data that’s self-describing, all of the things that you want to do for FAIR data, are really important foundationally for what you want to do with knowledge graphs and for how you want to give this trusted data to large language models, generative AI, to get the most out of those technologies. So in a nutshell, that’s been my journey over the last year.
Larry:
Yeah. And we didn’t talk explicitly about it as we were preparing for this, but AI is the logical and obvious place where all this is going now. And I think everybody’s concerned about delivering trustworthy, clean, FAIR data wherever you are. But do you feel like have you been uniquely well-prepared for that with both your company but… And I know your background, that’s what we want to talk about today, is the origins of the FAIR data standard and you’ve been around it right from the get-go right?
Tom:
Right from the beginning. And the community leans a lot on earlier trends around the Semantic Web, Semantic Web technology. I think a lot of the founders are very web centric in their thinking. And there’s a direct tie between with Tim Berners-Lee, Ora Lassila, Jim Hendler wanted to accomplish with the Semantic Web, how the standards evolved there and then grew up and became available within graph databases, eventually knowledge graphs, as a vehicle to prove that FAIR data worked. And so, that’s a direct thread between that and wanting to have knowledge injection for generative AI and the value there. The whole thing flows really, really well.
Larry:
Yeah, interesting. And one thing as you said that the direct descendants from Tim Berners-Lee’s and Ora and Jim’s, I guess the paper in Scientific American, one of the things that arose like, I don’t know what, five or 10 years after that was Tim Berners-Lee’s notion of five star data, like the kind of 1, 2, 3, 4, 5 star rating. And then only, what, five, not five, seven years later, FAIR came along. Can you talk a little bit about how these perceptions of and the way good data and their practices are codified?
Tom:
Sure. So if we think about five star linked data and kind of what Tim was trying to accomplish there, get your data on the web, having an accessible format, follow standards, have it linked together, that’s really, really close to the FAIR data principles itself. And I think a lot of the things within the FAIR data principles were learned directly from that. And I guess first I should take a step back and explain. People have probably come across the FAIR data principles, and they’ve heard Findable, Accessible, Interoperable, Reusable, and they think there’s four of them. There’s 15 of them. So this is where it gets to be a little bit more complicated. So FAIR as an acronym was just a very nice way of marketing and putting these things together, but a lot of the ways that they can become really useful is the cell principle. So I’m just going to talk about them and describe them real briefly without being too technical. People can learn more about it in the 2016 Nature Medicine paper.
Tom:
So the findable is really about URIs. And so it’s really about can I identify both an instance of data or a concept, a class that follows a URI, later an IRI, and sometimes we’re calling them persistent identifiers or GUPRIs, so Global, Unique, Persistent Resource Identifiers, all the same thing. So can you use that to identify a piece of data, and if so, when you resolve it, will it provide useful metadata for both humans and machines? That’s really the most important piece that you need to do to get started. Let’s put an identifier on our data, on our metadata, so that we can resolve it, find it, put it in an index, so that we can get something useful out of it. So that’s about four of the F principles there.
Tom:
Accessible is really about interoperability and it’s following common protocols. So HTTP, HTTPS, we’re not reinventing protocols, we’re following standards. And then authentication on top of that in some sort of a certified manner. Usually it ends up being LDAP with single sign-on or something like that. Some way of authenticating your data. And accessible becomes really important because it’s what makes the distinction between open data and FAIR data. FAIR is not necessarily open. You’re going to have times where you’re going to have data that needs to be protected, whether it’s things like patient data, medical records, or even licensed commercial content. So one of the ways that the FAIR community was able to get the publishers such as Elsevier on board, was to say, “We’re not going to make your data open. We’re going to make it accessible.” And so, this is one of the reasons why the publishers like Elsevier, like Nature, became early proponents of FAIR data.
Tom:
Interoperable, it’s really about the vocabularies and the knowledge exchange format. So you need to have one. If it’s standard space even better. And if your vocabularies are something that themselves also FAIR, so that they point to each other, they take advantage of each other, that becomes a really powerful way to inject the semantics into your data. So where you get all of the self-describing things that you want out of this data set by having interoperable FAIR vocabularies. And this could be an ontology, it could be a taxonomy using something like SCOS. This is also where potentially you want to bring in your rule systems like Shackle, so they’re going to really help with interoperability.
Tom:
Reusability, the last one, is really about bringing the first three together, making sure that you’re following any licensing and access rights on top of this, following whatever community standards are needed. And then detailed provenance lineage tracking. So again, it’s a lot more than what’s just in the five-star linked data, but everything five-star linked data is, is deeply embedded within FAIR.
Larry:
That’s really interesting. I’ve read that list a dozen times and everything you just said makes perfect sense, but I’m realizing that FAIR, it’s a brilliant… It worked really well as a marketing thing, because people get that. But what are the details, for somebody who’s onboarding to a new job where they haven’t worked with FAIR data or haven’t had to comply with the FAIR data standard before, how important is it to dive that? Because additional level of depth you just provided, that’s not a huge deep dive, but it seems really important to really have a handle on the details of each of those letters in the acronym.
Tom:
Yeah. I think that’s been one of the real challenges with FAIR data and with FAIR data adoption. So the paper itself describes the FAIR data principles. It doesn’t describe an implementation pattern. And so, that was deliberate, and that was done because many of the early practitioners coming out of a predecessor project, there was an IMI OpenPHACTS was a predecessor project where we learned how to take common bioinformatics, and other informatic data sources, and pull them together in a knowledge graph and come up with some reusable patterns. That one was a project that led to the birth of FAIR data. We can talk about that a little bit more if we want.
Tom:
There was one implementation pattern that was done there, which was basically have a knowledge graph underneath it, constraint it with APIs, and then provide that as a service. The implementation pattern was not prescribed within the paper. We wanted deliberately multiple implementation patterns to happen, so that we weren’t telling people, “You have to follow FAIR principles,” which everybody’s going to agree to. I mean, they’re going to look at these and go, “Oh, yeah, these are just common good ways of codifying data on the web. It’s a direct lineage from what you would expect from linked open data.” So I don’t think there would be much controversy there, but once you start getting the implementation patterns, right away, people are going to go, “Well, can I use my relational database for this? Does it have to be a knowledge graph?” And so, rather than really wanting to force a choice about making somebody have to put everything into a knowledge graph or graph database, I think we really wanted the community to experiment for a while.
Tom:
That happened and then eventually there were FAIR implementation patterns that were developed. I think more often than not, they have at least some linked data component to them, and there are certain standards that we see all the time. So for example, DCAT is a way of describing data catalogs at the level of, I have a file, I verified it, I want to make sure that this is something that I can find again and that I can manage all of the metadata around access to this particular file. Everybody uses DCAT. We’ve combined around a couple of URI patterns that are pretty powerful. But that wasn’t the intent. So this is, I’m going a little bit far afield from your question, Larry, but… Maybe I’ll let you reel me back in for a second.
Larry:
No, no, no. I was going to say, but it’s still super interesting to me because I’ve done kind of systems, they more like design systems in enterprises and stuff like that, and seeing other things like that where they often fail because you specify an implementation. So the fact that you anticipated that and did not do it, do you think that led to the success of the… Because it seems like quite a successful standard at this point. Do you think that’s part of its success?
Tom:
So I think it’s been both a curse and a blessing. So on the one hand, it did allow for multiple different implementation patterns to happen. And so, some of them went pretty far in particular academic circles, which was also one of the real drivers for FAIR to be born. Government funding agencies wanted a way to show at the end of a project, especially some of these big systems biology projects with omics data, a way of sharing that data back with the public. So as a repository for this public information, FAIR was really helpful there. So then in some ways, there was a really good implementation pattern that happened within those communities, especially within Europe, but it didn’t necessarily translate either to commercial entities or across the Atlantic.
Tom:
And so, there were lots of different ways that we could do FAIR, and there still are lots of different ways that you could do FAIR. And so, I think now it’s later as we’ve developed a small number of implementation patterns really headed by groups like the GO FAIR organization, headed out of the Netherlands, that brought a lot of this together, and have really shown the value of collapsing in a couple of powerful implementation patterns.
Larry:
Yeah. So you mentioned the GO FAIR initiative in the Netherlands. Are there others like that, or is that sort of a model, or is it just an exemplar of that category of a… That’s like the meta implementation, the support for implementations of it, is that?
Tom:
So that’s certainly one of the major organizations in the FAIR data community. Some of the other ones that I’ve had the pleasure of being part of are things like the Pistoia Alliance, which is a pre-competitive consortium primarily within the pharma and biotech space. And it’s both in Europe and the US. And along with a couple of like-minded colleagues, we were able to start a FAIR implementation team within the Pistoia Alliance, which has led to things like the FAIR Data Cookbook and a couple of other projects coming out of Pistoia. We do work closely with groups like GO FAIR and some of the other FAIR organizations, to really evangelize, show these common implementation patterns. So for example, one of the projects that we’re involved with right now is this idea of a pharma general ontology. And so here, it takes as a basis that companies are heading and have FAIR data ambitions, but what they really want to do is make their data interoperable within the company and then potentially outside of the company, then also to vendors in this space, CROs in this space.
Tom:
So what Pharma General Ontology, or PGO, attempts to do, is find some common vocabularies and some common definitions for things in the life science space that we care about, so that we can agree on that. So give you one example. There’s a disease ontology called Mondo, that is a very comprehensive cross-map disease ontology covering ICD-9 code, MeSH, MedDRA, human disease ontology, and many others. Because they’ve already done this work in this community, basically what we have to do is say, “All right, is this fit for purpose for how we are thinking about describing the concept of a disease or to a lesser extent related indication?” And so those sort of ideas of let’s find those common vocabularies that can be used broadly, now mean if we’re exchanging data within this consortium or across the consortium where we’re trying to get vendors to follow certain standards, rather than saying, “Pick one standard out of the 4,000 or so plus that are used in our space, here’s one that we agree on that I think most people are going to drive toward.” And that also helps with the whole idea of building consensus around implementation patterns.
Larry:
Yeah. Well, because when you mentioned the fact that the PGO is designed both for internal use and industry use, I know this can be dicey, but the political issues around that, were they significant or is it just kind, I assume, it’s a little bit of a known issue in any standards thing that you’re going to hit those concerns, like enterprise concerns versus industry concerns, but how did that manifest in the birth of FAIR?
Tom:
So I think we were fortunate that there were a lot of people within the scientific knowledge management community, the systems biology community, that really did want to come together and share their data, make their data interoperable, do it for public health reasons. I think there’s a really similar cultural aspect between that and the knowledge graph community, especially since there’s so many people that participate in both. So we know there’s going to be disagreement. We know that top-down is not necessarily going to work. So this is one place where you do have some top-down coming from standards agencies, ISO in particular. So you have to figure out how to make your internal concepts, whether it’s within a company, within a group within a company, say research versus commercial. So you do have to figure out where do you have your points of consensus and your points of commonality, and then where do you have your points of disagreement, and how can you build a structure that lets you work really well and really seamlessly within that structure?
Tom:
Well, this is something within knowledge graphs is pretty easy. So we think about layering, we think about different name spaces, we think about when we want these things to come together,, we think about building off of definitions that are agreed to in the public space. It’s the same thing for the FAIR community that you just pick those definitions. And you don’t have to agree everywhere, you have to agree when you have points of intersection.
Larry:
That reminds me back to the start of this, you talked about the overlap in old school, RDF knowledge graph people and this alliance. It sounds as you’re talking now, I’m like, “Well, duh,”” that just seems like a… You said there’s at first a lot of overlap, but also very common concerns in the kind of problems you’re addressing. I’m reading that right?
Tom:
Yeah, I think that’s spot on. I think that’s spot on.
Larry:
Yeah. Yeah. That’s really interesting too. And it doesn’t make getting stakeholders to agree on language any easier, but at least the mechanisms by which you ensconce it and all that, that’s a little smoother. I guess, what percentage of the stuff you dealt with was people stuff and what percentage was, I guess, people and culture versus technology and procedures?
Tom:
Yeah. So I think you’re now at a topic there that’s near and dear to my heart. So I started off as a scientist, as a systems biologist, as a bioinformatician, and the challenge that I had was all of these massive cross omics data sets, so it could be genomics or proteomics or metabolomics or imaging or clinical chemistries, whatever. And I wanted to make sense of them. And so, I became a bit of a computer scientist or technologist after being a biologist first, because I wanted to use graph as a way that made sense to me to be able to bring these things together. And then I’ve had a chance to see the knowledge graph industry grow up around that idea of using this as a way to serve and solve real deep biological medical problems.
Tom:
So you don’t have to go too far when those problems are going to be cultural problems. You’re going to have all these disagreements about technology choices. You’re going to have all of these disagreements about how you define things. So I think you have to approach this in such a way that why you’re here. And the communities that you’re trying to build are really about solving big problems. And big problems where you have to approach it with some humility that you’re not going to have all the answers. So if you have an approach that’s very, very flexible, that lets you build gradually, that lets you not get locked into technology, that’s FAIR and that’s knowledge graph. So they go hand in hand.
Larry:
The way you said that, it’s making more and more… This made sense to me before we started talking, but it makes more and more sense as you talk about this, especially the logical and natural things that arise, and the fact that both people committed to FAIR principles. And that’s really interesting. Was pharma and the life sciences in general an ideal proving ground in that? Are there things in that part of the academy that lend themselves as well? Did they also fit this little knowledge graph and FAIR data interest approach?
Tom:
It’s an interesting way of looking at it, because I think it was born out of academic systems biology projects in Europe that really wanted a way of serving that data up to the public, paid for it, after the projects ended. A lot of those same challenges around data stewardship existed within pharma. And so, the groups that were there at the beginning of, either the OpenPHACTS projects or the FAIR Plus Project, an antecedent project or predecessor project that came around afterwards to build a FAIR Cookbook, they’re a mix of academics, government agencies and the EFPIA seven pharma partners in Europe. So it’s always been that hybrid. And so, I think the ideas around data stewardship came out of either academia with government wanting to make sure that the data was served up with the public.
Tom:
But then within industry, we recognize quickly that a lot of these things apply to us. Not everything, because we’re not necessarily going to be setting up big data repositories for public consumption, but if we’re thinking about things like secondary use of patient data within the understanding of disease space, so those sort of things, we’re going to need FAIR data principles for. We’re going to need self-organizing, self-describing data that’s readable to machines and humans, that will allow us to make some decisions on this, both to get the most out of the research that we can, but then also to protect the data as we move along. So yeah, I think that’s a natural fit. I think part of the reason that it starts off in research is that’s going to be your most collaborative part of the enterprise. There’s certainly some primary research that’s going to happen in the pharma setting, but not as much as we can do with partners in the academic setting or the government setting. So because those sort of collaborations are very natural, it made a lot of sense for it to be born there.
Tom:
Now that said, I’m seeing it grow elsewhere quite a bit. So that’s been one of the revelations of leaving the research setting within a pharma company, is I do get to see it in commercial, I do get to see it in manufacturing. And so, I think more and more of these systems, which might’ve been a little bit more closed because that’s just not their culture, are really benefiting from FAIR.
Larry:
Interesting. Yeah. I was talking to a friend the other day about manufacturing supply chain, not just manufacturing, but big electrical grid stuff, and the importance of agreeing on how long is that turbine? What’s that part? How does that… It almost seems to me like that would be a stronger case for it, but I don’t know all the industry dynamics. But it’s interesting. So they started with pharma and the life sciences, and then has it rippled out from there? Is that your sense or…
Tom:
I think it’s really starting to. I think that those… And this is me being relatively new to that part of the industry. They tend to be driven more by a few big tech vendors that have reasonable starting points for their solution, but they don’t necessarily take advantage of the web yet in their thinking. And so, it took a long time for a lot of the big tech vendors to really adopt, and this is part of the reason why new players like Google became so dominant, because they were born on the web. And so, I think part of that too is we’re now still seeing companies that are adapting to this, that are adapting to their web thinking, that have had a pretty decent run for a long time by providing good products that were very tailored in scope. They can take advantage of this or not. And if they don’t, then we’re perfectly happy in my company to come up with alternative solutions that are FAIR knowledge-backed solutions.
Larry:
Yeah. As you talk about that, that’s really interesting that the more native an industry is to web and web ideas, like that notion of sharing in the biological sciences versus, I don’t know, Boeing and Airbus probably didn’t share a lot of stuff. I don’t know if they do to this day. But those kinds of relationships, is there a predictability about the age of an industry and its likelihood to adopt FAIR standards?
Tom:
I don’t know if I would look at it that way. Even for somebody like Boeing or Airbus, they’re going to have supply chains with a lot of the same suppliers, and the auto manufacturing as well too. So it’s going to behoove these companies to push standards on all of their suppliers. So I think in some ways they probably are going to be more interoperable than pharma and medicine. They just might not have thought about it this way. So I think in some ways pharma can lag a bit because there’s all of the regulatory requirements that are in place. I think that slows things down quite a bit. I mean, it’s still, I think the figures that I’ve heard most recently are 10 years and $2 billion to get a drug to market. And so, there’s been the push for efficiencies in that for an awful long time.
Tom:
And you can do it in the research side early, you can do it in the clinical trial space. There’s still a big gulf between adoption for when something is approved and when it penetrates into the market deeply enough and becomes part of the standard of care. So there’s a lot of room for improvement in my industry first. And so, I think some of the other industries can probably move faster and can take advantage of this too.
Larry:
Well, yeah. And that’s an interesting thing about pharma, is that you’re just reminding me of it’s pretty much all about genuine innovation. I think some industries are probably optimizing things. I’m just making up macroeconomics in my head here. But one thing, as I think about the scientific heritage in this, I remember 10 or 15 years ago, I used to go to a lot of science meetups and stuff when I lived in Seattle, and there was a lot of talk about open science and open data. And I know that’s become a thing in many government places, especially here in the EU. And as you’re talking about these commercial entities, I don’t know anything about the practices and standards in industry around things like people advocating for openness. Was that a big thing in the birth of FAIR, was just that common desire for openness?
Tom:
I think there was an awful lot of the people that were pushing for open science, especially on the academic and government side, were there at the beginning. So they were there in the OpenPHACTS project. They were there in the FAIR Plus projects, the different IMI initiatives that were pushing this in Europe. I think one of the things that happened pretty early on, was in order to get industry involved, we had to protect the data rights pretty strongly. So this is where accessibility rather than open became one of the main points. So whether it was you wanted to have licensed commercial content that was in here, or even if you wanted to have patient records, so you have to have ways of protecting that. So this was something where, I think, the FAIR community has been able to take advantage of a lot of smart work in the ontology community around patient standards, around data access rights, around consent ontology, and other places, where there’s now a standard in place or sets of standards that are emerging. They can help with this.
Tom:
So yes, we want open data, yes, we want to be able to benefit from that, but we also want to protect privacy. So I think it’s more important that we have mechanisms in place that we can share when it’s possible both for humans and machines. And if it’s not possible, then you need to be able to restrict it and have all of the provenance and audit trail behind it, so you know how it’s used.
Larry:
Yeah. And you mentioned earlier that that’s built into FAIR. So yeah. Hey Tom, I can’t believe we’re coming up close to time already, but I feel like we’ve given this… But before we wrap up, is there anything last, anything you’d like to revisit from the conversation or just make sure we share before we wrap?
Tom:
Yeah. I threw out a couple of teasers early on about generative AI and FAIR and knowledge graphs. And so, I would say that is a really interesting space. I think that it’s one of those things where we’ve seen a lot of really good convergence between knowledge graphs and the GenAI space about how knowledge graphs and ontologies can help constrain some of the things that will happen within your large language model or even your medium-sized language model. That’s all really great work. In terms of putting some structures, some more foundation to both the LLMs and the knowledge graphs, that’s where FAIR becomes really powerful and really valuable. And there’s so much existing work that’s in place already around the vocabularies, around ontologies that are commonly used, especially in the biomedical space, and now more and more in the manufacturing space, especially in the life sciences industry. We’re not starting from scratch.
Tom:
And so, I think not just thinking about, naively, companies are going to look at it and go, “What’s your AI strategy?” And so if you have an AI strategy, you better have a knowledge strategy. If you have a knowledge strategy, you better have a FAIR strategy. So I’m probably out on a limb a little bit on the third part of that pillar, but I think that’s where some of this needs to go.
Larry:
That lines up with a lot of stuff I’ve been hearing lately. So I think that’s quite plausible and really, yeah, it makes a lot of sense to me. So that notion from AI to knowledge strategy, to you better have your FAIR house in order at the very foundation of it. Yeah, that’s great.
Tom:
I’ve got a slide that I use all the time, Larry, that’s a pyramid with FAIR at the bottom, some sort of a data mesh in the middle, and knowledge graph at the top, or knowledge graph assistant AI at the top. So you’ll probably come across that on some of my talks.
Larry:
If you could send me a copy of that, I’ll put it in the show notes so people don’t have to go digging. Yeah, that’d be great. Well, hey, one very last thing, Tom. If folks would like to connect with you or follow you online, what’s the best place to find you?
Tom:
So LinkedIn’s probably the easiest place. So that’s TPlasterer is my LinkedIn handle, so just T-P-L-A-S-T-E-R-E-R. Should be able to find me there. We do blogs every once in a while. So that’s probably the best place to start.
Larry:
Okay. Yeah. The default place these days. Well, thank you so much, Tom. It’s always great to talk and this was really… We never got to nerd out before on FAIR, so this was really super helpful.
Tom:
Oh, pleasure was mine, Larry. Thanks for the invitation.
