OWL을 왜 보는가
OWL은 웹 온톨로지 언어입니다. agent 개발자가 OWL을 그대로 다 구현하지 않더라도, class, individual, property, restriction, inference의 감각을 익히면 schema 설계가 훨씬 또렷해집니다. 중요한 점은 모든 것을 LLM에게 맡기지 않고, 어떤 관계는 명시적 규칙으로 둔다는 태도입니다.
예를 들어 Document, Policy, Evidence, Action, UserData라는 class가 있고, Action은 hasTarget, requiresPermission, hasRisk 같은 property를 가질 수 있습니다. 이 구조가 있으면 agent는 '문서를 요약한다'와 '사용자 데이터를 외부 전송한다'를 같은 action으로 취급하지 않습니다.
EL의 감각
OWL EL은 큰 class hierarchy를 빠르게 분류하는 데 강합니다. 생물학이나 의료처럼 개념 수가 많고 part-of, is-a 관계가 깊은 영역에서 자주 언급됩니다. Agent 쪽에서는 거대한 도메인 taxonomy를 안정적으로 관리할 때 유용한 감각입니다.
예시로 Protein은 Molecule의 하위 class이고, Kinase는 Protein의 하위 class이며, 특정 효소는 Kinase individual로 볼 수 있습니다. agent가 단백질 데이터셋을 읽을 때 이 계층을 알면, 특정 protein에 적용 가능한 일반 규칙을 빠르게 찾을 수 있습니다.
QL과 RL의 감각
OWL QL은 많은 데이터를 DB처럼 질의하는 감각입니다. 로그, 문서 메타데이터, provenance record가 많고, 그것을 빠르게 조회해야 할 때 잘 맞습니다. agent가 '이 claim을 지지한 공식 문서가 무엇인가'를 자주 묻는다면 QL적인 설계가 필요합니다.
OWL RL은 rule 기반 검증에 가깝습니다. 'PersonalData를 포함한 PublicOutput은 privacy gate를 통과해야 한다' 같은 규칙을 두고, action 후보를 실행 전에 걸러냅니다. 실제 운영에서는 RL식 규칙이 SHACL, validator, policy engine과 만나는 경우가 많습니다.
작게 쓰는 법
Agent 프로젝트에서 OWL을 처음부터 거대한 학술 ontology로 만들 필요는 없습니다. 먼저 class 이름을 정하고, 그 class가 어떤 property를 가져야 하는지 적고, 어떤 action에서 반드시 확인해야 하는지 연결하면 됩니다. Document, Claim, Evidence, PolicyDecision, ActionCandidate 정도만 제대로 나눠도 LLM의 점프가 꽤 줄어듭니다.
중요한 것은 profile 이름을 외우는 것이 아니라 선택 이유를 남기는 것입니다. class hierarchy가 깊으면 EL 감각, 로그와 provenance를 많이 읽으면 QL 감각, 실행 전 gate가 중요하면 RL 감각으로 갑니다. 이 선택이 문서화되어야 나중에 agent가 이상한 결론을 냈을 때 어디를 고칠지 보입니다.
정리
이 문서의 taxonomy는 class, property, individual, restriction, profile choice입니다. EL은 분류, QL은 질의, RL은 규칙이라는 느낌으로 먼저 잡으면 됩니다. 세 profile은 우열이 아니라 용도가 다릅니다.
법적 규제 준수 관점에서는 OWL이 법을 대신 판단하지 않는다는 점이 중요합니다. 다만 개인정보, 저작권, 광고 정책처럼 놓치면 안 되는 대상을 class로 올리고, 검증 rule이 그것을 보게 만들 수 있습니다.
Taxonomy
- OWL class taxonomyClass, Individual, ObjectProperty, DataProperty, Restriction을 기본 구성요소로 둡니다.
- OWL EL taxonomy큰 class hierarchy와 part-of 계층, 빠른 분류가 필요한 도메인에 씁니다.
- OWL QL taxonomy관계형 DB 위의 질의, provenance 조회, 로그 검색처럼 많은 instance를 읽을 때 씁니다.
- OWL RL taxonomyif-then 규칙, 정책 gate, validation rule처럼 rule engine에 가까운 용도에 씁니다.
- profile choice taxonomy표현력, 속도, 설명 가능성, 운영 단순성, 데이터 규모를 기준으로 profile을 고릅니다.
- restriction taxonomysomeValuesFrom, allValuesFrom, cardinality, domain, range를 제약 표현으로 봅니다.
- reasoner taxonomy분류 reasoner, 질의 reasoner, rule reasoner, validation reasoner를 구분합니다.
- part-whole taxonomypart-of, has-part, component, membership, containment를 구분해 EL 설계에 씁니다.
- database mapping taxonomytable, row, key, join, materialized view를 QL 관점에서 mapping합니다.
- rule pattern taxonomyclass 포함, property 제약, if-then 규칙, validation rule을 RL식 패턴으로 둡니다.