이번에 더 배울 것
Noy와 McGuinness는 6장 “What’s in a name?”에서 명명 규칙을 정하고 끝까지 지키라고 권합니다. 흔한 관례는 클래스 이름을 대문자로(Wine, MealCourse), 슬롯 이름을 소문자로(maker) 시작하는 것입니다. 단수와 복수 중 하나로 통일하고(단수가 더 흔함), 이름에 ‘class’나 ‘property’ 같은 단어를 넣지 않으며, Cab 같은 약어 대신 Cabernet Sauvignon처럼 풀어 씁니다. 형제 클래스는 상위 이름을 모두 포함하거나(Red Wine, White Wine) 모두 빼야(Red, White) 합니다.
이름과 레이블은 나누어 관리합니다. 저자들은 클래스가 단어가 아니라 개념을 나타내므로 동의어(Shrimp와 Prawn)를 별도 클래스로 만들지 말라고 합니다. IRI의 로컬 이름은 바뀌지 않는 식별자로 두고, rdfs:label이나 skos:prefLabel·altLabel에 언어별 표기를 붙입니다. 팔란티어 설계 지침도 객체 타입 API 이름(PascalCase)과 속성 API 이름(camelCase)을 정하고, 소스 시스템 약어(dtLastInspMod) 대신 업무 언어(lastInspectionDate)를 쓰라고 권합니다.
정의문은 skos:definition이나 rdfs:comment에 씁니다. 고전적인 ‘상위 개념 + 구별 조건’ 형태(속과 종차)로 쓰면 is-a 계층과 자연스럽게 맞물립니다. ‘배송은 배송되는 것’처럼 정의할 말을 정의 안에 다시 쓰는 순환 정의는 피하고, 쓰임의 범위를 skos:scopeNote로 덧붙이면 경계 사례를 판단하기 쉽습니다. 정의문이 있으면 DAY 51의 ‘고객’처럼 같은 단어를 다르게 쓰는 문제를 문서로 막을 수 있습니다.
작은 예제로 따라가기
피할 이름 :Shipments_class, :dtPrmDlv를 :Shipment, :promisedDeliveryDate로 바꿉니다.
레이블을 따로 붙입니다. :Shipment rdfs:label "배송"@ko, "Shipment"@en ; skos:altLabel "출하"@ko .
정의문: :Shipment skos:definition "고객 주문 1건을 위해 한 출발지에서 한 목적지로 함께 이동하는 물품 묶음."@ko . 상위 개념(물품 묶음)과 구별 조건(같은 주문·출발지·목적지)이 드러납니다.
이름 심사
각 후보가 명명 규칙을 지키는지 먼저 판단하고, 고친다면 어떻게 고칠지 적어 보세요.
와인 하나는 ‘Wines의 한 종류’가 아니므로 계층이 틀립니다. 단수로 통일하면 이 실수가 생기지 않습니다.
학습을 시작하면 새 문제를 직접 풀고 확인 퀴즈를 마친 뒤 선택한 본과정 회차로 돌아갑니다.