지식 그래프

실무에서는

이 분야가 계속 흐려 놓는 구분을 가장 깔끔하게 잡는 방법은 이렇습니다. 온톨로지는 스키마이고, 지식 그래프는 그 스키마를 따라 실제로 채워진 인스턴스 데이터입니다. 온톨로지는 작업 지시가 장비에 연결되고 장비가 고객에게 속한다고 말하고, 지식 그래프는 수백만 건의 실제 작업 지시와 장비, 고객, 그리고 그 사이의 엣지를 담습니다. 실무에서 그래프는 RDF 트리플 위에 OWL 온톨로지를 얹은 형태로 저장되거나, Neo4j 같은 엔진의 속성 그래프로 저장됩니다. 그리고 상당수의 운영 그래프는 한 번도 문서로 작성된 적 없는 온톨로지 위에서 돌아갑니다. 같은 그래프 안에서 두 팀이 "고객"에 대해 서로 호환되지 않는 정의를 갖게 되는 경위가 정확히 이것입니다.

연결 형태의 질문에서는 지식 그래프가 올바른 도구이며, 다른 어떤 것도 근접하지 못합니다. 사기 조직, 실질 소유자 체인, 공급망 의존 관계, 네트워크 전반의 영향 분석, 십여 개 소스 시스템에 걸친 엔티티 해석, 그리고 "여기서 네 홉 떨어진 것은 무엇인가" 같은 형태의 모든 질문은 그래프에는 자연스럽고, 관계형 조인으로는 어색하거나 아예 불가능합니다. 그것이 풀어야 할 문제라면 답은 그래프 데이터베이스이며, 어떤 애플리케이션 플랫폼도 이를 대신하지 못합니다.

지식 그래프가 시맨틱 레이어와 공유하는 한계도 같은 것입니다. 지식 그래프는 압도적으로 읽기 구조입니다. 이것들이 연결되어 있다는 사실은 기록하지만, 누가 그것을 바꿀 수 있는지, 어떤 작업이 허용되는지, 변경이 어떤 감사 기록을 남기는지는 선언하지 않습니다. ObjectStack은 반대편 끝에서 연결에 접근합니다. 관계는 애플리케이션 자신의 메타데이터 안에서 객체의 타입 필드로 선언되므로, 비즈니스의 그래프는 동기화를 유지해야 할 두 번째 저장소가 아니라 애플리케이션이 이미 실행하고 있는 정의에서 자연스럽게 도출됩니다. 그리고 그 정의가 여러분의 저장소에 있는 파일이기 때문에, 이는 다른 누군가의 플랫폼 안에 있는 그래프가 아니라 개방된 비즈니스 온톨로지입니다. 이것은 소유권과 거버넌스에 관한 주장이지 그래프 분석에 관한 주장이 아닙니다. ObjectStack은 그래프 데이터베이스가 아니며, 깊은 다중 홉 탐색에서 이기려 하지도 않습니다.