같은 사용자 의도를 네 가지 데이터 모델로 표현해 보기

네 방식의 사용자 수준 의도는 같다. “질병 OMIM:222100과 표현형 HP:0410050의 연관을 기록하고, 그 근거가 논문 PMID:9357814이며 Nicole Vasilevsky가 2018-02-23에 기록했다는 정보까지 남긴다.” 그러나 네 코드가 RDF 의미론상 완전히 같은 트리플 집합을 만든다는 뜻은 아니다. 차이는 연관 기록을 무엇으로 취급하고 근거를 어디에 붙이느냐다.

표 4같은 기호도 언어에 따라 뜻이 달라진다

기호	Turtle·TriG·SPARQL에서	Cypher에서
:	rdf:type처럼 접두사와 로컬 이름을 나눈다. 앞이 비면 기본 접두사다.	:HpoDisease는 노드 레이블, :HAS_…는 관계 타입이다.
?	SPARQL에서만 ?source처럼 엔진이 결과값을 담을 변수 바구니를 표시한다.	이 예제에서는 쓰지 않는다. Cypher 변수는 d, r처럼 그냥 이름을 쓴다.
{ }	TriG에서는 그래프의 내용, SPARQL에서는 찾아야 할 패턴의 범위를 감싼다.	{id: "…"}처럼 속성 이름과 값을 묶는 map이다.
; · .	;는 같은 주어를 이어 쓰고, .은 한 RDF 문장을 끝낸다.	문장 끝의 ;는 Neo4j 실행 환경에 따라 선택적으로 쓴다. .은 n.id처럼 변수와 속성 이름을 나눈다.
^^	"2018-02-23"^^xsd:date를 단순 문자열이 아니라 날짜 값으로 해석하라고 지정한다.	이 예제에서는 날짜를 문자열 속성으로 저장하므로 쓰지 않는다.

① N항 관계 — 연관 기록을 ‘임시 포스트잇’ 노드로 만든다 (책 Listing 3.5 · 3.6)

비유부터 잡아 볼게요. 질병 카드와 표현형 카드 사이에 바로 메모를 쓰기 어려우니, 두 카드를 함께 가리키는 포스트잇 한 장을 붙이고 그 포스트잇에 출처·작성자·날짜를 적는 방식입니다. 여기서 “임시”는 이해를 돕는 비유일 뿐, 공백 노드가 메모리에서 곧 사라진다는 뜻은 아닙니다.

적는 법 · Turtle

_:Annotation rdf:type :PhenotypicAnnotation ;
    :forDisease        OMIM:222100 ;
    :phenotypicFeature HP:0410050 ;
    :source            PMID:9357814 ;
    :createdBy         "Nicole Vasilevsky" ;
    :creationDate      "2018-02-23"^^xsd:date .

표 5공백 노드 한 개에 연관의 다섯 역할을 연결한다

코드 조각	엔진에게 전달되는 뜻
_:Annotation	밑줄+콜론 _:는 전역 IRI가 없는 공백 노드라는 표시이고, Annotation은 이 문서 안에서 같은 노드를 다시 가리키는 로컬 표찰이다.
rdf:type :PhenotypicAnnotation	이 포스트잇이 아무 노드가 아니라 “표현형 주석” 종류라고 선언한다.
:forDisease · :phenotypicFeature	포스트잇이 어느 질병과 어느 표현형을 함께 설명하는지 연결한다.
:source · :createdBy	주장의 출처와 작성자를 같은 포스트잇에 붙인다. 세미콜론 덕분에 주어를 반복하지 않는다.
:creationDate … .	날짜 자료형을 붙이고 마침표로 이 주어에 관한 서술을 끝낸다.

꺼내는 법 · SPARQL

SELECT ?source ?author ?date
WHERE {
  ?annotation a :PhenotypicAnnotation ;
      :forDisease        OMIM:222100 ;
      :phenotypicFeature HP:0410050 ;
      :source            ?source ;
      :createdBy         ?author ;
      :creationDate      ?date .
}

위에서 아래로 읽어 보세요. WHERE { … }는 “이 모양과 같은 그래프 조각을 찾아 주세요”라는 검색 틀입니다. ?annotation에 조건을 모두 만족하는 포스트잇 노드가 들어오면, 그 노드의 출처·작성자·날짜가 각각 ?source·?author·?date에 채워지고 SELECT가 그 세 열만 결과로 내보냅니다. a는 작성 코드의 rdf:type과 같은 뜻인 짧은 표기입니다.

② 명명 그래프 — 문장을 봉투에 넣고 봉투에 발신 정보를 적는다 (책 Listing 3.7 · 3.8)

명명 그래프는 RDF 데이터셋 안의 트리플 묶음에 그래프 이름을 연결합니다. 편지 한 장을 봉투에 넣고, 봉투 겉면에 출처와 작성일을 적는 모습을 떠올리면 됩니다. 봉투 안 여러 문장은 같은 맥락을 공유할 수 있습니다.

적는 법 · TriG

:Graph1 {
    OMIM:222100 :hasPhenotypicFeature HP:0410050 .
}

:Graph1
    :source       PMID:9357814 ;
    :createdBy    "Nicole Vasilevsky" ;
    :creationDate "2018-02-23"^^xsd:date .

표 6중괄호 안의 그래프와 밖의 기본 그래프를 구분한다

코드 조각	엔진에게 전달되는 뜻
:Graph1 {	이름이 :Graph1인 그래프의 내용이 시작된다. :Graph1은 기본 접두사를 펼친 IRI이지 변수가 아니다.
OMIM:… :has… HP:… .	질병–표현형 트리플을 :Graph1 안에 단언한다.
}	명명 그래프의 내용이 끝난다.
:Graph1 :source …	중괄호 밖이므로 이 메타데이터 트리플은 기본 그래프에 기록된다. 내용물이 아니라 봉투 이름을 주어로 삼는다.

꺼내는 법 · SPARQL

SELECT ?source ?author ?date
WHERE {
  GRAPH :Graph1 {
    OMIM:222100 :hasPhenotypicFeature HP:0410050 .
  }
  :Graph1 :source ?source ;
          :createdBy ?author ;
          :creationDate ?date .
}

GRAPH :Graph1 { … }은 검색 대상을 그 봉투 안으로 제한합니다. 이어지는 :Graph1 :source … 패턴은 기본 그래프에서 봉투에 붙은 메타데이터를 읽습니다. SPARQL의 SELECT·WHERE·GRAPH 같은 키워드는 대소문자를 바꿔도 되지만, 읽기 쉽게 대문자로 쓰는 관례가 있습니다. 반면 ?source와 ?Source, 접두사로 펼쳐지는 IRI는 같은 것으로 바꾸어 읽으면 안 됩니다.

③ RDF-star — 문장을 인용해 그 문장에 관해 말한다 (책 Listing 3.9 · 3.10)

이중 꺾쇠는 대화에서 큰따옴표로 남의 문장을 인용하는 것과 비슷합니다. “질병이 이 표현형을 가진다”라는 문장을 하나의 대상으로 집어 들고, 그 인용된 문장에 출처·작성자·날짜를 연결합니다.

적는 법 · 교재 시점의 Turtle-star

<<OMIM:222100 :hasPhenotypicFeature HP:0410050>>
    :source       PMID:9357814 ;
    :createdBy    "Nicole Vasilevsky" ;
    :creationDate "2018-02-23"^^xsd:date .

꺼내는 법 · 교재 시점의 SPARQL-star

SELECT ?source ?author ?date {
  <<OMIM:222100 :hasPhenotypicFeature HP:0410050>>
      :source ?source ;
      :createdBy ?author ;
      :creationDate ?date .
}

SELECT 뒤에 곧바로 { … }가 와도 오류가 아닙니다. SPARQL에서 WHERE는 생략할 수 있기 때문입니다. 안쪽의 << … >>는 세 토큰을 단순 문자열로 묶는 것이 아니라 트리플 구조를 유지한 채 인용합니다. 그래서 조회할 때도 같은 구조를 써서 그 문장에 연결된 메타데이터를 찾습니다.

# Turtle 1.2 초안의 annotation 문법: 원 트리플을 단언하면서 근거도 함께 붙인다
VERSION "1.2"
OMIM:222100 :hasPhenotypicFeature HP:0410050
  {| :source       PMID:9357814 ;
     :createdBy    "Nicole Vasilevsky" ;
     :creationDate "2018-02-23"^^xsd:date |} .

④ LPG — 관계 자체에 키–값 속성을 둔다 (책 Listing 3.11 · 3.12)

LPG에서는 관계가 데이터베이스 안의 개별 요소이므로, 화살표 모양의 관계 안에 속성을 바로 넣을 수 있습니다. 다만 교재 Listing 3.11은 CREATE나 MERGE가 없는 모델 모양이라 그 조각만 실행할 수는 없습니다.

모델 모양 · Cypher 패턴

(d {id: "OMIM:222100"})
  -[:HAS_PHENOTYPIC_FEATURE {
      source:       "PMID:9357814",
      createdBy:    "Nicole Vasilevsky",
      creationDate: "2018-02-23"
  }]->
(p {id: "HP:0410050"})

실제로 적는 법 · 기존 두 노드를 연결하는 예

MATCH (d:HpoDisease {id: "OMIM:222100"})
MATCH (p:HpoPhenotype {id: "HP:0410050"})
CREATE (d)-[:HAS_PHENOTYPIC_FEATURE {
  source:       "PMID:9357814",
  createdBy:    "Nicole Vasilevsky",
  creationDate: "2018-02-23"
}]->(p)

MATCH 두 줄은 이미 존재하는 질병 노드와 표현형 노드를 각각 d와 p라는 변수에 담습니다. 소괄호 ( )는 노드, 대괄호 [ ]는 관계, ->는 저장 방향입니다. CREATE는 관계를 새로 만들기 때문에 같은 코드를 반복하면 같은 내용의 관계가 더 생길 수 있습니다. 반복 실행 안전성이 필요하면 주석 식별자와 중복 정책을 먼저 설계해야 합니다.

꺼내는 법 · Cypher

MATCH (d)-[r:HAS_PHENOTYPIC_FEATURE]->(p)
WHERE d.id = "OMIM:222100" AND p.id = "HP:0410050"
RETURN r.source, r.createdBy, r.creationDate

표 7관계를 변수에 담아 속성을 직접 읽는다

줄	엔진에게 전달되는 뜻
MATCH (d)-[r:…]->(p)	지정한 타입의 관계를 찾고 양쪽 노드를 d·p, 관계를 r에 담는다.
WHERE … AND …	두 ID 조건을 동시에 만족하는 연결만 남긴다.
RETURN r.source, …	관계 변수 r의 세 속성을 결과 열로 반환한다.

쉽게 말하면 — LPG는 관계 메타데이터를 조회하는 코드 경로를 짧게 만든다. 하지만 “같은 질병–표현형 사이의 여러 주석을 관계 몇 개로 볼 것인가”라는 식별·중복 설계까지 없애 주지는 않는다. §3.2에서 볼 수 있듯 관계를 질병–표현형 쌍만으로 MERGE하면 서로 다른 근거가 한 관계에 덮일 수 있다. 이 장이 LPG를 고른 이유는 문법의 절대 우월성이 아니라, 선택한 주석 단위를 보존한다는 전제에서 관계 속성을 바로 탐색할 수 있기 때문이다.

교재 Listing 3.5–3.12의 비교 의도를 보존하면서 작성·조회 코드를 분리했다. 원서 조판 과정에서 깨진 닫는 괄호·구두점(예: Listing 3.11의 미종료 문자열, Listing 3.10의 ? date 띄어쓰기)은 바로잡았다. 접두사 선언이 생략된 RDF 코드는 독립 실행문이 아닌 교재 조각이며, LPG에는 교재의 패턴 조각과 실제 MATCH·CREATE 예시를 구분해 제시했다. RDF 1.2 주의는 W3C 2026년 문서를 기준으로 보완했다.

전반부 코드 — 온톨로지가 들어오기까지 네 줄

표 9의 앞 세 단계는 코드로 보면 놀랄 만큼 짧다. 무거운 일은 전부 Neosemantics가 대신하고, 우리가 하는 일은 규칙을 미리 정해 두는 것뿐이다.

// ① 그릇 만들기 (책 3.13) — Enterprise 전용 명령이다
CREATE DATABASE hpo IF NOT EXISTS

// ② 중복을 막는 장치 (책 3.14) — 단순 무결성 장치가 아니다.
//    uri 유일성이 있어야 n10s 가 온톨로지를 MERGE 로 '몇 번 돌려도 같게' 적재한다
CREATE CONSTRAINT n10s_unique_uri IF NOT EXISTS FOR (r:Resource) REQUIRE r.uri IS UNIQUE;
CREATE CONSTRAINT IF NOT EXISTS FOR (n:Resource) REQUIRE (n.id) IS UNIQUE;
CREATE INDEX disease_id   IF NOT EXISTS FOR (n:HpoDisease)   ON (n.id);
CREATE INDEX phenotype_id IF NOT EXISTS FOR (n:HpoPhenotype) ON (n.id);

// ③ 변환 규칙 정하기 (책 3.15) — 이 두 줄이 이후 모든 Cypher 의 생김새를 결정한다
CALL n10s.graphconfig.init();
CALL n10s.graphconfig.set({ handleVocabUris: "IGNORE" });   // 네임스페이스를 버린다
CALL n10s.graphconfig.set({ applyNeo4jNaming: True });      // 관계 타입을 대문자로

// ④ 적재 (책 3.16) — 딱 한 줄이다
CALL n10s.rdf.import.fetch("http://purl.obolibrary.org/obo/hp.owl", "RDF/XML");

③이 왜 중요한가 — handleVocabUris: "IGNORE"는 임포트할 때 네임스페이스를 떼어 낸다. 그래서 속성 이름이 obo:IAO_0000115가 아니라 iAO_0000115가 된다. applyNeo4jNaming: True는 관계 타입을 대문자로 바꾼다. 그래서 OWL의 rdfs:subClassOf가 LPG 관용 표기인 :SUBCLASSOF로 들어온다. §5의 추론이 SUBCLASSOF라는 이름으로 계층을 훑을 수 있는 건 이 한 줄 덕분이다.

// ⑤ 접합면 만들기 (책 3.17) — 이 장에서 가장 중요한 다섯 줄
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/', ''), '_', ':'))

쉽게 말하면 — 온톨로지에서 온 노드의 주소는 http://purl.obolibrary.org/obo/HP_0410050이고, TSV 주석 파일이 쓰는 표기는 HP:0410050이다. 생김새가 달라서 그냥 두면 두 파일은 영영 만나지 못한다. 이 질의는 URI 앞부분을 잘라내고 _를 :로 바꿔 두 파일이 같은 언어를 쓰게 만든다. coalesce는 “이미 id가 있으면 건드리지 말라”는 뜻이라 여러 번 실행해도 안전하다. 그림 2가 말한 “표준 ID로 결합”이 실제로 일어나는 곳이 바로 이 다섯 줄이다.

후반부 코드 — TSV 한 행이 관계 하나가 되기까지

같은 파일을 세 번 읽는다. 첫 번째는 노드를 만들고, 두 번째는 선을 잇고, 세 번째는 그 선에 근거를 붙인다. 한 번에 못 하는 이유는 관계를 만들려면 양쪽 노드가 이미 있어야 하기 때문이다.

// ① 질병 노드 만들기 (책 3.19)
LOAD CSV FROM 'https://mng.bz/qRyr' AS row
FIELDTERMINATOR '\t'
WITH row
SKIP 5                                        // 메타데이터 4줄 + 헤더 1줄을 건너뛴다
MERGE (dis:Resource:HpoDisease {id: row[0]})  // 같은 질병이 여러 행에 나오므로 MERGE
ON CREATE SET dis.label = row[1];             // 이름은 처음 만들 때만 채운다

// ② 질병 ↔ 표현형 잇기 (책 3.20)
LOAD CSV FROM 'https://mng.bz/qRyr' AS row
FIELDTERMINATOR '\t'
WITH row
SKIP 5
MATCH (dis:HpoDisease)   WHERE dis.id = row[0]   // TSV 0번 열 = OMIM:222100
MATCH (phe:HpoPhenotype) WHERE phe.id = row[3]   // TSV 3번 열 = HP:0410050
MERGE (dis)-[:HAS_PHENOTYPIC_FEATURE]->(phe)

여기가 두 파일이 만나는 지점이다. phe.id는 ①에서 hp.owl의 URI를 가공해 만든 값이고, row[3]은 TSV가 원래 갖고 있던 값이다. 형식이 전혀 다른 두 파일이 온톨로지의 표준 식별자를 공통 언어로 삼아 하나의 그래프가 된다. §1에서 말한 “의미 통합”의 구체적 실체가 이 두 줄이다.

// ③ 관계에 근거 붙이기 (책 3.22) — 열 8개를 그대로 관계 속성으로
LOAD CSV FROM 'https://mng.bz/qRyr' AS row
FIELDTERMINATOR '\t'
WITH row
SKIP 5
MATCH (dis:HpoDisease)-[rel:HAS_PHENOTYPIC_FEATURE]->(phe:HpoPhenotype)
WHERE phe.id = row[3] AND dis.id = row[0]
FOREACH(_ IN CASE WHEN row[4]  IS NOT NULL THEN [1] ELSE [] END | SET rel.source      = row[4])
FOREACH(_ IN CASE WHEN row[5]  IS NOT NULL THEN [1] ELSE [] END | SET rel.evidence    = row[5])
FOREACH(_ IN CASE WHEN row[6]  IS NOT NULL THEN [1] ELSE [] END | SET rel.onset       = row[6])
FOREACH(_ IN CASE WHEN row[7]  IS NOT NULL THEN [1] ELSE [] END | SET rel.frequency   = row[7])
FOREACH(_ IN CASE WHEN row[8]  IS NOT NULL THEN [1] ELSE [] END | SET rel.sex         = row[8])
FOREACH(_ IN CASE WHEN row[9]  IS NOT NULL THEN [1] ELSE [] END | SET rel.modifier    = row[9])
FOREACH(_ IN CASE WHEN row[10] IS NOT NULL THEN [1] ELSE [] END | SET rel.aspect      = row[10])
FOREACH(_ IN CASE WHEN row[11] IS NOT NULL THEN [1] ELSE [] END | SET rel.biocuration = row[11])

FOREACH(CASE …)가 왜 이렇게 생겼나 — Cypher에는 “조건이 맞을 때만 SET”이라는 문법이 없다. 그래서 원소가 1개인 리스트를 도는 반복문과 빈 리스트를 도는 반복문(=아무것도 안 함)으로 if를 흉내 낸다. 목적은 단순하다. TSV에서 빈 칸인 열이 기존 값을 null로 덮어쓰지 못하게 막는 것이다. 여덟 번 반복되는 건 열이 여덟 개이기 때문이지 다른 뜻은 없다.

// ④ 사람이 읽을 수 있게 바꾸기 (책 3.23) — 약어를 문장으로, 출처를 링크로
CALL apoc.periodic.iterate(
  "MATCH (dis:HpoDisease)-[rel:HAS_PHENOTYPIC_FEATURE]->(phe:HpoPhenotype) RETURN rel",
  "SET rel.createdBy    = apoc.text.regexGroups(rel.biocuration, 'HPO:(\\w+)\\[')[0][1],
       rel.creationDate = apoc.text.regexGroups(rel.biocuration, '\\[(\\d{4}-\\d{2}-\\d{2})\\]')[0][1],
       rel.aspectName = CASE
         WHEN rel.aspect = 'P' THEN 'Phenotypic abnormality'
         WHEN rel.aspect = 'I' THEN 'Inheritance' END,
       rel.evidenceName = CASE
         WHEN rel.evidence = 'IEA' THEN 'Inferred from electronic annotation'
         WHEN rel.evidence = 'PCS' THEN 'Published clinical study'
         WHEN rel.evidence = 'TAS' THEN 'Traceable author statement' END,
       rel.url = CASE
         WHEN rel.source STARTS WITH 'PMID:' THEN
           'https://pubmed.ncbi.nlm.nih.gov/' + apoc.text.replace(rel.source, '(.*)PMID:', '')
         WHEN rel.source STARTS WITH 'OMIM:' THEN
           'https://omim.org/entry/' + apoc.text.replace(rel.source, '(.*)OMIM:', '') END",
  {batchSize: 1000})

// ⑤ 안 쓰는 것 치우기 (책 3.24)
CALL apoc.periodic.iterate(
  "MATCH (n:Resource) RETURN id(n) AS id",
  "MATCH (n) WHERE id(n) = id
     AND NOT 'HpoPhenotype' IN labels(n)
     AND NOT 'HpoDisease'   IN labels(n)
   DETACH DELETE n",
  {batchSize: 10000})
YIELD batches, total RETURN batches, total

④는 “친절함”을 데이터에 새겨 넣는 단계다. biocuration 칸에 HPO:NicoleVasilevsky[2018-02-23]이라고만 적혀 있으면 사람이 읽기 불편하다. 정규식으로 이름과 날짜를 뽑아 별도 속성으로 만들고, PCS 같은 세 글자 약어를 Published clinical study라는 문장으로 풀고, PMID:9357814를 클릭 가능한 PubMed 주소로 바꾼다. §6이 요구하는 “임상의가 근거를 열어볼 수 있어야 한다”가 여기서 준비된다. apoc.periodic.iterate는 28만 건을 1,000건씩 나눠 처리해 메모리를 아끼는 장치다.

⑤는 되돌릴 수 없는 단계다. 표현형도 질병도 아닌 Resource 노드를 전부 지운다. 온톨로지의 동의어 타입·주석 출처 같은 메타데이터가 여기서 사라지고, 그래서 책 3.18의 중간 점검 질의는 이 단계 이후 빈 결과를 낸다(§3.3 참조).

코드로 보면 두 줄 차이다

// 책 3.27 — 계층을 손으로 훑는다
MATCH (p:HpoPhenotype)<-[:SUBCLASSOF*1..3]-(n:HpoPhenotype)
WHERE p.id = "HP:0000818"
RETURN p, n

// 책 3.28 — 같은 일을 Neosemantics 프로시저에 맡기고, 그 결과로 질병까지 끌어온다
MATCH (cat:HpoPhenotype {label: "Abnormality of the endocrine system"})
CALL n10s.inference.nodesInCategory(cat, {
    inCatRel: "HAS_PHENOTYPIC_FEATURE",   // 질병을 표현형에 잇는 관계
    subCatRel: "SUBCLASSOF"})             // 하위 개념을 잇는 관계
YIELD node AS dis
WHERE dis.label IN [ … 질병 5개 … ]        // 재현용 화이트리스트 (지면 생략)
MATCH (dis)-[:HAS_PHENOTYPIC_FEATURE]->(phe:HpoPhenotype)
RETURN dis.label AS disease, collect(DISTINCT phe.label) AS features
ORDER BY size(features) ASC, disease

쉽게 말하면 — *1..3은 “하위 클래스 관계를 1단계에서 3단계까지 따라가라”는 뜻이다. 화살표 방향(<-)에 주의해야 한다. HPO는 자식 → 부모 방향으로 SUBCLASSOF를 저장하므로, 부모에서 자식을 찾으려면 화살표를 거꾸로 읽어야 한다. 3.28의 nodesInCategory는 이 순회를 대신 해 주면서 깊이 제한 없이 훑고, 찾은 표현형에 주석된 질병까지 한 번에 돌려준다.