데이터 관리를 위한 파운드리 온톨로지 이해

온톨로지 계층에서 데이터를 구조화하는 것은 데이터 자산을 결합하여 더 나은 탐색, 필터링 및 조사를 가능하게 하는 애플리케이션을 구축하는 데 핵심입니다.

### 파운드리의 온톨로지 이해
* 🔍 Foundry의 **'온톨로지'는 데이터 세트에서 데이터를 가져와 애플리케이션에서 빠르게 액세스**하고 사용자가 다시 쓸 수 있도록 구조화하는 객체 계층으로 생각할 수 있습니다.
* 🛠 온톨로지의 객체 유형에는 **백업 데이터 세트에서 객체로 데이터를 이동하는 방법**을 설명하는 구성이 있으며, 입력 데이터 세트의 각 행은 객체가 되고 각 열은 프로퍼티가 됩니다.
* 🔗 온톨로지의 링크 유형은 **객체 유형을 서로 연관시켜 객체 유형 간의 관계**를 정의합니다.
* 🔍 온톨로지에서 데이터를 구조화하면 **개체 탐색기와 같은 도구를 통해 사용자가 대규모로 데이터를 대화형으로 탐색**할 수 있는 새로운 방식으로 데이터를 검색, 탐색 및 시각화할 수 있습니다.
* 📊 개체 보기는 최종 사용자 워크플로우를 위해 재사용 가능한 다양한 구성 요소를 구축하는 컨테이너로서, **데이터에 대한 다양한 관점을 제공**하도록 사용자 지정할 수 있습니다.
* 📚 "온톨로지와 파운드리의 개념을 유용하게 이해하는 것은 까다로울 수 있지만, 시간을 들여 **데이터 모델을 생각**하면 분석 및 운영 워크플로우를 구축할 때 큰 도움이 될 것입니다."

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. 


Palantir Developers

파운드리 레퍼런스 프로젝트의 온톨로지 이해

Foundry의 온톨로지는 애플리케이션에서 빠르게 액세스하고 사용자가 다시 쓸 수 있도록 데이터를 구조화하는 객체 계층입니다.

온톨로지는 데이터 세트 계층과 구별되며 복합 데이터 자산을 구축하기 위한 기능을 잠금 해제하는 데 핵심적인 역할을 합니다.

온톨로지의 구성은 기본 수준에서 백업 데이터 세트에서 데이터베이스로 데이터를 이동하는 방법을 설명합니다.

입력 데이터를 데이터베이스의 개체 유형에 매핑하기

입력 데이터 세트의 행은 대상 개체 유형의 개체로 변환되며, 각 열은 속성이 됩니다.

개체 유형에는 1731개의 개별 알림 개체와 온톨로지의 다른 개체 유형에 대한 특정 편집 규칙 및 링크 유형이 포함됩니다.

링크 유형은 외래 키 관계와 향후 다대다 관계의 가능성에 중점을 두고 알림 개체 유형과 경로 개체 유형 간의 관계를 설정합니다.

이 구성을 통해 개체 유형의 표시, 서식, 조건부 규칙 및 기본 이름을 제어할 수 있습니다.

온톨로지 데이터 및 객체 유형 탐색하기

온톨로지에서 동일한 개체 유형을 연결하기 위해 다양한 유형의 링크가 사용됩니다.

객체 탐색기는 기술 수준이 낮은 사용자도 데이터를 탐색할 수 있도록 심층적인 기능을 제공하며 온톨로지 데이터의 개방형 탐색을 용이하게 해줍니다.

사용자는 경로를 비교하고, 데이터를 필터링하고, 관계를 추적하고, 비교를 위해 조사를 저장할 수 있어 데이터를 검색, 탐색 및 시각화하는 새로운 방법을 제공합니다.

데이터 관리에서 개체 탐색기의 중요성

개체 탐색기를 사용하면 개체 유형의 구조와 관계를 통해 대규모로 데이터를 탐색, 필터링 및 조사할 수 있습니다.

개체 보기는 재사용 가능한 구성 요소를 구축하기 위한 컨테이너 역할을 하며, 최종 사용자 상호 작용을 위한 풍부한 인사이트와 온레일 워크플로우를 제공합니다.

개발자는 항공사별로 항공편을 분류하고 관련 노선에 대한 액세스를 제공하는 등 개체 보기를 개선할 수 있는 도구를 통해 궁극적으로 더 많은 운영 용도에 맞게 개체 보기를 개선할 수 있습니다.

온톨로지와 파운드리를 이해하는 것은 데이터 구성에 대한 추상적인 논쟁으로 인해 어려울 수 있습니다.

시간을 들여 데이터 모델을 신중하게 설계하면 분석 및 운영 워크플로우에 큰 도움이 될 것입니다.

이 채널을 구독하면 온톨로지 설계의 코드 리뷰와 Foundry 참조 프로젝트에서 애플리케이션 개발에 미치는 영향에 대한 향후 동영상을 시청할 수 있습니다.