Michele Ann Jenkins: Taxonomy as the Foundation of Semantic Architecture – Episode 200

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS

Through her taxonomy and other information architecture work, Michele Ann Jenkins helps people across the organizations she works with align their mental models and terminology usage.

This alignment of concerns and language forms the foundation of the semantic architecture that is so crucial to modern content systems.

We talked about:

• her work as a consultant focusing on taxonomy but also working on information architecture, search, digital asset management, ontologies, knowledge graphs, and AI
• the focus at her consultancy on technology-agnostic frameworks and best practices, including governance
• the threshold at which to move from a CMS’s built-in taxonomy tools to a dedicated taxonomy management tool
• her description of the semantic layer and how it can help span organizational silos
• the benefits of a technology-agnostic enterprise content model and how far most organizations are from having one
• how the practice of taxonomy can help stakeholders understand each others’ mental models and terminology
• how the well-established idea of “concept-based indexing” can help bring semantic clarity to terminology work and take projects from taxonomy to ontology
• the baby steps an organization can take into ontology and an example of how an ontological representation of enterprise knowledge can help auto-tag content coming from different sources and infer levels of trust
• some interesting examples of rule-based classificiations going haywire
• her exposure to working with a “content graph” with a complex globally distributed product
• how to find the “creative edge” where the capabilities of computers end and only human judgement is necessary
• the enduring importance of governance, people, processes, consensus building, and using open standards that permit interoperability

Michele’s bio

Michele And Jenkins, MLIS, is an information management consultant specializing in taxonomy-driven content strategy. She has more than 20 years’ experience working with organizations across various industries, including Harvard Business Publishing, EA Games, and the Office of the High Commissioner on Human Rights (OHCHR).

Michele takes a holistic approach to information and content management, drawing from a multidisciplinary background in programming, IA/UX design, information science, and publishing. She is skilled at guiding clients through the entire content management process: from creating high-level strategic roadmaps through development, implementation, and migration to ongoing support and training.

Prior to joining Dovecot Studio in 2012, Michele was an independent consultant focusing on web development projects including large scale migrations, platform integrations, and implementing taxonomy-driven IA designs. Michele has over 15 years of experience customizing, coding, and developing IA for Drupal CMS.

Michele has contributed a chapter to “Taxonomies: Practical approaches to developing and managing vocabularies for digital information” (Facet Publishing, 2022). She is also a regular guest lecturer and occasional course instructor at McGill University, where she earned a Master’s in Library and Information Studies with a specialization in knowledge management. She frequently presents at conferences including DrupalCon and Taxonomy Bootcamp (part of KMWorld).

Connect with Michele online

• Dovecot Studio
• maj at dovecotstudio dot com

Video

Here’s the video version of our conversation:

Podcast intro transcript

This is the Content Strategy Insights podcast, episode number 200. The practice of taxonomy plays a crucial role in tying together the worlds of content management and semantic practice. Michele Ann Jenkins is an information management consultant who specializes in taxonomy. Her work helps stakeholders understand each others’ mental models and terminology and ensconce them in technical content systems. For all of the tech, though, she’s always aware of where computing capabilities end and only human judgement will do.

Interview transcript

Larry:
Hi everyone. Welcome to episode number 200 of the Content Strategy Insights Podcast. I am really delighted today to welcome to the show, Michele Jenkins. Michele’s a senior consultant at Dovecot Studio. I don’t know what kind of … consultancy based in Montreal, she’s got years of experience in both web development and information science, information architecture, taxonomy. So welcome Michele. Tell the folks a little bit more about what you’re up to these days.

Michele:
Hi, thank you so much. Yeah, my name’s Michele and I am a consultant. We focus on all things related to taxonomy, but that tends to be sort of the linchpin into the broader world of information architecture, search, digital asset management, and more and more we’re seeing people branch out into more semantic structures to support ontologies and knowledge graphs and artificial intelligence processes. So some of the things on my plate these days are designing a strategy for enterprise search for a European organization with over 220 different content repositories. I work with other organizations that are much more web focused, a lot of Drupal sites, SharePoint, WordPress. And then whether it’s within content management system, organizing that content for dynamic delivery and menus and filtering and sorting, or getting things to talk to each other so that we’re supporting editorial workflows across multiple systems such as a product inventory, going to a website, going to a blog, going to a different website, and then to a customer relation management tool and a digital asset management tool. So all those sort of acronym soup that we see everyone dealing with these days.

Larry:
Nice. Well, it sounds like you’re really out in the future on this because when we first met about a month ago at a content management conference in Montreal, you did this great presentation where you kind of set the whole talk up around this notion of these … That most ecosystems are not like the ones you just described. I mean, this is why people hire you, that there’s these clunky, fragmented content ecosystems with multiple different CMSs, different instances of the same CMS. And the culmination of that in your presentation was there’s just no Marie Kondo in sight. There’s no organization here. So how do you go from … How do people know to find you? And then what’s the process for helping them along this way to the better semantic understanding of their content?

Michele:
Yeah, well, it’s a real niche area to be working in. So generally people don’t wake up in the morning and say what we need is a taxonomist. They’re kind of thinking in terms of we are setting up a new system and we need it to do something, or we’re realizing that these pain points of manual processes are just untenable. We see people with very content-driven ecosystems that still involve downloading a spreadsheet and emailing it to someone, or calling someone or having to manually sync things between systems and reconcile different language.

Michele:
And sometimes people just go ahead and Google and try and figure out who can help us with this very particular area. In other cases, we find that a lot of times the vendors are sending people to us. So if you’re setting up a digital asset management tool, they might demo, “Look at all this great metadata. We are able to manage hierarchical taxonomies and synonyms.” And people are like, “We don’t have any of that” and they don’t know what it is.And so we might have a vendor who says, “Why don’t you go talk to these folks, see if they can help you out, and then you’ll be able to take advantage of what’s in our system.”

Michele:
Most of our business is through referrals, so we just sort of have some good street cred and word of mouth. It’s very small world. There’s not that many people who really sit down and focus on taxonomy and semantic structures outside of their particular platform or tool or the broader web development vision. And sometimes it can fall by the wayside a little bit when people are caught up in that bigger idea of migrating content, designing visual layers, designing navigation, and really thinking about this plumbing behind the scenes when you’ve got the whole house to build can be difficult.

Larry:
Yeah, well, as you talk about that, I’m reminded of the increasingly or more frequently decoupled architectures that a lot of content people are working in. The separation, because it used to be with the old monolithic CMSs that everything end to end was in there, out to the templated outputs of it. You mentioned a number of different CMSs. Do you typically work with a certain category of CMS or are you in all these different architectural scenarios?

Michele:
So we try and design technology-agnostic frameworks. We’re building off of best practices. There’s an ANSI standard for taxonomy. You have your SKOS standard for capturing taxonomy in RDF. You’ve got obviously the whole world of ontology and OWL and all that. And so we come from an initial place that’s talking about a lot of non-technology things like governance. How do you decide what terms you’re going to use in a taxonomy? How do you define what the facets of your taxonomy are going to be? And those are true regardless of the system. And then we have to take into account the reality, and sometimes the reality is that a lot of CMSs don’t handle synonyms or don’t let you create taxonomy term metadata to extend what you can do with they’re calling them categories, or they’re calling them topics or tags. And you don’t have the ability to say, make a relationship between the two of them or even a hierarchy. So we even still see systems that can only manage a flat list and aren’t going to know that grapes are a kind of fruit and cats are a kind of animal.

Michele:
And so we then have to think in terms of what is the workaround going to be? We’re going to have to flatten all these lists, so we’re going to have to put the synonyms in the term label in parentheses. And so we take our beautiful technology-agnostic, well-designed best-practice-following taxonomy and do what has to be done to make it actually work within the system. That obviously means that we have some systems that we’re happier to work with and others that we know we’re going to encounter challenges.

Larry:
That’s interesting. And some of those decoupled architectures I mentioned include separate taxonomy or term management systems. How frequently does that come up for you? Are you often, not stuck, but obligated to work within a particular CMS?

Michele:
Yeah, a lot of times we recommend a strategy that starts by focusing on your WCMS because it’s the most visible and obvious choice for showing people the power of taxonomy. So just getting your content organized within your CMS to use taxonomy is to follow best practices for governing those taxonomies and start using some of the basic use cases around dynamic content placement and things like that. And just having the taxonomy live in the content management system is that starting point. As soon as you have two or three systems that are sharing the same taxonomy, you can for example, use Drupal just fine. Or if you have a headless CMS, maybe it’s feeding out the taxonomy. We see people use SharePoint Term Store have to write some PowerShell scripts or what have you to feed that out to different systems.

Michele:
Once you get more than that going on, you really want to look at having a designated taxonomy management tool as a source of truth, and then it can start owning that information and not just feeding it to the content management tools, but feeding it into other things like an enterprise search or other parts of what we call the semantic layer so that you might have a flat list in your blog. But behind the scenes the system knows that those are actually hierarchical terms with relationships and that can be taken advantage of, say in your search results or in some of the other processes going on in other systems. So again, as you abstract out that taxonomy and that semantics, you can give each system what they can handle, but behind the scenes it all comes back and it’s all reconciled into something that’s more cohesive and more powerful.

Larry:
And that’s the semantic layer, right?

Michele:
Yes.

Larry:
I mean that’s an interesting term. I mean because it’s coming up a lot these days as companies and entities that do the kind of work that you do to describe that sort of organizational layer in between the apps and the data and the content they’re sourcing. I know this happens all the time, somebody corners you at a cocktail party and asks for a description of what the semantic layer is, how would you describe it?

Michele:
I mean, it is like a fuzzy edged box, but I would put into it both the technologies that are actually storing things like the taxonomy and ontology as well as things that are a little bit more abstract. Like if you have a metadata schema or a common metadata standard that says, “Hey, all of our systems have to have a title and a subject and a source of truth or system that they’re sourced from, and that’s what you need in order to be interoperable and then your taxonomy as well.” So you could say it’s the technology that’s storing things, but I really think it’s a little more abstractly, those semantic structures that we are taking out of just having them embedded in say a SharePoint Term Store and saying, “Look, we have a taxonomy. It’s managed and maybe it’s managed in a spreadsheet. Maybe it’s managed in a really complicated enterprise ontology management system.”

Michele:
But in that semantic layer, you’re able to make connections between say how your marketing team talks about things versus how your product management or engineering team talk about things. So you might have very machine-friendly labels that are in your PIM, and we have to map that to Viper Red color for the marketing website so that all can live in there. So I think it is interesting when we say semantic layer and everybody goes, “Oh yeah, semantic layer.” And then it’s like, “Okay, but what do you mean when you say semantic layer?”

Larry:
Because the first category you mentioned, the technology that stores it, that’s a pretty finite set of tools and technology that provide that. Whereas that abstract layer, I can’t remember, there were back-to-back conferences in Montreal when we met. I can’t remember which one it was at, but somebody brought up the idea of a technology, maybe it was you, a technology-agnostic enterprise content model as a way, just to understand the content part of it. That would be part of that second category.

Michele:
Yeah. To me, that would be part of that idea that we all know what an article is now and we all know what pieces an article is supposed to have and things like that. And a lot of organizations are very far from that right now. So there’s people definitely coming at different levels of maturity of thinking about their content outside of, I’m going to put a blog post up, or I’m going to put a new product on the website, or I’m going to put something on the internet. And starting to think about what these things have in common and when they need to have differences and when they don’t to start letting that content flow a little bit more freely instead of having to have these manual processes or repetitious duplication of effort.

Larry:
You’re getting now into the area of silo spanning and silo connecting, which is one of the benefits of this conceptual layer.

Michele:
Yes.

Larry:
How frequently do you have success actually doing that, helping marketing and product better see? Is that a pretty common outcome for you?

Michele:
Well, I’d say the technology is the easy part. It’s not easy, but the technology is definitely there to do that and getting people in the room together, we’ll have meetings where we’re workshopping some aspect of semantics or defining our facet use cases and you end up doing introductions because these people have never been in the same room together.

Michele:
And you’ll have little conversations like, “Oh, we say ocean.” “No, we say marine.” Okay, are those the same thing? Are they not? Why are they or why do these things need to be different? Sometimes parts of the organization want to be different just to be different, and sometimes you find that actually there is nuance there, there is a different perspective and you can’t just lump things together. So taxonomy to me is a way into these conversations about the different mental models that you’re going to get, whether you’re on the public facing marketing side versus the engineering side of things. And making that explicit in your taxonomy by stating these things are synonymous or they’re synonymous enough for us or they’re only synonymous in this context and not that context. All of that does actually do a lot to engender some trust that people’s perspectives are not being overwhelmed.

Michele:
I think a lot of times there’s a concern that there’s going to be a top-down idea that you all have to speak the same language or use the same terminology or you’re going to lose something that’s useful. And doing some more deep dive into why things are different and do they need to be, and really on a knowledge management level, build some bridges, if not break down silos. I don’t know if you can always break down the silos. Sometimes they’re there for a reason. But at least be creating paths between different parts of the organization so that they can have more reasonable discussions.

Larry:
The episode right before this one, the guests, they’re not optimistic about ever breaking silos. I think a lot of people aren’t. But that notion of being able to spam them is still very useful and what you just said about the terminology. That reminds me of, well, two concepts. When people ask me about this stuff, I talk about that Google, I think Google originally coined it, the notion of things not strings.

Michele:
Yes.

Larry:
We’re all talking about the same thing here. There’s a similar thing that comes out of I think, cultural anthropology, the notion of boundary objects where you have a-

Michele:
Yes.

Larry:
Yeah, and so can you talk a little bit about that? Is that a good way to think about the underlying … You kind of just gave examples of how it is the notion of synonyms and similar terms for the same thing. Is that a good way to think about it or are there other approaches?

Michele:
Yeah. Yeah, you move … I mean we used to call it concept-based indexing, like the idea that you’re going to relate the idea of a heart attack. Medical research found that doctors were capturing the idea of a heart attack using 104 different strings of writing. So it was myocardial infarction, it was different abbreviations on that, it was all from handwritten doctor notes. But they’re like, “If you break these down into character strings, there’s 104 different character strings and the concept is this person is undergoing a very clearly described medical situation.” And how do you bring those together? But the importance of semantics goes beyond just being synonymous or not. When you talk about something like is a doctor a physician? If I’m trying to make an appointment for my kid because they have a cough, yes, I want an appointment with a physician, I want an appointment with a doctor. If we’re doing medical credentials, no, they are two different things. A doctor is not a physician.

Michele:
So you end up having these moments where you need more semantics than simply saying these are the same thing. You need to be able to say these are the same thing in this context or for this purpose. So I think there’s a lot to unpack and that we talk a little bit about maturity. Having strings, then having things, having things with synonyms and then going further and saying, “Look, we’re going to actually describe context and worldviews and map those together so that we know we can get from doctor to physician and we know when we’re talking to patients.” These are more or less synonymous for the purpose of content delivery. And then when we’re talking about medical professional credentials, we need to make a distinction here.

Larry:
Interesting. Is this where we leave the world of taxonomy and get into the world of ontology?

Michele:
Yeah, exactly. So we started having layers upon layers, and you can get there through some baby steps of saying, “We have our terms, we have synonyms for our terms, and we have a hierarchy for our terms, and then we’re going to start having relationships between terms and we’re going to name those relationships.” So a tire is part of a car and then you can start making small inferences, even if you’re not using a high-end ontology tool, if you’re just in Drupal or something, you can say, “Tell me about the things that are related in this particular way.” And you start little one- or two-step graph traversals that can then lead to more important stuff.

Larry:
Interesting. It never occurred to me that like a CMS like Drupal can handle a well-structured taxonomy, it can handle basic inference like you would do typically with OWL or RDFS or something.

Michele:
Yeah, yeah. Very basic because you’ll start seeing some load impact if you do more than a couple of leaps, but you treat terms as entities and entities can have relationships and those relationships can have names. So you can say things like, “Show me all the articles that are about companies in this industry,” and that’s a little baby graph. So I think people can start playing with some of these concepts in a very understandable and straightforward way before you get into things that require set theory and a PhD in math.

Larry:
Exactly. Which I don’t have, but I spend a lot of time with those people and-

Michele:
That’s where I stopped, there.

Larry:
No, but also I think just having this understanding that there is a … I don’t know if this is what you call this, but this seems analogous to that maturity model you described earlier. In that you were describing kind of going … The slide you did at the presentation kind, I think from just tags-

Michele:
Tags.

Larry:
Bundles of words.

Michele:
Pre-text.

Larry:
Pre-text tags to a taxonomy to a … I guess for some kind of controlled terminology first, then a taxonomy, then an ontology. It sounds like from what you’re just saying that there might even be … There’s baby step ontological stuff you can do in a simple tool like the taxonomy stuff in something like Drupal. What’s the maturity scale in that ontological world or have you thought about that?

Michele:
You mean how complicated ontologies…?

Larry:
Yeah.

Michele:
I think that that inferencing part is the real leap for people because you go from something that’s fairly straightforward and understandable, which is very explicitly put. I mean it’s traversing a couple of steps, but you’ve explicitly said that this is related to this, which is related to this. When you get into real ontologies, you’re saying things like, “I’m going to tell you who my father is and who his brother is, and therefore the system knows who my cousin is.” And I have not said to the system that this is my cousin. It knows what a father versus a brother versus the child of the brother is. A more content management version of that would be, we have recipes for a nonprofit that deals in a particular disease and rather than tag the low-sodium salsa recipe with the particular conditions, we’re tagging it with “low sodium” and we can infer that low sodium recipe is going to be relevant if you’re dealing with hypertension. Not because we’ve tagged it with hypertension, but because there’s an understanding that low sodium is one of the factors that goes into controlling hypertension.

Michele:
So people have to start trusting the process and things are getting inferred metadata basically. We know another one is in a situation where you have a lot of systems that don’t have much metadata, but they’re being aggregated together, say into an enterprise search system, you can determine the security classification based on where it came from. This came out of Confluence, so we know it’s not terribly secure because it was in Confluence and it’s a very straightforward idea, like a business rule basically that says “If it’s coming from these systems, we’re going to go ahead and assign metadata to it.” You can determine metadata based on understanding who the person was, where they put it, what kind of content it was, and then it’s going to infer it into a class, basically adding metadata to it based on its understanding of how that organization works, which is that they don’t put classified material onto Confluence.

Larry:
You’re reminding me now of, I had a conversation a while back with a friend about different kinds of knowledge graphs. And the two biggest ones that you hear about, there’s a lot, but the product graph like at Amazon or the economic graph at LinkedIn, and those are kind of broadly speaking, like product, core product, your business entity’s main-thing-that-it-does graphs. But it’s the enterprise knowledge graph, which I think is what you were just talking about. In this enterprise context, we know that this system is trustworthy and has security that we can better trust stuff, whereas Confluence, we know how it’s governed, that’s described ontologically someplace, and therefore we can infer that something that comes out of Confluence is maybe not as canonically correct or something is-

Michele:
Exactly, exactly. Yeah. So you can apply levels of trust and understanding, but it does mean that you don’t have necessarily a human applying that metadata and people have to … And then if something ends up someplace weird, you can’t just look at a list of business rules to say, okay, the troubleshooting and the tuning on these things, when you get into making real ontological … Offloading that work to an ontology means that later on you have to have quite a bit of work to figure out like, okay, wait, why did it think that that was a frog when we can clearly see that it’s a fish? It’s like, oh, I had content about Condoleezza Rice being tagged, topic is agriculture.

Larry:
Wow.

Michele:
And then everything about diamonds ended up in alcohol because of De Beers.

Larry:
Oh, interesting.

Michele:
It took a while to figure out what was going on here, and these were very straightforward rule-based classifications, but it was looking for things. Now, if we knew De Beers ontologically was a diamond company, you would avoid some of that.

Larry:
You’d never have that problem in a proper knowledge graph implementation because you’d know that it was a company.

Michele:
But somebody has to sit down and either get that information, find that information, verify that that information is relevant to their organization’s worldview and codify it, which is a big heavy lift to start out with. But then you turn the machine on and it chugs away and over the long run you have a great benefit from it, but the lift at the beginning is pretty daunting. So I do see a lot of value in these baby steps and doing little ontology-lites to get people comfortable with what is going on and in an understandable, incremental way before asking them to contribute to and develop and manage something that’s a lot bigger and a lot harder to understand.

Larry:
And I just realized that kind of took us into enterprise knowledge graphs, and this is a content thing. And I’d love to come back and you’ve done some of this real practical concrete on-the-ground content stuff. You work at EA, Electronic Arts, I’ve talked to Aaron Bradley a lot about his work and you two work together there, and that’s an application of knowledge graph technology that I think is way more germane to most content practitioners. Can you talk a little bit about how, and did you call it content graphs there? I’ve heard that term used.

Michele:
Yes. Yeah, Aaron was one of the first times I heard content graph.

Larry:
In terms of a day-to-day content like strategist or design or something working with, you’re collaborating with an ontologist or a taxonomist and you’re trying to figure out how can they help me? I remember that one of the things that Aaron talked about a lot was the age restrictions and-

Michele:
Yeah. That’s what I was going to say. The ratings in countries, that’s a great example because each country belongs to different rating boards that define age groups and ratings differently. And all of those things together mean that you’re able to take the people out of the loop so somebody doesn’t have to sit down and figure out what’s going on with Germany and what sort of things, which games they’re allowed to promote to someone who is 14 in Germany. And so you have this merging of graphs because you know things about the person, what games they previously played, how old they are, what country they’re in. And then you know the country has a rating agency, the game has a rating, and so this piece of content from a newsletter can or cannot be included in something targeting that person. That’s that content bit is that you’re actually making content decisions based on an ontological understanding of the person, the products and the world.

Larry:
It seems like a really good use case or example of the benefits of an ontology, because you know that there’s this concept of ratings and of geographical differences or country or jurisdictional differences, whatever that is, you can tidy that all up and sort it out. I think a lot about that, what is it? Mutually exclusive collectively … Anyhow, that whole like a place for everything and everything in its place. Because that’s a really complex, and that’s one of the things I like about that example is it’s a really complex example, but as I recall from Aaron’s conversation, it seemed always that you could figure that it was an implementable system that you could rely on to serve the correct content. That whole idea of content strategy is right content, right person, right place, it seems like an important step in that.

Michele:
Yeah. But it is a challenge to reverse engineer the knowledge management, but the tacit knowledge that content workers will have, they will try and have an understanding of their audience and this is how I do it and I get a good feeling for what to send out and to take that and unpack what is going on there. I think the things that are a little bit more rigid, like don’t send R-rated Nazi stuff to a kid in Germany because it’s going to be a big problem, that’s a little bit clearer because the rating agencies have clear definition of ages. Countries most of the time are pretty clearly defined, and the relationship between the rating agency and the country is very clearly defined. When you get into what is somebody going to want right now after they finish playing that game, it gets a little bit more abstract and building the rules, I always wonder where that point is where people are just better.

Michele:
When is it worth deconstructing what someone knows into rules or into an ontology versus the fact that people are really good at some things and they can do it much faster and more agile than keeping an ontology up to date is going to be. So I think there’s an interesting line of where is the value to use machines to do what machines do really well, which is fairly clearly defined that we can get into some more and more fuzzy stuff with ontologies too, like contextual things and things that might be sort of true some of the time and how well they handle that versus when a person can just look and go, “That doesn’t feel right. I don’t like that.” So where’s that creative edge versus what the machines can do the heavy lifting for?

Larry:
And my friends in the knowledge graph world sell the ontology – the beauty of it is that it’s that representation of knowledge and agreed upon lore and knowledge that both machines can get and humans can get. And you’re saying, “Nah, you still need some human judgment in there.” So that’s just something to keep in mind.

Michele:
You keep that human in the loop, but also just that creative part, which I say belongs in marketing as well. Getting a feel for trends and audiences and what’s the next cool thing, we will always try and automate that, but I think there’s a value in letting the people do what people do well.

Larry:
Yeah, I’m always happy when there’s still a role for people in all this. Hey Michele, I can’t believe that we’re coming up close to time already, but before we wrap up, is there anything last, anything you’d like to revisit from the conversation or just share before we wrap up?

Michele:
I think one thing, just as a key takeaway, and I think this came up at the conference that we both attended, is that the technology is exciting, it’s moving fast. I love the headless CMSs and the idea of content APIs and knowledge graphs and things like that. But the underpinning importance of standards and governance and involving people and making sure that these things are built to serve the needs of actual people and the organization both because it’s the way to build bridges, it’s the way to facilitate the organization to keep doing a good job and not imposing something as a top-down, unilateral decision and instead being able to encapsulate what people need and what people are thinking of and the mental models they have. So just the importance of governance, people, processes, consensus building and using open standards ideally to allow interoperability aside from building big technology solutions.

Larry:
Yeah, I’m a huge fan of standards myself and it’s one of the reasons that drew me to that whole RDF stack. But hey, one very last thing, Michele. If folks want to connect or follow you online, what’s the best place to connect with you?

Michele:
So you can go to dovecotstudio.com, our website and we have a form there or you can email me, maj@dovecotstudio.com.

Larry:
Cool. I’ll put that in the show notes as well.

Michele:
Thanks.

Larry:
Thanks so much, Michele. I really enjoyed the conversation.

Michele:
Thanks, it was great. And happy 200th podcast.

Larry:
Oh, thanks so much.