Topic · 40 notes
Knowledge systems
온톨로지, 그래프, 근거와 기억
법률 변화는 모두에게 같은 뉴스가 아니다
입법예고 뉴스레터 시리즈를 관심영역과 다음 질문으로 연결하는 법
세대분리 하나에 왜 두 개의 답이 나오는가
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 19편
세금 AI는 물어본 것만 답한다. 나는 뭘 물어야 할지 몰랐다
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 12편
검증과 승인에도 신뢰도를 매긴다
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 13편 번외
예외를 규칙의 바깥에 두면 왜 결론이 흔들리는가
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 15편
선증여 뒤 재양도에서 끝내 남는 두 가지 사실
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 14편
계산 결과 다음에는 왜 가족의 다음 상태가 필요한가
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 18편
증여 뒤 매도에서 취득가액은 왜 원래의 시간으로 돌아가는가
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 16편
같은 사람에게 받은 증여는 왜 한 번의 사건으로 끝나지 않는가
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 17편
답하기 전에 무엇을 물어야 하는가
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트 번외편
금융소득 2천만원은 왜 세율이 아니라 조건인가
법률의 계산 규정을 읽고 TaxRule·TaxRate·reasoning 코드의 경계를 나누는 법
부담부증여는 왜 증여 하나로 끝나지 않는가
소득세법의 ‘양도로 보는 부분’을 읽고 하나의 이전을 두 개의 규칙으로 모델링하는 법
선증여 후 재양도는 왜 직접매매와 같은 규칙이 아닌가
소득세법의 의제 규정을 사건 구조로 읽고 TransactionPattern으로 모델링하는 법
OWL을 꼭 Reasoner로 써야 할까?
세법 온톨로지에서 공리와 SPARQL, Python의 실행 경계를 에이전트에게 물으며 다시 그린 기록
같은 단어를 같은 뜻으로 읽으면 안 됐다
법별 정의를 분리한 SKOS 용어집 v2로 세법 그래프의 해석 출발점을 다시 세우는 기록
상장주식 증여에서 먼저 봐야 할 것은 세율이 아니다
상증세법의 평가 규정을 읽고 Valuation을 TaxRule과 분리하는 이유
거래 다음에는 자산을 봐야 했다
관계와 거래의 그래프를 자산의 시간으로 이어, 보유와 처분에 따라 달라지는 세금 지도로 확장하기
어쩌다 보니 가장이 되어 버렸다
가족 자산운용을 위한 세법 온톨로지 제작 프로젝트
사람에게도 타입이 필요했다
그래프의 연결만으로는 읽히지 않는 법적 의미를 위해, 당사자 유형을 세법 온톨로지에 넣었다
법은 조건문의 집합이 아니었다
세법 온톨로지를 만들며 발견한 것은 규칙을 더 많이 찾는 법이 아니라, 사건의 모양과 빠진 사실을 판별하는 법이었다
모든 문장에 비싼 모델을 쓸 필요는 없었다
NLI 점수 하나로 얼마나 넘길지 정했다. 슬롯이 많아질수록 넘기는 비율도 늘었지만, 그게 오히려 맞는 신호였다.
EL과 QL은 또 다른 이유로 표현력을 깎았다
클래스 30만 개와, 기존 관계형 DB가 각자 다른 벽에 부딪혔다
OWL 2 RL과 OWL 2 DL은 다른 질문에 답한다
SKOS와 PROV가 표현력을 아낀 이유를 따라가면, OWL 안의 두 계약이 나온다
RDF/OWL로 다 표현할 수 있는데, 왜 SKOS와 PROV가 따로 있을까
표현할 수 있다는 것과, 표현해도 된다는 것은 다른 문제였다
이 관계는 규칙인가, 정의인가
새 관계를 하나 만들 때마다 물어야 하는 세 가지 질문
사용자의 발화는 아직 시스템의 질문이 아니다
사내 사용자의 한 문장을 대상·기간·사건·정책의 빈칸으로 분해하고, 바로 실행하지 않아야 하는 이유.
Knowledge Graph는 답을 저장하는 곳이 아니라, 발화의 문맥을 붙잡는 장치다
같은 별칭 아래 남은 후보를 지우지 않고, 관계와 근거를 더해 발화의 문맥으로 좁히는 방법.
Ontology는 사내 시스템의 데이터를 하나로 만드는 게 아니라, 질문 가능한 세계를 정의한다
서로 다른 사내 시스템을 하나로 합치지 않고도 같은 운영 질문으로 연결하는 의미 계약.
SPARQL은 데이터를 찾는 언어가 아니라, ontology의 약속을 실행하는 질문이다
확정된 대상과 정책을 검증 가능한 질의와 답변 근거로 바꾸는 실행 경계.
Conversation Design은 모호성을 숨기지 않고 다음 질문으로 바꾼다
후보 수, 점수 차이, 업무 정책의 빈칸을 바탕으로 시스템이 언제 무엇을 물어야 하는지 설계한다.
사용자의 말과 사내 시스템은 ontology에서 만난다
발화·그래프·ontology·질의·대화 정책이 하나의 운영 흐름으로 연결되는 구조.
Semantic Web은 마지막 선택지다
재사용·변경 이력을 수작업으로 설명하기 어려워질 때, 관계 모델을 확장하는 법
VIO는 온톨로지를 저장하지 않는다: Dynamic Ontology Runtime이라는 관점
Visual Identity Ontology를 만들면서 깨달은 건, 이게 브랜드 비주얼을 위한 지식 저장소가 아니라는 점이다. Workflow, 대화, 지식, 작업 기억은 서로 다른 데이터가 아니라 하나의 그래프 위에서 표현되는 같은 구조이고, 에이전트는 실행하면서 그 그래프 자체를 진화시킨다. 이 글은 VIO를 사상(왜 그래프인가), 구조(무엇이 같은가), 런타임(실행이 지식을 바꾼다) 순서로 정리하고, 그 끝에서 VIO가 Visual Identity Ontology가 아니라 Dynamic Ontology Runtime, 더 정확히는 Semantic Runtime이라고 다시 정의한다.
조직 기억을 재배선하다: Dynamic, Kinetic and Semantic
빠른 개선 — Dynamic, Kinetic and Semantic
조직 기억을 재배선하다: Dynamic, Kinetic and Semantic
빠른 개선 — Dynamic, Kinetic and Semantic