Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Android | Youtube Music | RSS
Jessica Talisman is a seasoned information architect with decades of experience across a variety of domains.
She’s done a lot of education and outreach around her semantic and and information architecture practices. One of the most important lessons she’s learned is the crucial role of standards like the W3C SKOS model to bring structure and semantics to information and knowledge systems.
Since there are never enough information architects in any organization, she supports the democratization of IA practices, but she’s also quick to highlight the unique skills that you can only get with deep study.
We talked about:
- her work as a senior information architect at Adobe and previously in GLAM (galleries, libraries, art, and museums) and other domains
- how her work in GLAM showed her the importance of the concept of lineage and attribution and benefits of the FRBR (Functional Requirements for Bibliographic Records) framework
- how standards and rules bring discipline and structure to information and data ecosystems
- how capturing knowledge via the SKOS standard can provide on its own the structure, semantics, and disambiguation your data needs, as well as set you up for future successes
- the importance of focusing on semantic fundamentals and how the ensuing understanding if your data assets can improve activities like a graph RAG implementation
- the importance of collaborating and sharing ideas across domains
- democratization, evangelism, and other kinds of information architecture outreach
- the “Golden Spike” railroad metaphor she uses to illustrate cross-functional collaboration challenges
- how linked data can help span organizational silos and align stakeholders on language and terminology
- the importance of understanding your unique organizational fingerprint
- how applying the library science concept of “scholarly communications” can move organizations forward and promote innovation
Jessica’s bio
Jessica Talisman is a Senior Information Architect at Adobe. She has been building information systems to support human and machine information retrieval for more than 25 years. Jessica has worked in a variety of domains such as e-commerce, government, AdTech, EdTech and GLAM. Jessica holds a Masters in Library and Information Science with a concentration in Informatics. She lives in Santa Cruz, California with her partner Dave, and two dogs.
Connect with Jessica online
- LinkedIn – Jessica is working on a new book about information architecture and is looking for anecdotes and other input. If you’re an IA practitioner with good stories to share, she’d love to connect.
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Knowledge Graph Insights podcast, episode number 12. Anyone who has tried to discern how people in a domain talk about the concepts in it, and then try to align stakeholders in an organization around those concepts and the words that describes them, and then share that information with computers so that you can scale the impact of your work, knows that you need a good system to manage your taxonomies and other terminology. Jessica Talisman argues that the W3C SKOS standard is your best friend in such endeavors.
Interview transcript
Larry:
Okay. Hi everyone. Welcome to episode number 12 of the Knowledge Graph Insights Podcast. I am really delighted today to welcome to the show Jessica Talisman. Jessica’s currently a senior information architect at Adobe, but she is extremely experienced in information architecture and knowledge graph stuff, so welcome Jessica, tell the folks a little bit more about what you’re up to these days.
Jessica:
Thanks, Larry. So I’m currently, as Larry said, a senior information architect at Adobe, and before this, I was information architect over at Amazon. I’ve worked in many different domain spaces, but my original foundational experience is in information and library science and I worked as an academic librarian in the past with books, museum galleries, library, art, and that really gave me the foundational experience and information and knowledge necessary to do my job.
Larry:
Nice. We were talking before we went on the air about how, especially your art and gallery and that kind of curation, tell me a little bit about how that … It seems like that was really foundational to your current practice or it’s been influential. Tell me why. Is it there’s something about the nature of those collections or what’s going on there?
Jessica:
One of the most critical things when working in that space in galleries, libraries, art. It’s called GLAM, which is actually a great acronym for galleries, library, art and museum, and within the GLAM space, provenance and lineage is something that cannot be ignored because you’re dealing with works, whether it be print books, art obviously, an attribution to the artist or writer and that’s instrumental to building information in library spaces within that domain space. And so that taught me a lot about linking records. There’s a super interesting framework that from the library and information science background, it’s a framework called FRBR, which is Functional Requirements for Bibliographic Records. And the whole idea is to maintain the manifestation and expression of works, which is the lineage of a piece of art or a book and being able to support proper provenance and attribution of works while maintaining lineage for the benefit of people and machines.
Larry:
Nice. And it’s so clear when you think about how LLMs work and the current state of AI, it’s clear for the need for that kind of thing. Well, and that’s kind of jumping ahead a little bit too to what you do with this stuff after you’ve got it all organized. I think in almost every case, whether you’re like a data scientist, an information architect, content strategist, a museum curator, whatever, you start with this pile of concepts and words and then people like you turn them in to something useful to both humans and computers. How does that look? Walk us through the top level overview of that.
Jessica:
So normally no matter what, when I come into an organization or any sort of information environment or data-rich environment, there’s usually problems, identified problems. And those usually are not the only problems within an ecosystem, an information or data ecosystem. And so the idea of nomenclature or vocabularies is instrumental. It’s the foundation of how we discover and find things within that ecosystem. And so having to look at the current vocabulary and the current environment of how words are implemented, that starting point in understanding culturally and otherwise, how words are used and vocabularies used to not only define a domain space but to help support information discovery and retrieval within a space.
Larry:
Yeah, because that’s the classic … I mean I think the way most people would think of, they don’t know anything else about information architecture, it’s about discovery and discoverability and findability. But there’s sort of levels to that. I work more in the UX world and there you’re like, here’s how we’re going to talk about things. With content designers and UX writers, that’s a common thing. So you just end up with a controlled vocabulary or something like that where you talk about it, but there’s sort of a progression from that level all the way out to a full-blown ontology. How does that escalation happen I guess from when does it become clear that you need, “Well we really need to define these things,” so I guess that’s a glossary right now?
Jessica:
Well, in looking at that environment, so you have a series or collections and I like to use the word collections of vocabularies. Often they occur or exist as flat lists and there are usually internal belief systems that determine how these vocabularies are structured and implemented. Some are closely guarded. I will give the forewarning that within these spaces sometimes branding and marketing will be also pretty protective over the vocabularies used, but not understanding that these are meant to work on the back end of systems to help facilitate information retrieval and discovery. And so when building for back end systems, the lowest common denominator aside from a flat list or controlled vocabulary is to use something like an ontology like SKOS, which is Simple Knowledge Ontology System. It’s a very simple ontology that helps to structure a hierarchy and simple relationships that are machine-readable. And it’s something that that one standard and lightweight or upper ontology, there’s the characteristics that are included with that, but it’s super machine-readable and translatable, but it’s also human-readable, which is what’s really critical about that structure.
Jessica:
And so you can not only define parent-child relationships, alt labels or aliases and encode those with ontological labels, but there’s rule bases, there’s standards included with that which lines up with several other standards that exist for information retrieval on the World Wide Web. So having to structure and include those rule bases that are standards-based as well helps to enforce a certain type of discipline and structure within that information ecosystem and data ecosystem, which helps to guide people towards best practices and not only why hierarchies or taxonomies are important. But the introduction of concepts like thesauri or thesaurus, you can actually build a thesaurus using SKOS. So whether people realize it or not, that actually helps to shape a thesaurus. And then you can also have a very sort of primitive knowledge graph but still a knowledge graph using SKOS. So it’s like a nice little primer and entry to the world of structuring data and information to be disambiguated. So you naturally go through a disambiguation process and a structuring process that really takes into account and models information for how the human brain works in addition to how machines work.
Larry:
Because when you think about all of this work, it’s like taking a bunch of individuals’ mental models, ensconcing them in a system that everybody can agree on, which is no mean feat. But it sounds like SKOS is a real … Because I think a lot of people think SKOS is just a vocabulary manager, like a taxonomy manager, but it is itself an ontology and a way of organizing this, and I know you’re big on … Maybe talk just a little bit more about why SKOS is such … I mean you’ve mentioned all the reasons, the standards that enforces best practices. Is that alone enough for that to be the standard for managing terminology?
Jessica:
For many organizations, there’s no need to have anything more sophisticated than that because we often scale beyond what we are capable of managing. So it really is a realistic standard and ontology that it could be enough. For many ecosystems, we’re learning more and more with especially working with LLMs that the complexity does not win the game. Volume or the amount of information doesn’t necessarily win the game. But the idea of working synchronistically with LLMs requires structure. We all know that and it requires disambiguation. So structure, semantics and disambiguation, how do we achieve that? Something like SKOS might be enough for your organization, which is simply you need to structure and communicate that hierarchy and really basic relationships between things to start.
Larry:
And I guess what are the thresholds? When do you go from like, “Boy, that’s a nice SKOS taxonomy” and all the things we’re talking about are in there, what’s the threshold that goes from a nice collection of taxonomies or term lists or whatever into a full-blown ontology?
Jessica:
So when there’s a need to have more complex or detailed descriptive relationships between things other than related to or is related or related, just the simple word related, or narrower term, broader term, because that’s what the ontological labels render as when there has to be more detailed structures such as event or history structures. If you’re doing event structures where something happened or there’s something that is going to happen at a certain time or that there’s a facet or something that’s unique that needs more descriptive or detailed relationships. What’s nice is before you have to transition to a whole other type of heavier ontology or introduce more complexity, there’s SKOS-XL. And that is sort of the transitive or the bridge that helps you to build into using something like OWL, the open Web Ontology Language and then invoke other ontologies.
Jessica:
But the interesting thing is that with SKOS, you also can very easily bridge without much complexity to open ontologies such as friend of a friend. You can use Dublin Core. There’s really easy transition points and the lessons learned from starting with SKOS and then building from there is that all of the other ontologies requires that you have some structure to begin with. You can’t jump … It’s sort of like not knowing how to swim and jumping into the deep end, never having been in a pool of water. So it allows you to incrementally build and check all the boxes and even though it seems very redundant and slow and difficult and painful out of the gate, once you have that foundational corpus that’s well-structured with SKOS, you’ve set yourself up for success for introducing more complexity. So it should be sort of a scaled building rather than coming out of the gate hot and going straight for what you perceive as the end result without actually being mindful of your data and how it needs to be structured, shaped and defined.
Larry:
Right. And I’m wondering now the relationship between everything you’ve just talked about and how it can help these LLMs that are good at a lot of things but not good at the things you’re talking about. Tell me about how that’s … And that’s evolved so quickly. We went from just, it was all LLMs all the time two years ago and now then RAG and now GraphRAG, and now Symbolic AI. And tell me about how everything you’ve talked about can help, because I think everybody’s … It’s distressing to me how much that its AI equals LLM but that’s clearly not the case. Can you talk a little bit about that?
Jessica:
Yeah, so we have our perceptions of how to optimize AI and how to implement graphs correctly or vocabularies or GraphRAG correctly within a space, and those are usually tightly held belief systems that are coming out of, and forgive me for if I insult anyone, but coming out of the idea of sort of monkey see, monkey do and that you’re just going to replicate what you see in a space. For example, vectors. You see very often vector databases. That’s all that we need. And so as we transition, it’s introducing, and this is something that I’ve seen as being successful, is if your current implementation’s not working, you usually have to look at the base foundation of what you’re implementing, the very foundation. It seems sort of recursive or redundant or boring, but in fact an end, it’s very easy to want to take shortcuts that are sort of prescriptive and promise the world and that can be problematic.
Jessica:
So a lot of times it’s just returning to the fundamentals and looking at your core data. Is it well-defined? Does it represent my business and my business use cases? Is it well-structured? Have I captured things like provenance or lineage? Am I able to describe content or whatever the data artifacts are within an ecosystem? And really looking at what is necessary to mobilize and to make your internal data assets useful within that environment. Usually what we have is right under our nose. We don’t have to seek something outside of our own organization or ecosystem to create miracles. Like if your base idea or concept is to help to implement and successfully implement something like RAG within your own system, does it have to be GraphRAG because that’s what everyone else is doing? Does it have to be vector DBs because that’s what everyone else is doing?
Jessica:
Start with the most simple architecture, which would be something like SKOS or implementing something according to those information retrieval standards and measure and build iteratively so that you’re able to encourage those feedback loops within your own system. In terms of results from the LLM, how much juice can you squeeze out of rendering these results while if you build something too large or something that’s outside of what your data is capable of doing within your ecosystem. For example, if SKOS isn’t working, okay, let’s try to add a little bit more complexity on top. But you should always be returning and going back to your foundational data model no matter what.
Larry:
So that model, so let’s connect these together now. You talked about the importance of this data and everybody didn’t say data is the new oil and every enterprise is sitting on its own collections of oil. And so stitching that together from what you’ve talked about to getting the … I guess, and stitching it together specifically to business results. You thought you could throw an LLM at this and discern the entities and relationships and do this thing, but it turns out that you need to know a little bit more like you were saying the lineage, the structure, the specific structure of the thing. I mean, and the architectures like RAG start to get at that, but I guess what would be your dream scenario for the relationship between how do you think your work could best be leveraged in new kind hybrid AI architectures to get the business results that people expect?
Jessica:
I mean, GraphRAG, RAG does not have to be a graph. That’s the first sort of misnomer.
Larry:
Yeah.
Jessica:
Does not have to be a graph. You can actually use a pretty strong taxonomy because at base what you’re looking for is to infer meaning, define and disambiguate what these things mean, and have some sort of classification structure so that when there are results it can be properly classified and cataloged. That’s the base result. We need the input. It should be equally findable on both ends of the model. And so if the front end doesn’t match the back end so to speak, you’ve got a problem. That’s the fundamental. Are we over-architecting and over-building? Yes. Are we holding onto these dear concepts that are cultural within an organization or an ecosystem?
Jessica:
That’s something that I’m starting to reflect on my career and see more and more that our failure to encourage communication between domain spaces and collaboration across domain spaces has led to these sort of vacuums where, and it’s much like these sort of echo chambers within organizations where a tightly held belief, and I’ll give you an example, is like when you build vocabularies, it doesn’t matter if it’s structured. All we need are nouns. We need nouns and verbs. Everything needs to be a noun and verb. And that tightly held sort of concept or architecture, is that going to make the difference within your ecosystem? What is that principle founded upon? Is it a data science or a strange sort of NLP-ish type antiquated idea? And if those ideas keep on getting perpetuated and there’s no communication between what each of the domain spaces has to bring to the table, then you end up going down a path that’s very narrow and is not expansive and doesn’t take into account how you can best optimize your architecture to make sense to line up with your end goal.
Jessica:
So using that example, if you build a flat list or vocabulary and that is your rendition or the way that you structure data within your organization and every word must be a noun, how is that going to support your end results? Is that going to get you to being able to classify the results coming out of your LLM? That’s the first question. Is that going to really move the needle or make a difference? Have you seen a difference? What if you did a little experiment and you modeled something, for example, a vocabulary with SKOS, and you threw out the idea that everything has to be a noun and you AB test that. That’s like a pretty low fidelity test and that can communicate volumes, but it can also create that necessary feedback loop that’s going to break you out of this sort of rigid thinking that’s driving your organization not towards innovation, but towards repeating the same mistakes you’ve made up to now.
Jessica:
And that’s what I see happening over and over again is this lack of expansive thinking where your lone solo information architect comes into your space because usually you don’t have throngs of information architects or taxonomists or ontologists. And that person comes in and says, “Well, let’s try to introduce some of these concepts” like structuring things as a taxonomy following ANSI Z39, which is a standard to structure vocabulary specifically for information retrieval. “Let’s try these different things,” and if we’re so siphoned off where we can’t accept or introduce new ideas into a space, the other side of this coin is innovation and taking risks and scholarly communication, actually communicating between domain spaces, sharing ideas and innovating together. But founding those principles on actual proven information science and information retrieval principles because ultimately we’re looking to encourage to support information retrieval and findability within your results, your core results, whether it be with an LLM or without an LLM, you’re trying to support information retrieval for machines and people.
Larry:
Yeah. And that’s that mutual understanding between machines and people. And like you said, SKOS is the place to start with that. God, there’s so much you just said that I want to circle back to. Well, one of the things I want to circle back to is that notion that there’s never enough talent, that there’s never enough information architecture, taxonomy, all the talent you need to do this. And that kind of speaks to my favorite topic, which is democratization. It’s a hazardous thing to do in some contexts, but if you have an important task like this ahead of you and not enough talent, how can adjacent practitioners like data scientists, data engineers, content people or other information architects who are less adept at SKOS, for example, how can those kind of folks adopt what you’re saying and at least get closer to that foundation you say we need?
Jessica:
Well, and this is an interesting one because I’ve been thinking about this quite a bit, is when I look at other domain spaces like data engineering or data science, I’m not learning SQL or Postgres overnight. It’s not an overnight transformation, you give me a spec and then all of a sudden I’m proficient in it. To be studied and learned, it takes not only on the ground experience, but it also takes definitely some academic work or domain-specific experience and you’re going to have to read some books and standards and apply those then practically within a domain space. Something that’s interesting. I’m not saying don’t learn from podcasts. Absolutely, there’s some great resources out there. I suggest downloading the ANSI Z39-19 standard and reading through that. It’s pretty beefy, but it’s worth the read. And some of the SKOS standards, you can go to the linked open data cloud and just to start to understand how ontologies are leveraged within the open web, which by the way is how most LLMs are trained on that same structured available data that’s structured exactly with … You’ll see most of the base models have SKOS.
Jessica:
So if you think about that translation between training data to the post-processing, does it help to match the structure of the data? Sure. So that sort of experiential aspect is really important. The academic putting time into reading and understanding this domain space. And I will say something I’ve been looking at is San Jose State offers a remote and non-remote post-master’s certificate. And I know this would exclude those who don’t have master’s, but that certificate specifically can, it’s like a six- to nine-month certificate, that gives you a certificate specifically in information in library science. And so those types of programs are popping up at different universities. The American Library Association has only 16 approved schools for information in library science, and almost all of them are master’s level. They also call them iSchools now. And so it can seem pretty prohibitive and because most everything’s introduced or exists on a higher level.
Jessica:
But the most interesting thing is not only … When you’re an information architect you move into a domain space that for the most part within any sort of organization predominantly you’re not amongst peers. You are entering a space that’s very foreign to what you’re used to. It would be a lot easier for me to work in a library and be amongst my peers where I don’t have to explain so much, some of these concepts and principles and open up the dialogue to start to ideate around these concepts. And so there’s a really interesting perception where there’s an expectation because you’re a data engineer, because you’re a data scientist, a machine learning engineer that this is something you should just know and that you’re an expert in. And so just show me, give me three hours and I’ll master this. I can do it or just show me, point me to the taxonomy that I need to use. And in fact, this is a skilled area and it’s something that does require a little bit of reading and studying and stretching outside of your comfort zone.
Larry:
And it probably goes both ways. As you’re talking, I’m realizing it would be like you just said, it would be so easy to just get a job in a library and hang out with other librarians and that would be great but the real impact you’re making is because you’re hanging out with engineers and data scientists and all these folks and doing this. But it also occurs to me that they could be coming to us too. And so it seems like I’m thinking about democratization, but there’s also some evangelism and outreach and indoctrination and maybe cult indoctrination or something to get them on board with this stuff. Have you had any success that way, kind of getting data scientists, engineers, others, adjacent disciplines, more curious about this stuff?
Jessica:
Yes. Yes, absolutely. And it can take a bit depending on the organization. I do think that with LMS there’s been this sort of rushed anxiety about, and I equate it to the building of the railroad because I like to put things into metaphors, but you think of the building of the railroad and there’s that whole concept of the golden spike and it’s like we’re building railroad on, and this is specific to on either side, and this is historical of the Deschutes River, the Pacific Railroad. It was whoever reached the Pacific Ocean first and nailed in the golden spike would win the contract, would win the prize, the big prize of achievement. And they would sabotage each other across the Deschutes River and throw quarter sticks of dynamite to sabotage the progress of the other. And this whole journey reminds me very much of that in that it’s high stakes for a lot of these larger organizations especially, and there’s been so much investment.
Jessica:
And so I think that there does need to be a little bit of slowing down to have the logical conversations we were having pre this new AI boom and that’s going to be necessary for us all to take a deep breath and say, “Okay, let’s really look and assess where we’re at now” and open up dialogue and really examine what we’re doing well, what’s not working, what research is predominating this space, what research has already been done, what research is coming forward or out. And let’s see how we can holistically understand this space and our own space better and apply some of these other ideas and techniques.
Jessica:
And to your point, and I would say this is mostly pre-AI boom, what’s really interesting is I used to have this exercise where when I went into organizations, the first thing I would do would be get OpenRefine on the back end. Because usually with security and OpenRefine is a great tool. It used to be GoogleRefine for cleaning and organizing, structuring data, dealing with data. There’s RDF plugins, which is Resource Descriptive Framework. It connects, you can just out of the box, connect it with Wikidata, the Getty, all of these large knowledge graphs to validate schemas and stuff like that.
Jessica:
So usually a really fun way to start understanding and exercising in the space is with OpenRefine, and I’ll usually connect it with Wikidata to show them what’s possible in helping to structure and define a vocabulary because it’s exciting to connect it with and start to see how a knowledge graph works, for example, and how structured data works. And 9 times out of 10, in the past, pre-LLM craze, data scientists and data engineers would get so excited about it and they would build these sort of complex models and think that was the end of the game. And they would align vocabularies internally with Wikidata, which is okay. I wouldn’t say it’s optimal because there’s some flaws in that rendering and system plus it’s very noisy and big. But the idea is to use that as a way to get your feet wet and to feel empowered and enabled to structure data and connect it to other graphs and have those lines of communication through linked data apparent and open. And that is when the light bulb usually goes off, where people realize, “Wow, this is really powerful. This really makes a difference.”
Larry:
Because I think most people realize fairly quick that you’re never going to bust silos, but linked data lets you span silos. Is that … Yeah.
Jessica:
It lets you span silos and create sort of a common language and align internal languages and nomenclature, vocabularies with the outside world. So with the democratization of data, you have closed world assumptions, which is how an organization defines themselves internally, which becomes those sort of echo chambers. And then you have open worlds, the open world and the open world is how the rest of the world defines and understands the nomenclature or vocabularies and relationships between those things. Is it better to have one over the other? No, but there has to be some awareness so that you can reconcile the meaning and structure of things. Because your customers, this is like the most instrumental, because ultimately your customers, your external customers, if you’re public facing, is their mental model and is their structure and idea and definition of words going to align with your internal model? Or are they going to be more comfortable and understanding of how the rest of the world’s structured and organized?
Larry:
Nice. I love that every IA conversation always has to at least allude to Conway’s Law.
Jessica:
Of course, of course.
Larry:
But hey, to that also, I talked to Tony Seale a couple episodes back, and he talks about his ontological projector. That’s the purpose of an ontological projector view on the world. I’ve heard you talk about fingerprints, that your unique organizational profile is like a fingerprint. And again, that’s another powerful metaphor. You’ve got golden spikes, fingerprints, projectors. Does that make sense? Tony’s projector in your org would project your fingerprint to the rest of the world.
Jessica:
It would project your fingerprint, but then also it defines it in a way where you can create those reference points to the things in the outside world. For example, if you take the definition of something within your space, which is assets. How an internal organization like Adobe internally defines assets, which might be a subclass of a product versus assets and how it’s defined globally, there is also that reconciliation between those two points in space. And so there does have to be a reconciliation, especially now if it’s being implemented in the realm of RAG, that there has to be that reconciliation because whether or not we accept it, LLMs are trained on the open web, and that’s what you’re aligning your vocabularies with.
Larry:
Interesting. No, that’s a really brilliant insight. Hey, I could literally talk forever, Jessica, but we’re coming up close to time. But before we wrap, I want to ask, is there anything last, anything that you’d like to revisit from the conversation or that you just want to make sure we share before we wrap up?
Jessica:
I think continuing the conversations and where I think the real gold in these dialogues happens is in the exchange of ideas and the willingness to be thoughtful and reflective, and that we’re all sort of swimming in this space together and that it’s the exchange of ideas, something that in the library space is called scholarly communications, which keeps us from repeating each other’s research. It’s actually the foundation for innovation. And so I think one of the most exciting things and sort of the theme of our conversation around also democratization of data is that scholarly communications is the foundation of how innovation happens usually in the research domains and spaces, and definitely in the library and archives space. So I think it’ll be really instrumental for us to move forward as a whole, all of our different communities and continuing to exchange ideas and building on top of each other’s contributions to the space.
Larry:
That is fantastic. That’s a great note to end on too, the call to like, “Well, hey, we need to be interacting more. It’s all about keeping the conversations going. And by the way, there’s this well-established scholarly communications discipline that can facilitate this in a way that promotes innovation.” That’s fantastic. Well, thanks so much. Oh, one very last thing, Jessica. If folks want to connect with you or follow you online, what’s the best place to find you?
Jessica:
LinkedIn for sure. It’s easiest. And if you message me if you have a personal message or I would love if anyone shared anecdotes, just because I’m in the middle of writing a book that hopefully will be near done by next summer. It’s a long timeline, but I would love to hear some anecdotes from the wild, actually.
Larry:
Excellent.
Jessica:
Anyone who wants to-
Larry:
I’ll put that in the show notes as well. And it’s a fascinating book about the long history of information architecture and yeah, I’m going to have to have you back to talk about that closer to publication date.
Jessica:
Definitely. Yeah, I would love to hear people’s war stories and anything else they want to contribute because I’m knee-deep in it and want to hear other people’s experiences.
Larry:
Absolutely, yeah, we’ll get the word out on social media about that.
Jessica:
Perfect.
Larry:
Well, thank you so much, Jessica. I really enjoyed the conversation.
Jessica:
This was fun. Thank you so much for having me.
