The Second in a two part series.
In part one of this blog, we defined and discussed the first two types of data that industrial companies concern themselves with: (1) fact data, which is extremely important and extremely large and (2) context data, which tells a company how all the different sets of fact data are related to each other. In the second blog of this series, we will define the final piece of the data puzzle, ontological data, and see how it all comes together to make the all-important meta-data.
Ontological data is to context data as context data is to fact data. It provides the structure of a contextual model. In the example ontology below, we outline the structure of the previous example. They are clearly very similar, but with a key difference: the ontology doesn’t have any specific information, they have placeholders for the different pieces of information in the context model. The arrows indicate the types of connections and what those connections are called. Take a look at the Pump in the diagram below - it has 4 arrows, 2 of which point to Vibration Tag, and 2 for PI Tags. In the context model, those arrows pointed to separate entities which follow the rules of those 2 types, but the entities are separate.
Figure 1: Simple example of pump data and vibration data and their connections
This is why, at Element, we talk about the ontology as the “shape” of the context model. It defines what kind of data and relationships exist in the context, but not the context itself. Because this is strictly less data than you would have in a context model, it’s easier to reason about for both humans and software - the data consumer doesn’t have to know anything about which specific vibration tag represents the specific pump and the specific plant, but that for any pump at any plant, you will have a Voltage sensor whose data is stored in a PI Data Archive. This allows us humans to think at a much higher level when formulating a strategy to answer a question. It also allows software to easily interpret a given context model through the lens of the ontology and without having to scan through the entire context model to build a picture of what’s in there. The benefits aren’t limited to using an already existing context model, there are huge benefits to actually building the context model as well - the ontology gives us a template to build against. If you know that a pump must have a functional location (FLOC in the example diagrams), you can fit that in consistently as you’re constructing the model. More importantly, they give you a clean way to sanity check the model as you’re building it by asking questions like “show me all of the pumps without a functional location”, or “which pumps don’t have a main shaft vibration sensor”.
Much like a context model, the ontology changes over time. This happens for many reasons: maybe the initial use case was very simple, and over time you want to pull together more and more of the existing enterprise data into play so you begin adding more and more components of the overall enterprise to the context model, and therefore must expand the ontology to cope, or maybe you added a new camera to all of your windmills, and want to ensure those video streams are associated with the correct windmills, or any number of other options.
Figure 2: Detail of the contextual models over time
As we change the ontology, the underlying context model can encompass more and more facts, but that doesn’t mean the old version of the context model was wrong, just that it used a different ontology. For this reason, it’s important to keep the historical record of the ontology around, even as you’ve moved well beyond the initial one.
Are you still with me?! Great. Now let’s talk about metadata.
Now that we’ve walked through these three categories of data, we’re ready to talk about metadata. Simply, metadata is the context model and the ontology for that context model.
Figure 3: Visualization of the 3 categories of data that make up our worldview of data and metadata
While all of these categories are data, only the top two are data about the underlying facts, or put another way, the metadata is the context and the ontology. Maybe it’s becoming clearer why I chose the Stephen Hawkings anecdote about the turtles in the first blog - without some kind of structure to this concept of metadata, it becomes very difficult to figure out how to get started on your metadata journey. It’s infinite. Could you have metadata about an ontology? Of course, let’s call that a meta-ongology. Could that meta-ontology have metadata? Yup. And so on, ad infinitum (or, perhaps, ad-nauseum).
As you travel up the layers of the pyramid, the data gets more compact in terms of data volume, easier to reason about, and less specific. While the fact data can tell you that Pump 37 was 142F at 1:45pm, without the context model, you can’t figure out which facts you might need to reference to actually answer the question, and without the ontology, you can’t easily interpret the fact that every pump has a temperature sensor, and that a temperature sensor’s data is stored in a PI Data Archive.
Trying to solve data problems without metadata is like trying to find the article on Turkey (the country) on Wikipedia, except all the articles are on one page, without any headings, punctuation, or hyperlinks. Hope you didn't skip part one of this blog series.
Register to view a live demo or sign up for a free trial to use the software for 30 days. You can also purchase a Personal License from the AWS Marketplace or Azure Marketplace.
Questions? Please contact us.
