어플리케이션 프로파일의 검토를 위한 표준

어플리케이션 프로파일의 검토를 위한 표준

작성자 :
DCMI 용어관리 위원회
발행일d :
2009-03-02
식별자 :
http://dublincore.org/documents/2009/03/02/profile-review-criteria/
대체함 :
http://dublincore.org/documents/2009/01/05/profile-review-criteria/
최근 버전 :
http://dublincore.org/documents/profile-review-criteria/
문서의 지위 :
이것은 DCMI 권고안이다.
설명 :
이 문서는 어플리케이션 프로파일의 검토를 위하여 DCMI 용어관리 위원회에서 사용되는 범주를 명시한다.

1. 평가의 대상

다음의 가이드라인은 DCMI 용어관리 위원회가 어플리케이션 프로파일을 검토하는 범주를 밝히고 있다. 2008년 3월 현재, 이러한 심사 범주를 위한 참고자료의 가장 중요한 포인트는 더블린코어 어플리케이션 프로파일을 위한 싱가포르 프레임워크[SINGAPORE-FRAMEWORK], 추상 모델[DC-AM], 그리고 기술집합프로파일 기술 초안[DC-DSP]이다. 어플리케이션 프로파일의 모범적인 활용의 예는 용어관리위원회에 의해 검토된 더블린코어 컬렉션 어플리케이션 프로파일 [DC-CAP]과 Eprints 어플리케이션 프로파일[EPRINTS]을 포함한다.

어플리케이션 프로파일은 메타데이터의 더 넓은 재사용을 촉진하기 위한 메타데이터 어플리케이션을 기술하는 문서(또는 문서의 집합)이다. 좋은 프로파일은 다음과 같은 항목들에 유용하게 사용될 수 있도록 충분한 세부사항과 맥락을 제공한다.

  • 여러 출처들로부터의 메타데이터를 통합할 필요가 있는 정보 제공자들, 그리고
  • 같은(또는 비슷한) 메타데이터를 사용한 어플리케이션을 만들기를 원하는 개발자들.

어플리케이션 프로파일은 다음과 같은 항목들을 문서화한다:

  • 어플리케이션의 목적과 범위,
  • 어플리케이션의 기능적인 필수요소들,
  • 어플리케이션에 의해 기술되는 독립체의 데이터 모델, 그리고
  • 용어에 대한 제약들과 함께, 어플리케이션 내에서 클래스와 속성들을 상세하게 기술하는 기술집합프로파일

이러한 요소들의 일부는 "필수"로 고려될 수도 있는 반면, 다른 것들은 간단히 "권유"된다. 문서화가 의미적으로 명확하고 내부적으로 일관되게 하기 위하여, 최우선되는 필수사항이 있다.

2. 평가의 영역

2.1. 어플리케이션의 목적과 범위

어플리케이션의 목적과 범위는 '반드시' 기술되어져야 한다. 문서화는 '반드시' 다음과 같은 질문들에 답할 수 있어야 한다.

  • 어플리케이션 프로파일이 사용되는(또는 사용될 수 있는) 맥락에 대한 기술이 있는가?

문서화는 '반드시' 다음과 같은 질문들에 답할 수 있어야 한다.

  • 어플리케이션 프로파일을 위해 대상이 되는 이용자 그룹이 식별되고 기술되는가?
  • 그리고 프로파일의 개발에 참여하는 기관들과 개개인들이 식별되고 기술되는가?
  • 프로파일의 추후 개발과 유지와 관련하여 조정, 가이드라인, 또는 의도 등이 기술되었는가?

2.2. 어플리케이션을 위한 기능적인 필수요소들

문서화는 '반드시' 이용자의 요구에 따라 어플리케이션의 기능을 기술해야한다. 이러한 기능적인 필수요소들은 "find", "identify" 또는 "select"와 같은 일반적인 기능들로써 정의되어야 하지만, 더욱 구체적일 수도 있다.

다음과 같은 질문은 필수적이다:

  • 기능적인 필수요소들이 정의되었는가?

2.3. 도메인 모델

만약 독립체를 기술하고 독립체 사이의 관계를 기술하는 간단한 것이라면, 어플리케이션 프로파일은 '반드시' 데이터 모델을 제공해야한다. 데이터 모델은 그래픽 형태 (예, UML 클래스 다이어그램과 같은) 또는 텍스트 내에서 묘사될 수 있다. 어플리케이션 프로파일은 외부적으로 정의된 데이터 모델에 기초할 수 있다. 데이터 모델에 관해서, 다음과 같은 질문들에 대답해야만 한다:

  • 모델이, 기술되어야하는 독립체 집합과 그 독립체들 사이의 관계를 묘사하는가?
  • 만약 어플리케이션 프로파일이 외부적으로 정의된 데이터 모델을 사용한다면:
    • 외부적 데이터 모델이 식별되는가?
    • 외부적으로 정의된 데이터 모델로부터의 변형이 문서화되는가?

2.4. 기술 집합 프로파일

기술 집합 프로파일은 "템플릿"과 "제약"에 관해서 메타데이터 레코드를 구체화한다 [DC-DSP]:

  • 기술 템플릿은 기술된 자원에 관련하여 제약들을 위한 그리고 기술 내에 만들어진 모든 문장들을 위한 컨테이너이다. (DCMI 추상모델 내에서, 기술은 하나 그리고 단 하나의 자원에 대하여 적용된다).
  • 문장 템플릿은 특정 문장 내에서 적용되는 모든 제약들을 위한 컨테이너이다. (DCMI 추상모델 내에서, 문장은 속성 URI와 값 표현으로 구성된다.)
2.4.1. 도메인 모델의 독립체를 위한 기술 템플릿

만약 도메인 모델이 오직 한 종류의 자원을 가진다면 (예, "도서"), DSP 문서 내에 있는 모든 문장들은 그 자원과 관련된 것으로 여겨질 수 있다. 공식적인 용어들에서, 기술 템플릿은 암묵적인 형태로 나타나며, 그러한 것으로서 분명하게 레이블을 붙일 필요는 없다.

만약 도메인 모델이 하나 이상의 기술된 독립체 (예, "저자"와 "도서")를 가진다면, 메타데이터는 각 독립체를 위한 분리된 기술을 가질 필요가 있다. 따라서, 기술 집합 프로파일은 반드시 분리되고 명확하게 범위가 정해진 구역을 제공해야만 한다 (기술 템플릿).

기술 템플릿의 헤더 또는 도입부는 반드시 다음과 같은 정보를 제공해야한다:

  • [필수] 이 기술 내에 기술된 자원들의 클래스(또는 클래스들)는 instance 가 될 수 있다. (예, foaf:Person, 또는 http://xmlns.com/foaf/0.1/Person) (자원 종류 멤버쉽 제약).
  • [선택] 메타데이터 레코드에서 기술을 식별하기 위해 사용된 문자열.
  • [선택] 템플릿에 기초한 기술들이 홀로 존재할 수 있는가에 대한 표시. (예, "저자는 기술된 도서가 없다면 기술되지 못할 것이다.")
  • [선택] 하나의 기술 집합 내에서, 이러한 종류의 기술이 최소/최대 몇 번 나타날 수 있는가.
2.4.2. 기술 템플릿 내의 문장 템플릿

문장 템플릿은 전형적으로 메타데이터 내에서 각각의 "사용된 용어들"을 위한 작은 표로 표현된다. 이것은 어떻게 이러한 용어들이 사용되는지 (기수, 부호화 스킴 등과 함께)에 대한 정보가 "목록 규칙" 또는 사용 가이드라인에 덧붙여 표현된다.

이러한 표들은 다음과 같은 정보를 포함할 수 있다:

  • [선택] 이러한 종류의 문장은, 둘러싸는 기술 내에서 최소 그리고 최대 몇 번 나타날 수 있는가.
  • [선택] 문장 내에서 허용되는 값 표현의 종류 (문자/비문자).

이러한 표들은 다음과 같은 속성 제약 중 하나를 반드시 포함해야한다:

  • [선택] 속성 목록 제약: 문장 내에서 사용되도록 허용된 속성들의 목록 (하나의 멤버만 가질 수도 있다) (URI 또는 축약된 URI로 주어지는, 예, 'dcterms:creator' 또는 'http://purl.org/dc/terms/creator').
  • [선택] 하위 속성 제약: 어떤 하위 속성의 속성이 사용될 것이다; 이 제약은 흔하지 않다.

단일 기술 템플릿 내에서, 속성 제약은 문장 내의 속성 URI가 최대 하나의 문장 템플릿 내에서 속성 제약과 일치할 수 있는 것과 같은 방법으로 반드시 구성되어야 한다. 예를 들어, 같은 속성을 나타내는 속성 목록 제약을 가지는 각각의 두 개의 문장 템플릿을 가지는 것은 허용되지 않는다.

문자 값 제약을 정의하는 문장 템플릿: 만약 문자열(즉, 문자)만이 값으로서 허용된다면, 문장은 문자 값 표현에 의해 나타내지는 문자 값과 관련하여 정의될 수 있다. 허용되는 제약들은 ("문자 값 표현"에서) 다음을 포함한다:

  • [선택] "동물, 야채, 광물..."과 같은 문자의 목록 (문자 목록 제약).
  • [선택] 문자에 관한 언어 지표들이 "의무", "선택" 또는 "허용되지않음" 중 어느 하나인가.
  • [선택] 어떤 언어들이 문자를 위해 허용되는가의 지표.
  • [선택] 문자를 위한 구문 부호화 스킴이, "의무", "선택" 또는 "허용되지않음" 중 어느 하나인가.
  • [선택] 구문 부호화 스킴 목록 제약: URI에 의해 식별되는 허용된 구문 부호화 스킴의 목록

문자가 아닌 값 제약을 정의하는 문장 템플릿: 허용되는 제약들은 (문자가 아닌 값 표현에서) 다음을 포함한다:

  • [선택] 값을 표현하는 데에 사용될 수도 있는 기술 템플릿의 식별자 (기술 템플릿 참고자료).
  • [선택] 클래스 멤버십 제약: (URI에 의해 식별되는) 값의 종류 리스트는 예시일 것이다.
  • [선택] 값 URI와 관련된 제약들: 값 URI는 "허용되지않음", "선택" 또는 "의무" 중의 하나.
  • [선택] 값 URI 목록 제약: 값 URI로서 허용된 URI들의 목록.
  • [선택] 어휘 부호화 스킴 생성 제약: 어휘 부호화 스킴은 "허용되지않음", "선택" 또는 "의무" 중의 하나.
  • [선택] 어휘 부호화 스킴 목록 제약: 어휘 부호화 스킴으로서 허용된 URI들의 목록.
  • 값 문자열 제약들
    • [선택] 최소 생성 제약: 이러한 종류의 값 문자열들이 둘러싸는 문장에서 최소 몇 번 나타날 수 있는가.
    • [선택] 최대 생성 제약: 이러한 종류의 값 문자열들이 둘러싸는 문장에서 최대 몇 번 나타날 수 있는가.
2.4.3. 전체로서의 템플릿과 제약

템플릿과 제약 (혹은 기술적으로 동등한 것들) 전체에 관련하여, 검토자들은 반드시 다음 질문을 해야 한다:

  • 기술 템플릿과 문장 템플릿에 나타난 제약들이 도메인 모델의 내용을 반영하는가?
  • 문장 템플릿에 나타난 제약들이 소유자에 의해 제공되는 속성들의 정의와 일치하는가?
    • 검토자들은 속성 제약 내에서 선언된 속성들이 문자 영역 혹은 문자가 아닌 영역으로 선언되었는지를 확인하고, DSP 에서 사용되는 것과 모순되는 것은 모두 지적해 내야 한다.

기술 집합 프로파일 내에 포함된 모든 정보가 위에 묘사된 유형에 들어맞는 것은 아니다. 그런 정보는 "주석"으로 간주될 수 있는데, 이는 공식적인 의미에서는 기술집합 프로파일 밖에 놓여지는 사용자 지침이 될 것이다. 이러한 종류의 정보 위해서 검토자는 반드시 다음과 같은 내용을 질문해야한다:

  • 권고되는 용어의 사용이 용어 소유자에 의해 제공되는 정의와 일치하는가?
  • 기술 집합 프로파일에서 이러한 용어들의 사용이, 선언된 의미론과 일치하는가?

2.5. 기술 집합 프로파일에서 참조된 메타데이터 용어들

검토자의 일은 기술 집합 프로파일에서 "사용된 용어들"을 확인하고 DCMI 추상 모델에 기초한 메타데이터 내의 사용을 위해 용어들이 적합한지를 검사하는 것이다. 적합성을 위해서, 용어들은 '반드시' DCMI 추상 모델 내에 정의된 역할을 포함하는 "메타데이터 용어"의 네 가지 종류 중 하나여야 한다: (요소로도 알려져있는) 속성, 클래스, 어휘 부호화 스킴 (VES), 그리고 구문 부호화 스킴 (SES). 다음과 같은 질문들은 알려진 유형에 주어진 용어가 맞는 지를 검사한다:

  • 1. DCMI 추상 모델은 속성, 클래스, SES, 그리고 VES의 예들이, 통합 자원 식별자(URIs) 로서 식별되는 것을 필수로 하고 있다. 용어가 "적절한" URI로 할당되어왔는가 (아래 논의를 보시오)? 만약 아니라면, 용어는 RDF 문장에서 인용될 수 없으며, 그러므로 용어는 DCMI 추상모델에 기초한 메타데이터에서 사용가능하지않다.
  • 2. 용어가 RDF 스키마 또는 다른 형태의 문서화에서 다음 중 하나로 분명히 선언되어졌는가?

질문에 있는 용어가 이러한 네 가지 종류 중 하나로 분명하게 정의된 것이 아니라면, DCMI 추상모델에 기초한 메타데이터에서 승인된 기능을 가지지 않는다.

2.5.1. 논의

RDF 스키마에서의 선언. RDF 스키마들은 "RDF 어휘 기술 언어 1.0: RDF 스키마" [RDFS]와 DCMI 추상모델 [DC-AM]과 같은 표준 사양에 의해 정의된 유형에 주어진 용어들이 어떻게 맞는지를 선언한다. 예시 스키마는 DCMI 메타데이터 용어집 [DCMI-TERMS], SKOS 어휘집 [SKOS-VOCABULARY], 그리고 RDF 어휘 기술 언어 (RDF 스키마) 그 자체 [SKOS-VOCABULARY] 를 포함한다. 예를 들어, 용어 "출판사(Publisher)"는 DCMI 메타데이터 용어집을 위한 RDF 스키마[RDFS-VOCABULARY]에서 "RDF 속성"으로 선언된다. 이는 다음과 같다:

<rdf:Description rdf:about="http://purl.org/dc/terms/publisher">
<rdfs:label xml:lang="en-US">Publisher</rdfs:label>
<rdfs:comment xml:lang="en-US">An entity responsible for making the
resource available.</rdfs:comment>
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
...
</rdf:Description>

모범 사례 RDF 스키마. 잘 선언된 용어들의 모범 사례 예시는 DCMI 메타데이터 용어집 [DCMI-TERMS], 더블린코어 컬렉션 기술 용어집 [DC-CDT], 그리고 Eprints 용어집 [EPRINTS-TERMS]이다. 용어들은 또한 반드시 RDF 스키마 내에서 선언되어야 한다. (예, DCMI 메타데이터 용어집[DCMI-TERMS-RDF]. 그리고 더블린코어 컬렉션 기술 용어집 [DC-CDT-RDF].

RDF 스키마를 가능하게 하기. W3C 문서인 "RDF 어휘집을 출판하기 위한 모범 사례 방법" [RECIPES]은 용어 URI로부터 이러한 용어를 기술하기 위해 사용된 RDF 스키마를 다시 향하게 하는데에 어떻게 HTTP redirects (돌아가기) 가 사용되어야만 하는지를 기술한다. 문서에서 기술되어진 것처럼, 이상적으로 HTML 웹페이지 또는 브라우저 선호도 ('text/html' 또는 'application/rdf+xml')에 기초한 콘텐츠 협상을 통한 용어 선언의 RDF 스키마 표현을 제공하기 위해 설정되는 서버들에서 RDF 스키마가 반드시 이용가능해야한다..

"적절한" URI. 관례상, 어플리케이션 프로파일의 생성 동안에 만들어진 새로운 용어들은 'http://example.org'라는 도메인 이름을 사용한 일시적인 URI에 종종 할당된다. 'http://example.org' URI가 용어 선언을 결정하는 데에 만들어질 수 없으므로, 그와 같은 일시적인 URI들은 메타데이터가 기반이 될 수 있는 적절한 URI와 반드시 교환되어야 한다. "적절한" URI는 용어의 생성자가 그러한 URI를 만드는 것에 권한을 부여받은 도메인 하에 있는 URI이다.

용어의 종류와 그에 따른 하위클래스. 위에 나열되어 있는 클래스들의 하위클래스로서 정의되는 용어의 종류는 DC-AM에 기초한 메타데이터에서 사용될 수 있다 -- 예, 웹 온톨로지 언어로부터 [OWL]:

http://www.w3.org/2002/07/owl#Class

http://www.w3.org/2000/01/rdf-schema#Class 의 하위클래스이고

http://www.w3.org/2002/07/owl#ObjectProperty

http://www.w3.org/1999/02/22-rdf-syntax-ns#Property의 하위속성이다. .

2.6. 구문 가이드라인

구문 선택과 데이터 형식과 관련된 가이드라인은 선택적으로 어플리케이션 프로파일 내에서 제공될 수 있다. 만약 그러한 자료들이 제공된다면, 검토자는 기술집합프로파일에서 표현된 제약들을 선택된 구문(또는 구문들)이 지원하는지 아닌지를 반드시 확인해야한다. 예를 들어, 만약 주어진 부호화 구문이 DC-AM 구성 어휘 부호화 스킴 URI을 지원하지 않고, 어휘 부호화 스킴 URI와 관련된 제약들이 기술집합 프로파일에서 정의된다면, 검토자는 이러한 모순을 반드시 알려야한다. 검토자들은 기술집합프로파일이 데이터 형식에서 직접적으로 표현되는 것이 아니라, 변형의 방법(예, GRDDL)에 의한 표현이 가능하다는 점을 반드시 고려해야한다.

검토자는 다음과 같은 사항들을 반드시 질문해야한다:

  • 어플리케이션 프로파일이 구문과 관련된 지침을 제공하는가 (스키마의 형태이든 인간이 읽을 수 있는 이용자 가이드라인의 형태이든지간에) ?
  • 만약 맞다면, 구문이 어플리케이션 프로파일에서 사용된 DC-AM 독립체들을 분명하게 지원하는가?

참고자료

DC-CAP
Dublin Core Collections Application Profile, 9 March 2007.

DC-CAP-REVIEW
DCMI Usage Board Review of Collections Application Profile, 20 July 2007.

DC-CDT
Dublin Core Collection Description Terms, 9 March 2007.

DC-CDT-RDF
RDF schema for Dublin Core Collection Description Terms, 9 March 2007.

DC-DSP
Nilsson, Mikael. Description Set Profiles: A constraint language for Dublin Core Application Profiles.

DC-AM
Powell, Andy, Mikael Nilsson, Ambjörn Naeve, Pete Johnston, Thomas Baker. DCMI Abstract Model.

DCMI-TERMS
DCMI Metadata Terms.

DCMI-TERMS-RDF
RDF schema for http://purl.org/dc/terms/.

EPRINTS-TERMS
Eprints Terms.

OWL
Web Ontology Language (OWL) Reference Version 1.0.

RDFS
RDF Vocabulary Description Language 1.0: RDF Schema.

RDFS-VOCABULARY
RDF schema for RDF Vocabulary Description Language (RDF Schema)

RECIPES
Best Practice Recipes for Publishing RDF Vocabularies.

SINGAPORE-FRAMEWORK
Nilsson, Mikael, Thomas Baker, Pete Johnston. The Singapore Framework for Dublin Core Application Profiles.

SKOS-VOCABULARY
SKOS Core Vocabulary Specification.

변경 내역

2009년 3월 2일. 2009년 1월 28일의 결의안에 따라, 2.4.2 부분의 "값 표현의 종류"의 첫번째 항목 부분에서 임의(optionality)가 "의무"에서 "선택"으로 수정되었다.2009년 2월 26일 결의안에 따라, 공유된 속성 목록 제약을 가진 복합 문장 템플릿의 확인과 관련된 문장이 추가되었다.