JSON-LD @protected 검수JSON-LD protected term redefinition속성 범위 컨텍스트JSON-LD IRI 매핑 검수

JSON-LD @protected 검수, 상태 필드의 뜻이 바뀔 때

JSON-LD의 같은 상태 키가 주문과 배송에서 다른 IRI로 펼쳐질 때 검수하는 기준입니다. @protected의 동일 정의와 속성 범위 예외를 가상 입력 7개로 비교합니다.

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

발행 ·알파카랩스

JSON-LD에서 @protected는 용어 정의를 지킵니다. 속성에 붙인 컨텍스트는 그 범위에서 정의를 바꿀 수 있습니다. 2026년 11월 11일 기준입니다.

주문과 배송 시스템이 모두 status라는 키를 쓴다고 해 보겠습니다. 주문의 confirmed와 배송의 packed는 각각 다른 속성에 속합니다. JSON 문법 검사를 통과해도 지식그래프에서 둘을 같은 속성으로 읽을 수 있습니다. JSON-LD를 확장해서 주문의 상태와 배송의 상태가 어느 IRI로 나오는지 확인합니다.

보호된 용어는 언제 오류가 나나요?#

JSON-LD 컨텍스트는 짧은 키를 지식그래프에서 쓰는 IRI와 값의 해석 방식에 연결합니다. 용어 정의에 @protected: true를 두면 이후 일반 컨텍스트에서 다른 정의로 재정의할 때 확장 오류가 납니다. IRI가 같더라도 값 해석을 일반 문자열에서 IRI로 바꾸는 정의는 다릅니다. 보호 플래그를 제외한 정의가 동일하면 반복해도 처리할 수 있고 기존 보호가 유지됩니다. W3C 보호된 용어 설명 · W3C 용어 정의 알고리즘

속성의 용어 정의에 붙인 컨텍스트는 해당 속성의 값에 적용됩니다. 표준은 이 속성 범위 컨텍스트에서 보호된 용어를 바꿀 수 있도록 합니다. 아래 예시에서는 문서 상위의 status가 주문 상태로, delivery 아래의 status가 배송 상태로 확장됩니다. 새 매핑을 어디에서 허용할지 정하고 해당 위치의 결과를 따로 검수합니다. W3C 확장 알고리즘

주문과 배송의 상태를 어떻게 검수하나요?#

가상 표본의 주문·배송 IRI는 아래 JSON에 나옵니다. 인수표에는 입력 위치, 적용 컨텍스트, 기대 IRI 또는 오류 코드, 적재 여부를 각각 적습니다.

가상 입력기대 확장 결과검수 지점
보호한 주문 status주문 상태 IRI기본 매핑 유지
보호 없이 IRI 재정의배송 상태 IRI두 번째 정의 적용
보호한 주문 IRI를 배송 IRI로 재정의protected term redefinition일반 컨텍스트에서 변경 오류
보호한 정의와 같은 정의 반복주문 상태 IRI동일 정의에서 IRI 유지
같은 IRI에 값 유형 @id 추가protected term redefinition값 해석 변경도 오류
보호 정의가 있는 컨텍스트를 일반 위치에서 null로 초기화invalid context nullification보호된 용어의 삭제 차단
배송 속성 범위 안에서 재정의상위는 주문, 배송 값은 배송 IRI각 위치의 확장 결과 대조
PyLD 3.2.0의 JSON-LD 1.1 모드에서 인라인 컨텍스트 표본 7개를 확장했습니다. 판정은 해당 위치의 속성 IRI와 오류 코드입니다.

아래는 마지막 행에 사용한 가상 입력입니다. delivery의 용어 정의 안에 컨텍스트가 있어 이 예시에서는 그 값인 배송 객체에 배송 상태 매핑을 적용합니다.

{
  "@context": {
    "@version": 1.1,
    "status": {
      "@id": "https://example.test/order/status",
      "@protected": true
    },
    "delivery": {
      "@id": "https://example.test/order/delivery",
      "@context": {
        "status": "https://example.test/shipping/status"
      }
    }
  },
  "status": "confirmed",
  "delivery": { "status": "packed" }
}

원본과 매핑을 함께 검수할 때는 확장된 속성 IRI를 비교합니다. 상위 주문의 상태가 배송 IRI로 펼쳐지거나 오류가 나야 할 입력이 통과하면 적재를 보류하고 적용 컨텍스트를 확인합니다. 파서, 컨텍스트 또는 원천 매핑이 바뀌면 같은 입력을 다시 시험합니다.

같은 키를 허용하는 편이 나은 때는 언제인가요?#

상위 주문과 하위 배송이 독립적으로 정의된 데이터라면 같은 짧은 키를 유지하면서 속성 범위를 둘 수 있습니다. 관리하는 쪽에서 필드 이름까지 바꿀 수 있다면 서로 다른 이름을 쓰는 방법도 있습니다. 표의 속성 범위처럼 합의한 예외가 있는지와 실제 확장 결과가 맞는지 먼저 확인합니다.

보호된 용어가 올바르게 확장되면 다음으로 상태값이 허용된 업무 값인지, 필수 속성이 있는지 확인합니다. 적용 대상과 검사 결과를 대조하는 방법은 SHACL 검증 대상 확인에서 다룹니다.

어떤 문서에서 기준을 확인했나요?#

공개 문서는 2026년 11월 11일 확인했습니다. 표는 외부 컨텍스트를 불러오지 않는 가상 입력의 확장 결과입니다.

자주 묻는 질문#

@protected를 쓰면 같은 정의도 다시 쓰기 어렵나요?

보호 플래그를 제외한 용어 정의가 같으면 반복할 수 있습니다. 이전 정의의 보호 상태는 유지됩니다.

같은 IRI인데 @type만 추가하면 어떻게 되나요?

값을 해석하는 방식도 용어 정의에 속합니다. 보호한 일반 문자열의 정의를 같은 IRI에서 @type: @id로 바꾸는 가상 입력은 protected term redefinition 오류가 납니다.

@context: null로 초기화하면 어떻게 되나요?

보호한 용어가 있는 상태에서 일반 컨텍스트를 null로 초기화하면 invalid context nullification 오류가 납니다. 속성 범위처럼 표준이 보호 재정의를 허용한 위치는 별도로 검수합니다.

속성 범위 안에서 바꾼 상태가 주문 쪽에도 적용되나요?

표의 입력에서는 delivery에 붙인 컨텍스트가 그 속성의 값에 적용됩니다. 상위 주문 상태는 주문 IRI로, 배송 객체의 상태는 배송 IRI로 확장됩니다.

@protected를 쓰면 잘못된 상태값도 발견할 수 있나요?

@protected는 컨텍스트의 용어 정의를 지킵니다. 업무에서 허용하는 상태값, 필수 속성, 접근 권한은 별도의 검수 조건으로 확인합니다.

컨텍스트 매핑의 인수 범위를 정할 때#

JSON-LD 매핑의 인수 기준을 정리합니다

첫 범위 협의에서 비식별 JSON-LD와 기대 IRI를 바탕으로 보호 용어와 속성 범위 예외의 인수 기준을 정리합니다. 소요 시간은 표본과 매핑 검수 범위를 확인한 뒤 협의합니다.

JSON-LD 매핑 인수표 초안 협의