RDF 리터럴 비교 검수SPARQL sameTermSPARQL 숫자 값 비교RDF 원천 대사

RDF 리터럴 비교에서 숫자가 같은데 대사는 왜 어긋날까

RDF 수량의 숫자 값이 같아도 원천 표기는 다를 수 있습니다. SPARQL sameTerm과 숫자 비교를 나눠 실행하고, 원본 보존·단위 불명·누락을 구별하는 가상 인수표를 확인하세요.

이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스

발행 ·알파카랩스

RDF의 숫자 값이 같아도 원천 표기는 달라질 수 있습니다. 2026-11-04 기준, 수량 비교와 원본 대사를 나누고 단위 미확정은 보류합니다.

입고 파일에 수량이 ‘07’로 들어오고 조회 화면에는 ‘7’로 표시되는 상황을 가정하겠습니다. 입고 수량을 합산할 때는 같은 단위의 7로 계산할 수 있습니다. 반면 감사 화면에서 입고 파일의 표기를 다시 보여줘야 한다면 ‘07’을 찾을 수 있어야 합니다. 하나의 합격 표시로 두 요구를 처리하면 값이 틀린 행과 표기만 달라진 행을 구별하기 어렵습니다.

숫자는 같은데 RDF 항은 왜 다를까요?#

RDF에서 리터럴은 숫자나 문자열 같은 값을 나타냅니다. 리터럴에는 표기 문자열인 어휘형과 데이터형이 있습니다. 같은 정수 7을 나타내는 ‘07’과 ‘7’도 어휘형이 다르면 다른 RDF 항입니다. SPARQL 1.1의 sameTerm은 두 항이 같은지 검사하고, 양쪽이 유효한 숫자일 때 등호는 숫자 값을 비교합니다. W3C RDF 1.1 리터럴과 SPARQL 1.1 연산자 매핑에서 두 기준을 확인할 수 있습니다.

같은 수량 필드라도 저장 형태가 달라질 수 있습니다. 숫자 7과 소수 7.0은 이 예에서 같은 값을 나타내지만 RDF 데이터형은 다릅니다. 2026년 11월 1일 공개된 SPARQL 1.2 작업 초안도 정수와 소수, 정수 어휘형 차이를 항 비교에서 구분합니다. 아래 표본은 SPARQL 1.1 문법으로 실행합니다.

현업 검수에서는 무엇을 따로 판정하나요?#

업무 필드를 정한 뒤 원천 표기, 숫자, 단위를 따로 대조합니다. 계산값은 단위가 같거나 환산 규칙이 확인된 경우에 비교합니다. 원본 대사에는 원천 파일의 행 키와 그대로 읽은 필드 문자열을 함께 남깁니다.

가상 입력확인할 조건기대 판정
수량 07과 7같은 단위, 유효한 정수값 일치, 표기 다름
수량 7과 7.0같은 단위, 각각 정수와 소수값 일치, RDF 데이터형 다름
수량 7과 8같은 단위, 유효한 정수값 불일치
코드 07과 7원천 코드 체계 확인숫자 비교 제외, 코드 규칙으로 판정
수량 없음 또는 단위 미확정비교 전제 확인원인 표시 후 보류
같은 필드의 값·표기·누락을 구분한 가상 인수표입니다.

수량의 단위를 바꾸는 과제는 품목별 포장 단위 환산 검수에서 따로 다룹니다.

SPARQL에서 두 결과를 어떻게 나란히 보나요?#

같은 입력 쌍에 sameTerm과 등호를 별도 열로 둡니다. 아래는 유효한 숫자만 비교하는 쿼리입니다. 앞의 세 쌍은 각각 참·참, 거짓·참, 거짓·참이며 마지막 쌍은 거짓·거짓입니다. 각 쌍의 첫 판정은 항 일치, 둘째 판정은 값 일치입니다.

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?sample
  (sameTerm(?left, ?right) AS ?termMatch)
  ((?left = ?right) AS ?valueMatch)
WHERE {
  VALUES (?sample ?left ?right) {
    ("a" 7 7)
    ("b" "07"^^xsd:integer 7)
    ("c" 7 7.0)
    ("d" 7 8)
  }
}
ORDER BY ?sample

운영 대사에는 비교 결과와 입력 상태를 함께 남깁니다. 예를 들어 SPARQL 1.1의 BIND 안에서 표현식 오류가 나면 그 행의 결과 변수가 바인딩되지 않을 수 있습니다. 이 상태를 숫자 불일치로 기록하면 누락이나 변환 오류를 가릴 수 있습니다. 먼저 값 유무·숫자형·단위를 확인하고 비교하지 못한 이유를 남기세요. W3C SPARQL 1.1 BIND

적재할 때 이미 07이 7로 바뀌었다면요?#

저장된 항이 이미 정규화됐다면 같은 쿼리에서 변환 전 표기를 복구할 수 없습니다. RDFLib 7.6.0으로 가상 입력을 대조했을 때도 정규화를 켠 입력에서 어휘형은 7만 남았습니다. 원본 대사가 필요한 필드는 로더에 넣기 전에 원천 행 키와 표기를 확보하고 계산용 값은 별도로 적재합니다. 운영 저장소에서 적재 전후의 어휘형을 확인한 뒤, 원천까지 돌아갈 수 있는 표본을 인수 조건에 넣습니다.

계산만 필요한 필드라면 정규화가 합리적일 수 있습니다. 그래도 07이 품목 코드인 경우에는 원천의 식별자 정책을 적용해야 합니다. 어느 그래프를 조회했는지가 의심되면 SPARQL 조회 범위 검수를, 파일 전체에서 임시 노드의 이름이 달라졌다면 RDF 파일 비교 검수를 참고하세요.

RDF 리터럴 비교 검수 FAQ#

SPARQL sameTerm이 거짓이면 수량도 다른가요?

두 RDF 항이 다르다는 뜻입니다. 같은 단위의 유효한 숫자라면 숫자 값 비교에서 일치할 수 있습니다. 표기 차이인지 실제 수량 차이인지 두 결과를 함께 확인합니다.

07과 7을 품목 코드로 쓰면 합쳐도 되나요?

앞자리 0을 지우기 전에 원천 코드 발급 규칙을 확인합니다. 같은 업무 개체를 가리킨다는 근거가 있으면 매핑으로 연결하고, 근거가 없으면 각각의 원천 코드를 보존합니다.

로더를 바꾸면 같은 쿼리도 다시 검수해야 하나요?

원본 표기 보존이 계약에 들어 있다면 다시 확인합니다. 적재 전 원천 문자열과 적재 후 어휘형을 비교하고, 쿼리 결과에서 원천 행을 다시 찾을 수 있는지 확인합니다.

수량 누락은 비교 결과에 어떻게 표시하나요?

누락을 거짓이나 0으로 채우면 실제 값이 다른 행과 섞입니다. 비교하지 못한 사유를 기록하고, 담당자가 원천 행과 단위를 확인할 수 있게 남깁니다.

원천 파일 전체도 sameTerm으로 대조할 수 있나요?

sameTerm은 두 RDF 항을 비교합니다. 파일 전체의 보존 여부는 원본 파일과 행 식별자, 변환 범위에 맞는 별도 대사로 확인합니다.

수량 비교와 원본 보존 기준 협의#

알파카랩스는 온톨로지 구축 서비스에서 원본 보존, 필드별 단위와 변환 규칙, 기존 집계 대사 범위를 협의합니다. 문의 양식에 비교할 필드 하나의 비식별 표기와 기대 판정을 남기면, 원본·계산값을 어디에서 나누고 어떤 표본으로 검수할지 초안을 함께 정할 수 있습니다.

원본 표기와 계산값의 검수 범위를 정합니다

비식별 표본 한 행으로 원본 보존과 계산값의 기대 판정을 협의합니다. 자료 확인 뒤 소요 시간을 정합니다.

리터럴 비교 검수 범위 협의하기