시공간 모델링 — 2대 패턴의 정식 채택

코스 1에서 학계 관행으로 확인하고 앞 모듈에서 예고한 두 패턴을 스펙에 정식 채택합니다.

패턴 A: 이벤트 중심 모델링 (동적 사실)

"무슨 일이 일어났나"는 전부 이벤트 노드입니다. 이벤트는 네 요소를 표준 장착합니다 — 누가/무엇이(참여 관계) · 어디서(장소 관계) · 언제(시각 속성) · 무엇에 대해(대상 관계).

접안을 예로 들면:

(BerthingEvent {etb, atb, status})
  -[:PART_OF_CALL]->(PortCall)
  -[:AT_BERTH]->(Berth)

컨테이너의 "선박 탑재 이력"도 같은 패턴입니다. (Container)-[:CARRIED_ON]->(Vessel)을 현재 상태 조회용 단축 관계로 두되, 이력은 LoadingEvent/DischargeEvent가 담당합니다. "지금 어디에"(OP-01)는 단축 관계로 1-hop, "언제부터 언제까지 어느 배에"는 이벤트로 답합니다.

단축 관계 + 이벤트 이력의 이중화는 성능(빈번한 현재 조회)과 완전성(이력 분석)을 모두 잡는 실무 표준 기법입니다. 대신 ⚠️ 둘의 정합을 ETL이 보장해야 한다는 비용이 따릅니다. 코스 3에서 이 부담이 실제로 돌아옵니다.

패턴 B: 유효기간 관계 (준정적 사실)

"한동안 참인 사실"은 관계에 {from, to}를 답니다. 운영권(OPERATES), 장비 배치(ASSIGNED_TO), 선석 배정(ALLOCATED_TO)이 해당합니다. to: null이면 현재 유효입니다. 이력 CQ("2025년 당시 이 터미널의 운영사는?")는 시점 필터로 답합니다.

판별 기준

시각이 "발생의 순간"이면 이벤트(패턴 A), "지속의 구간"이면 유효기간 관계(패턴 B)입니다. 접안은 순간들의 연쇄(ETB→ATB→ATD)라 이벤트, 운영권은 구간이라 관계입니다.

E/R/P/A 쟁점의 결판 — 속성이다, 단 4종 세트로

앞 모듈에서 보류한 쟁점입니다. 타임스탬프를 노드로 승격할 것인가? 결론: 속성으로 둡니다. 이벤트 노드에 E/R/P/A 4종 속성을 세트로 장착합니다.

(BerthingEvent {
  estimatedTime,   // E: 추정 (DCSA Estimated)
  requestedTime,   // R: 요청
  plannedTime,     // P: 계획 (선석 윈도우 확정치)
  actualTime,      // A: 실제
  timeBasis: "berth"  // 어느 지점 기준 시각인지 (선석/도선점/정박지)
})

근거는 셋입니다.

1. 표현력의 이득이 없습니다. PL-04(편차 분석)는 actualTime - plannedTime 속성 연산으로 충분히 답할 수 있어, 노드 승격이 주는 추가 표현력이 없습니다.
2. 그래프가 비대해집니다. 타임스탬프를 노드로 만들면 이벤트당 4노드가 증식해 3~4배로 불어납니다.
3. 표준과 정합합니다. DCSA JIT도 타임스탬프를 이벤트의 데이터 요소로 정의합니다.

단, 재개정 이력이 CQ로 요구되면 — 예를 들어 "ETA가 몇 번, 언제 변경됐나" — 그때 TimestampRevision 노드를 추가 승격합니다. v1 CQ에는 없으므로 보류합니다.

이 판단 자체가 "CQ 변별력" 원칙의 재적용임을 확인하세요. 같은 원칙이 클래스에서 한 번, 이벤트에서 한 번, 타임스탬프에서 또 한 번 쓰였습니다.