데이터를 연결했다고, 의미까지 연결된 걸까?

희귀질환 후보를 찾으려면 형식 통합보다 먼저 질문·표준 의미·연결 근거를 고정해야 합니다.

질문에서 근거 있는 후보까지, 다섯 결정을 따라간다

도구 기능이 아니라 각 단계가 남겨야 할 검증 산출물을 중심으로 봅니다.

목표는 자동 진단이 아니라 검토 가능한 후보 탐색이다

같은 “당뇨병”도 질병과 표현형이라는 서로 다른 역할을 가질 수 있습니다.

어느 파일에서 무엇이 정본인지 먼저 고정한다

두 원천은 형식뿐 아니라 변경 영향과 검증 단위가 다릅니다.

같은 사실 하나를 적는데, 문법은 네 개가 필요하다

“OMIM:222100–HP:0410050 연결의 근거는 PMID:9357814” — 이 한 문장을 적고 다시 꺼내는 방법입니다.

// ① N항 관계 — 근거를 담을 노드를 새로 만든다
_:Annotation :forDisease        OMIM:222100 ;
             :phenotypicFeature HP:0410050 ;
             :source            PMID:9357814 .

// ② 명명 그래프 — 문장을 봉투에 넣고 봉투에 적는다
:G1 { OMIM:222100 :hasPhenotypicFeature HP:0410050 }
:G1 :source PMID:9357814 .

// ③ RDF-star — 문장 자체를 주어로 삼는다
<<OMIM:222100 :hasPhenotypicFeature HP:0410050>> :source PMID:9357814 .

// ④ LPG — 관계 안에 그냥 적는다
(d)-[:HAS_PHENOTYPIC_FEATURE { source: "PMID:9357814" }]->(p)

선택의 근거 — “LPG가 RDF보다 낫다”가 아닙니다. 주석마다 근거가 다르다는 이 장의 요구가 관계 속성을 필수로 만들었을 뿐입니다.

이 사례는 RDF 원천 위에 LPG 애플리케이션 모델을 얹는다

온톨로지 표현은 입력에서, 관계 중심 탐색은 앱 모델에서 활용합니다.

각 적재 명령 뒤에 ‘무엇이 보존됐나’를 묻는다

성공 로그만으로는 의미·주석·추론이 보존됐는지 알 수 없습니다.

형식이 다른 두 파일은 결국 이 두 줄에서 만난다

온톨로지는 URI(…/obo/HP_0410050), 주석 파일은 콜론 표기(HP:0410050). 그냥 두면 영영 만나지 않습니다.

// 책 3.17 — 온톨로지 노드에 '주석 파일과 같은 모양'의 id 를 만든다
MATCH (n:Resource)
WHERE n.uri STARTS WITH "http://purl.obolibrary.org/obo/HP"
SET n:HpoPhenotype,
    n.id = coalesce(n.id,
      replace(apoc.text.replace(n.uri,'(.*)obo/',''), '_', ':'))

// 책 3.20 — 그 id 로 TSV 의 두 열과 맞물린다
MATCH (dis:HpoDisease)   WHERE dis.id = row[0]  // OMIM:222100
MATCH (phe:HpoPhenotype) WHERE phe.id = row[3]  // HP:0410050
MERGE (dis)-[:HAS_PHENOTYPIC_FEATURE]->(phe)

같은 파일을 세 번 읽는 이유 — 노드를 만들고(3.19), 선을 잇고(3.20), 그 선에 근거를 붙입니다(3.22). 관계를 만들려면 양쪽 노드가 먼저 있어야 합니다.

책의 결과와 현재 실행 결과가 다른 이유를 설명할 수 있어야 한다

원자료·교재·실습 코드를 대조해 여섯 가지 재현 경계를 확인했습니다.

추정이 아니라 직접 돌려 본 숫자입니다

학습 노트북 03_chapter_guide.ipynb로 Neo4j 5.26.28에서 전 과정을 실행한 결과입니다.

다섯 표현형의 겹침 수를 집계하고 이름으로 동률을 푼다

count(nodes)는 주석 경로 수이며 진단 확률이 아닙니다.

MATCH (phe:HpoPhenotype)
WHERE phe.label IN [
  "Growth delay", "Large knee",
  "Sensorineural hearing impairment", "Pruritus",
  "Type I diabetes mellitus"
]
WITH phe
MATCH path=(dis:HpoDisease)
  -[:HAS_PHENOTYPIC_FEATURE]->(phe)
UNWIND dis AS nodes
RETURN dis.id AS disease_id,
       dis.label AS disease_name,
       collect(phe.label) AS features,
       count(nodes) AS num_of_features
ORDER BY num_of_features DESC, disease_name
LIMIT 5

빠진 것 — 희귀도·부정 소견·발현 시점·증거 질·환자 맥락은 이 단순 랭킹에 포함되지 않습니다.

같은 질의를 지금 돌리면 2위 이하가 바뀝니다

코드는 한 글자도 바뀌지 않았습니다. HPOA 스냅샷만 2025-02 → 2026-06-23으로 바뀌었습니다.

더 넓은 결과가 더 정확한 결과는 아니다

추론의 가치는 누락을 줄이는 데 있고, 위험은 범위와 설명 경로에 있습니다.

깊이를 정하는 순간 절반을 못 보고, 계층이 바뀌면 결과도 바뀝니다

노트북이 HP:0000818(내분비계 이상) 아래를 직접 세어 본 결과입니다.

“근거를 열어볼 수 있어야 한다”는 이미 만들 수 있는 질의다

교재 §3.4 연습문제 — 3.26에 관계 속성을 더해 보세요. 달라지는 건 한 군데뿐입니다.

MATCH (phe:HpoPhenotype)
WHERE phe.label IN $features
MATCH (dis:HpoDisease)
  -[rel:HAS_PHENOTYPIC_FEATURE]->(phe)
WITH dis, count(DISTINCT phe) AS matched,
  collect({
    feature:  phe.label,
    evidence: rel.evidenceName,
    source:   rel.source,
    url:      rel.url,
    curator:  rel.createdBy,
    date:     rel.creationDate
  }) AS grounds
RETURN dis.id, dis.label, matched, grounds
ORDER BY matched DESC

겹침 수가 감추는 것 — 같은 “3개 일치”라도 근거의 무게가 다릅니다. 관계에 rel이라는 이름 하나를 붙였을 뿐인데 이 차이가 보입니다. §2.2에서 LPG를 고른 결정이 값을 치르는 지점입니다.

이 장의 결과는 진단이 아니라 검토 가능한 후보 생성이다

기술적으로 재현된 경로도 실제 임상 의사결정의 안전성과 유효성을 자동 증명하지 않습니다.

온톨로지와 그래프는 질문에 필요한 만큼만 쓴다

기술 이름보다 문제의 모양과 운영 책임으로 도입 여부를 판단합니다.

세 질문으로 우리 시스템의 책임을 드러낸다

용어 암기보다 설계 결정을 말할 수 있는지 확인합니다.