What is the ontology in Foundry? In this video, we're going to try to pin down this sometimes slippery concept with a few examples from the Foundry Reference Project. Now, when we talk about a term like ontology, it's easy to get wrapped up in big picture metaphors: The ontology is a digital twin for your organization, or it's a data API for structured access, or it's a semantic layer for putting business meaning on top of your rows and columns. Now these framings all have their place, and they're useful conversation starters when it comes to thinking about building value from Foundry holistically. However, in the case of an individual project, I often find it more useful to simply think about the ontology as the object layer, where I've pulled data out of my data sets and structured it for fast access and user write back in my applications. In this video, we'll poke at the details of what differentiates data

in the dataset layer from the ontology layer, 
and see how structuring data in the ontology is the key to unlocking features that allow 
us to build applications that will compound, rather than fragment, our data asset. Let's 
go. Let's keep this practical lens as we take a look at the object types we've configured in our 
reference project. Continuing in our data lineage view where we left off in the last video, on our 
right, we see the final data sets in our pipeline, and from them, a one-to-one correspondence 
to an object type. If we right-click on our example data route alert object type, then we 
can jump into the ontology management application where this object type is configured. Before we 
get distracted by all the things in the overview, let's reinforce what's happening technically at a 
fundamental level. Our object type configuration simply describes how to move data from 
our backing data set into a database.

and in that database, each row in our input data set becomes an object in our destination object type, and each column in our input data set becomes a property on that object type. Here we're looking at the property mapping. Every property on our object on the right corresponds to a column in our input data set on the left, and each property has its own configuration to control its display stuff — like how dates and numbers are formatted, as well as conditional rules that can change the color and alignment based on simple logic. Now the overview should make a bit more sense. We've got an object type called example data route alert, and within that object type, there are 1731 individual alert objects in addition to the properties that we just saw. We've got two other key pieces of structure to add to this object type over here. The actions are specific edit rules that define how users can edit these objects. In this instance, we've got a

few state machine-style edits that can change the 
status and assignee of one or more specific alerts as they go through their life cycle. And below, 
the link types relate this particular object type to other object types in our ontology. Here we see 
each alert is linked to the corresponding route. Each link type has its own configuration. Here 
we've got our alert object type on the left, and our route object type on the right. They're 
linked with a simple foreign key relationship. The route id property on each alert needs 
to match the primary key property on the corresponding route. If we instead 
had a many-to-many relationship, we'd be prompted to choose a join table 
that defines the mapping between primary keys on both sides of the relation. We'll take 
a look at this configuration in a future video. Otherwise, there's not much else going 
on in the relationship configuration. The names config should have reasonable 
defaults, but you can change them if you need to

differentiate between link types that are making 
connections between the same two object types. And here's a quick navigation tip. To move 
around the connected parts of our ontology, hover over the back home button, and you can see 
related objects, relations, and actions. Let's jump to the route object type configuration just to see 
another example. Here we've got over 6000 routes, and we can see more relationships defined: 
both the relationship to the alert where we just came from, but also relationships to 
the flight airport and airline object types. Enough poking under the hood. What does 
all this structuring actually get us? Well, one thing it gets us is a new way to search, 
explore, and visualize our data. Let's open up our routes in object explorer. Object explorer 
is sometimes overlooked by platform builders, but it's got a surprisingly deep feature set for 
less technical users to explore and drill into data. And often, it's the perfect place to push 
users out from a structured application workflow.

into more open-ended exploration of the ontology data. For instance, let's say we want to compare all the routes that fly into two of the busiest airports in the U.S.: Chicago and Atlanta. All of our charts are interactive, so I can just click to filter down to the Chicago routes. I can also use my linked data, following the relations that we defined in the ontology. So, for instance, I can get just the routes that also have at least one alert that hasn't yet been resolved. I can also save this investigation, and here I'll just call it my Chicago routes with alerts. Now that it's saved, I can compare it with the exact same set—except with Atlanta routes that I saved earlier. All of my charts now show the comparison between these two sets, and I can see that Atlanta's problematic routes are generally longer haul flights, and the problematic routes in Chicago are much more often cancelled. So putting our data into object types

unlocks object explorer for our end users. And we 
can see that how we structure and build relations   between our object types will dictate how they 
can navigate, filter, and investigate this data.   While object explorer lets users wrangle data 
at scale, having our data in object types also   unlocks the primitive of an object view. 
Let's check out some example object views   and how they serve as containers to build rich 
reusable components for our end user workflows.   From our exploration, we can use the 
results to jump into any individual route.   If you've created an object type before, you might 
be familiar with the default object view that's   automatically generated. They look something like 
this, and just lists out the properties and links   for, in this case, the Denver to Atlanta route.   But as developers, we've got the 
tools to make these views much richer.   For instance, the carriers tab breaks down the 
flights on the route by the different carriers;

and the flight performance tab gives users an on-rails workflow to segment and compare different cohorts of flights that have flown along that route. We can also traverse out the links for this specific route, and for example, hop into the object view of a related route alert. Here, our object view is geared towards more operational use rather than the dashboards that we just saw for the route. Our alert is summarized and placed in context, and we have access to some of the actions we've defined in our ontology to move this alert through its lifecycle. In the next video, we'll dive into how to build and configure these views, as well as standalone applications. You can find more detailed guidance on configuring your first object types in the Foundry Academy 301 course, as well as in the ontology documentation. And you can obviously continue to explore the other object types and their configurations within the Foundry Reference Project on your Foundry stack.

Getting a useful grasp of the concept of ontology and Foundry can be tricky. It's easy to get sucked into abstraction and debates about how to organize data systems. While this makes it tempting to throw up your hands and simply treat the ontology as a dumping ground for data of all shapes and sizes, taking a little bit more time to think through your data model will pay dividends when it comes time to build your analytical and operational workflows, as well as make every future project that much easier to implement. Subscribe to the channel to catch an upcoming video where I'll do a code review on my own ontology design within the Foundry Reference Project, and talk about what I'd do different if I could start it all over. And also the next video in this series, where we'll look at the application development examples in the Reference Project, and see how the ontology structure we looked at today affects how we can build applications for our end users. See you there.

Foundry Reference Project | Ontology

Palantir powers AI-assisted decision-making from war zones to factory floors. Follow our Developers channel to learn about our software directly from Palantir engineers and architects. 
