 Hello and welcome. My name is Anita Kress, and I am the Webinar Production Assistant for Dataversity. Thank you for joining the latest in the Monthly Webinar Series, Lessons in Data Modeling with Donna Burbank. Today, Donna will discuss data modeling for XML and JSON. A couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the Webinar, and we very much encourage you to chat with us and each other through the Webinar. To do so, click the chat icon on the top right corner of the screen to activate that feature. For questions, we will be collecting them through the Q&A section. If you would like to tweet, we encourage you to share highlights or questions via Twitter using hashtag lessons data modeling. As always, we will send a follow-up email within two business days containing links to the recording of this session and additional information requested throughout the Webinar. Now, let me introduce our speaker, Donna Burbank. She is a recognized industry leader and expert in information management with over 20 years of experience in data management, metadata management, and enterprise architecture. She currently is managing director of Global Data Strategy, an international data management consulting company. Her background is multifaceted across consulting, product development, product management, brand strategy, marketing, and business leadership. She has worked with dozens of Fortune 500 companies worldwide in the Americas, Europe, Asia, and Africa and speaks regularly at conferences. So at this moment, thank you, Donna, for speaking with us today, and I'll hand it over to you. Great. Thank you, Anita. It's always great to speak at diversity. And so, as Anita mentioned, today's topic is data modeling for XML and JSON, which is a little different from some of the other topics we have had. I'll go through some of the topics later. Anita already mentioned me, and I think many of you know me already. So probably the most relevant to this discussion today, some of you know me from past roles, either on the ER Studio team, whereas director of product management, or with the Irwin team, whereas I'm a VP of product marketing. It's got to have a lot of experience in the data modeling space. I'm both on the technical and the strategic. And I wanted to kind of address that today and kind of some of the, well, I don't say do when it comes to XML, but you know, non-traditional, non-relational areas when it comes to data management. This is, let's see, this is the last, this year in the series. So if you haven't joined some of the others, they are all available on demand. And you'll see that we tried to mix it up a little bit in terms of topics. We started out with data modeling as part of your data strategy. We have things on data modeling and metadata management, big data, UML. And this one gets a little more in the nitty-gritty of XML and JSON at the end. Keep you, keep you wondering until the end what we have a whole lineup for next year as well, but we tried to do the same thing, kind of some bottom-up and some top-down. And then we tried to judge by the attendance what are kind of the more popular ones. So definitely, you know, if there is something by the end that you don't see in the agenda, do let us know because we try to always go by feedback of what's been interesting to folks. So today on the agenda, we're going to talk specifically about XML and JSON. If you're not familiar with that technology, what it means with things like data modeling and metadata for XML and JSON. And then what it means to integrate some of these technologies with databases. When I mean databases, it isn't always relational databases, right? So we have, you know, SQL databases as well. And then a little bit, which is still modeling. It's familiar with things like RTF and the Semantic Web and how things like XML like fill in stuff into that before you open it up to Q&A. But before I go too much further, I told you a little bit about myself and you heard a little bit about me, but it's always awkward on these webinars because I can't see you. And I do recognize some of the names and familiar faces, I guess, on the webinar, but some of you I don't know. So we have a couple of questions, just so I can kind of level set in the presentation. Anita, would you be able to kind of bring those up? Or Shannon, I'm not sure who's running in the back. Kind of the poll questions? Anyone? I'm going to run one at a time so we can answer. That's why I've got it set up. Okay. I don't see it. Should I be seeing it or do I need to click on it? There we go. That's the first one. Okay. The first one is, how familiar are you with relational data modeling or edited relationship modeling? Like ER, kind of the boxes in line. I don't know if we have every button there if you want to just give a vote and let me know. Shannon, there's a time. We have 22 seconds left. I'm sure we can show. I think we can all see the results when they're ready. And Shannon, have they opened up or do we have to wait longer? I don't know if I should be seeing something. Yeah, this is where it's closing. It's taking time to... Oh, this is where I sing? I wouldn't sing. No, whatever. Come back. We need the Jeopardy music. My assumption here is that this will be high because generally, and this was sort of my assumption building the presentation, a lot of folks on these data modeling webinars are data models, funny that, or data architects. And it looks like we were proven right. So most of you folks are pretty familiar with the relational world, which isn't a surprise. That's kind of the data versus the core and especially when we come to a data modeling series, a lot of folks are familiar with that. When we look into XML, I don't know if Shannon's going to pull up that one. Same thing. Are you, how familiar are you with the XML technologies or whether you've coded it, whether you've heard of it and don't know what it is? Be honest here because no one else can see your answers but you. We do not catalog these in any way. So I have my thoughts on this one, but I will wait to be surprised. So I was good to know. And I saw some folks didn't vote last time. They were not allowed. They must not see what they come out to this time. The poll is assorting. It's adding to the suspense. I would say, but really that no one ever come back. This is things that Shannon's sick. Shannon's a singer. If anyone didn't know that, I want the cat out of the bag. My voice is not there today. All right. It's a little bit of a mix. Some folks are very familiar somewhat. And then some are not familiar. And some are still shy and refuse to answer. So you shall be punished for that. The next one you have to answer. But that was my assumption too. I think a lot of folks that are familiar with relational modeling maybe aren't as familiar with XML and vice versa. So to bring up the very last one, Shannon, we're going to ask a similar thing about JSON. Is JSON something you're familiar with? Again, have worked with, heard of or not? So again, don't be shy. We don't publish these to Twitter. This is how somebody we did post to Twitter. Joe doesn't know anything about JSON. No, just kidding. We did not do that. Just more, you know, as I go through, I kind of want to know what people's backgrounds are as I ramble along. It's always good to know the audience a little bit. And on that note, I neglected to say on the intro slide, I will go back to that. If anyone is a Twitter person, there is a hashtag today. Hashtag Lessons DM. So if there's something that you're, you know, questions or comments or something from the presentation you want to share, there is a hashtag out on Twitter as well. And I guess this is a long, long call. They need a better data model behind so they can calculate the queries faster. I think there's some people on the call that could help with that. All right, similar. That some folks are somewhat familiar with it. Some folks is new to them. A few folks are kind of very familiar with it. So it's a bit of a mix. Not sure if the same people who are familiar with XML are also familiar with JSON, but don't worry, we will not have you do another poll. But thank you for doing that. It helps me a little bit just to make sure that we're, you know, hitting the right target. So see if I got it right. On the next slide, my assumption was that most people on the call today are familiar with the relational databases in ER. So yes, there are cartoons about data modeling. And this is one from my first book, Data Modeling from the Business with Steve Hoverman and Chris Bradley. Some people read Data Mods to the kids to put them to sleep. I think Steve Hoverman is probably one of them. I think he has stories where his child was in kindergarten doing data models. But he's probably the exception of the rule. But again, yeah, often on these webinars, there's a little heavy, heavy focus on data models, data architects, et cetera. So the example I'm going to give in this presentation have that bias, i.e., a comparison with the relational database world. And I know that's an assumption, but I went with it. So this is not in fine. If you want to leave, we have to hear this. But this is not going to be a deep dive into the technical aspects of JSON and all the different options of modeling it, et cetera. There are webinars on that, and it's a fine topic. I thought, as we put through this agenda, it would be a good introduction to some folks that are familiar with relational databases, but maybe not so familiar with JSON and XML. Or you might be familiar with them, but kind of want some thoughts or conversation on how they might fit together. So here we go. What is XML? So I'm sure you've heard the term accessible markup language. It's really used to store and transport data. It has a very simple definition. And it was really designed on the concept of simplicity. So some of the basic design principles of XML, when it was created, was this idea of simplicity. So the fact that if I can make it easy to use, if it can interoperate with everything else and easy to understand, then it's going to be taken up in the market. Well, it's lasted 20 years now. It's been around for quite a long time. I think it succeeded in that. The other thing is this idea of modular design, to do one thing well. And the one thing it is supposed to do is data availability, transport, and sharing. So that is its purpose. Don't overload it with other things. If you go into the bottom bullet, what it doesn't do is format the information. That's what HTML is for. It doesn't transport the data. That's where something like a web service is for. It doesn't necessarily design to store it with large legacy amounts of information. That's where you may use a database. So it is what it is. It does one thing well and it does it very well. The other idea is to make it extensible. So you can easily modify the structure and content and also self-descriptive. So not only can it be machine readable, but a human can read it. And if you open up an XML file, I'm sure you can basically understand it because it has these things called an embedded descriptive tag. And we'll talk more about this. This was a pretty big deal, especially when it first came out. Think of things like object-oriented programming or some of the designs at the time where you're mixing the code still around, but mixing the code directly with the data or things like the mainframe where it's a big top-down design. This was pretty revolutionary. And I actually, in preparation for this, did some research that we'll talk about in a bit. But the big idea here is that it exists with things like data exchange. So if they give a B to C or a B to C, I have a company sending a purchase order to another company or you're buying off the web, right? Or I'm a research organization and want to share information. It's that way to be the ubiquitous exchanger of information. Which, again, we take for granted so much now, but it really was pretty revolutionary at the time. So if you were on my big data webinar, I talked about the same theory in a slightly different context. I'm sort of a fan of it, so bear with me. Because it changed in the way of my thinking. So if you're familiar with this idea of emergence and philosophy, not to get philosophical, but I tend to do that on some of these webinars. So there's this idea of the fact that complex systems and patterns can arise out of a multiplicity of relatively simple interactions. So let's think of a snowflake, right? There's all these different facets of a snowflake or crystals that form together to create this larger thing that we pretty much quickly look at and say, okay, that's a snowflake. But no two snowflakes are exactly the same. If you look at the snowflakes in the picture, they're all vastly different. But they're all made up of similar components and religion aside. There was no one person that decided that I'm going to design a snowflake. They just sort of appear, right? And this bothers me, actually, it did bother me. In my previous presentation that you may have heard, so I won't go too much into it, I think it's comfortable for us to say if we could just design it and we understand the world with something like the periodic table of elements and we could organize it everything as well. But the more we look into some things with nature, it does seem to be a chaotic mix of things that mesh together of trial and error and create beautiful things like a snowflake. Well, the idea behind the internet, really, or things like XML is very similar to that. Just do one thing well, I share data. When you think of something like the internet, the ability to share data across these disparate systems, across the globe in a very simple way is actually a big deal. So I think I mentioned when I went back to my presentation and was doing some research for some of my books, oh, from, like, 1990 something or early 2000s and they were talking about the revolution of data and this idea that you could actually order something online and that shipped to your house. Things that we're doing now and don't even think of, you know, and you could thank things like XML because it is very modular and it helps something very simple to do that data exchange across organizations. So it was also kind of cool because the way they read was very similar to some of the things we're saying now in the press because we like to make big deals about things. Internet of things or big data and, you know, they were right back then, you know, a lot of the stuff that they say was going to happen did. So who knows what's going to be here 10 years from now when we do a data diversity webinar on the new topic. But it's just kind of a different way of thinking of this modularity of data to share. So back to XML itself. So a little different than you might think with a relational database. It uses a hierarchical structure or a tree structure. So here's an example of one where this might be, you know, a purchase order where you can see. Again, you may never have seen XML before, but if you haven't, you still could understand it. So funnily enough, there's a ship to address with a name that's John Smith who has an address of city in a country. And it's sort of labeled with these different tags. So there's different nesting. So, you know, the ship to address, that's going to be your root element. And then you have these child elements. If you can almost think of that apparent child relationship similar in a relational data model. The other nice thing about it is this extensible. And for some of you folks will talk later about when you think of things like document databases, there's a similar theme here. So the idea is, you know, I have this ship to address, but maybe I didn't know everything at the time, right? So I have a name, address, city, but you'll notice there's no state in that. So the one on the right, we've added a state so that I know that this is Boise, Idaho, and not Boise, Utah. The nice thing is that any programs that have been looking at that, the original version will still work. You can sort of do this additive thing. So, you know, it's not like you have a relational database and you need to get the DBA to add the column. You know, it's frozen cost to each. But that is one of the nice things about it that is extensible because you're basically matching on these element names. The other nice thing is that it's self-describing. And I say sort of because I'm a metadata and data modeling geek and we'll kind of, you know, clarify that, but it is. I mean, the nice, the one nice thing is it's human readable. You can open up an XML file that's in text and basically understand that this is a ship to address with a name address city country. You know, fairly self descriptive. And they do describe the content of the element. So, you know, if I didn't know that John Smith is the name, it tells me, you know, the city is Boise. It's pretty obvious that's the city. But if we're true data modelers, which many of you on the call are, it doesn't provide the full metadata. So what's the data type of Boise? Does that need to be a string? Is it a character 10 field? You know, addresses that broken up. What's a numeric field, et cetera, et cetera? What's the business definition? What do we need by name? Is that customer name? Is that the ship to name that might be a gift? You know, what's the business definition of these different fields? You know, his name required all these kind of things that you might have in a traditional metadata tool or a database that kind of were these things or data model were these things you defined. It isn't. But, you know, we'll talk about this later. That's not really his purpose. It's just sharing some, you know, quick data across. But it does not fill that full metadata around it. It does have metadata. You don't need to, but people do. And it's a good best practice. You know, similar to DDL, you have what's called the XML schema or an XSD that helps define the structure and format of the data, which is basically metadata. So a little different. When you look at the data, which I'm saying is actually the XML file here in the middle as I kill my presentation. In a way, that could be a little bit confusing because you're saying, well, that's actually some metadata in there too because you do have kind of the name address, et cetera. But that really is your raw data. The metadata on the left with the XSD that helps you kind of define the structure. So you can say here that a name is a string type and a city is a string. But you're kind of noticing a lot of strings. It doesn't really have the full data typing that we may be familiar with in the data modeling world. And then the other piece of the data piece is that there's actually an order shipment here. That's actually what you're doing here. You have a shift to address for this person that you're sending some data to. So a little bit of the different information between data and metadata in these different fields. Okay, you can also show it in a model. And maybe I'm the same way. I think we can be sloppy. When I'm talking about a model, I kind of want to see a box in a line. I tend to be a visual person. And I like to see physical diagrams of things. And it can do that as well. So here's an example of an XML schema on the left. That's almost like your DDL that you might render into an ER diagram. Similar thing. So this is a web description of a literary work on the internet. So your resource could be anything. It could be a web page. It could be a document. It could be a blog. So you have the resource here. And then with this graph, I don't know, on the left it's fine. You might be a text-based person. You can read through that and see that you have... I can't even seem to grab it here somewhere. You're pointing it to it. There's a resource, right? And you can go through and see that resource has a title and a URL in the description. Okay, to me, that's a little... It has an information and that's fine. To me, that's a little hard to read. I like to see it on the right, where you can still say that there's a resource that has a title and a URL description with an author that it might have a first name, last name, et cetera. And it can parse it out. And there's different tools that can do this. I definitely don't like to talk too much about tools to keep this better and new cool. But just because people will ask. There's kind of two schools of thought there and we'll get into that. Maybe it would be a good idea to have the next slide. Nope, I'm going to knock the next slide. There's some tools that will focus specifically on things like XML and JSON and do that fairly well because you're modeling the XML, which is hierarchical, right? So when you're trying to... There's also ER modeling tools, your typical entity relationship modeling tools. They can either import or export XML, but there's always a compromise, right? And if you've heard me speak before, you know, I'm a big fan of not being too academic about this. So, yeah, there's a UML class and there's a relational table and there's an XML schema and there's enough information. Maybe it's the 80-20 rule. There's some core information that you're still talking about customers with a name and address. Could we somehow reconcile and rationalize them into a single source? So that's a bit what some of the data modeling tools do. They're going to try to mush this into a relational table, which is just not the same thing, which is not good nor bad. That's just what they're doing because that's what their tool is. To be fair, tools do a little bit of both. But when you think about this, this is almost a one-to-many relationship with the resource being the one and then the works being in many. And there's different ways to model this back and forth, but it doesn't go so well the other way, right? Could an author be the author of two resources? You know what I'm trying to say. I mean, I sleep last night, but it tends to go one directional with the parent being the parent of the hierarchy being the parent of the relationship and the ER tools tend to do it the same way. There's different ways you can do that, but that tends to be the assumption. Okay, so the XML schema is good. It's good because it can tell you the schema but without having the data and it tells you some basic physical structure. But did that kind of hit on before? Is that name field required? What's the definition of a women by name? Are there code values when you might mention that there was, but I have Boise, Idaho. Do they put Idaho? Do they put ID? You know all that stuff we're used to in a nice data model or a relational database they don't have or can use a complex data type, right? Not just string. So I want to kind of talk about this and I have shown this in other slides too, this kind of idea of a pyramid. There's different levels of data modeling. So the XML schema can just define physical data, the physical structure of, you know, it really does not have much business or metadata. So you're not going to have the business rule behind, you know, how the, I don't know, prices counted or what the business, what a customer is and how it relates to account and kind of customer have more than an account. It doesn't have that. That's really where you add that logical or even conceptual layer on top of that. Doesn't mean it's bad, but that's not what it was designed necessarily to do. And that's where it is helpful often to integrate with something like a fuller data modeling tool or metadata repository to kind of add that on or source your XML from that even better. So this is some of the context that's often lost. And yes, there's yet another metadata data modeling cartoon, right? So from the same book. And if you've, you know, done any development in the past, you might get a giggle out of this. I know it's a data modeling cartoon, so I'm not expecting a full laugh, but maybe a giggle. Okay, we're almost done with our user acceptance testing and everything looks great with this new marketing application. Just one small question. What's a customer, right? And we can laugh at that, but I have worked for and worked with huge organizations that have not made that distinction and made very sensitive and embarrassing mistakes, like sending renewal notices to prospects who haven't brought the product, or I get this all the time from my bank, right? And I get a, I have a credit card, and then I keep saying, get this new credit card at a lower rate than I already have, right? So they can't figure out that I'm already a customer and they're sending me a mailing notice to a prospective customer, right? So all the stuff that we spend a lot of time with in metadata management and data modeling, that's just not what XML necessarily has. So you can see some examples. Can a customer have more than one account? What kind of customer is this? Do we assign the ship to address to the customer, or is that maybe a sign to the account, right? All these kind of things, valid values, that's not going to be in your XML file. Because you can almost see the XML file filling its eyes. Dude, that stuff isn't my job. I'm just sending the purchase order, right? Sometimes it's good to remember that. What XML was defined for, and the beauty of it, and the power of it, and why it has become so popular. It is really a data exchange. So I'm trying to send the purchase order from company A to company B. I'm trying to order something online. This is very good. So that idea of modularity and simplicity is the sort of power of it. So it comes with pros and the cons. It's just how you use something for its design purpose. So that is why often XML is used in conjunction with a relational database for that sort of permanent storage and integration. Or if you want to have that with your operating system, or your operational, or your reporting, or your reference data, you could, as I mentioned, often export from a racial database to XML and vice versa. Because they're fit for purpose things. Here's one way I'd kind of talk about this a little bit, but you can. You can take an XML schema and generate EDL from it. So you can see here in the example that if I have the resource table, I can create a table called resource. You'll notice that they're all text shields right now. Because again, you have that very limited data typing in XML. It will create an author, et cetera. I'll say you can. There is a translation with kind of caveats that I had mentioned earlier. And again, some comparisons between what we might say an XML diagram with its sort of native modeling XML as a hierarchy. And then some of the compromises that might be made when you put that into a relational model. Then you have to make some design decisions. In this case, it is sort of doing that. I have a resource and an author and you can have more than one. But there's some design decisions that can be made. It isn't necessarily a direct translation. Because again, they're designed to be different things. One's hierarchical and one's not. Okay. So a little bit about XML. Hopefully that was some thoughts that were helpful. When we talk about JSON, some folks think of it as a more modern version of XML. Some people have a slightly different use case. We'll leave the jury out on that. But similar, it's a JavaScript object notation. And it's a minimal readable format for structuring data. And again, primarily the transmit data between the server as an alternative to XML. It has some other use cases I've seen as well. But we'll talk a little bit about some of those. You'll see an example on the left is an example of the same thing. We have a list of our employees. So we have Shannon and Anita and Tony. You might recognize those names. So it's the same information one showed in JSON and one shown in XML. So you can make your choices. I tend to think JSON is a bit easier to read here on the left. It's just more concise. If you're programming world, obviously it comes from the JavaScript. You might be more familiar with that. And I was a programmer too. So I kind of like the look of that. One of the things that can be very annoying when more than our XML file, at least gets huge. Just think how long this took for these hash tags. I mean, the element tags. This is the way they're broken out. But similar to XML, it is sort of self-describing so that you see that this is the first name and the last name right there with the data. It does have that same hierarchy. And it is simple and interoperable. So it still has that same design. It is different. You can do things like arrays. You can, you know, the idea that it can be parsed with things like JavaScript. And as I already mentioned, kind of design-wise, it can be seen as simpler and shorter to write. That's always difficult to say because everyone has their preference, right? You can look at the one on the right and say, no, I like that because you can see it. It looks almost more like a table. It's more structured. Again, there's different ways of doing things. I will let you decide. I should take a poll for that. See who likes which one better. Okay, so similar to the XML, there's this idea of a schema with JSON metadata. And here's an example. You might have had a JSON-based product catalog. So you have sort of an ID, a brand, a price, and kind of an optional set of tags. I see it is a bit more advanced than some of the things you can do with XML. So here on the left, you can have your data, right? And that can be, look if you can do it, folks, because it's kind of a mix of metadata, too. You can obviously see this is an ID, a brand, a price, and you're going to do things like tags, like a metadata tag, right? So that I can say that this information has to do with camping and sports because it's a super cooler, maybe something like you put water or beer or something in. But still, you don't have the full context, right? You could say, well, can the ID contain letters? Well, you'll see here that the typing is a little bit more advanced here. You can say, oh, yes, it's an integer. Whereas the brand is a string. You can put things like description here as well. And you can do things like it's just required. So yes, you can. The brand's ID is required. So a little bit more robust in some of the things people traditionally do in XML, which can be very nice. So one of the use cases that's become popular with JSON is this idea of a document database. They often use the JSON documents to store their records or the collections in their databases. So one of the rise in the popularity of things like a document database is that idea of the ability to store unstructured data in a flexible way. So if you think back to the idea of XML, it's extensible, right? So in one version, you could have name and address, and in one you could have name address, and it's not going to break things. So similar idea with document databases. And one use case might be, I'm a museum, right? And I have all this stuff about China. So one says I have this nice beautiful vase or vase, have you seen, that comes from China. And I could do a search on that. I also have some great books in the lobby that have some information about China. And you can see that that field matches. But everything else about it is different. One's an artifact and one's a book. One has things about what medium it's done in. Is it ceramic? Is it cloth? Is it paint? The other one has a title, which may not make sense for other works of art. So that's one of the beauties of a document database and why they have become more popular is that idea of the kind of flexible schema. And Jason can do very nice things with that. So that's kind of why those things fit very nicely together. A little bit of a jump, but not too much. So jumping back a little bit to a different topic is this idea of the semantic web. So there's this idea of the resource description framework, RDF, that really helps drive a lot of the things in the web. So back to the earlier point where I had the internet interweb of a thing to thing and how XML sort of shared that the data exchange between them. Well, that's sort of thinking of a server to a server, kind of sharing data between them. The goal of the semantic web, and we should like this as data people, is that you're trying to share data so that it's data to data. And they're trying to make, and this is kind of that second bullet here, goals to move from a web of documents where you have URL, and you just go URL to URL to a web of data so that you can actually see what's in that URL and add some semantics and some contextual meeting. So I guess you can think of it as a data model of sorts, a very simple one. So you basically have subject object predicate here on the left. And it could be something like ACME Publisher is the publisher of RDF is easy. And it's really limited to that because you're trying to see basically just the basic connections between them. So these are sort of, if you think of graph databases, related to things, and trying to see connections between them. And we'll get into some things like vocabularies. And there is a vocabularies, friend of a friend. So you can see who's related to whom. That's kind of the power of some of this. Well, there's certain serialization formats for this. And you'll see that there's an RDF XML, the common one. There's also a JSON, right? So when you're thinking of the exchange format, this is a very good use case of where things like XML and JSON are used. So there are things like vocabularies or schemas to describe what's in that to you make free words, things like the Dublin Core or schema.org. And again, this is adding some of that semantics and context around the very web itself. And again, this is an idea of creating a web of data rather than a web of documents. And this is an example I've stolen from Data Diversity so they can sue me. No, I was kidding. It's actually out there. You can do it yourself. You can go to the website and right-click and save you source. And you can see some of these examples yourself. So here's an example of, OK, so last year we had the Enterprise Data World Conference. Hopefully some of you went there. And it was at a place, right? It was at the Sheridan San Diego Hotel in Marina. So what the code on the left is saying, this was taken from schema.org, one of the vocabularies. There's a type of thing called a place. What are some common things about a place? It's going to have a name. It's going to have an address, a postal code, et cetera. And those are some common things that define placeness, if that makes sense to a modeler. Well, at that conference, and I was lucky to be there, I took a picture in the upper right. Won't win any awards for that picture. But I took a picture and say I posted this out on my website or Twitter or something, right? There's certain tags around that. But if I had this on my website, I could put some of this code in there to define. This one is not real. I made this one up. The one on the left is real. You can go look at that. I could say that there's a type of a thing in this website called a place. And you'll see there's some of the same field, the name, address, et cetera. And so why is this important? Maybe I'm trying to find out everything that's happening at this certain place here in San Diego, Marina. The place stays the same here, right? What I'm interested in is the place. And I know that there's a conference at this place. And I have an idea what it looks like because there's a picture about the place. That's making it a web of data, right? So you could have had that this is an event. And you might have wanted to know everything about data events. And that might have been a different type of data, if that makes sense. So it's sort of giving meaning to what's on that webpage. And then you can do sort of smart queries around that because you're saying, tell me everything about a place. Tell me everything about speakers. Tell me everything about a book that might be referenced on that. And the authors of that website can kind of put that in there to help a help their search results and help provide more information. So you may be familiar with Dublin Core. And that's a common set of metadata standards for things like media and books and that kind of thing. So it creates this kind of standard for having a title. What are the things about a work of, I don't say art, but a literary work that has a title and a subject and a description, et cetera. And again, you'll see that some of the resources can be described in things like XML. This example on the right is not an XML, but it gives the idea of what it is. So what do we do on the internet? We post pictures of cats. So I wanted to make sure my picture of a cat got out there. I could create a resource description and kind of say, well, here's the title of my favorite cat video, the subject is cats, a quick description of it, that it's a video and not a book, what language it's in. I guess it's my cat speaks English. It would be in English and publish it with cats online. So it just gives you a little more information about that resource. So it just isn't a bunch of stuff on the internet, but it's sort of a semantickness around it. Schema.org is another popular one. Webmasters can use to mock up their web pages. So if you haven't heard of it before, you should at least be impressed by some of the folks that have. So it was actually created by a group of some of the search providers, things like Google and Microsoft and Yahoo and Yandex. And these vocabularies are created by kind of an open community process. So there's a GitHub project out there. There's also a public mailing list through the W3C. So again, they create these types with certain properties in there. Again, you can describe them using JSON, RDFXML, et cetera. So again, what type of thing am I describing? Is it a place? Like we gave the example of the Sheraton in San Diego. Is it a type of person? Is it a creative work? Et cetera, et cetera. There's also certain extensions for certain industries. Health, life sciences, auto, et cetera. Because certain industries, again, if you think of the main purpose of things like XML is sharing between B2B and B2C, you probably want to have some really shared attributes and some commonality in your schema if you want to be sharing information. There are other common schemas and vocabularies out there. Again, Dublin Core and schema.org are probably the two popular ones that come up if people are familiar with this and mentioned some. There's actually a site, the link to open vocabularies, and they kind of do a heat map of the different helpful listings of them. So I mentioned earlier, and there's a website here if you want to look. The friend of a friend, that's again linking people to people. So when you think of social networking and that kind of thing, you can help with that as well. So in summary, XML are used for transport and interoperability of data, and that is what they're good at. And that's important to remember because they don't do a lot of the things we're looking for in a relational database and vice versa. So they are simple by design, and that's what's good about them that also can be frustrating about them if we're familiar with products and have a lot more richness around things like metadata. They do other things like this idea of simplicity, modularity, and extensibility as well as being self-descriptive again. We can, as a data modeler, open it up and say, oh, they just addressed. They don't say whether that's mailing address or PO box or, but we knew it was an address. That's a lot further than we would have been if we didn't have something like XML that was going to share it. You can integrate with some of these databases, either translational with some of the compromises we mentioned to a relational database, or at some of the core storage for some of these no SQL databases like document database. Whether it's relational or XML or JSON, you can still do graphical models. And that might be something folks aren't familiar with. I think often, especially with some of these, you're used to seeing text-based format, but there are tools in the market that do that. And for me, personally, as I said, I am a visual person, so I like to see it that way. It kind of makes a lot of sense to me to see it. It's kind of a use case of some of these. You have a semantic web that turns the web from a web of documents related to a web of data and has semantic meaning around it. A little bit about me. In my company, we kind of specialize in data design and how that kind of helps businesses do what businesses do best. Here's me. If you want to contact, I would do it with Shannon, and I need to post all this information. So if you do want to contact me for any reason, after that, please feel free. A little bit of a plug. We do have a metadata management course that goes deeper into some of these topics, which is available through the university. And another shameless plug is for our lineup next year. So we have already planned a full list of lineup. Our very next one is on January 26th, where, again, we try to do a mix next time. It's going to be talking about enterprise architecture and how that data modeling fits in with that. You can see throughout the list there's a whole wide range of different topics. Hopefully you'll join us for one of them. So without further ado, I will open up to Anita or Shannon for questions. Great. Thank you, Donna. Well, to answer the most common question we get, we will be sending a follow-up email within two business days with links to the slides, links to the recording of the session, and anything else you requested throughout the webinar. If you have any questions, put them in the Q&A. We'll be working through those, and I'll give you a minute to do that. And in the meantime, I think we have a few. Donna, related to slide 14, do you know if Irwin supports the XML modeling that you showed there? We'll be talking about it. So I'll make sure I'll go back to the right 14. Well, in general, I don't generally like to talk, but I think it was one of the ones for that. So in general, I would just say I don't like stock products, but they generally do more of the translation model than showed. They don't show a native diagram of XML. They're going to translate that into an energy relationship model. So Irwin is one of them, because they're the group in the ER world, they don't show native XML models. They're going to do that translation so that when you import XML, it's going to show up as sort of an ER rendering of an XML file, if that makes sense. Great. So I'm not seeing any more questions at the moment. I see one, and Mary's more of a comment rather than a question. So in my view, XML and JSON, quote, modeling doesn't make any sense when we model something. It depicts a logical concept of the solution under consideration. More likely you're referring to diagramming, which is not the same thing as modeling. And wow, that's kind of a lot of different things. Well, I think that we could be a modeler and say, how do we define a model? Right? So there's several different parts of modeling. So one is the very physical nature of modeling. I would say modeling is the structure of your database and the format. If we think back to that pyramid that I have, this is a logical conceptual and physical modeling. I think JSON and XML modeling do an excellent job of that physical layer. And if you're thinking about creating a data structure, which maybe 75% of a lot of people doing data modeling, you're using it just for that. So I think in that sense, they're great. I think there's some also some design decisions of how you do that modeling and what makes sense and how you break up the fields. So in that sense, you're doing some design. If you think of modeling as terms of that, I would agree with you. It's not necessarily a thing of modeling and the kind of conceptual logical doing all the relationships and integration. But again, that's probably not what it's designed for. So I have some agreement. It's probably some clarification in kind of my view. But I would also agree. Some people think of modeling as diagramming. And I did want to kind of make that point that if we think of modeling as diagramming, which some people do, I mean, when I think of it as diagramming often because it's easy to kind of do that design in pictures, you can do some of that with XML and JSON. I want to let people know because I think a lot of folks kind of think they're stuck in a text editor when they're doing that. But there are solutions to that. Great. Thanks. Are there any other emerging standards that might replace XML or JSON? I am going to defer that. I think those are two popular ones out there. I'm not following some of the other ones that might be. I am reading another one where it said, you refer to XML. In my company, we create an XSD, which is called a message format that is shared. How does JSON relate to this? So XML is going to be the format. XSD is kind of the schema. And JSON has a schema as well. And then I showed a picture as well. So they have their version of that as well. Sorry, I keep jumping ahead of you. You can't trust me. I get excited about a question. There's a question. Where can collections and field definitions be captured? Are there better options than Excel? I would say that's a good use case to use. One of these modeling tools. So self-model natively can track some of this interface. And I showed the JSON schema. There was a field where you can use definitions. And sometimes, depending on your use case, if you are integrating with things like a relational database, you can store them in kind of a relationship model. So if you just... Also, there's things like metadata registrants. When you're thinking of some of these vocabularies, that is often where some of those, you know, on the web, where some of these are posted as well. We also have a question about healthcare. I'm not sure. Do you have any thoughts on FHIR? I am not familiar with that. So I am going to defer on that one as well. Okay. And then what is the best practice to translate from relational model to JSON format? Ooh. That's probably a bigger question than just this one topic. I would go back to your use case. I mean, I think if it's already in a relational model, it's probably there for a reason. I wouldn't necessarily start there if I'm building JSON. I guess it was my rambling way of trying to answer that question. But often that is where it is. So one of the things is what's kind of different with those is the idea of the relationships. So you're going from an ER to a hierarchy. So you want to think through those and see what makes sense. Actually, there's another day diversity webinar that went a little deeper. Sometimes it makes sense to break them up into separate documents. Sometimes you want to break it up into a hierarchy. Maybe a general thought of giving some thought to that is that relationships are just handled a little differently. You can have separate documents. You can have embedded hierarchy sometimes that has to do with performance, readability, et cetera. So a couple of thoughts there, but probably a deeper webinar to do on that one. Okay. Are you seeing many people transform your models to JSON-LD or most just starting with JSON text? I am seeing a lot more uptake right now from folks to going from relational data models to XML. I think JSON is a little not as... I almost think there's almost two camps. I think a lot of folks in the programming world are a little more comfortable with JSON. So I have not experienced too much going to the JSON-LD more of the other. But that would be my answer to that. So I think that was fun. There's another one. The programming tool. I'm sorry. I'm jumping ahead of you again. That's okay. I don't want to answer that because that's kind of a vendor plug, which I don't. But there are. But yeah, I would just... I guess my general comment on that is that do take a look. There's some that have been out in the model. There are some categories. There's some data modeling tools that can export out. There are some native ones. And with the native ones, there are some that kind of grew up in the XML world. And they're adding JSON. Some are native JSON. So there's also a difference. And most of them are kind of start-up mode. Some are actually getting this idea of a semantically as well. Often they do kind of focus almost by defining a necessity on this physical layer. Take a look. Some of them actually have this idea of adding the semantic layer as well. Okay. Can XML JSON data modeling replace ER modeling completely? And if yes, in what cases could that happen? Oh, I don't think any technology replaces anything else completely. I think as I mentioned in the call, they're kind of different use cases. So I would see XML more as data transport. I think ER modeling is good for ER. You're looking at kind of acid transactions, right? That's what ER modeling is good for. So this is probably more succinctly in other presentations when I was thinking more clearly than I'm not doing today. ER modeling is good for what ER modeling was designed for. I want transactions that are linked. And I have the accountability for that. If you want to use something like JSON, the one example I gave was things like document databases, which is a very different use case than your traditional ER model. So often they're used to kind of complementary. I wouldn't say any technology is going to replace. I would probably still put my accounting system on the ER system and the relational database, a lot of data warehouses. There's a lot of good reasons why folks are doing that because of the rollback, because I mean a lot of the great things relational databases have. If I'm trying to do something behind a website or have a lot of multimedia, something like a JSON based document database is an excellent thing as well. So right now, no, I don't think there would ever replace ER modeling completely maybe as things mature. But I kind of doubt that because they're really, right now, different designs. But that said, what we're seeing in the market with even big data databases becoming more, having relational features and more relational databases, adding some big data type stuff, things are merging. But I guess my general thing is the big thing of the use case for it, and I wouldn't say any. The vendor tells you they're going to replace everything else. Just give some thought behind that of, you know, often these technologies. A lot of the big companies I work with have heard of the different use cases that you're using it for. Yeah, ER modeling does its place in many, right? Great, thanks. Okay, sorry. Go ahead. I was just going to wrap up. I was going to say I could do the email if they are any others, or did I miss them? No, I'm not sure that you missed any. Oh, hi. Well, thank you, Donna, for another great presentation on QA. I'm afraid, you know, it's all the time we have for today. So just to remind everyone, we will be posting the recorded webinar and slides to DataVersity.net within two business days. And we will send out a follow-up email to let you know the links and other requested information. Thank you again for attending today's webinar. Thank you, Donna, for another great presentation, and I hope you all have a great day. Thank you.