OWL 함수형 관계: 담당자 ID가 둘인데도 오류가 안 나는 이유

온톨로지 관계 개수 검수는 OWL 추론과 입력 값 개수를 나눠야 합니다. 2026-10-30 기준, 함수형 관계만으로 입력 중복이 차단되지는 않습니다.

담당자는 하나라고 선언했는데 담당자 ID가 둘인 데이터가 오류로 잡히지 않을 수 있습니다. 두 ID가 실제로 서로 다른 사람을 뜻하는지, 같은 사람의 별칭인지부터 미확인입니다. 온톨로지를 인수할 때는 논리 판정과 입력 그래프의 개수를 각각 확인해야 합니다.

동일인 후보를 찾고 병합을 승인하는 흐름은 온톨로지 엔터티 해소 기준에서 확인합니다. 이 글은 객체 관계의 함수형 선언이 무엇을 뜻하는지와 입력 개수의 검수에 집중합니다. 문자열·날짜 등 데이터 속성의 의미는 별도 범위입니다.

함수형 관계는 담당자가 정확히 한 명이라는 뜻인가요?#

함수형 객체 관계는 한 주체가 그 관계로 최대 하나의 개체와 연결된다는 뜻입니다. 연결 대상이 반드시 존재한다는 조건은 포함하지 않습니다. 서로 다른 이름이 반드시 다른 개체라는 가정도 OWL의 기본 전제가 아닙니다.

W3C OWL2 Primer의 관계 특성 설명은 함수형 관계에 두 이름이 연결되면 같은 개체로 추론할 수 있다고 설명합니다. 다른 이름의 해석은 같은 문서의 §4.7에 있습니다. 이 설명서의 권고일은 2012-12-11, 확인일은 2026-10-30입니다.

여기서 다루는 오류는 OWL의 논리적 불일관입니다. 파일 파싱 오류, 추론기 실행 실패, SHACL 제약 위반은 별도 결과로 남깁니다. 관계 선언만 추가하고 실제 검사를 수행하지 않은 상태도 통과로 기록하지 않습니다.

담당자 ID가 둘인데도 논리적 모순이 없을 수 있나요?#

두 ID가 같은 개체를 가리키는 해석이 가능하기 때문입니다. 유효한 OWL2 DL의 객체 관계 p에 S가 A와 B로 연결돼 있고 p가 함수형이면, A와 B는 같은 개체를 가리켜야 합니다. 이것은 원본 행을 삭제하거나 업무상 병합을 승인하라는 명령이 아닙니다.

아래는 S를 업무 대상, A/B를 서로 다른 IRI의 담당자 ID로 둔 가상 예시입니다. 표에 적은 공리·관계 외에 충돌을 일으키는 조건이 없고, 단순 객체 속성 p를 사용하는 정상적인 의미론을 전제합니다. 실제 엔진을 실행한 결과나 고객 사례는 아닙니다.

판정의 근거는 OWL2 Direct Semantics의 함수형 객체 속성과 §2.3.6의 DifferentIndividuals 정의입니다. 권고일은 2012-12-11, 확인일은 2026-10-30입니다. 실제 두 사람이 다르다는 근거를 확인해 모델에 반영해야 하며, 오류를 만들 목적으로 차이 공리를 임의로 추가하지 않습니다.

SHACL 값 개수 검사는 무엇을 세나요?#

SHACL의 개수 제약은 제공된 데이터 그래프에서 지정 경로로 얻는 값 노드를 셉니다. sh:maxCount는 상한, sh:minCount는 하한을 검사합니다. 이 검사는 원천 행 수나 업무상 사람 수를 그대로 세는 계약과는 구분해야 합니다.

다음 가상 표는 S를 명시 대상으로 삼고 경로 p를 검사하는 활성·유효한 속성 규칙이 정상 완료한 경우입니다. OWL 동일성의 대표화나 IRI 치환 없이 해당 입력 그래프를 검사하며 다른 제약은 없습니다. 상한만 1인 규칙과 하한·상한이 모두 1인 규칙의 기대값을 비교합니다.

근거는 SHACL 권고의 §3.7·4.2 값 노드와 개수 제약입니다. 권고일은 2017-07-20입니다. RDF1.1 Concepts의 그래프는 트리플의 집합이며 권고일은 2014-02-25입니다. 두 원문을 2026-10-30 확인했습니다.

동일성을 추론해 관계를 추가한 그래프와 대표 IRI로 치환한 그래프도 서로 다릅니다. 대표화로 두 ID를 하나로 바꿨다면 검사 입력부터 달라집니다. 원본을 보존하고 어떤 변환을 거친 값인지 남겨야 결과를 비교할 수 있습니다.

어떤 업무 조건이면 단수 관계를 다시 봐야 하나요?#

공동 담당이 정상인 업무라면 단수 선언과 상한 1이 업무 규칙에 맞는지 먼저 확인합니다. 과거 담당자와 현재 담당자를 같은 관계에 섞은 경우도 분리해야 합니다. 사람 수를 줄여 검사를 통과시키는 방향으로 원본을 고치지 않습니다.

기준 시점과 적용 기간은 온톨로지 시점 조회의 적용일·기록일 기준과 연결해 정합니다. 또한 그래프의 값이 하나여도 수집하지 못한 관계가 있는지는 별도 문제입니다. 실제 대상을 검사했는지는 SHACL 검사 범위와 완료 근거로 확인합니다.

불일관한 온톨로지의 추론을 업무 확정에 쓰지 않고 원인을 확인하는 보류 조건을 두세요. 모델 규칙이 잘못됐는지, 식별자 매핑이 틀렸는지, 원천 사실이 충돌하는지는 추가 근거로 구별합니다. 이 보류·승인 절차는 운영 설계 제안입니다.

관계 개수 검수의 인수 기록에는 무엇을 남기나요?#

원천 행, 그래프, 논리 공리와 입력 제약을 같은 실행에 연결해 남깁니다. 개수의 단위와 실제 검사 입력이 맞아야 통과·위반·실행 실패를 비교할 수 있습니다. 아래 기록 항목은 표준의 공통 필수 필드가 아닌 설계 제안입니다.

현재 공개된 SHACL1.2 Core의 2026-10-25판은 Working Draft입니다. 2026-10-30 확인했으며 확정 권고나 모든 엔진의 지원을 뜻하지 않습니다. 위 기대값은 2017 권고에 기반하므로 실제 규격·엔진·전처리 버전을 고정해 검수합니다.

규칙을 고친 뒤에는 온톨로지 스키마 변경·복구 기준에 따라 영향 범위와 재검수 표본을 남깁니다. 예제 표가 맞는다는 사실만으로 전체 데이터의 정확성을 승인하지 않습니다.

온톨로지 구축 범위와는 어떻게 연결하나요?#

관계의 업무 의미와 원천 매핑, 추론·검수·수정 승인을 함께 정합니다. 데이터 정비만 필요한지, 별도 관계 모델과 검사 흐름이 필요한지도 비교합니다. 특정 추론기 이름만으로 운영 인수의 완료 조건을 대신할 수는 없습니다.

알파카랩스의 공개 온톨로지 서비스는 명칭·식별자와 관계, 정규화·원천 매핑·사람 검수, 변경 이력과 복원을 검수 조건으로 협의한다고 안내합니다. 이는 회사 자기표기이며 OWL 추론기나 SHACL 전용 기능의 기본 탑재·고객 성과를 보장하는 설명은 아닙니다. 게시일은 미표기이며 2026-10-30 확인했습니다.

비식별 관계 표본과 공리·입력 규칙, 엔진·전처리 조건, 정상·충돌·누락의 업무 기대값을 준비하세요. 관계 의미와 입력 개수의 판정표 초안을 협의하는 데 사용합니다. 비용과 소요 시간은 자료·권한·엔진 지원·운영 승인 범위 확인 후 정합니다.

OWL 함수형 관계와 개수 검수에서 자주 묻는 질문은 무엇인가요?#

OWL 함수형 관계를 선언하면 담당자는 정확히 한 명인가요?

최대 하나의 개체와 연결된다는 의미이며 담당자의 존재까지 강제하지는 않습니다. 입력 필수 여부와 값 개수는 별도 검수 조건으로 정합니다. 담당자 없음과 미수집도 업무 상태에 맞게 구분해야 합니다.

담당자 ID가 다르면 서로 다른 사람 아닌가요?

OWL은 이름이 다르다는 이유만으로 서로 다른 개체라고 가정하지 않습니다. 함수형 객체 관계의 두 목적어는 같은 개체로 추론될 수 있습니다. 업무상 실제 동일인인지와 원천 레코드를 병합할지는 별도 근거와 승인으로 판단합니다.

owl:sameAs를 넣으면 SHACL도 항상 한 개로 세나요?

그렇게 전제하면 안 됩니다. 동일성 대표화 없이 두 IRI를 값으로 가진 그래프와 대표 IRI로 치환한 그래프는 검수 입력이 다릅니다. 실제 엔진의 추론·전처리 조건과 검사한 그래프를 기록하세요.

같은 관계가 원천에서 두 번 왔는데 maxCount가 통과해도 되나요?

RDF 그래프는 트리플의 집합이므로 같은 트리플을 반복해도 별개 값 노드가 늘지는 않습니다. 그래프의 관계 개수와 원천 행의 중복은 다른 검사입니다. 원천 식별자·수집 이력과 그래프 변환 결과를 함께 대조합니다.

OWL 불일관이 나오면 원본 데이터를 자동으로 고쳐도 되나요?

어느 공리와 입력 사실이 충돌했는지 확인한 뒤 모델과 원천 중 수정 대상을 정해야 합니다. 불일관한 결과를 업무 확정이나 자동 병합의 근거로 사용하지 않는 기준을 둡니다. 엔진 미실행·오류·시간 초과도 정상 판정과 구별합니다.