 Long-shulked is an individual that has for a long time seen the need for common data vocabulary and semantic introsperability. So with that, I'll pass it over to Long-shulked. Thank you Michael. And I appreciate everyone's presence here as we get into what I consider a very important part of how you manage data. I truly believe it's important to manage data by, first of all, understanding the metadata associated with data. And the ODAC standard is one of, I consider a critical part of that, whether it be toward smart cities or smart anything or help you manage the vast, big data associated with a business. And I've got an example with a use case. The use case happens to be associated with a very, very large shipping company. Their enterprise architect is directly involved with the ODAC project team in helping to put together a use case. And I'll be briefly talking about that in this slide. So with that, to start with looking at what are some of the typical problems. And then the shipping industry use case will highlight some of those problems and the need for a solution because of the complexity of what they have to go through. And as highlighted by Don, when you want to understand and analyze data, you naturally begin to categorize that. When I was growing up, I played the game of, is it a person, place or thing? I don't know if you've played that game. But in so many questions, you get down to what it is that the person's thinking about. And you answer either yes or no based on them asking questions. And then you get down to figuring out what it is. Well, there's a natural tendency when we look at something new to categorize. And I'm going to provide an illustration of how ODF is an intuitive categorization approach. And then, you know, what are the capabilities that are necessary for a solution, which really are going to highlight what ODF is all about. And then what are some of the key features of ODF? And then what's the business value of the ODF standard? So what are some of the typical problems? First of all, enterprise applications within the stove pipe or silo, if you will, of one enterprise are generally built with that regard to a common vocabulary across those applications. You typically go out and you buy some vendor product, you plug it in, you have to deal with all the APIs that are tying that application to the other applications they have to interface with. And in many instances, large organizations, and I came from a large organization called Lockheed Martin, a very large organization with thousands of applications. So our spider web was tremendous. And then many organizations also have this exchange data with multiple external organizations. And then some people would say, well, how about using standards? Well, problem there is, many of the standards out there conflict with each other. With the exception of two standards on that list there, every one of those other remaining standards all deal with the concept of address, physical location, address. You think that at least they can get their act together and compare notes to come up with a common approach for how address should be represented. And that's not true. So it's an issue. Everybody comes up, even standards bodies come up with their own mindset of what, you know, how to represent concepts. So. Or the two. You want to ask me see if you can see? Yes. Shipping industry. Again, a very large shipping company. They, not only is there the item starting at the factory, ultimately getting out to the end consumer, the item, but then there's the containers that go around multiple items. So you've got the container carrying, you know, thousands of items within them. And then you've got thousands of containers on container ships. Or on, you know, you could have a thousand containers riding on a train. You might have two or three containers, you know, going by truck. Bottom line is you've got multiple companies. You've got multiple countries and locations, especially when you get into crossing borders, country borders. So you've got export import requirements. You've got lots of planned and actual events that happen. And then you've got unplanned events like hurricanes, in the case of, or other kinds of weather issues for the trucks and so forth. And then you've got reporting requirements. You want to know the status of your containers. You want to know the status of those goods that are in the containers. And there's no common vocabulary. And the senior architect from this large shipping company saw, heard about the ODF at the last open group meeting, which was in London, said, I like what you've got here. We need to incorporate it. And they're involved now in helping us build a guide for the use of the ODF. So I'm going to provide you a little bit of insight into what that is. But first I want to highlight their, their problem is very complex in the shipping industry. You've got all these legs with each, you know, whether it's the train or the ship or the truck, you've got all these legs. You load cargo, you depart, you arrive, and you discharge or unload whatever it is you're carrying. And then it goes on to the next carrier and then the next carrier and the next carrier. In addition, they have a plan for all of Lewis 4 items. And then something happens, you have to adjust it so it becomes an estimated time. And then you've got an actual. And so you're keeping track of the log that keeps track of all the day times of all of these things. And so all of these things then are part of a string of things that they need to monitor because they all have to ultimately be recorded. I'm going to use the analogy here out of chemistry. When you combine different elements from the periodic table, you get molecules. If you combine multiple molecules, you can get a compound. And when you want to understand what you have, you typically do analysis, you do some sort of testing to find out of a given compound. You do different types of testing for certain liquids and then boil it or heat it to determine what kind of elements are part of that compound. And so for the analysis, there ultimately has to be a rigorous data categorization. That data categorization is typically, I hope everyone in here is familiar with periodic table. All the elements known to man are part of a periodic table. And they can be arranged in different sequences based on how they want to use the data. But what's important is each of them has a unique ID. So helium is number one because it has one proton associated with that atom. Helium has the number two. It has two protons with that atom and so on with everything else that's in this list. And so when you combine different elements, you then can have molecules and molecules combined can become compound. I'm going to suggest to you that ODEP is quite similar to the periodic table but for data elements. And each concept in the ODEP has a unique ID. When you combine two, when you combine things from the ODEP, you get data on concepts and then when you combine more of those data on concepts, you get a data model. So the capabilities of a solution, analogous in many ways to the periodic table, you need a basic grammar for data descriptions. You need a consistent and reasonable way of tagging the data. In other words, this ID. You can use those IDs in the periodic table to understand and they've got H2O and there's a way of the semantics of mixing chemicals that is consistent across the entire science of chemistry. You need a language independent unique identifier for each data element concept. So since it's language independent, if you've got a concept and then it's initially based on English, but that same concept then in Russian or German or French or Chinese will end up having the same ID. Similar to an IP address, www.company.com has a unique ID that finds that unique spot on the planet in the inner. And so what you want to do then is enable the use of existing vocabularies. The ODEP is going to be something that's very fundamental and very intuitive, but they will plug in existing standards that are existing vocabularies. So some of the features of the ODEP officially published by the open group in May 2016. It enables interoperability with an intuitive categorization of basic units of data that does have a language independent unique ID for each concept. And the core index for being part of the basic standard has 12 basic object classes and there's just a few of them there. Fundamental, what is an enterprise? What is a person? What is a product? What is a process? What is an event? They're all defined and they have unique IDs. Similarly, basic fundamental properties, name, date, amount, quantity, time, measure, text, date, time, there's a total of 14. Currently, and it's not limited to this set, but currently we have identified those four standards as plug-ins to the ODEP. So the United Nations Standard Product and Services Code, we have a fundamental core object called product. The United Nations has tens of thousands of products and services identified in that standard. And so that entire list, that entire taxonomy is a plug-in under the object class called product. Why reinvent that wheel or even try to? There's decades of work that went into that standard and it's also the same body that gives you the bar codes that you find on anything you buy at the grocery store. Okay, UNEC Rep 20, units of measure. It's got hundreds of units of measure used by the United Nations. And I can't, if you look at that set of units of measure, I can't imagine any unit of measure that's not already on that list. Each of those has a unique ID associated with each of those products and services, each of those units of measure, and then standard industrial codes. If you are in the U.S., you're obligated when you get your IRS ID to have to go and find out what kind of business are you, and you have to get a standard industrial code. So you have to record that for your business. It has been done, you've already done it in the U.S. There's a similar one, but it's a little different in the U.K. And then currency codes, nice little standard currency codes. Okay, also, and by the way, that's not a limited list. Any other standard that you want to plug in to an appropriate spot that you've voted, you can do that. The current snapshots have extensions for the concept of date, so things like birth date, delivery date, production date, and so forth. An amount cost amount, price amount, tax amount, and there's not a limit to other extensions as well. So just using that core set of ODEV objects and properties, you can get these kinds of concepts in this, it'd be much longer than this, but these are just examples. So person identifier, enterprise identifier, person family name, person given name, and so forth, as you can see there. And the unique ID, so no matter what language you're in, the concept of enterprise ID would have two underscores, one across all languages. So to the shipping event model, again, I've already highlighted the fact that there's a low departure of arrival unload, and this particular company to highlight the complexity of their problem and why they see value in the ODEV. They have 742 vessels, they carry 12 million containers every year, and they call, you know, stop at 343 ports in 121 containers, and they have to keep track of all that, and there's, they lack a common vocabulary. So they're quite interested in coming up with an approach that would leverage ODEV to help them in their problem. In the case of ODEV, there's a fundamental core object called event, and so a proposal would be to extend event with a dot transport dot load and a dot transport dot departure, in other words event, dot transport dot arrival, and event dot transport dot download, to capture those four events as an extension to the ODEV object. Similarly, an example of the plug-in. When you go from port to port, the export import folks want to know what's leaving the country, and before it arrives at the port, they want to know what's coming in. So there's a United Nations standard UNSPSC. If you go to that URL, and then you enter the word steel beams in their search title, you'll get those two options, steel beams or stainless steel beams, and they have a unique code associated with each of them. And if you went in and wanted plants, there's, I mean, there's over a thousand different types of plants, from live plants to cut plants to roses to, anyway, it's just huge. But the point is these codes then can be used within the ODEV syntax. So if you combine that then, so that UNSPSC is a plug-in under product, which is an object class, a fundamental object class, and then the UNEC erect 20, which has all these units to measure, is a plug-in under the measure, then you've got a complete ODEV name which says I've got a product, it's UNSPSC version 18, I've got steel beams, underscored, I've got a measure, UNEC erect 20, mechanics.mass.ton.hype.metric.ton. So you want it, you know, obviously they have metric ton, and then they also got, you know, the standard ton as used in the U.S. So that whole concept then has this other ODEV data concept identifier, which is derived from the syntax of the ODEV itself, coupled with those IDs that are coming from, in other words, TME is the representation for the UNEC erect 20 for that measure. And similarly, if this container ship has a temperature sensor because they've got a refrigerated container, you want to know what the temperature is, and you want to know the end of the measure of that temperature sensor. So applying the same principles with UNSPSC version 18, and just enter temperature or sensor, you get all the different kinds of sensors that are part of UNSPSC, and then the code associated with a temperature sensor is that one there for 1111970, and then you're monitoring the temperature in Celsius, and so again, the complete ODEV main following the syntax rule of the standard is as shown here, but its equivalent data on the concept identifier is as shown down below. So what does that do for you? The value to the shipping industry is I can say I've got 150 tons of steel beams, and in another country it's 150 whatever that is in Chinese, and the ship's manifest then is capturing the ODEV code so that when they show up in a different country, then that code is understood, and for the sake of transferring something like those codes, you're reducing bandwidth. It's simple. You're sharing vocabulary that reduces the need for multiple APIs, and you're basing it on existing standards. You're just giving it a framework that allows all these existing standards to be shared amongst multiple companies in multiple countries. It's an open source standard, again using these plugins. It's translatable into human readable language. Hopefully these concepts, it's a temperature center that's measuring degrees Celsius. Now yes, it's lengthy, but it's understandable, and using this ID, you go across all languages, and it's enabling better communications across borders, across languages. This is my last slide. If you want to get more information about the ODEV, this is a link that allows you to get that information, and that's my email. I'm the chairman of the ODEV project. Thank you very much, Ron. What do you say, Ron, is a good project to start working with the application of ODEV, because a standard like this, as comprehensive as it can be, can also seem a bit intimidating. What would you recommend is the ideal project to start picking the timers with something like ODEV and trying to tame the beast of data? If you simply went to the current ODEV object classes and properties without worrying about how to deal with plugins, you can get hundreds of concepts that are common to almost any business. I mean, person family name, person given name, enterprise name, person identified. There's just a whole lot of concepts that are common to so many businesses, just with the original core set of the object classes and properties. Just look at what's there, and I want to highlight, very significantly, that we can extend ODEV, submit a proposal, or get involved with the ODEV project team, and propose extension as to what's already there. And the process is really quite simple. I'm wondering, couldn't you imagine, I mean, the RDF is the basis of the submit to go. I mean, you're all set up with the notion of subject by the object. Why we can't help market ODEV as the concept of its RDF ready. The entire ODEV standard itself is already in the standard, it is RDF, and it appears as RDF. I just, you know, I don't know what people get. I mean, I think we're probably getting to the point where people get that RDF is the message that's making semantic web happen, making autonomous cars happen, making this next generation of sport things. But ODEV should be that mechanism. The Internet of Things, I have one example here, but this obviously could play a key role in the Internet of Things. Because anything you can imagine is probably got some sensors tied to it. And you go to the U.S.B.S.C., they got pressure sensors, they got temperature sensors, and energy sensors, and they got spout here, the kind of sensor thing. And then just what kind of given measures of, you know, speed of light. Sometimes what holds up the adoption of these sorts of things is that it requires some manual input tagging these things, bringing them in. But now that we have technologies that do recognition and video and other mechanisms, different types of sensors, and we can play and use intelligence, is there a way of sort of automating the input across the business process like shipping, where some sort of automated machine type approach brings all that data into that ODEV that then therefore allows for that cross-pulmination to not data ecosystem? Yeah, if a company is a member of the U.S.B.S.C., we're able to download an Excel file that contains all of the U.S.B.S.C. names plus their codes. If you're not a member, then anybody can go online and do what I sort of have to show here on the slide. In addition, on the ODEV website, we're in the process of building an application that will allow you to enter some terms, and then get associated with ODEV ID. I'll also offer a question that you've just asked is, to me, a very cool one. I think everyone in this room and maybe everyone in this conference, we sort of intuitively get this. We know this is a good thing. We all, in our respective teams and projects, perhaps have explanations or excuses, different priorities, right, and dictate why we haven't done it like security in many cases. But what makes this kind of exciting and a good opportunity for many vendors and IT consumers is the dynamic you just mentioned, that some of the technologies that could support this happening at scale are in place. But part of what we're doing is trying to lay the groundwork where you support an industry like shipping, you support industries like Smart City, and Open Group is not really in the market to make money, but as a group here to facilitate innovation, better success, better technology through open standards. So that's what we've been working on. I work for a company that I make that suggestion to, but I'm not CEO, so I can't make it happen. If your company is in that realm, I strongly agree with you, because I imagine there's market value, because even data entry folks are going to be more expensive than they are model-powered by a loss in, or an alpha go, or a deep mind, or what happened. So you're exactly right in seeing that. And we're providing a foundation, offering it to the community, and seeing where people want to take it. Imagine that Google DLP is a lot of venture, they charge $20 an hour per hour, and it pays a lot of deals. So you can set a stream of data, it's a first name, last name, and more than one. Your address, your city, postal code, some state, number, license number, or some security. That is a target. Give it back to you for $20 an hour. Well, shouldn't there be one that does the same thing, that actually pipes it through ODAF, in Chexton, and then essentially plug it, calls you in SBC, and gives you that cut roses into a 114039. Yes, and should that be $20 an hour? Sure. And then you have, is $85,000 or $185,000 a list? Well, in the version 18, it was $87,000. Is $87,000 going beyond that? So yeah, that would be great because essentially what you've done is you could take your print, all of your data to an integer, and isn't that the same as asking? That's one step shorter. It's actually cheaper, because you don't have to classify it into a word and then don't want to classify it, and then have a key fill. You could actually put it in the USBC code. So it's a great story, just, you know, something like that. Since all the work from the ISA mine file model, it's very similar. I guess that would be a standard that we can have an association with. That's the price model where they do feedback checking between companies and ISA. I suspect that the contents that we have of this company are probably aware of that. So could you, is that ISA or? ISI. ISI. Sorry. I didn't quite answer. Do we have any other questions for Home Short as far as business value, or some of the semantic applications of the ODET standard? And if you're not sure who the right person has your question is, if you have followed this, a panel discussion with our speakers today, so you'll have opportunities to field your questions to multiple folks. Hearing none of the questions, again around the applause for Ron Scholler.