문서적용 프로파일 가이드라인

작성자 :
Karen Coyle
컨설턴트
작성자 :
Thomas Baker
DCMI
발행일 :
2009-05-18
식별자 :
http://dublincore.org/documents/2009/05/18/profile-guidelines/
대체함 :
http://dublincore.org/documents/2008/11/03/profile-guidelines/
대체됨 :
해당없음
최신 버전 :
http://dublincore.org/documents/profile-guidelines/
문서의 지위 :
This is a DCMI 권고안
설명 :
이 문서는 더블린코어 어플리케이션 프로파일의 생성을 위한 가이드라인을 제공한다. 이 문서는 더블린코어 어플리케이션 프로파일의 핵심 요소에 대해 설명하며 프로파일을 개발하는 과정을 단계별로 보여준다. 이 문서는 어플리케이션 프로파일의 설계자들을 대상으로 한다- 구체적인 맥락에서의 사용을 위한 메타데이터 용어들을 한데 모으는 사람들. 이것은 어플리케이션 프로파일의 기계판독이 가능한 실행의 생성도, 더 넓은 의미에서의 메타데이터 어플리케이션의 설계도 다루지 않는다. 추가적인 기술적 세부사항을 위해, 독자들은 추가적 정보원을 고려하도록 한다.


목차

  1. 서론
  2. 더블린코어 어플리케이션 프로파일을 위한 프레임워크
  3. 기능적인 필수요소의 정의
  4. 도메인 모델의 선택 또는 개발
  5. 메타데이터 용어의 선택 또는 정의
  6. 기술집합 프로파일과 관련한 메타데이터 레코드의 설계
  7. 사용 가이드라인
  8. 구문 가이드라인
  9. 부록 A: 기술 집합 모델 (DCMI 추상모델)
  10. 부록 B: MyBookCase기술 집합 프로파일
  11. 부록 C: 프로파일 내에서 RDF 속성의 사용: 기술적 입문서

1. 서론

메타데이터와 관련하여, 한 사이즈가 모든 것에 맞지는 않는다. 사실, 한 사이즈는 종종 많은 것에 맞지도 않는다. 특정한 커뮤니티와 어플리케이션의 메타데이터 요구는 매우 다양하다. 결과는 공통적인 메타데이터 요구를 가진 어플리케이션들 간에서 조차도, 메타데이터 형식들이 엄청나게 늘어난다는 것이다. 더블린코어 메타데이터 이니셔티브는 더블린코어 어플리케이션 프로파일(DCAP)의 설계를 위한 프레임워크를 제공함으로써 이것을 다루어왔다. DCAP는 전세계적으로 정의된 어휘들과 모델들에 기초한 다른 어플리케이션들과의 시맨틱 상호호환성을 제공하면서, 구체적인 어플리케이션 요구를 만족시키는 메타데이터 레코드들을 정의한다.

DCAP는 DCMI [DCMI-MT]에 의해 정의된 메타데이터 용어들의 사용이 요구되지 않는 메타데이터 레코드들을 설계하기 위한 일반적인 구조임에 주목해야 한다. DCAP는 필요한 경우 다수의 namespaces 로부터 용어를 결합하는 RDF에 기초하여 정의된 어느 용어든지 사용할 수 있다. DCAP는 메타데이터 레코드를 위한 일반적인 모델인 DCMI 추상모델 [DCAM]을 따른다.

DCAP는 메타데이터 생성자들을 위한 안내와 메타데이터 개발자들을 위한 분명한 규격을 포함한다. 무엇이 의도되었고 데이터로부터 무엇이 기대될 수 있는지를 분명히 표현함으로써, 어플리케이션 프로파일은 커뮤니티 내 또는 커뮤니티 간의 데이터 공유와 링크를 장려한다. 결과로 초래된 메타데이터는 링크 데이터 [LINKED]의 시맨틱 웹과 통합할 것이다. 이것을 성취하기 위해서는, 기술되어야하는 자원들의 전문화된 지식을 지닌 팀에 의해 어플리케이션 프로파일이 개발되도록 권유된다. 또한 이러한 자원들의 기술 내에서 메타데이터가 사용되어야 하며, 시맨틱 웹과 링크 데이터 환경의 이해 또한 이루어져야 한다.

링크 데이터 환경 내에서 DCAP에 기초한 메타데이터의 상호호환성은 표준의 기초로부터 얻는다:

  • 자원 기술 프레임워크(RDF), 도메인 표준에 있는 기초 표준.[RDF]
  • 더블린코어 추상 모델, 메타데이터 레코드를 위한 일반적 구문 [DCAM]
  • 더블린코어 기술 집합 프로파일, 어플리케이션 프로파일을 위한 제약 언어 [DCSP]
  • 실행 인코딩을 위한 DCMI 가이드라인 [DCMI-ENCODINGS]

2. 더블린코어 어플리케이션 프로파일을 위한 프레임워크

DCAP는 특정 어플리케이션 내에서 사용되는 메타데이터를 구체화하고 기술하는 문서 (또는 문서 집합)다. 이것을 달성하기 위해서, 프로파일은:

  • 그 어플리케이션을 통해 커뮤니티가 무엇을 달성하기를 원하는지를 기술한다 (기능적인 필수요소);
  • 메타데이터와 그들 간의 관계를 통해 기술되는 것들의 종류를 특징짓는다 (도메인 모델);
  • 사용될 메타데이터 용어들과 규칙들을 열거한다 (기술집합프로파일과 사용 가이드라인); 그리고
  • 데이터를 인코딩하기위해 사용될 기계 구문을 정의한다 (구문 가이드라인들과 데이터 형식들).

singapore-framework
Singapore Framework

이러한 표준들이 얼마나 서로 잘 맞는지는 더블린코어 어플리케이션 프로파일을 위한 싱가포르 프레임워크 [DCMI-SF]에서 그림으로 설명되어진다. 가장 아래 단계인 RDF는 도메인 표준이 세워지는 기초 표준을 제공한다. 가운데 단계는 어플리케이션 프로파일을 위한 구조적이고 의미론적인 안정성을 제공하기 위한 도메인 표준을 정의한다. 가장 위의 단계는 구체적인 메타데이터 어플리케이션의 디자인과 문서 요소를 담고 있다.

로드맵으로서의 싱가포르 프레임워크의 윗 단계를 가지면서, 다음 섹션들에서는 DCAP의 생성을 위한 과정을 하나하나 살표보도록 하겠다. 그 과정을 설명하기 위해, 우리는 책과 저자들을 기술하는 간단한 어플리케이션 프로파일을 만든다. 우리는 이 예를 MyBookCase 라고 부른다.

3. 기능적인 필수요소의 정의

어떤 메타데이터이든지 그 목적은 활동을 지원하는 데에 있다. 그 활동에서 사용되는 어플리케이션의 분명한 목표를 정의하는 것은 반드시 필요한 첫번째 단계이다.

기능적인 필수요소들은 목표와 경계를 제공함으로써 어플리케이션 프로파일의 발전을 이끌며, 성공적인 어플리케이션 프로파일 개발 과정의 필수 요소이다. 이 개발은 종종 넓은 커뮤니티 과업이며, 서비스 관리자, 사용되는 자료의 전문가, 어플리케이션 개발자, 그리고 서비스의 잠재적인 이용자들을 포함할 것이다.

이러한 방법론들은 비즈니스 프로세스 모델링과 같은 기능적인 필수요소들의 생성과 통일된 모델링 언어(Unified Modeling Language) (UML)과 같은 시각적 필수요소들을 위한 방법에 도움이 된다. 몇몇 사람들은, 특정 어플리케이션을 위한 사용 예들과 시나리오들을 정의하는 것이, 그렇지 않으면 간과될 지도 모를 기능적인 필수요소들을 끌어내는 것을 도와준다고 발견하였다.

기능적인 필수요소들은 다음과 같은 질문들에 답한다:

  • 당신의 어플리케이션에서 무엇을 달성하기를 원하는가?
  • 당신의 어플리케이션의 한계는 무엇인가? 달성하고 하는 것에서 무엇이 제외되는가?
  • 당신의 어플리케이션이 데이터를 정렬하거나, 특별한 형식으로 데이터를 다운로드하는 것과 같은 특정된 행동들을 수행해야만 하는가?
  • 당신의 자원들의 핵심 특징은 무엇이며, 어떻게 그것이 당신의 데이터 요소들의 선택에 영향을 미치는가? 예를 들어, 당신은 (다국어 지원을 위한) 다양한 문자 집합을 다루어야만 하는가?
  • 당신의 자원들의 핵심 특징은 무엇이며, 어떻게 그것이 당신의 데이터 요소들의 선택에 영향을 미치는가? 예를 들어, 당신은 (다국어 지원을 위한) 다양한 문자 집합을 다루어야만 하는가?
  • 당신의 이용자들의 핵심 특징은 무엇인가? 그들은 특정 단체와 연결되어 있는가? 또는 당신은 일반 대중을 대상으로 하는가? 그들은 같은 언어를 사용하는가? 당신의 어플리케이션이 관리할 데이터와 관련하여 그들은 얼마나 숙련되었는가? 기술된 자원들의 종류에 관하여 그들은 얼마나 숙련되었는가?
  • 고려 되어야 하는 커뮤니티 표준들이 존재하는가?

기능적인 필수요소들은 당신이 다루어야 하는 구체적인 과업들 뿐만 아니라 일반적인 목표들도 포함할 수 있다. 이상적으로, 기능적인 필수요소들은 메타데이터 생성자들, 자원 이용자들, 그리고 어플리케이션 개발자들의 요구들을 반드시 개진해야 한다. 이는 결과물로서의 어플리케이션이 완벽하게 커뮤니티의 요구를 지원할 수 있도록 하기 위해서이다.

여기 Schoarly Works Application Profile (SWAP)로부터의 샘플 필수요소들이 있다.[SWAP]:

  • 오픈 액세스 자료들의 식별을 용이하게 한다.
  • 연구 자금 제공자와 프로젝트 코드의 식별을 가능하게 한다.

기능적인 필수요소들의 집합은 반드시 지원되어져야 하는 이용자 과업들을 포함할 수 있는데, 예를 들어 다음과 같이 서지 레코드들을 위한 기능적인 필수요소들 (FRBR) 들을 따르는 것이다.[FRBR]:

  • 이용자의 정해진 검색 기준에 일치하는 자료들을 찾기 위한 데이터를 사용하라.
  • 독립체를 식별하기 위해 검색된 데이터를 사용하라.

MyBookCase DCAP를 위한 우리의 기능적인 필수요소들은:

  • Title 검색을 이용하여 도서들을 검색하기 위한 데이터를 사용하라.
  • 특정 언어로의 검색을 제한하라.
  • 출판일을 기준으로 검색된 항목들을 정렬하라.
  • 주어진 주제에 대하여 자료들을 찾아라.
  • 연락의 목적을 위한 저자명이메일 주소를 제공하라.

4. 도메인 모델의 선택 또는 개발

기능적인 필수요소들을 정의한 후에, 다음 단계는 도메인 모델을 선택하거나 개발하는 것이다. 도메인 모델은 당신의 메타데이터가 기술할 것들에 대한 기술이며 그들 간의 관계이다. 도메인 모델은 어플리케이션 프로파일의 구성을 위한 기초적인 청사진이다.

MyBookCase를 위한 도메인 모델은 두가지를 가지고 있다: 도서사람(도서의 저자). 우리는 어떻게 titlelanguage 같은 요소들을 사용하여 도서를 기술할 것인지, 이름이메일 주소를 통해 어떻게 사람을 기술할 것인지를 아래의 내용을 통해 보게 될 것이다. 간단하게, 우리의 MyBookCase를 위한 도메인 모델은:

mybookcase

모델들은 이것보다 더욱 간단해질 수도 있고 (예를 들면, 그냥 처럼), 더욱 복잡해질 수도 있다. 예를 들어, Scholarly Works 더블린코어 어플리케이션 프로파일(Scholarly Works Dublin Core Application Profile)을 위한 도메인 모델은 도서관 커뮤니티의 도메인 모델에 기초한다: 서지 레코드를 위한 기능적인 필수요소들(Functional Requirements for Bibliographic Records (FRBR)) [FRBR]. SWAP은 FRBR의 더욱 일반적인 독립체 Work 대신에 Scholary Work를 정의한다. 그리고 FRBR에서의 것들을 너머 새로운 에이전트 관계를 소개한다 (예) isFundedBy, isSupervisedBy): 이 방법으로, SWAP는 FRBR을 사용하지만, 구체적인 요구를 충족시키기 위해 FRBR 모델을 수정한다.

eprints

5. 메타데이터 용어의 선택 또는 정의

메타데이터를 위한 도메인 모델을 정의한 다음에는, 모델 내의 것들을 기술하기 위한 속성들을 선택해야할 필요가 있다. 예를 들어, 도서(Book)는 표제(title)과 저자(author)를 가질 수 있다. 저자는 이름(name)이메일 주소(email address)를 가진 사람(Person)일 것이다.

그 다음 단계는 그 속성들이 필요한지 아닌 지를 보기 위해서 이미 선언되고 사용이 가능한 RDF 어휘들을 자세히 조사하는 것이다. 적절한 때에 존재하는 속성들을 사용하는 것은 적은 노력이 필요하고 당신의 메타데이터의 상호호환성을 증가시킨다. 만약 필요한 속성들이 아직 이용가능하지 않다면, 부록 C에 기술된 것처럼 자체적으로 선언할 수 있다.

우리의 단순한 예의 목적을 위해서, DCMI 메타데이터 용어 [DCMI-MT]는 기초적인 자원기술을 위한 속성들의 출처이다. FRBR과 직접적으로 관련된 더욱 확장된 속성집합은 자원기술과 접근 (RDA) 표준을 위한 개발 하에 있다. "친구의 친구(Friend of a Friend)" 어휘는 사람들을 기술하기 위한 유용한 속성들을 가지고 있다.[FOAF]

존재하는 어휘들로부터의 용어를 평가함에 있어서 가장 분명한 고려사항은 그들의 정의다. 예를 들어, 더블린코어 속성 "표제(title)는 "자원에게 주어진 이름"으로 정의된다. 만약 정의가 당신의 요구와 맞는다면, 이 속성은 당신의 프로파일에서 이용을 위한 후보이다. 그러나, 특정한 어플리케이션에서 이용을 위한 속성의 적합성은 또한 속성이 가질 수 있는 값들의 종류에 의존한다. 당신의 속성들을 위해 계획된 값들의 종류들은, 당신이 사용하기를 윈하는 존재하는 속성들의 허용된 값 종류들과 반드시 일치되어야만 한다.

프로파일에서 필요한 각 속성들과 함께, 사용하고자 계획하는 값들에 관한 다음과 같은 질문들을 물어보는 것이 유용하다고 생각될 것이다. 어느 속성을 위해서든지 유념해야 할 것은, "예"라는 대답은 한 개 이상 있을 수 있다는 것이다.

  • 속성값을 위한 자유 텍스트를 사용하기를 원하는가?
  • 날짜 ("YYYY-MM-DD")를 위한 W3C 형식과 같은 미리 정의된 형식을 따르는 것을 자유 텍스트가 필요로 하는가?
  • 통제된 목록으로부터의 유효한 값들을 선택하기를 원하는가?
    • 만약 그렇다면, 그 목록이 이미 어딘가에서 이용가능한가? 또는 그것을 만들어야 하는가?
    • 당신은 유효한 값들을 목록으로부터의 선택으로 한정하기를 원하는가? 아니면 목록되지 않은 값들이 사용가능한가?
    • 목록에 있는 값들이 (URI의 형태에서) 할당된 식별자들로 되어왔는가? 아니면 당신은 미래에 그들을 위해 이용가능해질 수 있는 URI들을 기대하는가?
  • 단일 값 문자열들(예, "1989" 또는 "John Adams")로 충분한가? 아니면 이름, 이메일주소 그리고 관계와 함께 기술되는 저자와 같이, 잠재적으로 복합 요소들과 함께 더욱 복잡한 기술적인 구조들이 필요한가?

우리의 MyBookCase를 다시 한번 본다면, 이것은 우리가 도서를 위한 속성들과 관련된 질문에 어떻게 대답할 수 있느냐를 보여주는 것이다:

  • 표제는 도서 자체에 의해 옮겨쓰여질 것이다. 이것은 자유 텍스트 문자열이 될 것이다.
  • 우리는 날짜(date) 속성을 검색된 서지 레코드의 집합을 분류하는 것과 같이 소프트웨어 어플리케이션에서 다양한 방법으로 사용하기를 원한다. 그래서 우리는 날짜들이 구조화된 문자열로서 한결같은 방법으로 표시되는 것을 확실하게 하기를 원한다.
  • 우리는 이용자들이 그들의 검색을 언어로써 한정할 수 있도록 도서의 언어(language)를 나타내기를 원한다. 언어들이 항상 같은 방법으로 입력되도록 확실하게 하기 위해서, 우리는 언어들의 통제 목록을 사용하기를 원한다.
  • 우리는 통제된 목록으로부터 주제(subject)를 기록하기 원한다. 미 의회도서관 주제명 표목표와 같이 적어도 하나의 가능한 통제된 목록이, 확인하는 어휘 값 URI와 함께, 우리가 사용할 수 있도록 되어 있다.[LCSH].
  • 우리는 저자(author)가 단일 텍스트 문자열이 아니라 몇 개의 정보들과 함께 기술될 것이라는 것을 안다. 예, 이름(name)또는 이메일주소(email address)처럼..

메타데이터 개발 과정은 부록 C에 기술되어있는 것처럼 데이터 요소들의 기술적인 모델을 만들기 위해 이러한 결정들을 사용하게 될 것이다. RDF와 DCMI 추상모델과 일치하는 다음과 같은 데이터 모델에서의 이 분석 결과는:

표제

표제를 위해서 더블린코어 속성을 사용할 수 있다. dcterms:title, 자유 텍스트 문자열 (a "literal").

날짜

우리가 날짜(date)를 분류하는 것과 같이 자동 실행을 원하기 때문에, 우리는 더블린코어 속성을 선택할 수 있다. dcterms:date. 이 속성은 문자열 값을 가질 수 있다. 구문 부호화 스킴을 사용한 W3C 날짜(W3C Date)와 시간 형식 규격(Time Formats specification)과 일치하는 방식으로 값 문자열이 형식화 되었다는 것을 우리는 나타낼 수 있다. dcterms:W3CDTF.

언어

언어는 통제된 목록으로부터 선택될 필요가 있다. 국제표준 ISO 639-3에 있는 3레터 코드의 사용을 요구함으로써 이것을 달성한다. 이것은 언어의 이름(예, "eng"는 "English"를 위한 것)을 구문 부호화 스킴과 함께 표현하기 위함이다: 데이터타입으로서의 dcterms:ISO639-3. 이것을 위해서 우리는, 식별자 혹은 언어 용어 혹은 문자열을 포함할 수 있는, DCMI 속성을 사용할 수 있다 dcterms:language.

주제

우리는 통제 목록을 사용하여 주제를 기록하기 원한다. 우리만의 것을 만들기 보다는, 이것은 이미 존재하는 리스트를 사용함으로서 보다 쉽게 해결하며, 또한 데이터를 위한 상호호환성의 잠재성을 증가시킨다. 우리는 미 의회도서관 주제명 표목표(LCSH)가 우리의 이러한 필요와 일치한다고 결정하였다. RDF vocabulary Simple Knowledge Organization System(SKOS)[SKOS],를 사용한 형식적인 어휘로써 LCSH의 용어들이 사용가능하기 때문에, 우리는 이것을 식별하는 URI를 사용함으로써 각 주제를 나타내는 선택권을 가진다. 예를 들어, 미 의회도서관 주제명 표목표 "이슬람과 과학"은 URI http://id.loc.gov/authorities/sh85068424에 할당되어왔다. DCMI 속성 dcterms:subject는 일반 문자열의 사용 또는 URI를 지원할 수 있다.

저자

저자(author)이름(name)또는 이메일주소(email address)와 같이 복합 요소들과 함께 기술되어져야 할 필요가 있기 때문에, 저자 속성은 비문자 범위 (non-literal range) 를 가져야 한다. 그렇게 함으로써 분리된 그러나 연결된 기술이 메타데이터 레코드 내에서 생성될 수 있다. 더블린코어 속성 dcterm:creator 는 문자가 아닌 값과 함께 사용될 수 있다. 그래서 우리는 이것을 MyBookCase내에서 사용할 것이다.

사람(person)으로서 저자를 기술하기 위한 속성들의 선택은 다음과 같은 모델을 따른다:

사람(person)은 이름을 가지고 있지만, 우리는 단일 문자열보다는 이름과 성을 구별해서 기록하기를 원한다. DCMI 메타데이터 용어는 특별한 속성을 가지고 있지않기 때문에, 우리는 Friend of a Friend 어휘로부터 foaf:firstName와 foaf:family_name 속성들을 사용할 것이다 [FOAF].

  • 사람(person)을 위한 연락처로서의 이메일주소를 기록하기 위해서, 우리는 속성을 사용할 것이다; 문자가 아닌 범위를 가지는 foaf:mbox와 값으로서의 mailto: URI.
  • 이러한 결정들은 부록 C에 기술되는 속성들의 기술분석을 반영하는 다음과 같은 표에 요약될 것이다. 열에 쓰여진 표제 용어는 더블린코어 추상모델에서 정의되었다.

속성의 기술적 분석 반영
Property Range Value String SES URI Value URI VES URI Related description
dcterms:title literal YES no not applicable [1] not applicable not applicable
dcterms:created literal YES [2] no not applicable not applicable not applicable
dcterms:language non-literal YES YES [3] no no no
dcterms:subject non-literal YES no [3] YES YES [4] no
dcterms:creator non-literal YES no no YES no
foaf:firstName literal YES no not applicable not applicable not applicable
foaf:family_name literal YES no not applicable not applicable not applicable
oaf:mbox non-literal no no YES [5] no no

[1] 이러한 값들은 "literal" 범위의 값들을 위해 적용되지 않는다.
[2] http://purl.org/dc/terms/W3CDTF
[3] http://purl.org/dc/terms/ISO639-2
[4] http://purl.org/dc/terms/LCSH
[5] Email addresses can be given using mailto: URIs.

6. 기술집합 프로파일과 관련한 메타데이터 레코드의 설계

다음 단계는 상세하게 메타데이터 레코드를 기술하는 것이다. DCMI 접근 방법으로, 메타데이터 레코드는 기술집합모델DCAM] (그 자체가 DCMI 추상모델의 일부분)을 기초로 한다(부록 A 참조). 그리고 레코드의 디자인은 DSP 제약언어 [DSP]를 사용한 기술집합프로파일(또는 DSP)에서 상세하게 기술된다. 레코드 내에서의 각각의 기술과 문장을 위해서, DSP는 템플릿을 정의하고, 각 템플릿은 허용가능한 값들에서의 요소 또는 제한의 반복성과 같은 기술 세부사항들을 구체화하는 관련된 제약 언어들을 가지고 있다. 이 부분은 MyBookCase를 위한 단순 기술집합 프로파일에 나타난다.

DSP는 도메인 모델의 각각에 하나의 기술 템플릿을 포함한다. 여기서 도메인 모델은 각각을 기술하는 속성들의 전체를 위한 문장 템플릿을 차례로 포함한다. 이러한 템플릿들은 값 종류들 또는 요구사항들 그리고 반복성과 같은 기술 또는 속성들의 사용을 제약하는 규칙들 또한 포함한다.

MyBookCase를 위한 DSP는 두개의 기술 템플릿을 가질 것이다: 하나는 도서를 위한 것이고 다른 하나는 사람을 위한 것이다. 각 기술 템플릿은 도서 또는 사람을 기술하기 위해 사용되는 각 속성들을 위한 문장 템플릿을 가진다. 문장 템플릿은 속성을 이름짓고, 속성, 값 문자열, 어휘 부호화 스킴 등등에 있어서 단일 문장에 적용되는 모든 제약들을 포함한다.

만약 우리가 각 메타데이터 레코드가 정확하게 하나의 도서를 표현하는 것을 결정한다면, 도서 기술 템플릿이 한번 또는 각 기술집합당 오직 한번씩 나타날 것이다:

DescriptionSet: MyBookCase
Description template: Book
minimum = 1; maximum = 1

우리는 각 도서가 반드시 하나의 표제를 가질 것을 결정할 수 있는데, 그것은 속성 URI http://purl.org/dc/terms/title로 식별된다.

문장 템플릿들은 또한 도서(필요할 경우 선택과 다른 제약을 만들 수 있다)를 기술하기 위해 사용되는 각각의 다른 속성들을 위해 생성된다.

DescriptionSet: MyBookCase
Description template: Book
minimum = 1; maximum = 1
Statement template: title
minimum = 1; maximum = 1
Property: http://purl.org/dc/terms/title
Type of Value = "literal"
Statement template: dateCreated
minimum = 0; maximum = 1
Property: http://purl.org/dc/terms/created
Type of Value = "literal"
Syntax Encoding Scheme URI = http://purl.org/dc/terms/W3CDTF
Statement template: language
minimum = 0; maximum = 3
Property: http://purl.org/dc/terms/language
Type of Value = "non-literal"
takes list = yes
Syntax Encoding Scheme URI = http://purl.org/dc/terms/ISO639-2
Statement template: subject
minimum = 0; maximum = unlimited
Property: http://purl.org/dc/terms/LCSH
Type of Value = "non-literal"
takes list = yes
Value Encoding Scheme URI = http://lcsh.info/
Statement template: author
minimum = 0; maximum = 5
Property: http://purl.org/dc/terms/작성자
Type of Value = "non-literal"
defined as = person

위의 몇몇 속성들은 0의 최소 발생을 가진다. 이것은 이러한 속성들이 레코드 내에서 선택적인 것을 말하는 방법이며, 비록 이러한 속성들이 표현하지 않는다 하더라도 레코드는 유효함을 나타내는 방법이다. 몇몇 속성들은 반복될 수 있다. 예를 들어, 언어(language)는 최대 세 번까지 나타날 수 있으며, 저자(author)는 최대 다섯 번 나타날 수 있다. 우리는 그 자체의 기술 템플릿에서 기술된 사람(Person)의 값을 가진 저자를 정의해왔다:

Description template: Person id=person
minimum = 0; maximum = unlimited
Statement template: givenName
Property: http://xmlns.com/foaf/0.1/givenname
minimum = 0; maximum = 1
Type of Value = "literal"
Statement template: familyName
Property: http://xmlns.com/foaf/0.1/family_name
minimum = 0; maximum = 1
Type of Value = "literal"
Statement template: email
Property: http://xmlns.com/foaf/0.1/mbox
minimum = 0; maximum = unlimited
Type of Value = "non-literal"
value URI = mandatory

사람은, 문자열로서 하나의 선택적인 이름과 하나의 선택적인 성을 가질 수 있다. 사람은 접두사 mailto: 와 함께 URI에 의해 반드시 표현되는 이메일 주소를 또한 가질 수 있다. 우리 중 많은 사람들은 하나 이상의 이메일 주소를 가지고 있기 때문에, 우리는 필요한만큼 종종 반복될 수 있도록 이 문장을 허용한다.

우리는 사람(Person) 기술 템플릿이 메타데이터 레코드 내에서 얼마든지 반복되어 사용되는 것을 허용한다. 이것은 사람(Person)도서 기술에 있어서 최대 다섯번까지 저자가 나타날 수 있다는 사실과 상충되어보일 수 있다. 그러나 우리는 레코드 내에서 사람(Person)을 표현하는 데 가능한 다른 방법들을 (예를 들어, 도서의 주제와 같은) 기대한다. 그래서 우리는 일반적으로 레코드 내에서 그 숫자를 제한하지 않기로 정했다.

사람(Person) 기술이 오직 한 사람을 위한 데이터 요소를 포함할 수 있다는 점에 유념하여야 한다. 이것은 또한 저자(author) 문장이 오직 하나의 사람(Person) 값을 가질 수 있음을 의미한다. 만약 두 명의 저자가 있다면, 각 사람을 표현하기 위해 메타데이터 레코드 내에서 두 개의 저자(author) 문장이 필요할 것이다. 본명과 필명과 같이, 한 사람이 한 개 이상의 이름을 가지는 경우를 허용할 수도 있을 것이다; 그러나, 여러 이름을 가진 단일 저자의 경우 (여러 개의 문장 템플릿) 와 여러 명의 저자의 경우 (여러 개의 기술 템플릿) 를 메타데이터는 분명하게 구별할 것이다.

만약 저자(author)가 소속된 기관을 포함하기를 원한다면, 그 기관의 이름과 위치를 포함하는 기관 기술 템플릿을 만들기를 원할 것이다. 그리고 그것은 저자 기술 템플릿으로 연결될 것이다. 기관 이름들과 위치들은, 도서의 출판사와 관련한 정보를 기록하는 등의 다른 용도로 사용될 수도 있을 것이다.

이로써 MyBookCase를 위한 단순 기술 집합 프로파일을 마무리한다; XML에서의 DSP 부호화 버전을 위해 부록 B를 참조하기 바란다.

7. 사용 가이드라인

기술집합프로파일은 어플리케이션 프로파일의 "무엇"을 정의한다; 사용 가이드라인은 "어떻게" 그리고 "왜"를 제공한다. 사용 가이드라인은 메타데이터 레코드를 만드는 사람들에게 지침을 제공한다. 이상적으로, 그들은 각 속성을 설명하며 메타데에터 레코드를 만드는 동안에 반드시 만들어져야하는 결정들을 기대한다. 메타데이터 생성자들을 위한 문서는 DSP에 포함된, 그러나 사람이 더 잘 이해할 수 있는 형태로 몇몇 똑같은 정보들을 나타낸다. 메타데이터를 입력하는 사람들은 다음을 알 필요가 있다: 이 속성이 필요한 것인가? 반복가능한가? 내가 속성과 함께 사용할 수 있는 값들이 제한되는가? 흔히 유저인터페이스는 이러한 질문들에 답변을 줄 수 있다. 예를 들면, 유효한 값들의 목록을 메타데이터 생성자들에게 보여줌으로써.

규칙들과 관련된 몇 예시들은 사용 가이드라인에서 볼 수 있다:

  • 여러 명의 저자들이 있는 저작을 위해서, 저자들의 순서와 얼마나 많이 포함할 것인가 (예, "처음 세 명", 또는 "20명 보다 많지 않게")
  • 어떻게 문서 종류의 규정된 어휘를 해석할 것인가
  • "가장 간단한" 레코드를 위해 최소로 필요되는 요소들
  • 문자열에서 사용되는 (다국어 사용을 위한) 문자 집합, 구두법, 그리고 약어들

상대적으로 간단한 사용가이드라인의 몇몇의 경우에서, 속성의 기술이 DSP 문서와 함께 포함될 지도 모른다. Scholarly Works Application Profile은 안내 설명서가 기술집합프로파일 정의와 나란히 포함된 예이다.

길이나 복합성때문에 매우 복잡한 규칙들을 가질지도 모르는 다른 커뮤니티들은 분리된 문서로서 가장 잘 나타내진다. 예를 들어, 몇몇 도서관에서 가이드라인으로 사용되는 영미 목록 규칙(Anglo-American Cataloguing Rules)은 600페이지짜리 도서[AACR2]에 기록되어있다. 표제와 관련된 사용설명서는 여러 장에 걸쳐 나타나며 많은 페이지에 걸쳐 실려있다. 이러한 길이의 가이드라인은 DSP로부터 분리되어 가장 잘 나타내질 수 있을 것이다.

8. 구문 가이드라인

문서 내에서 묘사되는 기술들은 구문 중립적이다; 즉, 사용된 구문이 DCAP에서 정의된 값과 관계를 완벽히 표현할 수 있는 한, 그 기술들은 특정 기계판독가능한 부호화 구문을 필요로 하지 않는다.

개발자들이 그들의 어플리케이션 프로파일을 소프트웨어 어플리케이션을 기능하는 것으로 바꾸는 것을 돕기 위해서, DCMI는 다양한 부호화 가이드라인을 개발해왔다
[DCMI-ENCODINGS]. 기술집합프로파일은 구체화된 추상모델로의 맵핑을 위한 구체적인 실행 구문을 사용하여 전개될 수 있다. DCMI는 HTML/XHTML, XML, 그리고 RDF/XML에서 DCAM을 기반으로 하는 메타데이터를 부호화하기 위한 가이드라인을 개발해오고 있거나 개발하고 있다; 추후에 다른 것들이 추가될 수도 있다. 결과 데이터 포맷이 기초 표준이나 DCMI 추상모델과 호환이 가능한 한, 다른 종류의 구문의 사용에 제한은 없다.

참고문헌

AACR2
American Library Association and Library Association, Anglo-American Cataloguing Rules, 2nd ed. (London: Library Association, 1978).
CTERMS
더블린코어 컬렉션 기술 용어
<http://dublincore.org/groups/collections/collection-terms/2007-03-09/>
참조 RDF schema <http://dublincore.org/groups/collections/collection-terms/2007-03-09/cldterms.rdf>
COOLURIS
Sauermann, Leo, Richard Cyganiak, eds. Cool URIs for the Semantic Web.
<http://www.w3.org/TR/cooluris/
DCMI-ENCODINGS
DCMI 부호화 가이드라인
<http://dublincore.org/resources/expressions/>
DCMI-MT
DCMI Metadata Terms. January, 2008.
<http://dublincore.org/documents/dcmi-terms/>
참조 RDF schema<http://dublincore.org/2008/01/14/dcterms.rdf>
DCAM
Powell, Andy, Mikael Nilsson, Ambjoern Naeve, Pete Johnston and Thomas Baker. DCMI Abstract Model. DCMI Recommendation. June 2007.
<http://dublincore.org/documents/2007/06/04/abstract-model/>
DCMI-SF
Nilsson, Mikael, Thomas Baker, Pete Johnston. The Singapore Framework for Dublin Core Application Profiles.
<http://dublincore.org/documents/2008/01/14/singapore-framework/>
DSP
Nilsson, Mikael. Description Set Profiles: A constraint language for Dublin Core Application Profiles. March, 2008.
<http://dublincore.org/documents/2008/03/31/dc-dsp/>
ETERMS
Eprints Terms.
<http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Terms>
FOAF
Brickley, Dan, Libby Miller. FOAF Vocabulary Specification 0.91. November, 2007
<http://xmlns.com/foaf/spec/>
FRBR
서지레코드를 위한 기능적 필수요소에 관한 IFLA 연구 그룹 (IFLA Study Group on the Functional Requirements for Bibliographic Records.) (1998). Functional Requirements for Bibliographic Records - 최종보고서(Final Report). Munich: K.G. Saur. 이 링크에서 볼 수 있다<http://www.ifla.org/VII/s13/frbr/index.htm>
미 의회도서관 주제명 표목표 (LCSH)
Library of Congress Subject Headings. In: Library of Congress Authorities and Vocabularies.
<http://id.loc.gov/authorities>
LINKED
Linked Data
<http://linkeddata.org>
RDA-ELEMENTS
<http://metadataregistry.org/schema/show/id/1.html>
RDA-ELEMENTS
<http://metadataregistry.org/schema/show/id/4.html>
RDF
월드와이드웹 컨소시엄 (World Wide Web Consortium). 자원기술프레임워크(Resource Description Framework) (RDF)〈http://www.w3.org/RDF>
RDFS
Brickley, Dan and R.V. Guha, editors. RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation. 10 February 2004.
<http://www.w3.org/TR/rdf-schema/>
RDF-PRIMER
Manola, Frank, Eric Miller. RDF Primer. W3C Recommendation 10 February 2004.
<http://www.w3.org/TR/2004/REC-rdf-primer-20040210/>
RECIPES
Berrueta, Diego, Jon Phipps, eds. Best Practice Recipes for Publishing RDF Vocabularies.
<http://www.w3.org/TR/swbp-vocab-pub/>
RFC3066
Alvestrand, H. Tags for the Identification of Languages. January, 2001.
<http://www.ietf.org/rfc/rfc3066.txt>
SWAP
Scholarly Works Application Profile.
<http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Application_Profile>
UML
Booch, Grady, James Rumbaugh and Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1998.

부록 A : 기술 집합 모델 (DCMI 추상모델)

DCMI 추상모델 [DCAM]의 "기술집합모델"에 따르면, 더블린코어 기술집합은 다음과 같은 구조를 가진다:

  • 기술집합은 하나 또는 그 이상의 기술들로 구성된다.
  • 기술은 구성된다.
    • 0 또는 하나의 기술된 자원 URI와
    • 하나 또는 그 이상의 문장들로
  • 문장은 구성된다.
    • 정확하게 하나의 속성 URI와
    • 정확하게 하나의 값 표현으로
  • 값 표현은 문자 값 표현 또는 문자가 아닌 값 표현 둘 중 하나이다.
    • 문자 값 표현은 구성된다.
      • 정확하게 하나의 값 문자열
    • 문자가 아닌 값 표현은 구성된다.
      • 0 또는 하나의 값 URI
      • 0 또는 하나의 용어 부호화 스킴 URI
      • 0 또는 그 이상의 값 문자열들로
  • 값 문자열은 단일 값 문자열 또는 규정된 값 문자열 둘 중 하나이다.
    • 일반 값 문자열은 값 문자열 언어와 관련이 있을 수 있다.
    • 규정된 값 문자열은 구문 부호화 스킴 URI과 관련이 있다.
  • 문자가 아닌 값은 다른 기술에 의해 묘사될 수 있다.

부록 B:MyBookCase 기술 집합 프로파일

〈?xml version="1.0" encoding="UTF-8"?>
〈DescriptionSetTemplate xmlns="http://dublincore.org/xml/dc-dsp/2008/01/14"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://dublincore.org/xml/dc-dsp/2008/01/14">
DescriptionTemplate ID="Book" minOccurs="1" maxOccurs="1" standalone="yes">
〈StatementTemplate ID="title" minOccurs="1" maxOccurs="1" type="literal">
〈Property>http://purl.org/dc/terms/title〈/Property>
〈/StatementTemplate>
〈StatementTemplate ID="dateCreated" minOccurs="0" maxOccurs="1" type="literal">
〈Property>http://purl.org/dc/terms/created〈/Property>
〈LiteralConstraint>
〈SyntaxEncodingScheme>http://purl.org/dc/terms/W3CDTF〈/SyntaxEncodingScheme>
〈/LiteralConstraint>
〈/StatementTemplate>
〈StatementTemplate ID="language" minOccurs="0" maxOccurs="3" type="nonliteral">
〈Property>http://purl.org/dc/terms/language〈/Property>
〈NonLiteralConstraint>
〈VocabularyEncodingSchemeURI>http://purl.org/dc/terms/ISO639-3〈/VocabularyEncodingSchemeURI>
〈ValueStringConstraint minOccurs="1" maxOccurs="1"/>
〈/NonLiteralConstraint>
〈/StatementTemplate>
〈StatementTemplate ID="subject" minOccurs="0" maxOccurs="infinite" type="nonliteral">
〈Property>http://purl.org/dc/terms/LCSH〈/Property>
〈NonLiteralConstraint>
〈VocabularyEncodingSchemeURI>http://lcsh.info〈/VocabularyEncodingSchemeURI>
〈ValueStringConstraint minOccurs="1" maxOccurs="1"/>
〈/NonLiteralConstraint>
〈/StatementTemplate>
〈StatementTemplate ID="author" minOccurs="0" maxOccurs="5" type="nonliteral">
〈Property>http://purl.org/dc/terms/작성자〈/Property>
〈NonLiteralConstraint descriptionTemplateRef="person"/>
〈/StatementTemplate>
〈/DescriptionTemplate>
〈DescriptionTemplate ID="person" minOccurs="0" standalone="no">
〈StatementTemplate ID="givenName" minOccurs="0" maxOccurs="1" type="literal">
〈Property>http://xmlns.com/foaf/0.1/givenname〈/Property>
〈/StatementTemplate>
〈StatementTemplate ID="familyName" minOccurs="0" maxOccurs="1" type="literal">
〈Property>http://xmlns.com/foaf/0.1/family_name〈/Property>
〈/StatementTemplate>
〈StatementTemplate ID="email" minOccurs="0" type="nonliteral">
〈Property>http://xmlns.com/foaf/0.1/mbox〈/Property>
〈NonLiteralConstraint>
〈ValueURIOccurrence>mandatory〈/ValueURIOccurrence>
〈/NonLiteralConstraint>
〈/StatementTemplate>
/DescriptionTemplate>
〈/DescriptionSetTemplate>

부록 C: 프로파일 내에서 RDF 속성의 사용: 기술적 입문서

모든 어플리케이션 프로파일 기획팀은 RDF를 기초로 하는 메타데이터를 기획하기위한 기초 원리들을 이해하는 사람들을 반드시 포함해야한다. 이 섹션은 어플리케이션 프로파일 내에서의 RDF 속성들의 선택과 사용과 관련된 모델링 선택의 간략한 개요를 제공한다. 이 섹션은 기술적 기획 선택과 관련함으로써 결론짓는다. 속성에 의한 속성 필수요소들은 다음과 같은 요소들과 관련된다:

  • 자유 텍스트가 사용될 것인가 아닌가
  • 자유 텍스트가 사전에 정의된 형식을 따를 필요가 있는가 없는가
  • 유효한 값들이 통제 목록으로부터 선택되어야만 하는가 아는가, 그리고
  • 단일 문자열들로 충분한가 아니면 더 복잡한 값들이 필요한가.

RDF 속성의 기초

RDF 속성들은 그들이 나타나는 문맥의 일관적인 방법으로 참조되고 진행되도록 개발되었다. 예를 들어, 더블린코어 요소인 표제(title)는 기술하는 도서를 위한 하나의 문맥 내에서 그리고 기술하는 상태를 위한 다른 문맥 내에서 사용될 수 있다. 정확하게 사용되고 데이터를 위한 RDF "문법"을 따라 사용될 때, 그렇게 일반적으로 정의된 어휘들은 다양한 출처로부터 일관된 데이터 집합체로 자원기술을 통합하기 위한 기초를 제공한다.

RDF에 기반한 메타데이터에서 사용가능하게 하기위해서는, 속성들은 반드시 통합 자원 식별자(URIs) 에 의해 식별되어야 한다. 예를 들어, 더블린코어 요소 표제(title)는 URI http://purl.org/dc/terms/title 로 식별된다. (여기서는 dcterms:title로 축약). 좋은 실행은 이러한 URI들이 "RDF 속성"으로써 어디서인가 선언되고 상세히 기록되도록 한다. 이 선언은 아마 산문으로 만들어질 것이다. 그러나 전형적으로 기계판독이 가능한 RDF 스킴에서도 만들어지며, 이상적으로는 URI를 위한 인터넷 도메인의 소유자나 URI 를 위해 사용되는 하위도메인에 만들어진다. 예를 들어, dcterms:title을 위한 URI는 돌아가기를 통하여 RDF 스키마로 도달한다. — http://dublincore.org/2008/01/14/dcterms.rdf — 이것은 기계가 이해할 수 있는 방법으로 dcterms:title이 RDF 속성이라는 것을 의미한다. 하위 도메인인 http://purl.org/dc/는 더블린코어 메타데이터 이니셔티브가 소유하는 것이다 ("통제"라는 점에서).

메타데이터 어플리케이션을 개발함에 있어서, 어딘가에서 이미 선언되어오고있는 RDF 속성을 사용하는 것은 많은 이유로써 바람직한 일이다. 최소한 이것은 누군가의 RDF 속성을 선언하는 것과 관련하여 추가 작업을 수행하는 것보다 쉽다. 더욱 중요한 것은, 알려진 속성의 사용이 다른 출처로부터의 메타데이터와의 의미론적 상호호환성을 위한 기초를 제공한다는 것이다. 어휘들을 생성하는 개개인들이 직업을 바꾸고 이직할 수도; 연구 프로젝트는 그들의 일을 종료하고 결국에는 그들의 서버가 사라질수도; 그리고 도메인 이름의 소유권이 소멸할 수도 있음을 기억하여야 한다. 그리하여 최근에 RDF 스키마로 연결되어지는 URI들이 아마 지금으로부터 10년 후에는 신발 광고로 연결될 수도 있을 것이다. 관리를 하겠다고 천명한 기관들에 의해서 지원를 받는 속성들을 사용하는 것이 가장 좋은 방법이다.

RDF 속성 의미론

RDF 속성은 보통 자연어 정의로 제공된다. 어플리케이션 프로파일의 개발자들은 그들의 정의와 호환가능한 방법으로 속성을 사용해야함에 유의해야만 한다. 개발자들은 기술적인 제약들을 속성을 사용하는 데에 추가할수도 있고 (반복성과 같은) 또는 특정 목적들을 위한 정의의 좁은 의미의 해석을 더 많이 제공할 수도 있다. 그러나 그것들을 유지하는 사람들에 의해 의도된 속성들의 의미와 상충되어서는 안된다.

속성의 계획된 의미는 단지 자연어 정의에 의할 뿐만 아니라 다른 속성으로의 주어진 속성의 공식적으로 선언된 관계에 의해 결정된다. 정의는 일반적으로 형식 "도메인" (속성에 의해 기술될 수 있는 것들의 종류)과 "범위" (값들이 될 수 있는 것들의 종류)로 구체화된다. 이러한 추가적인 정보는 기술하는 데에 사용되는 것들에 대한 가능한 추론들에 의해 RDF 속성의 유용을 개선한다. 예를 들어, 속성 foaf:img (이미지)는 foaf:Person의 도메인과 foaf:Image의 범위를 가진다. 그래서 메타데이터 소비 어플리케이션이 속성 foaf:img를 사용한 메타데이터를 찾았을 때, 이 속성과 함께 기술되는 것들이 사람이고 속성에 의해 추론된 값이 이미지라는 것을 자동적으로 추론할 수 있다. 예를 들어, 속성 dcterms:abstract는 dcterms:description의 하위속성인데, 이는 어떤 것이 초록 (abstract) 을 갖고 있다면 그것은 또한 기술 (description) 을 갖고 있다는 것을 의미한다.

어플리케이션 프로파일에서 재사용되는 속성들의 목적을 위해서, 속성들이 문자인 값들과 사용되도록 의도되었는지 아닌지를 확인하는 것은 특히 중요하다. 문자인 값들과 사용되도록 의도된 속성이라면—즉, 정의에 의한 값들은 아마 하나의 값 문자열로 구성될 것이다, 언어 태그 ("보통 값 문자열"에서) 또는 데이터타입 식별자 ("규정된 값 문자열"에서)는 선택적으로 향상된 - "문자" 범위를 가지고 있다고 일컬어진다. "문자" 범위의 속성들의 예시들은 rdfs:Literal으로, 그리고 owl:DatatypeProperty로써 정의된 foaf:firstName으로 선언된 dcterms:date이다. "문자" 범위의 속성들의 장점은 간단함이다. 메타데이터는 보통 또는 규정된 값 문자열을 전한다—그리고 메타데이터 소비 어플리케이션은 그것들을 기대한다. 동시에 이것은 메타데이터를 간단하게 부호화하고 간단하게 처리한다.

"문자"값 이외의 다른 것을 가지는 속성은 "문자가 아닌" 범위를 가진다고 한다. "문자가 아닌" 범위를 가지는 속성의 예는 dcterms:LicenseDocument 범위를 가지는 dcterms:license와, foaf:OnlineAccount범위를 가지는 foaf:holdsAccount를 포함한다. 문자범위의 속성이 처리할때 간단하기는 하지만, 문자가아닌 범위의 속성은 더욱 유연하고 확장가능하다. 기술적인 메타데이터에서, 문자값은 "터미널" (종료점이라는 점에서)을 구성한다; 값 문자열 "Mary Jones"는 그 자체로 Mary Jone라는 사람의 확장된 기술을 위한 시작점이 될 수 없다. 반대로, 문자가 아닌 값은 Mary Jones라는 사람에 관한 정보의 추가적인 조각들을 더할 수 있는 고리를 가진다. 예를 들면 그녀의 이메일주소, 공공기관, 생일. 잠재적으로, 문자가 아닌 값들은 다음과 같은 것들의 어떤 조합에 의해서든지 표현될 수 있다:

  • 보통 또는 규정된 값 문자열 (DCMI 추상모델에서의 값 문자열) —그리고 영어, 불어 그리고 일본어로 표현된 표제의 경우에서 단지 하나가 아닌 동시에 잠재적으로 몇 개.
  • 값 자원을 식별하는 URI (Value URI).
  • 값이 하나의 구성원인 곳에서 열거된 집합(또는 통제어휘)를 식별하는 URI (Vocabulary Encoding Scheme URI).

문자 범위와 문자가 아닌 범위의 속성들 사이의 차이점은 첫째로 모델링 문제임에 주목하여야 한다. 속성의 종류는 어떻게 메타데이터가 교환을 위한 기계 처리가 가능하게 부호화하고 메타데이터를 사용하는 어플리케이션에 의해 어떻게 해석될 것인지를 결정한다. 최종 사용자들이 차이점을 반드시 알아야 할 필요는 없다. 검색결과에서 값 문자열이 표시될 때, 그것이 직접적으로 문자값 또는 문자가 아닌 값에 덧붙여진 값 문자열이든지 아니든지에 상관없이 문자 문자열은 같게 보인다.

존재하는 속성을 사용할 때, 문자와 문자가 아닌 범위 사이에서의 선택은 보통 공식 정의에 의해 강제될 것이다. 만약 강제된 선택이 충분하지 않거나 (예, dcterms:date 속성은 문자 범위를 가지며 더욱 복합적인 값이 필요된다), 만약 필요한 시맨틱을 가지는 속성이 어디에서도 찾아질 수가 없다면, (새로운 URI를 가지는) 새로운 속성이 반드시 만들어져야한다.

새로운 RDF 속성 만들기

정의에 의하면, 더블린코어 어플리케이션 프로파일은 어디에선가 정의되어온 속성을 "사용한다" — 즉, 프로파일 자체의 밖 어딘가. 만약 잘 알려진 어휘 가운데에서 원하는 속성을 찾을 수 없다면, 어플리케이션 프로파일 개발자들은 그들 스스로 그것을 선언해야할 필요가 있다.

그 자체 내에서 새로운 속성을 선언하는 것은 어려운 일이 아니다. 정의를 공식화하는 이름을 주는 누군가는 문자 또는 문자가 아닌 범위를 가지는 것을 결정하며, 접근을 가지는 네임스페이스 하 (그리고, 예를 들면, http://microsoft.com 또는 http://amazon.de의 하위가 아닌) 의 속성을 위한 URI를 만든다. DCMI 속성을 식별하기 위한 http://purl.org와 같은 서비스들은 일시적인 위치에 있는 문서로 주소를 바꾸는 것이 가능한 "불변의" URI를 제공한다. RDF 어휘를 생성하고 발표하기 위한 안내는 "시맨틱 웹을 위한 좋은 URI" [COOLURIS]와 RDF Primer [PDF-PRIMER], "RDF 어휘들을 발표하기 위한 최고의 기술 방법" [RECIPES] 에서 찾을 수 있다. 모범 활용 예들은 DCMI 메타데이터 용어집 [DCMI-MT], 더블린코어 컬렉션 기술 용어집 [CTERMS], 그리고 Eprints 용어집 [ETERMS]를 포함한다. 또한 용어들은 RDF 스키마로 발표되는 것이 좋은 실천이다. 예를 들어, DCMI 메타데이터 용어집 [DCMI-MT]와 더블린코어 컬렉션 기술 용어집 [CTERMS]와 일치하는 스킴들을 보기 바란다.

문자 또는 문자가 아닌 범위를 할당하는 것은 간단함과 확장성 사이에서 선택이 필수적이다. 값 문자열 혼자서는 날짜 ("2008-10-31")나 표제 ("Gone with the Wind")를 기록하기 위해 충분하지만, 저자를 위해서는 아마 이름 뿐만 아니라 더 많은 것들을 기록해야할 필요가 있을 것이다. 의심쩍을 때에는, 문자가 아닌 범위를 할당하는 것이 현명하다. 예를 들어, 저자의 경우에는 문자가 아닌 범위가 이메일주소, 기관, 생일을 위한 또는 누군가의 기관 밖에 있는 저자의 기술을 가리키기 위한 URI를 사용하기 위한 고리를 제공한다. 왜냐하면 그들은 URI (즉, "문자열로서"가 아닌 "URI로서의" URI의 사용), 문자가 아닌 값들은 전세계적인 유효 식별자들을 사용하여 상호참조되는 링크된 메타데이터 기술의 목표를 달성하는 데에 중요하다.

사용자 정의 데이터 필수요소들을 개발 결정으로 번역하기

우리는 이제 잠재적인 값들과 관련된 각각의 잠재적인 속성과 관련하여 데이터 콘텐츠 전문가들에 의해 질문된 궁금증들에 답변을 해줄 수 있다.

자유 텍스트를 사용하기를 원하는가? "자유 텍스트" (즉, 문자들의 문자열)는 DCMI 추상모델에서 값 문자열이라고 불리며, 문자 또는 문자가 아닌 범위의 속성을 가지고 사용될 수 있다. 몇몇 경우에 있어서는, 예를 들어 여러 언어들로 표현된 값들의 경우, 하나의 문장에 병렬로 여러 개의 값 문자열을 사용할 필요가 있다는 점에 주의해야 한다. 이것은 오직 문자가 아닌 범위의 속성들과 함께 이루어질 수 있다.

자유 텍스트가 미리 정의된 형식을 따를 필요가 있는가? 만약 그렇다면, 값 문자열이 의미론적 부호화 스킴 (데이터타입)과 함께 사용될 수 있다.

단일 값 문자열들이 충분한가? 아니면 복합요소들과 함께 더욱 복합적인 구조가 필요한가(또는 잠재적인 요구)? 만약 값을 위해 단일 값 문자열보다 더 많은 것이 필요하다면, 사용된 속성은 반드시 문자가 아닌 범위를 가져야만 한다. 만약 우연히 여러분이 적당한 자연어 정의, 그러나 잘못된 범위를 가진 속성을 발견했다면, —예를 들어, 더욱 한정하는 문자 범위를 가진— 여러분은 문자가 아닌 범위를 가지는 정의를 사용하고 고유 URI를 가지는 여러분 자신의 속성을 만들 필요가 있을 것이다.

값을 식별하고 값의 기술을 가리키기 위한 URI를 사용하기를 원하는가? DCMI 추상 모델은 값 문자열과 분리된 구문론적인 구조로서 값 URI를 정의한다. 값 URI는 문자 값을 기술하기 위해 사용될 수 없다; 그들은 반드시 문자가 아닌 범위를 가지는 속성들과 함께 사용되어야만 한다. 물론 값 문자열로서 URI를 기록하는 것은 가능하다—아무튼 URI는 문자열—그러나 이것에 기초하여 메타데이터를 사용한 어플리케이션은, 식별자로서 그러한 문자열을 다른 문자열로부터 구별하는 안정적인 방법을 가지지 못한다.

통제된 목록으로부터 유효값을 선택하기를 원하는가? 만약 그렇다면, 다음과 같은 것들이 가능하다:

  • 텍스트 문자열의 간단한 목록은 기술집합프로파일 내에서의 사용 가이드라인으로써 비공식적으로 문서화될 수 있다.
  • 텍스트 문자열의 간단한 목록은 많은 어플리케이션 프로파일에서 인용이 가능하고 사용이 가능한 목록을 만드는 URI와 함께, 구문론적 부호화 스킴(SES, 또는 데이터타입)으로써 더욱 공식적으로 정의될 수 있다.
  • 문자열의 목록은 아마 콘셉트의 목록을 위한 라벨로서 해석될 것이다. 이것은 어휘 부호화 스킴(VES)라고 불린다. SES에 목록된 개별 텍스트 문자열과는 다르게 VES의 개별 콘셉트는 아마 URI를 사용하여 식별될 수도 있다는 점에 주목하라.
  • 만약 값의 목록이 이미 어딘가에서 사용가능하며 이미 구문론적 부호화 스킴 또는 용어 부호화 스킴으로써 식별되어져오고 있다면, 적절한 모델링 구성을 가진 URI를 사용하여야 한다.
  • 만약 값의 목록이 이미 어딘가에서 사용가능하지만 아직 SES 또는 VES로써 식별되지 않는다면, 당신은 어떤 모델이 더 잘 맞는가를 해석할 필요가 있다. 때때로 해석은 어느 쪽이든 방어가 가능하다. 어떤 방법을 여러분이 결정하든간에, 여러분이 부호화 스킴을 위해 만든 URI가, 메타데이터 내에서 애매함을 피하기 위하여, 어느 한 쪽으로는 분명하게 선언되어야 한다는 점은 중요하다.
  • 만약 여러분이 (목록되지 않은 값들의 사용을 허용하는 것과 반대로) 고정된 리스트로 유효값의 집합을 제한하고 싶다면, 이 제한은 기술집합프로파일 내에서 선언되고 문서화될 수 있다.

일반적으로, 통제된 목록과 같이 공식적으로 정의된 값들의 사용은 메타데이터에 정확성을 더한다. 그래서 자동화 과정을 위한 적합성을 증가시킨다. 적절한 SES와 VES의 사용은 이것을 위해 중요한 단계이다. 그러나, 점점 RDF 용어 Simple Knowledge Organization System [SKOS]를 사용한 통제된 용어들 내에서 URI가 개별 용어에 할당되고 있다. 예를 들어, 미 의회도서관 주제명 표목표에서의 "월드와이드웹"의 개념은 최근에 URI http://id.loc.gov/authorities/sh95000541#concept에 할당되어오고 있다. 통제 어휘들이 점점 "SKOSified"되어감에 따라, 이러한 용어들을 사용해서 오픈 웹에 있는 많은 출처들로부터 자원들로의 접근을 찾고 통합시키는 것이 쉬워지고 있다. VES 구성은 값 문자열만로부터 VES URI를 가진 값 문자열로, 그리고 거기서부터 값 URI (VES URI를 가지는 혹은 갖지 않는)로 변화를 유연하게 포함할 수 있다.