왜 그렇게 나눴는가

설계 논쟁 3제 — 왜 그렇게 나눴는가

계층 자체보다 중요한 것이 경계 결정의 근거입니다. 세 가지 대표 논쟁을 기록합니다. 실무에서 온톨로지 리뷰 회의는 대부분 이 세 유형의 싸움입니다.

논쟁 ① Terminal(장소)과 TerminalOperator(조직)의 분리

현장 언어는 "터미널"로 뭉뚱그리지만, 우리는 Place 기둥의 Terminal과 Party 기둥의 TerminalOperator로 분리하고 (TerminalOperator)-[:OPERATES {from, to}]->(Terminal) 관계로 잇습니다.

근거는 셋입니다.

운영권은 임대 계약이라 바뀝니다. 분리하지 않으면 운영사 교체 시 시설의 이력이 단절됩니다.
두 축의 질문이 독립적으로 존재합니다. PL-06(터미널 간 생산성 비교)은 시설 축, PL-09(선사별 물동량)는 조직 축의 질문입니다.
UN/CEFACT의 Party-Role 패턴과 정합합니다.

같은 원리로 CargoOwner도 고정 클래스가 아니라 역할입니다. 같은 회사가 이 B/L에서는 Shipper, 저 B/L에서는 Consignee가 되므로, 다음 모듈에서 관계에 역할을 싣는 패턴으로 처리합니다.

논쟁 ② Event 를 어디까지 승격하는가

극단 A(모든 것을 속성으로): (Vessel)-[:BERTHED_AT {ata}]->(Berth) — 단순하지만 PL-04(E/R/P/A 편차)나 AN-02(지연 전파 경로) 같은 CQ에 답할 수 없습니다.

극단 B(모든 것을 노드로): 타임스탬프 하나까지 노드로 만들면 그래프가 폭발합니다.

우리 기준은 CQ 변별력입니다 — CQ가 그 사건의 속성·참여자·인과를 묻는가? 묻는다면 이벤트 노드(PortCall, DischargeEvent, GateTransaction…), 묻지 않는다면 관계 속성입니다. 이 기준으로 앞의 Event 기둥이 확정됐습니다. 코스 1에서 본 학계 관행(AIS 이벤트 노드, DCSA 이벤트 체계)과도 일치합니다.

참고로 PortCall을 **"허브 클래스"**로 명명한 이유가 있습니다. 선박·선석·신고·하역·도선이 전부 기항을 통해 연결됩니다. 기항이 이 그래프의 그랜드 센트럴 역입니다.

논쟁 ③ 화물 3형제 — Container, Cargo, Shipment 의 구분

초심자가 가장 많이 뭉개는 지점입니다.

Container는 상자(물리적 용기)
Cargo는 내용물(물품)
Shipment/Consignment는 거래 단위(계약상 화물 묶음)

셋은 다대다로 얽힙니다. 한 컨테이너에 여러 화주의 화물이 실리고(LCL), 한 거래가 여러 컨테이너에 걸칩니다.

OP-01(상자 위치 추적)은 Container를, CO-05(검사 대상 물품)는 Cargo를, OP-14(화주의 거래 현황)는 Shipment를 각각 요구하므로 셋 다 필요합니다. v1에서는 Container와 Cargo를 클래스로 세우고, Shipment는 B/L 중심으로 문서-화물 관계에서 파생하는 것으로 시작합니다. 과도한 선행 설계를 피하려는 것이고, 필요해지면 승격합니다.