 Here we go. Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the Data Diversity webinar concept models, enabling your data to speak the language of the business. A celebration of Ron Ross's new book titled Business Knowledge Blueprints, enabling your data to speak the language of the business. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the bottom middle of your screen for that feature. And for questions, we will be collecting them by the Q&A in the bottom right hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights or questions via Twitter using hashtag dataversity. And if you'd like to engage more with each other and continue the conversations after the webinar, you can go to the dataversitycommunity at community.dativersity.net. And as always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Ron Ross. Ron is co-founder and principal of brsolutions.com, which provides consulting, training, and mentoring in support of concept modeling, business vocabulary. I can speak today, sorry. Business vocabulary, business rules, and business knowledge transfer. His 45-year career has consistently featured creative business-driven solutions. Ron holds an MS in information science from the Illinois Institute of Technology and a BA from Rice University. And with that, I will give the floor to Ron to get today's webinar started. Hello and welcome. Thank you, Shannon. And thank you, Dataversity, for sponsoring this webinar. Welcome, everyone, out there as well and in keeping with the times. I hope you are all safe and healthy. Today, I'm going to talk about concept models. And I'm going to show you how concept models are very different from data models. I'm also going to explain why concept models are indispensable for the kind of work all of you need to do. I'll get to all that in good time. But first, let me start off by examining a data modeling puzzle. Now, it's a bit long, but I think it's well worth the trouble. So I'll ask you to stick with me on this, and then you'll see why I think it's so important. Now, your driver's license has a unique identifier. A given driver's license should be held by it must only one person. And it must... There you go. Sorry. It must have been a delay. The slide just switched. Okay. Okay. Your driver's license has a unique identifier. A given driver's license should be held at most by only one person. And only at most single person should hold a given driver's license. Now, does that make the person and the driver's license the same thing? Well, of course not. A driver's license isn't a person. That's a false equivalent. A driver's license is not a flesh and blood person. And it doesn't go around driving by itself. A driver's license is an authorization that permits a flesh and blood person to drive legally. But data designs often seek to take advantage of, quote, unquote, one-to-one identifiers and collapse two things as if they were one. Now, that's what's been done here in this consolidated driver's table, which has driver's license number on the left as its key. This consolidated table mixes data about two distinct things. Driver's license data, which is shaded in gold, and driver data, which is shaded on the right in pink. Conceptually, that's simply wrong. What in the world does that represent? But that's only a small part of the story. This is no mere academic curiosity. Big dangers will lurk in the data. To illustrate, let's instantiate the table and have some data to play with. There's our guy, Mr. Sample, in the first row, and we had a few other rows with various classes of driver's license. Now, mixing driver data with driver's license data produces big challenge for this data design, specifically how to handle unlicensed drivers. Unfortunately, people without driver's license do drive, and they do get into accidents. Although they don't have driver's license numbers, they will find their way into your data, and they become what I call phantoms. Now, how will you handle such phantoms in your data design? Let's take Ms. Kathy Wong here. She drove without a driver's license, and unfortunately for her, she got caught. How will you handle Ms. Wong in the false equivalence data design that we looked at? Now, here's how we might include data from Ms. Wong in the driver's table. We got her in. You can see her there in the last row. But let's look very closely at what we've done in the process. First, we created a driver's license number that isn't a driver's license number. That's because she doesn't drive. She doesn't have one. That's data pollution. Second, we've created a class of driver's license that isn't a class of driver's license. We called it none. That's not really a class of driver's license, and that creates more data pollution. Third, until now, a resident city was probably mandatory for all people with a valid driver's license. We could probably count on knowing their city of residence if they have a valid driver's license. But for Ms. Wong, we may not even know what state she's from or what country. And it gets worse. Now we have dates, if you look carefully, that aren't really dates. So all your rules and standards about valid dates just flew out the window. Now think about how this data pollution might affect your analytics. Suppose you're doing long-term resource planning and you need to ask things like, how many driver's license will expire after 2020? Now you're not going to get a very good answer unless you're really careful and do some very astute expression. Now do remember for the sake of clarity, I've kept this example as simple as possible. But imagine all the clarity that we're losing and all the complexity we're adding to maintaining and using this data correctly. You have to ask yourself the question, even for this simple example, is all the extra work and all these workarounds really worth the trouble? Now let me speak to you plainly. It's design choices like these that crap up your data. People are going to make mistakes no matter what. Data quality is going to suffer. Why design data so as to make it more likely people will make mistakes? It's just not smart. Now let's remember why all this trouble started. The data design equated two concepts that weren't the same. The driver's license and the driver. As a consequence, we find it difficult to handle phantoms, the data, like our Ms. Wong. In doing what we had to do under this data design, we polluted our data badly. And the worst part is we actually brought all this trouble onto ourselves. Now I would bet if I could talk to each and every one of you, probably all your organizations have phantoms in your data designs similar or equivalent to the one I'm describing. Now we need to stand back in this time together and look closely at the underlying concepts in the matter and figure out what's wrong and figure out what we're really trying to model. In short, what I'm going to tell you is we need a concept model. Now how do we do that? Here's a very quick preview. What we do is look at the nouns and the verbs we use to communicate about the problem space and then we base our model directly on those nouns and verbs. Here's a little simple starter concept model to illustrate. And during this time we have together, I'll try to expand on that so you have a much better sense of what I'm expressing. Now I'm sure you're going to want to ask, doing my presentation, and it's a very fair question. What's the difference between a concept model and a data model? I'm going to develop a whole series of differences during this presentation, but here's the first big one. A concept model pays no attention whatsoever to keys and cardinality. Those things I'm afraid are pure IT speed or pure data speed. Starting off talking about such things puts the cart way before the horse. First we need to understand the world and how we talk about it, how we conceptualize the world, and if we do that properly then we can talk about how the world should be represented in data. That's really what a concept model is about. Now actually how a concept model can be represented in data is not necessarily that hard. So I'm not going to be putting extra burden on you except to think through the semantics of business communication. To illustrate let's follow our example through to a better data design. Based on the concept model, this data design features separate tables for drivers versus drivers licenses, even though they are at most one-to-one. Now we've introduced a meaningless identifier for drivers and it's not tied in any way the driver's license number. And now there's a foreign key based on driver's license number to link the two tables. Very simple, very straightforward. Now let's look at the consequences. Here's our data for our guy Mr. Sample sitting in the driver table because yes he is a driver but it's also linked to his driver's license data in the driver's license table. And we've kept those two things separate because they are not the same thing. Now some observations about this data design. First our unlicensed driver Ms. Wong, the phantom, appears only in the driver's table, which is correct because she has no driver's license. Second, there's now no polluted data sitting in the three fields of the driver's license table. Class of driver's license, date of issue, and expiration date. No corrupted data. Third, you're much more likely to get correct results on your analytics like the query how many drivers license will expire after 2020. That's because all the dates are now following the rules and we can depend on those standards. For a better data quality, here's another step we've taken. You can't necessarily trust what's listed on a driver's license as representing the most recent or the most current known address for a person. Our Mr. Sample here, for example, used to live in Phoenix but currently, he lives in Scottsdale, as you can tell from the driver's table. To say that differently, you can't necessarily change what's physically represented on the actual driver's license just because a person has a new address. So now as shown, we have two differently named fields in the respective tables to handle the city of residence. And I've done something else as well. I think you'll find this interesting, maybe amusing. We've introduced a new field called deceased in the driver's table. Now think about that. Unfortunately, people do die, but when they die, it's not the driver's license that dies. It's the person that dies. Putting a deceased field in the driver's license table would just be too weird. Think about it. A deceased driver's license, what is that? Now that's a real phantom for you. Now I didn't make this problem of phantoms up. They happen all the time. Let's take a couple of more examples. Is a scheduled appointment with a doctor the same as the actual visit to the doctor's office on that particular day? No. Are there potential problems? Yes. Suppose you have a one table data design that covers both scheduled doctor appointments and the actual visits to the doctor. Now you're going to have phantoms there too. First, think about no shows. Is a no show an actual visit to the doctor? No, it was just an appointment that didn't happen. Second, think about walk-ins, cases where patients did not have a scheduled visit, but they just showed up on the doctor's doorstep. Will you create a false appointment ID for those visits? That's bound to cause confusion and mess up your analytics again. Now an appointment is an appointment and an office visit is an office visit. Even though potentially one-to-one at most, they are not the same. This sort of thing happens all the time. For example, I'm sure most of you have taken flights places. You made a flight reservation. Did that always turn out to be the actual flight that you took? No, probably not. There were delays, there was rerouting, there was rescheduling. You know, a flight reservation is not the same as the flight you actually take. Or a hotel reservation. Is that the same as the actual hotel stay? No, it's not. Or an applicant to try to become an employee in your business. Is the applicant the same as an employee? No, it's not. Bound to cause confusion. Unfortunately in the real world aspirational things are never the real things. Now just in general as an aside, it's sort of unsatisfied aspirations that are how phantoms often arise in your data. Wishing something would be one way but it turns out not to be that way. The general topic of these examples I present and I know this was sort of a long lead up to this, but what we are really talking about is the notion of classification. And what classification means is about putting things in the right conceptual buckets. What do you need for that? Well, you need workout compelling business definitions. If you can't tell me clearly what something is directly and unambiguously without exception, you have little or no hope of getting data designs right. It's just that simple. So here's some examples of good working definitions and definitional criteria. Good definitions are business oriented, they're relatively short, and they're highly succinct. Good definitions also give you immediate clues for the classification of things as they define the fundamental essence of what the thing is that you're talking about. In the case of driver and driver license, for example, I want you to look very quickly at these two simple definitions and notice the definition of driver starts out with person and the definition of driver's license starts out with authorization. Those are different concepts and authorization is not a person. A person is not an authorization. Different concepts. And also in the case of the doctor visit, an appointment, what's an appointment? What's a doctor appointment? It's an arrangement to see a doctor at a given time, whereas a doctor visit is a meeting with a doctor for consultation or treatment at a particular time. So a meeting and an arrangement are those the same thing? No, not at all. They're great clues there. You look at definitions closely and you can see that you're talking about different concepts. So here's a second major difference between concept models and data models. Business definitions in concept models reign supreme. Diagrams do not make up concept models. In data modeling, we've always had it backwards, I'm afraid. The model needed is not about drawing boxes and arrows primarily. It's about creating great business definitions. So let's look a little bit closer at that, the notion of great business definitions. And what a great business definition does is it gives you exhaustive criteria for determining when an instance does or does not belong to a given conceptual bucket. And that's important because the source of much ambiguity in many business areas, errors, is what I call boundary cases. Now here's an example to illustrate using a definition from Merriam-Webster Underbridge Dictionary. That's the definition of vehicle. You look it up and here's the definition from Merriam-Webster. It's a means of carrying or transporting something, a carrier of goods or passengers. Now as you can see, when you start looking carefully at examples, the weakness of this definition for the purposes of insurance becomes quite visible, quite obvious, very quickly. Will the insurance company ensure trains? Probably not. Motorboats? Probably not. And so on and so forth. So it's just not a good definition for the purpose of insurance because it hasn't captured the essence of the concept and eliminated these boundary conditions. Now here's a revised definition which does get better at the essence. It is sufficient to properly evaluate most of the boundary cases. And it says a motorized means of carrying or transporting something on land without the need for rails. So if you look at that, think about it, evaluate your examples. The only ones that now probably remain to be questioned are motorcycles and tractors. Now here's an important insight about creating definitions. The secret is literally looking at lots and lots of examples, examples, examples and more examples, all these potential boundary cases. And actually that that point shouldn't really surprise you because one of the key notions of concept modeling, as I mentioned, is classification. And that means putting examples into the right conceptual buckets. Now I've heard some software professionals, some in the software ontology community, saying, ah don't do business definitions because they just slow you down and you never get anywhere. Well I'm sorry, in my view, and speaking plainly here, that's absolute nonsense. Without definitions, how can you ever be sure about classifying stuff correctly? Now furthermore, your definitions need to be in plain business English. Otherwise, how will you verify them with business people? After all, it's the business people who have the business knowledge. Now creating robust business friendly definitions is a scarce skill. It's not an innate, we're not born with it, at least most of us are not, and it doesn't come with your technical training. I'm afraid it just doesn't happen that way. So one of the things I've done in my new book, business knowledge group, is I've devoted a whole new part to definitions with plenty of examples and so on. There's actually one whole chapter to introduce it and then a whole part with do's and don'ts and so on. So that's something that you can definitely take advantage of because we need guidelines to do good business definitions. But today I'm talking about concept models and I want to come full circle back to that. And concept models feature three key notions, three basic notions. We've already talked about the first, which is classification. And classification is the most basic of all and that's why I started there. It's about being very clear what we're talking about so we can put things in the right conceptual buckets. Now for the rest of my presentation I'll talk about the other two notions which are categorization and verb concepts. And by the way my new book also covers those two notions in quite a great deal of detail with illustration. So yes these three notions do address the fundamental challenges of data design. But as you're going to see as I continue through my discussion we're going to start sort of moving away from data design only. And what we're going to see is that there are actually quite a far broader set of challenges that we need as professionals to be addressing today. So my deeper message to you and I hope you'll listen very carefully to this is start thinking about the taking the data blinders off. There are bigger fish to fry these days and you can provide so much more value to your organization than just the pure idea of data design that we've been discussing. What's a concept model? Well it's something that's going to allow you to produce phantom-free data designs. Look at a concept model this way. If you start with concepts in designing your data all you need to do to turn the concepts into data is mostly just add keys and formats. If you start with data and then try to turn the data back into concepts you're going to need something like magic. If that weren't true reverse engineering data stores would be a breeze but I can tell you from experience that's certainly not the case. Now concept models are a relatively new technique but they have been the subject of standards development for over a decade. For the record the ideas that I'm talking about in this presentation come directly from a very powerful standard called the semantics of business vocabulary and business rules SBBR. And one thing about this standard is it's important to note that SBBR is a linguistic standard. Its core ideas are based on natural language not data design per se and that makes it that's what makes it fundamentally different and also what makes it so much better suited for today's broad set of challenges. By the way you can find out more about SBBR if you're interested on BR community and there's the URL for that on the slide. All right now let's move along and let's do some battle with type codes. The next subject is categorization and I want to get right into that. Now by looking at this sample data do you have any idea what this data is about and I'll give you a hint it's all about the different kinds of assets that railroads must manage. Okay still not clear? All right let me give you a little bit more help here sorting out these type codes. An asset can be only one of three things a detector which is something that text trains passing by on rails a fixed asset things that don't move like railroad tracks and stations and things that do move across the railroad tracks like cars and that's that's called stock equipment. Now kind of stock code applies only to movable assets or equipment. Kinds of rolling stock apply the code applies only to stock that are not maintenance of way or non-rolling stock. Kind of car code applies only to kinds of rolling stock that are not locomotive or caboose or steel wheel set. Now are you getting a little bit better sense of this data now? Is it becoming crystal clear to you? No? Well I could go on and on and on I haven't even talked about these other type codes but when you agree that this is just about hopeless how can you have a conversation about these business things using these type codes? This is classic IT speak or classic data speak maybe it's not the language of the business at all your data is not speaking the language of the business and if you think you are you're just fooling yourself yet this is roughly how we implement data designs all the time. I wonder we have such a tough time coping with them and I hope out there you can sort of feel my pain because I know you've all dealt with this problem. I think you'll like this version much much better and what this version features is deep categorization to engineer all the concepts clearly. Now this is speaking the language of the business and all the noun things that we need to organize together. So the blue things here with the heavy dark lines those are all categories and what a category is simply a special kind of variety of a broader concept it's very natural very easier we're just talking about narrower and narrow concepts as we go down the hierarchy. Let's take boxcar for example starting at the bottom of the hierarchy. So boxcar is a kind of freight car you just follow me up through the black lines freight car is a kind of car a car is a kind of rolling stock a rolling stock is a kind of equipment a synonym for equipment is movable asset and equipment is a kind of asset now I've just given you a very clear sense in this context of what a boxcar is and that's very important and what you need to do and this is part of the trick trick and concept modeling because definitions reign supreme is to work these categorizations right into your business definitions so let's illustrate that what is a maintenance of weight that box in the orange well it's a rolling stock notice that's the next higher category the super category used to support the maintenance of the railroad what's a rolling stock well again notice that it's based on the next higher super category equipment or synonym movable asset that's a movable asset that has railweed railwheels you need to say what is a movable equipment well that's an asset just following it up the black line which is expected to move in the right way to support railroad operations and finally you get to the highest level concept asset something of value utilized in supportive railroad operations what we have then is a very rich set of examples a rich set of definitions that correlate directly with the model that we have given now and by doing this correlation it makes the definitions much easier much richer and makes our diagram much more robust so here's another difference between concept models and data models concept models forces you to see type codes for what they really are they are pure data constructs they are pure it speed they are not business speed why do we have them in data designs well you could argue that a big part of the legacy a big part of the reason is just pure legacy once upon a time space was limited maybe still limited in certain guis and so on type codes will really kill business communication and that's the point in today's world clear communication about business knowledge is far more important than compact data schemes categorizations give you exactly the right nouns you need to express business thoughts precisely and here's a simple example we have organization in a category of organization's categorization corporation more narrow category and then a special category of corporation is limited liability corporation special kind of variation and what that allows you to do by having this assortment announced is to make statements correctly so here's a for example a business rule which is in fact the law in most states a limited liability corporation must be dissolved if a member leaves now that makes perfect sense it's perfectly precise perfectly accurate now this version would not be precise and it's not accurate a corporation must be dissolved if a member leaves that's just not true wrong choice of nouns and this version is also certainly not correct an organization must be dissolved if a member leaves that's just not true it's just not essential to the meaning of organization so the categorization in organizing your nouns the nouns that stand for concepts gives you a very rich vocabulary to make statements about the business in this case business rules correctly all right that's categorization that's the second notion but i want to take you right along quickly to the third notion of concept models and that is verb concepts and here's things i think really get interesting we really get into some deeper semantics but first let me try to motivate the problem for you by using a simple example and the point i want to make i'll just tell you where i'm going in advance here is that the way normal communication takes the way we're communicating right now even though we're not face to face and i can't see you you can't see me is through complete sentences i'm trying to express what i know in complete sentences using grammatical conventions and those conventions inevitably include verb concepts the fundamental problem with structured data here again is an example of structured data is that is essentially been stripped bare of almost all grammatical conventions it's essentially naked with respect to grammar and verbs now here's here again it's a simple example let's try to reconstruct the meaning of this table just from what we see in the data so what i've tried to do here is express the semantics of the data by writing out a sentence and you can read that sentence for yourself but you can see that i get stuck right off how can i be sure what the true connection is between this person uh c the letter c that's all we have for that person and the order 20680 we're really just guessing does that person live in the the city you track what did they place the order in the city you track do they want the order ship to the city you track it's not clear we have phantoms we have missing semantics it's gone it's evaporated that is not good actually the problem is even worse than what i what i say because i i sort of slipped by this little phrase on you but i i was making the assumption that the order 20680 was placed by the person c but how can i be really sure about that there could be some other connection maybe it was a person who ordered it for someone else maybe it was uh you know some other third party how do we know that order was placed by c the semantics are gone they're evaporated they disappeared because we forced it into this tabular form that is not good the reason it's not good is because it makes business users and developers make assumptions about what data mean and as soon as you start making assumptions you're often going to be wrong this is it's me and it's killing the data's ability to speak the language of the business let's take another example now let's just don't stick to data design you know as i say there are much bigger fish to fry these days here's an example to illustrate this example is happens to be a business rule because that's my company's one of our specialties but the same points i'll make hold true for any kind of business communication including but not limited to textual requirements so i have a sentence here you read it with me an order must not be shipped if the outstanding balance exceeds credit authorization the first time you look at that sentence you may think well that's pretty clear but if you start poking around at it like we data analysts and business analysts tend to do right off you're going to discover that the meaning is really actually quite murky something seems to be missing or hidden for view so you need to be asking some questions so are we talking about the outstanding balance of of what is it the order is it the customer is it the account is the shipment are we talking about the credit authorization of what is it the order the customer the account the shipment again there's no clarity here which makes the sentence the business rule or the requirement subject to great ambiguity so what we need in order to rectify that problem and eliminate the ambiguity is take verb concepts from our concept model and insert them in the sentence to remove the ambiguity so let's assume for the sake of argument that the relevant verb concepts i've listed them here here is account balances of account account is held by customer customer places order credit authorization is of customer those are the structural elements using verb concepts to indicate how our nouns relate to each other then what we can do is use those verb concepts to completely eliminate as far as i know the ambiguity in the original statement so let's read this together with the verb concepts inserted an order must not be shipped if the outstanding balance of the account that is held by the customer that placed the order exceeds the credit authorization of the customer now it's going to be really hard to misinterpret that sentence although i guess possible but what we want to do is to ask that return that to the business expert the subject matter expert say is that correct that we understand that correctly is there anything we're missing and then we have a dialogue about it to make sure we're on target that is the secret of disambiguation and so where i'm going with that is to tell you that a concept model is not made up of just nouns it's made up of nouns and verbs in equal measure that we use to talk about things in particular our knowledge we are not talking here about entity relationships and attributes i hope i'm not stepping on any toes here but those are just not the way in the 21st century that we need to be thinking about designing data we need to be thinking about nouns and verbs because that's how we communicate knowledge and that's the most important thing i hope you'll take away but let's take another example very quickly this is more complicated but it makes the same point um here is a another business rule income must be greater than 20 of the estimated value of subject to litigation you read that the first time you think to yourself i kind of understand what that says um i've got some sense of it but do you really the more you poke at it the more you're going to realize that this data statement is highly highly ambiguous and by the way this is a real example from one of our major institutions in washington but i won't name them just to protect the the innocent here so let's look at all the potential sources of ambiguity you'll notice there are actually two incomes so which income in that statement am i talking about am i talking about the income of the property or the income of the party don't know and let's also notice that the idea of the verb the unary verb concept is subject to litigation that binary verb concept is associated with both property and party which one am i talking about is it the property or is it the party okay but even worse maybe is i don't know which verbs to use in order to read sentence correctly so uh to interpret it there are five different possibilities i could be talking about the income and the estimated value of the property itself and wanting to compare those two things or i could be talking about the income of the party who owns the property because the party has an income too or i could be talking about the income of the party who leases the property ambiguity rampant ambiguity or this is a little more complicated because it involves two verb concepts i could be talking about the income of the party to complete the loan application that lists the property as collateral that's what i could be talking about or finally and it actually turns out this is the correct interpretation i could be talking about the income of the party who completes the loan application to request financing for the property which we call the subject property and it turns out after extensive discussion with the subject matter experts that's what they really meant finally how the ambiguous we haven't done an adequate job on the knowledge of the organization whatsoever why because we have no structure no blueprint to the knowledge to create some blueprint we need both nouns and verbs in equal measure so what do you do to correct that ambiguity well as before you just drop the verb the verb phrases into the statement in order to eliminate the ambiguity so i'll do that here and then and the right interpretation is the income of the party who completes the loan application requesting financing for a property that's the income we're talking about must be greater than 20 of the estimated value of the property if the property is subject to litigation okay now one of the things that verb concepts allow you to do is introduce what's called role names and role names take their meaning from verb concepts for those of us who have had a career in data design we never really thought about nouns that could take their meanings from verbs but it happens all the time for example what do we call a party who completes a loan application call them an applicant what do we call a property that's listed on a loan application we call it collateral what do we call sub property that that a loan application request financing for we call it subject property your business vocabulary is full of terms that are exactly like that and what we could do is to introduce those role names to even create a more succinct more packed a more precise version of this rule statement we could say the income of an applicant must be greater than 20 of the estimated value of the subject property if the subject property is subject property of the subject property if the subject property is sub litigation so much cleaner clearer version so role names that take their meaning from verbs the verb concepts between our our noun concepts have a very important role to play in clarity and disambiguation for example here's a perfectly meaningful business rule an applicant must have a current credit score well of course not all parties have to have credit scores that would be incorrect only those who are completing a loan application must have a only those who have a loan who are completing a loan application must have credit score four okay well you see the importance of disambiguation and what i'm going to contend is that there's never been really a data model that's ever been created to help you disambiguate natural language statements which is to say to address the problem of knowledge and its chapter expression and that's ultimately the point i want to make is that a concept model gives you all the vocabulary you need to disambiguate sentences about business knowledge not just about data design and you can't expect customers and developers to make up for what you can't communicate precisely my last thought to you today is it's increasingly the job of professionals like yourself to step up to the challenges of today's world it's not about just building data models building databases developing software solutions but rather the much larger problem of care of clarity in business communication and by the way that's going to be extremely important as you apply AI and machine learning to text uh current capabilities are just really dumb when it comes to business vocabulary don't have time to go into that if i had more time i would if you don't take up this challenge who will who's better qualified you guys are because you're sensitive to the issue of ambiguity and subtle meaning semantic so take the data blinders off step up to the challenge and what i'm telling you is the concept models give you the necessary uh tools everything we've discussed today and a whole lot more is covered in my brand new book on concept models called business knowledge blueprints i hope you have a look i've been told it's fairly easy reading that's what some of the feedback is saying so that's gratifying for that um concept models are what truly enable you in your data to speak the language of the business okay that concludes what i have for you i'll pass it back over to shannon uh if you have some questions or some comments uh we have a little bit of time to talk about it i love it ron thank you so much for this great presentation and if you have questions for ron feel free to submit them in the bottom right hand corner of your screen in the q and a section and just to answer the uh most commonly asked questions uh just a reminder i will send a follow-up email by end of day thursday for this webinar with links to the slides and links to the recording and i'll link to uh how to get uh ron's book so ron um concept model and conceptual model the same thing i you know i could have guessed that would be the first question and and i want to give you the answer to that first just a shout out to uh jane uh who said wow we are feisty today did i come across as feisty if i did my apologies i was just trying to keep you awake and also you know i feel pretty strongly about some of these points and the fact that you don't step up to some of these challenges okay well i just wanted to throw that in all right concept models compared and contrasted to uh conceptual model well i'm going to say conceptual data model because i think that's probably what the question is asking um if not you know shoot in another question in a conceptual data model what's the difference between a concept model and conceptual data model i'm going to ask you first a question what exactly is conceptual data are you creating a model of conceptual data i don't know what conceptual data is you know and so one of the points i've tried to make in this presentation is the need for great precision in the terminology that we use and the term conceptual data model is probably the most unclear that anybody ever invented so no i'm not a fan of that term um but maybe a little more seriously is the part about conceptual and i think when people talk about conceptual data models or conceptual models in general um they're talking about relatively lightweight models right because you're just getting into a problem and you're trying to sort of sort out what are the major elements and you're going to create a fairly simple top level diagram that covers most of the main things in the space i want to make a very very clear distinction here because if you're going to disambiguate business knowledge and really discover the root causes of ambiguity you're going to need far more than a conceptual model you're going to need nouns and verbs extensively we've created fairly simple concept models one with only maybe a dozen terms and a dozen verb concepts somebody somewhere might call that a conceptual data model however i would challenge you to look at the business definitions which are the most important thing and i think you'll see the quality of the business definitions as far above what you might see conceptual data model we've also created concept models that literally have 500 terms and hundreds of verb concepts because we are capturing and we are disambiguating thousands actually in one case hundred not hundreds but tens of thousands of business rules for the whole area of property insurance and so you're not going to do a conceptual model at that degree of precision and depth there's no need to once you get into language and communication knowledge you'll discover it's a whole different problem so here's what i'll say here's my bottom line on the question is that a conceptual data model is not meta the data it's just not it is a different kind of model that focuses on language nouns and verbs isn't intended to attack the problem of knowledge that's increasingly where our industry is and where things need to get awesome so it's keeping on with concept models ron how do concept models compare and contrast with ontologies okay um good question um you can be justified if you like calling a concept model a business ontology and i'm going to use that term very carefully call it a business ontology ontology because it does have the constructs of categorization and it also has the the construct of verb concepts however the difference is i think a lot of people when when you say the word ontology almost immediately and reflexively think about al web ontology language and tools of those kinds which are really technical tools that are aimed toward improving search and maybe integration problems for data and i have looked at a lot of software ontology they very very seldom have robust business definitions for things it's almost like a no go um and so you know if your intent is to build a business glossary which is absolutely the intent with a concept model you're probably not going to see that in uh an ontology one that business people could really sink their teeth in um so i'm going to i think i can i'm sure because i've talked to experts in the field in conjunction with spvr and so far that is legitimate call concept model a business ontology has the right foundations and it does map the predicate logic and so on but i'd caution you that most things that people in the ontology call uh community call business ontology are not concept models for the reasons i've discussed and run uh i can see how concept models help you make elegant and consistent data models but how do they help you make use of your data well i think that one important thing is to sort out the anomalies in the data now if we're looking to uh so um integrate some data we're trying to consolidate some value chains we're trying to put together um know a superstructure from the existing legacy data stores in order to address um business analytics and those kinds of queries um the approach i've described is going to be extremely helpful for you in sort of sort of reverse engineering semantics or guessing at the semantics that are in those existing data stores and to help you um create a blueprint that will serve you in trying to i won't say integrate but it'll certainly serve you better in trying to consolidate the data from multiple sources and you know that's where a lot of us are today in one way or another we're trying to reverse engineer the semantics from existing data stores and the way they're designed those semantics it's just gone it's evaporated it's just not there i think that was one of the main points in my presentations today um and so um i think the main help you're going to get in that situation is um to provide you a blueprint that you can organize structure your thinking trying to validate and understand clearly the semantics of what it is you're trying to address and i think we have time to slip in one more question here is there uh you you mentioned that reverse engineering is difficult and possibly requires magic as many of us do not have the luxury of starting with data before it is already in the system what do you suggest is the first step well you know i not surprisingly i'm going to suggest that you do a concept model because otherwise i don't have a good idea of how you come to grips with the the different semantics including rules by which the existing stores of data have been created and what are just to organize your own thinking to clarify the ambiguities put yourself in a position to compensate for the language squarely things that you'll find in those existing data stores with some compensation compensating logic you know concept model is pretty much the the the exactly the right thing you needed in order to to try to move forward as deeply as is useful and productive and i always issue that caveat it's not useful and productive well stop but you know until you get to that point it'll be very helpful by the way shannon just before you sign off i want to mention um if i think you're going to put these slides up for a download somewhere or distribute them in any case yeah in any case the remainder of the presentation and i included more slides than i knew i could get through here goes through one by one all of the reasons for doing concept models and they range from text and AI and machine learning and shared understanding all the way through data models and business initiatives and integrating value chains data quality and a whole a whole lot of things so there's there's more resource you can draw well run i certainly appreciate that thank you so much for this and this great presentation and thanks to all of our attendees for being so engaged in everything we do and all the great questions but i'm afraid that is all the time we have for today again just a reminder i will send a follow-up email to all registrants by end of day thursday with links to the slides the and the recording and a link to purchase ron's book ron again thank you so much my pleasure great to be here all of you be safe indeed thanks everyone stay safe out there and have a great day