 So I'm going to get started. First off, thank you for getting up this morning, especially anybody coming from the West Coast. I really appreciate seeing everybody at 9 AM. I wasn't sure if everyone would be here bright and early, so thanks a lot. I'm going to go through this presentation. I do want to leave time at the end. Previous presentations have had lots of questions towards the end, so I will try and leave a good five minutes or more for questions or discussion at the end. I'm going to go into some quick intros and background about myself and some fundamental things. I did mark this as an intermediate. So I'm sort of assuming some previous experience with Drupal, but nothing too in the weeds. So if you are still new to Drupal, should be fine to follow along. But I won't be spending a ton of time explaining the basics of what, say, taxonomy manager does in Drupal. And then we'll talk about taxonomists, who we are, what we do, the kind of activities, and a deep dive into particularly around governance, which I find is the missing link in architecture and Drupal implementation projects. And then a little bit about where you can learn more. Great, so my name's Michelle Ann Jenkins. I have been doing Drupal stuff for a very long time. I think this actually wasn't my first account, but it says 17 years and four weeks as of yesterday. So I got my hands dirty in Drupal 5 as a implementer, wrote some extensions, played around with customizing and integrating before moving into the more strategy layer around information architecture, and then very specifically the niche of taxonomy development for information architecture. I work with Dovcott Studio, where you're a tiny group of consultants based in Montreal, Quebec. We have clients all over the world. We basically do all things tangential to taxonomy around search tuning, information architecture, a lot of digital asset management for massive repositories of millions of pictures, for example, taxonomy governance. We work with UN organizations, US government organizations, but also Fortune 500 companies, and we love doing small nonprofits and GOs and all good works. Not all of these are Drupal. We are technology agnostic, but you have to get into the nitty-gritty of implementation quite often. So of these, the BANQ, which is the Bibliotech Nationality of Quebec, and the National Kidney Foundation, and who else from this one is Drupal? In other words, one more. Oh, I'm not supposed to mention them, that's why. Sorry, I didn't get to sign off on the last one. So I'm always really happy when we start in on a project and people say, by the way, we're using Drupal. I'm like, great, that's awesome. Oh, UNHCR does use Drupal as well. But we end up doing SharePoint and WordPress and a lot of home-rolled systems or enterprise content management systems of different flavors and designs. First off, even if you're familiar with taxonomy, even when you've been working with taxonomy, this question stills comes up. People don't wanna ask, but I just wanna get it out of the way. Taxis means arrangement, Dermia's skin. That's why it sounds like taxidermy. We get a joke all the time. People say, what are you doing? Why is it taxidermy? My website doesn't need it. We do taxis arrangement nomi method taxonomy. And now you know and you can tell your friends, don't make this joke to taxonomists. We've heard it, we're over it. I actually had to look it up eventually because I was like, I don't know why. I don't know why they sound the same. Now, if you've used Drupal, you might have created taxonomy. You've experienced a list of words and we all come from a history of free keywording, hashtags, categories, navigation, all these different ways that we can organize things. But what makes it a taxonomy and not just a list of words? So the key here is that it's governed or as we say in library science, it's controlled. So someone who is an authority has decided and vetted each of the terms in your taxonomy and determined that each concept or idea is only defined once. So if we have a concept like a small fuzzy creature with pointy ears and whiskers, we could say feline or kitty or cat. All of those are labels on a concept. So in a taxonomy, we really have to be a little semantic and think about are our concepts to find in one place with the single preferred label. That doesn't mean we won't have lots of other labels and that's one of the powers of taxonomy is that you do recognize there's lots of different ways to talk about things. But someone has gone through and thought about what is the style, what is the approach, what is in scope, how does it fit in to a structure? So a hierarchical structure. You don't have to have a hierarchy but very often we see a hierarchy. And as I said, support for synonyms or we call them non-preferred terms or alternate labels. So you might just have a big bag of synonyms. These are all the words that we are gonna consider the same. Or you might have very specific kinds of synonyms. This is an acronym. This is a layperson's term. This is the legal term. This is the Latin scientific name, for example. And you have extensible term metadata. You can start to think about why Drupal's so great for taxonomy when I say something like extensible term metadata because you can add editorial notes, history, definitions, kinds of relationships. And all of that is what makes it a taxonomy. Now if anybody here is a library scientist, yes we have ontologies and controlled vocabularies into the sore eye. But generally we try not to confuse people with that minutia unless it's technically important. So I will be talking about all of these as a taxonomy. But don't come at me. I do know that there's some nuance there. Now what makes a taxonomy a good taxonomy? We could have an authority. We could have a controlled list. We could have agreed upon labels. But unless you're looking at the user needs, making sure you're matching their terminology, their mental models, how do they think about things? What do they call it when they look for it? Even if maybe it's technically not accurate. What are the goals of the business? Are you trying to upsell, cross-sell, inform, engage? What are your metrics for success and how does taxonomy support those? And then fit to purpose. And that's that kind of part where we can't be technologically agnostic all the time because some systems can do things that others can't. So if you're using views and Drupal, you think about what is views and Drupal do well, which is a lot, which is great. Other systems might not support hierarchy or custom relationships or even synonyms. So you have a fit to purpose. Underlying all of this is the governance. The governance is what keeps it all linked together. It keeps quality and consistency and credibility of the taxonomy. Now we have best practices and standards. There is an ANSI standard. It's like 80 pages long. It's extremely boring to read. It's written in a very library scientist, library focus and uses a lot of an anachronistic terms about hyperlinks or things like that. But it does have a fantastic starting point in terms of recommendations on style and approach that you then customized to fit your user needs, your business goals and your fit to purpose. There's also a schema called SCOS, which is a technical like XML specification for relationships, alternate terms and things like that. Again, a good solid basis, but always needs to be customized around these other considerations. Why do taxonomists like Drupal? And when I say taxonomists, me, I love Drupal. I'm so happy when we're using Drupal. I do try and evangelize to other taxonomists. Hey, if you have any say, you have any input or you have an opportunity to work with Drupal, you're gonna love it because it's got out of the box taxonomy management. You come in, you don't have to implement something different. You don't have to write code. You don't have to kind of hijack some sort of free tag system and make it or force it into doing good taxonomy structure. I haven't asked tricks there because I do have notes on taxonomy manager, especially in Drupal 10, we're shifting over there. There's some feedback that I do wanna get more involved in terms of taxonomist perspective on it, but it's just great that you turn it on, you plug it in, and right there in the list of things you should think about in your site structure is taxonomy. Drupal plays well with other systems. In some cases, you do need, excellent. Hold on a second. It feels so much better. Okay. You're welcome. Oh, thank you. Just felt like I was peering over the edge. This is actually really tall. This is awesome. I wore heels, too. Thank you. I really felt like I was in the kitchen trying to get up on the counter. I'm not sure the wood holds. Yeah, I know. I'm gonna tell you, hi, I'm your taxonomist. Great. Okay. So much better. Last year, they had like a sound box for me, which was good, but all right. Plays well with others. So in some cases, you will need a real taxonomy management tool. If you're getting into things like ontologies and knowledge graphs, you need a designated taxonomy management tool that has versioning and history and triple store and all your kind of ontological bells and whistles. But if you're just using a straightforward web taxonomy, Drupal works great as a taxonomy management tool as your source of truth to feed out to other systems. And I have recommended this to people in the past. If Drupal is in your toolbox already and it's in your ecosystem, you can manage your taxonomy there and it's relatively easy to have Drupal send those terms out to your digital asset management system, your product information management system, or your intranet. So it's just great. Everything's an entity. That was a revolutionary. I started in Drupal 5 and then when they rolled out entity structure, I immediately saw that I can just go in and add fields and expand and customize and extend and you can start making little proto ontologies. You can have named relationships between things and you don't just say, this is related, this could be a symptom of, a piece of, a kind of, a part of, it's really cool. And you can get really far without involving development and writing code. Drupal designers and developers get taxonomy. Again, it's out of the box part of what you think about when you're thinking about structure. If I come to someone who has a home ruled web management system or they're working in SharePoint and I say, hey taxonomy, they're like, okay, I guess we're gonna do that if you want me to. And instead you go to Drupal and you say, hey, what's your plan for content types? What's your plan for Drupal? And the relationship between content types and taxonomy is also very clear. I do not need to sell people on it. I don't need to explain that you're gonna have different kinds of content. They're gonna have different taxonomy. It's just there. And then finally over 250 stable modules. So there's, I think I saw 900 modules at all and then I filtered to like the solid stable ones. 250 modules on taxonomy and they do a variety of things, which we'll talk about a little bit. So as I said, I'm not gonna go into detail about implementing taxonomy in Drupal but the most common use cases, views. Pulling stuff together from across your site based on shared metadata. Whether it's a list of three related links, read these next, featuring your three most recent news stories or pulling together entire pages and entire architecture of your site being generated by templates that know what they should be showing based on site metadata. And I love this experience for content creators. You publish your content with appropriate metadata and the system knows everywhere it needs to show up. You don't have people whose job it is to go find the seven pages to add a new link to. There are still websites out there that are doing it. There are very big websites out there that are still manually updating everywhere and you miss something or it gets out of date or you forget a page exists and the last update is 2017 because it's relying on very overworked people instead of metadata. So even this basic out-of-the-box views, serving up content is amazing use of taxonomy. You can have advanced search. You have faceted filtering. You can have type ahead that leverages synonyms. You can expose tags and do cool things with them. So you can get a little bit fancier. We know people don't use advanced search much but for the people who do, if you have a document repository, oh, I don't wanna do that. If you have a document repository of 60,000 legal documents, filtered, no, I still don't. Filtered, okay. Filtered search is really appropriate and a faceted filtering search where you have the ability to slice and dice things. If you have any commerce situation where you have 40,000 different t-shirts, definitely filtering search is worth people's time and they will use it if it's designed appropriately. Now beyond Drupal, as I said, Drupal plays well with others. You can be leveraging your taxonomy in the content strategy and planning stage. You can do gap analysis against personas. How much content are you creating on topics related to specific personas or kinds of content related? We know professors want short videos on course design. How many short videos on course design do we have? Let's pull that up in a view. It's great. So even behind the scenes for internal use, keeping an eye on what content you have and how well it's performing. Search rank enhancement, so leveraging those synonyms, leveraging the relationships to have guided search. Navigation, I could do a whole talk on why not to use a semantic taxonomy as your navigation. Excellent, people will get that, but it's so fun to be at a Drupal God. But taxonomy can support navigation. I did a website for a large tropical plant delivery company and they wanted gift plants, but they didn't want to tag gift plants with gift because what is cool or popular changes. Instead, we tagged them with what kind of plant they are and they had a bundle on a page that said, this is our gift page, include orchids, roses and bonsais and then suddenly cactuses got cool. They didn't have to go back and tag all the cactuses as gifts. They just added to the view on that gift page includes succulents and cactus because everybody wants cute little cactuses now. And so rather than retag 10,000 products, they had a navigational layer on top of their taxonomy. So it's my little segue about that. Reporting and analytics. Again, slicing and dicing by your taxonomy. You might have taxonomies that are only important internally. You don't want to expose them to end users. You don't include them in views, but you want to know, hey, what are the things that came from our external content contributors? What are the things that came from a budget line item? What are the things that support these strategic goals? You can have syndication, content flowing to other places, whether it's feeds or whether you have microsites or whether you're partnering with other people and they want to show your news. Workflows, permissions, that gets into some of those custom modules that can leverage taxonomy in really exciting ways. All right, so this is another bit like the taxonomy taxidermy just framing the conversation. If you go and search for taxonomous jobs, you're going to get two flavors of people. I totally respect scientific taxonomous. They do amazing work. It's super cool. It is a different beast. They are classifying biological organisms with a predefined hierarchy. The taxonomy exists. It is very structured. You have to get your master's degree or PhD to understand it and you learn to place things into that taxonomy under a prescribed nomenclature. Everybody uses the same system, phylum kingdom order. I don't even know those. Like I should learn them just cause I'm a taxonomist, but it is different than a business taxonomy or a content taxonomy. We are also classifying things by shared characteristics, but we really care about the context and the situation. There are authoritative taxonomies that we might lean on or be inspired by, but if I say medical taxonomy, you can't just take one of the 50 authoritative medical taxonomies and use that for your website. You can use it as a source, but it's not gonna serve your content, your audience, your needs, and your technology. So we are making many, many, many different taxonomies that are custom to your situation. So it's a different skill set, kind of the same label, but very different skill set. So we're focusing on the business content folks. Taxonomists come from many backgrounds. This is one of my favorite things about this discipline is it's always a good story. Like how did you become a taxonomist? So I was working in libraries and I realized that I could do my classifying, but on the website, and then you get to make the classification schemas and that was cool. Or somebody else says, hey, I was in marketing and we just kept getting lost in all of our resources and somebody asked me to organize them. I started Googling and I realized it was a whole discipline. Or I come from UXIA and we're structuring things and we need to relate things to how people talk about them and connect that to the user journey. I came from the technology side. I had a degree in linguistics. I got into computational programming and actually wrote WCMSs when they first kind of became a thing in the late 90s. So I came from the technology side and when we provided these really cool systems that now you could have a database driven website, people didn't know what to do with them. They were just like, I don't know, I'll just throw some things together. And I was like, I feel like somebody has figured this out. Somebody else has been thinking about how do people look for information? How do you organize it so you can retrieve it? And I was like, those library and people, they've been thinking about this for a while. So that's what sent me that way. Not everybody has a masters in library science. Different programs provide more or less useful masters of library science for web taxonomy. So don't take that as they have to, but it's definitely one of the routes. Increasingly but not always have experience with advanced semantic structures. So they might be coming from an ontology perspective. They might know math, like set theory and stuff. Like that's, I draw the line. I'm just, as soon as you're over there, I don't do colors and I don't do math, but there's a little sweet spot in between. But they might be very technical and semantic. They might be trying to, yeah, again, knowledge graphs, ontologies. They should be familiar with UX. There's always a big UX component of understanding the users. So interviewing, stakeholders, card sorting. We'll look at some of that stuff in a minute. And they may or may not be engaged with a specific WCMS. They may be more behind the scenes, creating the taxonomy, tagging content, maybe contributing to architecture discussions and then they stop there. And then there's folks like me who are like, can I have admin access? Can I get into the code repository? Like, you know, you can't stop me. So different backgrounds and different strengths. Some of us work as independent consultants, such as myself. Some people are brought in on a kind of ad hoc basis, like, hey, we need to grab a taxonomist. Sometimes it's just one hat that an architect or a content strategist wears. They might just be a more holistic content strategist and taxonomy is one of the things that they focus on. So there's not a ton of people who are just taxonomists and I'll get into wire frames sometimes and I get into implementation quite a bit as well. It might be baked into a web agencies development and design process. So if you're engaging with someone who's going to be architecting your site, that's a great question. Do you guys have a taxonomist? Who does taxonomy? What do you think? Do you know the difference between taxonomy and taxonomy? You can ask them now. In some cases you do have full-time positions in an organization. The New York Times has five full-time taxonomists and they work like seven days a week and there's 300 pieces of content published every day. It gets reviewed and it's super cool. But generally, there's not a need for a full-time taxonomist in an organization unless you're the New York Times, the UN, META, something like that. Yeah, and like I said, it could be part of a broader role. So it doesn't always need to just be a specific taxonomist. When do you bring us in? Lots of different points in the process and people ask like, oh, should you come in early? Should you come in when we've already figured things out? The answer is yes. It really helps to have a taxonomist assess current state. So what do you have going on right now? What are all the free keyword lists? Or if you're even making a bigger jump, what are all the folders and navigational elements and files, what nomenclature exists already and where the gaps or problems or strengths are in it right now? If you're planning a new site, again, it helps to have someone bring up the taxonomy implications. What are the hooks that you need into your content in order to generate the experience you want? Or conversely, what could taxonomy provide? Like maybe you haven't realized that your recipes can be showing up alongside products if they share a relationship between ingredients and product ingredients. If you're implementing a new content type, that's a great time to talk to a taxonomist about what sort of metadata it needs and which of those elements are going to be taxonomy driven. If you're migrating, always a good time to do your content audit and do some cleanup. And content audits can be helped by having taxonomy as part of that process to, again, get a high level view of what you have and how well it's working for you. As I said, they don't have to have an MLIS, but it's definitely something to look for. But real-world experience is great. A lot of people are self-taught. They've got the experience. They've seen stuff. Communication is huge. So taxonomy is daunting and boring to a lot of people. And if you can make it interesting and you can bring some energy to it and you can break down complicated things and not say things like the pre-coordinated non-preferred term is ontologically imprecise, then, yeah. We'll say that in the privacy of our own taxonomy conversations, but we don't need to say that in public. So being able to make presentations, training material, communication, change management, like how often does whatever we do end up actually being about change management? Domain experience, people ask me that. Can you make a taxonomy about snowmobile parts? Yes, because I'm going to talk to your snowmobile engineers. And I learned so much about snowmobiles. And now I've forgotten just about everything. Once in a while, like a ATV vehicle goes by. And I'm like, oh, I know that the flare on the back there is using Viper green paint. It'll just be like a little tidbit left there. But we work with subject matter experts. Some exceptions, medical vocabulary is like its own whole thing. So it does help if you are doing something that's a very specific science, medical area. It doesn't hurt if the people have domain experience. But we're great listeners. And we ask questions. And people love it when we come in and say, can you explain snow tire treads to me? They're like, oh, I'm so glad you asked. Technical expertise, like are you expecting them to go into Drupal and be interacting with things? Are they going to be tagging things using views? Do you want them to build views? Like that's asking a little more on top of the other things. But it's definitely great to see have you worked in WCMSs or do you work in spreadsheets? And we implement it for you. Do you work in, are you going to provide JSON? Are you going to provide handwritten notes? That probably won't work as well. So all right, I could do a separate session on every one of these parts. I'm just going to dip in and give you some context for some of the activities we do. And then we'll spend the rest of the time on governance. Now, each of these areas also is a point where requirements might come out. We might discover at any one of these stages that we want some technical stuff to support these decisions. Or we might, again, discover some cool things you could do because of the way we've designed things. So as you move through this process, it is helpful if the text on a list has touchpoints with architecture, UX, technology, content owners. They aren't going to work in isolation. You don't say, hey, can you go make me this taxonomy? And we're like, yeah, we'll talk to you in two weeks. Here's your taxonomy. It has to have a lot of touchpoints. And the more you can integrate the taxonomist so that they can have those touchpoints, the smoother it's going to be. Otherwise, you end up, as we say, build it. You're both building a bridge from different sides. And then you get to the middle and you're like, oh, we need a, oh, OK, we either have to move part of the bridge or build across. That happens frequently, actually. So in the first step, which is discovery and assessment, we will do very similar to UX or IA or Web Development Project Discovery. In fact, it's great if we can piggyback on what's already happening so we don't ask people the same questions. What's the technology ecosystem? What are your goals? How much content do you have and what kind? All that usual, like, getting a sense for the place. But then we dig into what vocabularies do you already have? Are they controlled or not? Where do they come from? Are they working for you? What authorities exist in your domain? So do you refer to a government list of geographic locations? Do you use mesh because you're in the medical area? Most formal domains have some sort of glossary or dictionary or taxonomy of different levels. We will do a heuristic assessment of an existing taxonomy. This also is very helpful if you're trying to get buy-in because this one is showing some green. But a lot of times it's like a whole lot of red and orange. We're like, this is what's wrong. This is what's wrong. And you can use that to say, we need to invest in taxonomy because here are the reasons why our current taxonomy is good enough, is not good enough. Or we might find, hey, this is pretty solid. Let's just enhance what you have and build out from it. So we take the ANSI standard plus our own kind of secret sauce of things we know work well or not, and then basically evaluate your taxonomy, make up a number, and then the rest of it is examples and user impacts and things like that. So that's a really nice thing as a starting point because you can then go do that again at the end and say, hey, look, we moved these numbers and we changed these colors, which is always useful. And then when we get into strategy, strategy is actually pretty big. What kind of taxonomy do you need? Do you need something just dead simple that's going to be maybe 75 high level topics? Or do you need the IMF has 30,000 terms? Or New York Times actually has hundreds of thousands because they have entities. Like every person that has ever come up in the New York Times is part of their giant list of things you can tag with along with some other information. So when we know what your use cases are, we start looking at what the design impacts are. If you're using taxonomy as plumbing, nobody's ever going to see this. It's just going to drive views. It's going to drive analytics. It's going to do cool search things in the back end. You could have a really nerdy, machine-friendly, ontologically rich taxonomy. But that's going to be a very different beast than, hey, we want people to click on something and it can't be more than two levels deep. And it's got to reflect the words that they're using. So strategy is important. Do you need to integrate with other taxonomies in your organization? If so, do you want an enterprise taxonomy, a single taxonomy that everybody uses? Or do you have a internal business taxonomy, a sales taxonomy, a marketing taxonomy, and a web taxonomy? And they all have to be able to talk to each other somehow. So there's quite a bit to hash out in that strategy of just all the possibilities of different flavors of taxonomy and different impacts. And now we, from that, create a framework. And this is definitely a missing link in a lot of taxonomy projects. The framework is great for a couple of reasons. One, you say what you're going to do before you do it and you make everybody agree to what you're going to do. And that's a crazy idea. But you have the argument in the framework instead of having the argument when your elbows deep in 1,000 terms that you could possibly be using. It defines what is your tax, what's a topic? It's a weird idea. Like what the heck is a topic? So what are topics? What is the scope of things that belong in topics? What is it going to do? Are people going to see it? Does it need a hierarchy? Do you need other relationships or special properties? What are some considerations or challenges that you've already identified? What are the sources? Who do you talk to in the organization to answer questions? All of that needs to get laid out. And you use that as the blueprint. And then when you're done, it becomes kind of the master book of how you manage it over time because people will come and go in the organizations. You may or may not have a taxonomist on staff, but later we'll see in governance, somebody says, I want you to add potatoes to the list of fruit. And you're like, OK, I guess. Like, I don't know. Can I say no? I don't know. Why do you need potatoes? And then we go back and we say, look, we're only allowed to have fruit. It's a culinary definition of fruit. So tomatoes aren't in here. Potatoes are not in here. We all agree to this. You can't have that. And that's very important because it becomes the basis of providing that consistency and credibility over time. Yeah, sources for candidate terms. So when we need a new word or we need to expand this, where do we go? Who do we look for? Hey, WHO just changed monkeypox to Mpox. Are we going to do that? Do we follow them? Are they a source for us? I don't know. So lay that all out. And then you're actually building your taxonomy. You might be building from scratch, which is just blank page. Like, OK, let's have a brainstorming session or let's do a content audit or term extraction and pull out all the words from the titles or search logs. But you might already, in many cases, have a bunch of taxonomies, and that's the problem. Is a performance review the same thing as a performance appraisal? Is a PR a press release, a performance review, a pancake revival? You can have behind the scenes systems that are using short forms because when they built this in Lotus Notes in 1980, you only could have two characters. That's a real thing that happens, right? Like, you have all these internal systems, and people are like, oh, I just know the number. They're like, what? They're like, I don't want you to put words in here, numbers, because that's my job security is that nobody else can do this because all day I know the coding. And then you've got people who've come up with the same idea, the same concept in different places, so flex time versus flexible hours. And your Drupal system cannot know that those are the same thing unless you tell it. So a lot of times what we do is sit down and say, hey, why are these different? Is these meaningful differences? Sometimes they're plurals versus singular. Great, our style guide says we're going plural. Everybody's plural. But is the United States and Canada the same thing as North America? No, technically, it's not the same thing. But is it close enough? Do we merge those? Do you need this grouping? What's Scandinavia versus Nordic countries versus EU? There's fuzzy, overlapping, squishy things. And again, context matters. There's a great example from public health right now is cannabis and marijuana, the synonymous. If I'm searching for information in a public health context, yeah. If somebody says marijuana or cannabis, you want to send them to the same place. If you're doing imports and exports, no, that's very different things. As a heart attack, the same thing as a myocardial infarction as the same thing as cardiac arrest is a physician, a doctor. Is a doctor or is a physician? It depends. Depends if you're the layperson and you're like, just give me my phone number to make an appointment versus I'm doing medical accreditation or medical training. So again, no off the shelf solution, a lot of iterations and conversations to figure out what things are the same and what things are different. We really just sit around and think weird thoughts all day long. Is that the same thing? What's another word for that? Is hospitality the same thing as accommodation and food services? If not, how are they different? We do try and use data whenever possible. Google has some cool stuff where you can say, hey, we've got some people saying online marketing, some people saying digital marketing and some people saying internet marketing. We've decided for our context, these are the same things. Which one should be our label? Digital marketing wins quite a long shot. Now it becomes a problem if your company really likes the word online marketing and they don't like digital. And like marketing's like, no, no, no, you have to say online. That's cool, that's our signature. And you're like, well, okay, but you might have to make sure people can say what they wanna say and say what they're saying and connect it to the term that you're using. Here's another one where you've got blood tests and nose plastic surgery. So once we decide what labels we're going with based on our style guide and our framework, you just go and do a whole bunch of research, basically mining for other words. There's a lot of really cool ways to do this. That I've found to just generate a whole bunch of words. Now you might be able to say, hey, some of these are just capitalizations or punctuation or plural. We're gonna write some code instead that does some nice natural language stemming or lemming and things like that. But a lot of people don't have that and that's one of those technical considerations. Do we have to lay out synonyms that are ING versus ED versus plural or are you gonna do some cool fuzzy stuff in the background? All right, implementation. Again, this really depends on the taxonomous. I love it. I like getting to the implementation part. There's always some retrofitting. A lot of times we will build the taxonomy. It's good enough. You tag the content and then you build the system and it's just not giving you what you want. People are complaining. Things are showing up in a weird way or we didn't expect that the budget cut would mean we couldn't actually have synonyms, that happens, and you have to come in and make some adjustments. Or hey, we ended up with some really long terms and they're wrapping weird in the select menu or something. So you suddenly have these. Ideally you know about these things ahead of time, but come on, honestly you find out when you're reviewing it in development that there are some things you didn't catch at the beginning. I like being there for the implementation. This is an example of taking the SCOS schema, mapping it to Drupal properties and then reviewing with the subject matter experts and site owners to say, hey, which one of these things is gonna be useful to you? Like SCOS has quite a lot of properties. You may or may not be using them. You might use them slightly differently or call them something more human friendly instead of taxonomous friendly, but having the taxonomous stick around when you're actually going through implementation can be very useful. All right, now governance is a big one. It is often put to the side. You've got the taxonomy done. It's great. You're building your site and then, like I said, somebody comes up and asks for something. They wanna change almost immediately when things go live. Even if you've asked everyone to review and sign off and have the stakeholder meetings, nobody pays attention until it's suddenly on the public site and they're like, why are you saying that? We can't have that or this is missing. So who creates, maintains and controls the taxonomy? You may have the taxonomist for six months as part of this project and then they're gone. Who owns it? Is it owned by technology? Is this like a web development ticket or is this a content editorial ticket? Is there another layer of governance? Ideally, you have governance for your website and this is a component, but that's not always true. Who are the stakeholders? How do people know who to ask? Hey, we have a question about, I'm trying to not just do medical and snowmobiles. That's another good one. We have a question about excluded corn product development, research and development. Who do we go to for excluded corn products? Like, I don't know. We're gonna go to the company directory and search that. You need to keep track. It's a huge project to keep track of the subject matter experts for different parts of your taxonomy. You don't want, web developers are great, but you don't want your web developer making decisions about the semantics and labeling of the taxonomy unless they are also the taxonomist and that's been decided and they've got that background for it. Who else do you need to be talking to? What are those points of contact in your organization for, hey, we're gonna make a change. It's gonna impact metrics and search and content creation and press releases and archiving and web development. Who needs access to the taxonomy? This is a funny one. Drupal is so good at giving a simple editorial form for content creators, but my experience is that a lot of sites still have content creators email someone to put stuff on the website for them. That's really common or maybe they have a ticketing system or maybe they have some other layer there, but if they don't have an interface that has that tagging widget, how are they knowing what terms to suggest? Because the terms should always come from the content creators. They should not come from the person cut and pasting things into the WCMS. So do they go to the internet? Is the website, is it in a spreadsheet? If so, how does it stay up to date with what's in Drupal? Can you have an internal view that's just the taxonomy and if so, are they still kinda cut and pasting? Because they won't do that. They'll just guess. They'll be like, who's the words I think? I'm thinking of, and they're gonna think of it like hashtags and they're gonna give you like 50 words and somebody's gonna have to figure out which of those are in the taxonomy. So how do they actually know what's in the taxonomy? In general, as like, hey, show me what the taxonomy is. How do they interact with it to select and submit tags? When does that happen in the editorial workflow? My suggestion is that they actually tag content before they write it. Make them say, I'm writing for this audience on this topic and this kind of content before they do anything else and then everything else builds from that. Because when it's at the end, everybody's in a hurry and they don't care or something. The other thing is, you'll figure out then, hey, there's no taxonomy term for what I'm gonna write and then it becomes a taxonomy request and hopefully by the time they've written their content we have that term available. Who ensures that it's correct? If you let content creators tag their own content, is anyone taking a step back and looking at usage patterns? Or, oh, everybody's tagging everything with Ardvarks. I think they're not really thinking this through. I think they're just taking the first one from the list. Where do new requests come from? Who are the people who are gonna think of something new that needs to go in your taxonomy? Obviously content creators and taggers are a good one. What other rules in your organization are gonna care and have input and how do they do that? Do they email someone? Do they do a jara ticket? Do they call you? Do you guys have a monthly web governance meeting and it should be on the agenda there? What is that processor or tool and how do you get them to give you the best information? If they just say, add this, it's hard for the taxonomy owner to make a judgment call on it. They're gonna need to do, what are some examples of content? What impacts are there? Do we have to go re-tag things that already exist? Do we need to change the logic in any views? What are all of those implications? Are there downstream impacts because you're using Drupal to feed other systems and hopefully it all just flows, but maybe it doesn't and somebody has to know to make an update somewhere else. Who communicates those changes? If you've added 10 new terms, how do people know to start looking? You got a nice autocomplete or something, but if they don't know there's new terms, they're not gonna know to look for those. And are there any technical requirements to support this governance? So giving permission to people to tag content or view the taxonomy or submit a taxonomy term. You can actually put taxonomy terms in Drupal into the workflow and have them show up as unpublished and then have a review process. So you can actually treat them as little editorial pieces if you give people access. So I am giving you all the questions. I'm not giving you the answers because it depends. This is just an example of what a taxonomist would do when they get a term request. We don't just say yes because you've spent all this time building this beautiful wall that fits together. You don't wanna just start chucking things at it. I come back after a year or five years and I'm always like, you guys, come on, I told you. It's a garden or it's like getting a puppy when your kid's like, the puppies are free and you're like, it's not getting the puppy. It's like the next 16 years of taking care of the puppy. Taxonomies, puppies, gardens, they need ongoing work. So if somebody says add a new term, we say, hey, is this covered by something already? You want flex time, but we have flexible hour scheduling. Is that gonna work for you? Do we need to change the label? Why don't you think we have the term because we do? Is it in scope? Does this fit into what we've defined? We have a list of countries and you want me to put Jerusalem or Kosovo or something else tricky and you're like, we need to talk about is this a country? Wait, this is the tri-state area. First of all, which tri-state area and secondly, that's not a country, you can't just stick it in our list. So keeping everything clean and mutually exclusive. Is it useful? Are you using this to tag a single piece of content and no one else will ever use it? That comes up a lot. I wrote a piece of content and I want to tag for it. Does it meet the style guide, capitalization? I don't think it's gonna seem trivial, but when you have a list and it's all, these are camel case and these are sentence case and these are title case, it reduces subconsciously the credibility of the whole thing and where does it belong in both which facet? Is it a topic or is it a entity or is it a country and where does it fit in the hierarchy? You have to develop training material and documentation to support all of this. One, it gives the taxonomy authority. If you come up and say, hey, read the manual, they won't always read the manual but the fact that a manual exists means they will argue less about your governance. So having an internet site, having a lot of documentation and being able to say, we did the work here, we didn't just pull this out of our hat. Testing and assessing, so again, periodically checking your taxonomy, so we check term usage, so how many times does this tag use? Hey, we added this tag five years ago, it's been used twice, we don't need it. Let's roll it up and tag with a parent. We don't need Myers lemons, we just need lemons, that's good enough. Or hey, people don't know this tag exists and they should be using it. So if they're not using it and they should be, that's a training issue if they are using it incorrectly is the other thing we get, where again, everybody's tagging aardvarks, there's either something wrong with the UI, whether it's a default, or people are not appreciating the value of the taxonomy. Being able to literally see when I tag it, it shows up places. If you have a taxonomy that does not do something that people can see it doing, your tagging quality is always gonna be less. I did mention user testing back in the day pre-COVID, we used to take giant pieces of paper and have post-it notes and draw on things, then I got on the airplane with all my rolls of paper and now we mostly use mirror boards or OptimalSort is a website that does tree testing and different kinds of card sorting, open, closed, and hybrid, and then spits out all these really cool graphics for you to put in your presentations to show people how you've tested the taxonomy. I'm gonna go very quickly. If you wanna know more, the Accidental Taxonomist is like the book by Heather Heddon. It's great, it's got a forward by Dovcott, Stephanie Lemieux, she's the president of Dovcott. It's very complete and assumes no background knowledge and gives you all the basics, but it basically is walking through the ANSI standard in a friendly way. A new book out, Taxonomies, Practical Approach to Developing and Managing Vocabularies is a bunch of different chapters. I have a chapter in there on using taxonomy for search. Every year we have taxonomy boot camp in Washington DC. The first two day is a start to finish, learn how taxonomies work, usually given by Heather, and then we have two days of talks, I'll be speaking there, usually M, virtually. Taxonomy boot camp London has gone virtual, so they do bite size four times a year. I'm speaking on June 21st about using air table for taxonomy, mapping, and development. And hit me up, I have the little come talk to me button, and I won't always be this tall, but you can spot me while I'm walking around. I'm also on all the things. Thank you, we have a minute or two for questions. And he, I didn't leave that much time, but yes. So the question is how often to revisit your taxonomy? So you wanna have, in your governance, saying that once a year you're gonna pull those reports, but you might have a taxonomy that's very solid. If you have colors, they're probably not gonna change and they're just good. If you have topics and you're in a technical field, you might need to do it every month or two. So it really depends on the volume of content coming through and the variability of the subject. But I'd like to say about once a year to just sit down with it and give it a good lookover is usually useful. So yeah. Slow down enough to really get to overtake before you know the proper cohesion than to undertake long cohesion. Yeah, yeah, that's a good question. So if you kinda have to go with what you got and you're trying to decide if you overdo it, yeah, if you have too much granularity, you can pull things up and roll them up and you can even decide at the display layer, like, hey, we tagged six levels deep, but we're only gonna deal with the three top levels so that it does at least give you a hook into things. If you tag at a high level or under tagged, you can't go find those things as easily later. So yeah, the trick is though, if you really over tag, you get this indexing feel and you go to the librarian and say, do you have a book on Abraham Lincoln? And she gives you an 800 page book that mentions him on page 12. You're like, okay, that's that free key wording thing that people wanna do versus what is this about? So I would caution against overtagging because it's a lot of noise, but I do say tagging at a granular level if you're not sure how granular to get, if that helps. Yes. So in this case, we mapped it to Drupal properties and so we're able to say, just take it as a list of suggested fields, map it to Drupal properties. If you wanted to use scoffs for exchanging information with another system, that would be baked into that layer that would say, hey, our Drupal field that's called name is actually pref label and the Drupal field that we've called map to mesh is actually close match there. So yeah, so you can use it as a guidance in terms of how you structure out things in Drupal, but it would be a whole separate thing in order to say, now it's going to talk to something else in scoffs. Any over here? I think I can squeeze in one more. Okay, great, thank you everybody. Enjoy the rest of your day.