추상모델

생성자 :
Andy Powell
UKOLN, University of Bath, UK
Mikael Nilsson
KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden
Ambjorn Naeve
KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden
Pete Johnston
UKOLN, University of Bath, UK
발행일자 :
2005-03-07
식별자 :
http://dublincore.org/documents/2005/03/07/abstract-model/
대체함 :
http://dublincore.org/documents/2005/01/31/abstract-model/
대체됨 :
해당사항 없음
최신 버전 :
http://dublincore.org/documents/abstract-model/
문서의지위 :
DCMI 권고안.
해설 :
이 문서는 더블린코어 메타데이터 기술을 위한 추상 모델을 설명한 것이다.

차례

  1. 서론
  2. 더블린코어 추상 모델
  3. 기술, 기술집합, 레코드
  4. 덤다운(Dumb-down)
  5. 부호화 지침
  6. 전문용어
    참고문헌
    감사의 글
    부록 A - 구조적인 값에 관한 주석
    부록 B - 추상 모델과 RDF
    부록 C - 추상 모델과 XML
    부록 D - 추상 모델과 XHTML

1. 서론

이 문서에서는 더블린코어 메타데이터 [DCMI]에 대한 추상 모델을 구체적으로 제시하고 있다. 이 문서의 주된 목적은 비교 가능한 특정한 DC 부호화지침에 대한 참조 모델을 제공하기 위한 것이다. 참조 모델이 체계적으로 기능하기 위해서는 어떤 특정한 부호화 구문과는 독립적일 필요가 있다. 이러한 참조 모델을 통해서 부호화하고자 하는 각종 기술을 더 잘 이해하게되고, 상이한 구문 간에 원활한 변환이나 매핑개발을 촉진하게 될 것이다.
이 문서는 더블린코어 메타데이터를 지원하는 소프트웨어 어플리케이션 개발자와 더블린코어 메타데이터용으로 새로운 구문 부호화 지침을 개발하는 일을 담당하고 있는 사람들, 그리고 더블린코어에 기반한메타데이터 어플리케이션 프로파일을 개발하는 사람들을 주된 대상으로 하고 있다.

2. 더블린코어 추상 모델

더블린코어 메타데이터 기술로 기술되는 자원의 추상 모델은 다음과 같다.

  • 개개의 자원은 0이거나 하나 이상의 속성/값의 짝으로 되어 있다.
  • 각각의 속성/값 짝은 하나의 속성과 하나의 값으로 구성되어 있다.
  • 개개의 값은 자원이다(자원을 기술하기 위해 속성이 사용될 때 이 속성과 관련된 물리적 혹은 개념적 개체).
  • 개개의 자원은 하나 이상의 클래스의 성원이다.
  • 개개의 속성과 클래스는 선언된 특정한 의미를 지닌다.
  • 각 클래스는 관계를 더 구체화함으로써(하위관계로) 다른 클래스와 관련을 가질 수 있다(여기서 하위 클래스의 성원인 모든 자원은 동시에 관련된 클래스의 성원이 되는 것과 마찬가지로, 두 개의 클래스는 어떤의미를 공유하게 된다).
  • 각 속성은 관계를 더 구체화함으로써(하위속성으로) 다른 속성과 관련을 가질 수 있다(여기서 자원이 하위속성에 의해 값과 연결될 때는 언제나 이 두 개의 속성은 어떤 의미를 공유하게 되고, 동시에 이 자원은그 속성에 의해 동일한 값과 관련을 가지게 된다).

더블린코어 메타데이터 기술의 추상 모델은 다음과 같다.

  • 기술은 하나 이상의 문장(단 하나의 자원에 관한)과 그리고 0이거나 하나의 자원 URI(기술대상자원을 식별하는 URI 참조)로 구성되어 있다.
  • 각 문장은 속성/값의 짝을 구체적으로 설명한 것으로, 속성 URI(속성을 식별하는 URI 참조)와 영이거나 하나의 값 URI(속성 값을 식별하는 URI 참조), 영이거나 하나의 어휘 부호화 체계 URI(값의 클래스를식별하는 URI 참조), 그 값에 대해 영이거나 그 이상의 값 표현으로 구성되어 있다.
  • 값 표현은 값 문자열이나 다양한 표현 형식을 취할 수 있다.
  • 개개의 값 문자열은 속성 값인 자원을 표현한 간단하면서도 육안으로 식별할 수 있는 문자열이다.
  • 각각의 값 문자열은 구문 부호화 체계를 식별하는 관련된 구문 부호화 체계 URI를 가질 수 있다.
  • 각각의 값 문자열은 ISO 언어태그(예를 들어 en-GB)인 관련된 값 문자열 언어를 가질 수 있다.
  • 각각의 다양한 표현은 속성 값인 자원을 표현한 것으로 일종의 마크업 텍스트와 이미지, 비디오, 일종의 오디오 등이거나 또는 이들의 결합이다.
  • 각각의 값은 독립적인 관련 기술의 주제일 수 있다.

위에서 이탤릭체로 사용된 단어와 구에 대해서는 다음의 전문용어 절에서 정의하고 있다. 이 모델에 관하여 지적해 두고 싶은 여러 가지 사항은 다음과 같다.

  • 관련 기술은 관련된 자원을 기술한 것이며 따라서 기술의 일부가 아니다. 예를 들어 관련 기술은 기술된 자원의 저자인 인물에 관한 메타데이터를 제공할 수 있다.
  • 구문 부호화 체계는 어느 면에서는 '데이터유형'(datatype)으로도 알려져 있다.
  • 각각의 자원은 하나 이상의 클래스의 성원일 수 있다. 자원이 값인 경우 그 클래스를 어휘 부호화 체계라고 한다는 점을 유의할 필요가 있다.
  • 더블린코어 메타데이터 기술에서 기술대상인 자원의 클래스는 일반적으로 DC Type 속성의 값으로 제시된다.

자원과 기술에 대한 더블린코어 추상 모델을 그림 1과 2에서 UML 클래스 도표로 표현하였다.

fig1

그림 1 : 더블린코어 자원 모델

fig2

그림 2 : 더블린코어 기술 모델

UML 클래스 도표와 친숙하지 않은 사람은 블록 화살표의 끝에 오는 행을 '이다'(영어에서는 'is'나 'is a'로)로 읽어야 하고(예를 들어 '어휘 부호화 체계는 클래스이다'), 블록 다이아몬드로 시작하는 행은 '포함하고있다'('contains a')거나 혹은 '가지고 있다'로 읽어야 한다는 점을 유의해야 한다(예를 들어 '문장은 속성 URI를 포함하고 있다'). 그 밖의 관계는 레이블로 적절히 제시되어 있다. 4각형으로 분명하게 표현된 클래스는 위의추상 모델을 텍스트로 기술할 때 명시적으로 언급하지 않았지만 부록 A에서 다루고 있다. 여기에 사용된 UML 모델링은 추상 모델을 보여주고 있지만 더블린코어 소프트웨어 어플리케이션 개발에 필요한 적절한 기반을구축하고자 하는 의도는 아니라는 점을 유의하기 바란다.

3. 기술과 기술 집합, 레코드

위에서 설명한 추상 모델에서는 개개의 더블린코어 메타데이터 기술이 단 하나의 자원을 기술하고 있음을 보여주고 있다. 이것을 흔히 1대 1의 원칙이라고 한다.

그런데 실세계의 메타데이터 어플리케이션에서는 느슨하게 연결된 기술 집합에 기반하는 경향이 있으며(여기서 기술대상 자원은 일반적으로 몇 가지 방법으로 관련되어 있다), 여기서는 이것을 기술 집합이라고 한다.예를 들어 기술 집합은 그림과 화가 양쪽 모두의 기술을 포함할 수 있다. 더 나아가 대개의 경우 기술 집합은 기술 집합 자체에 관한 기술을 포함하기도 한다[때로는 '관리자 메타데이터'('admin metadata') 혹은'메타-메타데이터'('meta-metadata')라고도 한다].

소프트웨어 어플리케이션 상호 간에 교환을 목적으로 더블린코어 부호화 지침 중(XHTML 메타 태그, XML, RDF/XML 등) [DCMI-ENCODINGS]하나의 지침에 따라 메타데이터 레코드 형식으로 기술 집합을 구체적으로 제시하였다..

이 문서에서는 다음과 같이 기술 집합과 더블린코어 메타데이터 레코드를 정의하고 있다.

  • 기술 집합은 하나 이상의 자원에 관한 하나 이상의 일련의 기술이다.
  • 더블린코어 메타데이터 레코드는 더블린코어 부호화 지침 중(XHTML 메타 태그, XML, RDF/XML 등) 하나의 지침에 따라 구체적으로 제시된 기술 집합이다.

4. 값

더블린코어 메타데이터의 값은 자원을 기술하기 위해 사용된 속성과 관련된 물리적, 개념적 개체이다. 예를 들어 DC Creator 속성의 값은 사람이나 기관, 서비스와 같은 물리적 개체이다. DC Date 속성의 값은시점이나 시간대와 같은 추상적인 개체이다. DC Coverage 속성의 값은 지역이나 국가와 같은 물리적 개체이다. DC Subject 속성의 값은 개념적 개체인 개념일 수 있고, 또는 물리적 개체인 물리적 대상이나 사람일 수 있다.이들 개체 각각은 하나의 자원이다.

값 URI를 사용하여 값을 식별할 수 있는데, 값은 하나 이상의 값 문자열이나 다양한 표현으로 표현될 수 있으며, 이 값은 어떤 관련 기술을 가질 수 있으나 이 값은 자원이다.

5. 덤-다운(Dumb-down)

'간략' DC와 '확장' DC라는 개념이 더블린코어 문서와 공개토론 과정에서 폭 넓게 사용되고 있다. 그런데 이들 용어의 용법에 다소간 차이가 있기 때문에 이 문서에서는 이들 용어가 의미하는 관점을 확실하게제시하지는 않았다. 그러나 일반적으로 말하면 '간략 DC'라는 말의 의미는 각 문장이 값 문자열만을 수록하고 있고, 부호화 체계와 요소 세목을 사용하지 않은 DC 메타데이터를 지칭할 때 사용되며, 반대로 '확장 DC'라는말은 여기서 설명한 추상 모델의 모든 자질을 사용한 메타데이터를 지칭하는 데 사용된다.

확장 DC를 간략 DC로 변환하는 과정을 일반적으로 '더밍-다운'(dumbing-down)이라고 한다. 더밍-다운 과정을 속성 덤-다운과 값 덤-다운의 두 부분으로 구분할 수 있다. 나아가 두 가지 방법 중의 하나로 이 두 가지과정을 각각 적용할 수 있다. 덤-다운 알고리즘을 수행한 소프트웨어가 특정한 더블린코어 메타데이터 어플리케이션에서 사용되는 값과 속성 관계에 관한 지식을 알고 있는 경우에 정교한 덤-다운이 일어난다. 그리고 사용된속성과 값에 대해 덤-다운 알고리즘을 수행하는 소프트웨어가 사전 지식이 없는 경우에 불완전한 덤-다운이 일어나게 된다.

이와 같은 분석에 기반하여 다음과 같이 '덤-다운 알고리즘' 행렬을 개관할 수 있다.

Rights
  요소 덤-다운 값 덤-다운
불완전한 덤-다운 더블린코어 메타데이터 요소 집합 [DCMES]이 아닌 속성을 식별하는 속성 URI를 포함한 어떤 문장도 무시하라. 값 URI(제시된 경우)나 값 문자열을 새로운 값 문자열로 사용하라. 관련된 어떤 기술이나 다양한 표현도 무시하라. 어떤 부호화 체계 URI도 무시하라.
정교한 덤-다운 인정된 속성으로 확인될 때까지 하위속성 관계를 반복해서 분석하고, 문장에 포함된 기존의 속성 URI 대신 해당 속성의 속성 URI로 대치하라. 인정되는 속성이 확인되지 않는 경우에는 그 문장을 무시하라(대부분의경우 요소 세목이 아닌 속성이 오면 이 과정은 중단된다). 새로운 값 문자열을 작성하기 위해 다양한 표현 및 관련된 기술, 또는 값 문자열에 관한 지식을 사용하라.

하위속성 관계를 자동으로 분석하기 위해 RDF 스키마 언어 [[DC-RDFS]에 표현된 더블린코어 용어 선언과 DC XML 이름공간 URI[DC-NAMESPACES], 그리고 적절한 더블린코어 부호화 지침(XHTML 메타 태그, XML, RDF/XML,등)[DCMI-ENCODINGS]을 사용해야 한다는 점을 유의하기 바란다.

소프트웨어가 복수의 기술을 포함한 기술 집합을 더밍-다운하는 경우, ‘더 단순한’ 기술(원래의 기술 집합에 있는 기술마다 하나의 단순한 기술)을 다수 작성하거나 아니면 하나의 ‘간략’ 기술(이 경우 원래의 기술 집합에서어떤 기술이 ‘주된’ 기술인지를 결정해야 한다)을 작성할 수 있다. 이것은 특정한 어플리케이션에 적용되는 결정이다.

6. 부호화 지침

특정한 부호화 지침(HTML 메타 태그와 XML, RDF/XML 등)[DCMI-ENCODINGS]에서는 위에서 설명한 추상 모델의 모든 관점을 부호로 표현할 필요는 없다. 그러나 부호화 지침을 제공하고 있는 더블린코어 권고사항에서는 이더블린코어 추상 모델을 참조해야 하며 이 모델의 어떤 부분을 부호로 표현하였고 어떤 부분을 부호로 표현하지 않았는지를 제시해야 한다. 특히 부호화 지침에서는 자원 URI와 값 URI를 부호로 표현하는 기법을 제시해야한다. 추상 모델에서는 http://purl.org/dc/terms/URI 이라는 구문 부호화 체계와 관련된 값 문자열을 값 URI로 취급해야 하는지 아니면 자원 URI로 취급해야 하는지를 제시하지 않고 있다는 점을 유의할 필요가 있다. 부호화지침에서는 이 모델이 지닌 이러한 특성을 부호화하기 위한 기법을 분명하게 제시해야 한다. 아울러 부호화 지침에서는 어떤 문장과 관련된 다양한 표현이나 관련 기술을 레코드 내에 내장할 것인지 아니면 별도의 레코드에부호로 표현하고 URI 참조를 사용하여 이 레코드와 연결할 것인지를 제시해야 한다.

다음의 부록 B와 C, D에서는 추상 모델과 RDF/XML, XML, XHTML 부호화 지침과를 간략하게 비교한 내용을 제시하고 있다.

7. 전문용어

이 문서에서는 다음과 같은 용어를 사용하고 있다.

클래스(class)
클래스는 속성과 행동, 관계, 의미를 공유한 성원으로 구성된 그룹으로서 일종의 범주이다.
클래스 URI(class URI)
클래스 URI는 클래스를 식별하는 URI 참조이다.
기술(description)
기술은 단 하나의 자원에 관한 하나 이상의 문장으로 구성되어 있다.
기술 집합(description set)
기술 집합은 하나 이상의 자원에 관한 하나 이상의 일련의 기술이다.
요소(element)
더블린코어에서 요소는 일반적으로 속성과 동의어로 사용되고 있다. 그러나 지적하고 싶은 것은 요소라는 단어는 흔히 XML 문서에서 구조적인 마크업 구성요소를 지칭하는 데에도 사용된다는 점이다.
요소 세목(element refinement)
좁은 의미에서 보면 요소 세목은 특정한 더블린코어 속성의 의미를 공유하고 있는 자원의 속성이다. 요소 세목이 속성이기 때문에 관련된 속성과는 독립적으로 메타데이터 기술에 사용될 수 있다. 실제로 더블린코어에서요소 세목은 바로 하나의 더블린코어 부모 속성을 더 상세하게 설명한 것이다.
부호화 체계(encoding scheme)
부호화 체계는 어휘 부호화 체계와 구문 부호화 체계에 대한 일반적인 명칭이다.
부호화 체계 URI(encoding scheme URI)
어휘 부호화 체계 URI나 구문 부호화 체계 URI에 대한 일반적인 명칭
마크업 텍스트(marked-up text)
HTML이나 XML, 기타 마크업(예를 들어 TeX)을 포함한 문자열로서 속성값과 연결되어 있다.
속성(property)
속성은 자원을 기술하기 위해 사용된 특수한 관점이나 특성, 성질이나 관계이다.
속성 URI(property URI)
속성 URI는 하나의 속성을 식별하는 URI 참조이다.
속성/값의 짝(property/value pair)
속성/값의 짝은 자원을 기술하기 위해 사용된 속성과 값의 조합이다.
한정어(qualifier)
현재 한정어는 특별히 요소 세목이나 부호화 체계를 지칭하는 용어에 대해 사용되는 일반적인 명칭이다.
레코드(record)
레코드는 더블린코어 부호화 지침(XHTML 메타 태그와 XML, RDF/XML 등) 중 하나를 적용하여 실례를 들어 설명한 기술 집합이다.
관련 기술(related description)
관련 기술은 기술대상 자원과 관련된 자원에 관한 기술이다.
자원(resource)
독자성을 지닌 것이라면 어떤 것이라도 자원이다. 흔히 볼 수 있는 예로는 전자문서와 이미지, 서비스(즉 "로스 엔젤리스의 오늘의 기상상황"), 기타 자원의 집서 등 이 포함된다. 모든 자원이 네트워크에서 "검색가능한" 것은 아니다. 예를 들어 사람이나 기업체, 개념, 도서관에 소장된 제본 도서 등도 자원으로 취급될 수 있다.
자원 URI(resource URI)
자원 URI는 하나의 자원을 식별하는 URI 참조이다.
다양한 표현(rich representation)
속성 값과 관련된 일종의 마크업 텍스트와 이미지, 비디오, 때로는 오디오 등(혹은 이들이 합성된 것)
문장(statement)
문장은 속성 URI(속성을 식별하는 URI 참조)와 0 혹은 하나의 값 URI(속성 값을 식별하는 URI 참조), 영이나 하나의 어휘 부호화 체계 URI(값의 클래스를 식별하는 URI 참조), 영이나 그 값의 여러 가지 값 표현으로구성되어 있다.
구조적 값(structured value)
구조적 값은 다음과 같은 것에 대한 일반 명칭이다.

  • 기계분석이 가능한 구성요소(그리고 이 구성요소를 문자열 내에 부호화하는 방법을 제시한 관련된 구문 부호화 체계를 가진 구성요소)를 포함한 값 문자열
  • 일종의 마크업 텍스트
  • 관련 기술

구문 부호화 체계(syntax encoding scheme)
구문 부호화 체계는 "2000-01-01"과 같이 날짜를 표현하는 표준인 공식적인 기호 체계에 따라 값 문자열이 포맷되었음을 지시한다.
구문 부호화 체계 URI(syntax encoding scheme URI)
구문 부호화 체계 URI는 구문 부호화 체계를 식별하는 URI 참조이다. 더블린코어에서 권고한 모든 부호화 체계에 대해서는 부호화 체계명과 해당 이름공간 URI을 http://purl.org/dc/terms/이름공간 URI을 연계하여 URI참조를 작성하게 된다.
용어(term)
속성(즉 요소와 요소 세목)과 어휘 부호화 체계, 구문 부호화 체계 또는 제어어휘집(개념공간)에서 취한 개념에 대한 일반 명칭
용어 URI(term URI)
용어를 식별하는 URI 참조에 대한 일반 명칭
값(value)
값은 자원을 기술하기 위해 사용될 때 속성과 관련된 물리적, 개념적 개체이다.
값 URI(value URI)
값 URI는 속성 값을 식별하는 URI 참조이다.
값 표현(value representation)
값 표현은 그 값을 표현한 것(즉 값을 대표하는 것)이다.
값 문자열(value string)
값 문자열은 속성 값을 표현한 간단한 문자열이다. 일반적으로 값 문자열은 어떤 마크업 텍스트도 포함해서는 안된다.
값 문자열 언어(value string language)
값 문자열 언어는 값 문자열의 언어를 지시한다.
어휘 부호화 체계(vocabulary encoding scheme)
어휘 부호화 체계는 미국국회도서관 주제명표와 같은 제어어휘집(혹은 개념공간) 에서 취한 속성 값을 지시하는 클래스이다.
어휘 부호화 체계 URI(vocabulary encoding scheme URI)
어휘 부호화 체계 URI는 어휘 부호화 체계를 식별하는 URI 참조이다. 더블린코어에서 권고한 모든 부호화 체계에 대해서는 부호화 체계명과 해당 http://purl.org/dc/terms/ 이름공간 URI을 연계하여 URI 참조를 작성하게된다.

참고문헌

DCMI
Dublin Core Metadata Initiative
http://dublincore.org/
UML
The Unified Modeling Language User Guide
Grady Booch, James Rumbaugh and Ivar Jacobson, Addison-Wesley, 1998
DCTERMS
DCMI Metadata Terms
〈[원문보기]〉
DCMES
Dublin Core Metadata Element Set, Version 1.1: Reference Description
〈[원문보기]〉
DCMI-ENCODINGS
DCMI Encoding Guidelines
〈[원문보기]〉
DC-RDFS
DCMI term declarations represented in RDF schema language
http://dublincore.org/schemas/rdfs/
DC-NAMESPACES
Namespace Policy for the Dublin Core Metadata Initiative (DCMI)
〈[원문보기]〉

감사의 글

이 문서의 이전 판에 대한 검토와 관련하여 베이커씨와 헤리씨, DC 이용국 회원, DC 아키텍처 실무진들에게 감사드린다.


부록 A - 구조적 값에 대한 설명

이 부록에서는 작성 당시 DC 메타데이터 어플리케이션에서 사용된 바와 같이, '구조적 값'을 다루고 있다.
기존의 여러 DC 메타데이터 어플리케이션에서는 비교적 복잡한 '값 표현'(즉 단순히 간단한 문자열이 아닌 표현)을 부호화하고자 시도하였다. 이러한 시도에서는 이것을 느슨한 표현인 '구조적 값'이라는 말로 사용하였다.일반적으로 사용해 왔던 여러 다양한 종류의 구조적 값을 확인할 수 있을 것이다. 다음과 같은 네 가지 값을 볼 수 있다. 이 중에서 처음 두 가지는 구조적인 값의 정의에 따라 값을 정의한 기존의 부호화 체계라는 점에서더블린코어에서 권고되고 있다. 나머지 두 개는 현재 권고되지는 않고 있으나 메타데이터 어플리케이션 전반에 걸쳐 전 세계적으로 상당히 많이 사용되고 있는 것으로 판단된다.

레이블이 있는 문자열(Labelled strings)

이것은 분명히 레이블이 있는 구성요소를 포함한 문자열이다. 이와 같은 종류의 구조적인 값의 예로는 다음과 같은 것이 포함된다.

DCSV

DCSV와 이를 바탕으로 구축된 더블린코어의 각종 구문 부호화 체계 - 시대, 지역, 박스이다. 시대에서 DCSV를 사용한 예는 다음과 같다.

<meta name="dc:date" scheme="dcterms:W3CDTF" content="2003-06-10" />

vCard

예를 들면 다음과 같다.

<meta name="dcterms:temporal" scheme="dcterms:Period" content="start=Cambrian period; scheme=Geological timescale; name=Phanerozoic Eon;" />

vCard는 현재 더블린코어에서 권장하는 부호화 체계가 아니라는 점을 유의하기 바란다.

레이블이 없는 문자열(Unlabeled strings)

이것은 문자열 내에 묵시적으로 구성요소를 포함한 문자열로서, 예를 들면 이 구성요소는 오로지 문자열 내에서의 위치에 따라 결정된다. 이와 같은 구조적 값의 예로는 다음과 같은 것이 포함된다.

W3CDTF

대부분의 DC 메타데이터에서 사용되는 일자-시간 포맷으로서, 예를 들면 다음과 같다.

<meta name="dc:date"
scheme="dcterms:W3CDTF"
content="2003-06-10" />

마크업 텍스트(Marked-up text)

이것은 ‘표현상’ 혹은 다른 마크업을 포함한 문자열로서, 예를 들면 문단 나누기와 어깨글자, dc:description에 대한 화학적/수학적 마크업 등이다. 다음과 같이 다양한 종류의 마크업을 특징지을 수 있다.

  • HTML버전에 기반한 마크업.
  • CML과 MathML과 같이 XML 기반 언어에 기초한 기타 마크업.
  • TeX와 같은 XML 이외의 마크업 언어.

관련된 자원 기술(Related resource descriptions)

이것은 두 번째 자원(즉 DC 기술로 기술되는 자원이 아닌)을 기술한 메타데이터 기술이다. 예를 들면 dc:creator의 값과 연결된 관련 기술은 자원의 저자에 관한 완전한 기술을 포함할 수 있다(생일이나 눈의 색깔, 원한다면기호음료를 포함해서).
과거 ‘관련된 자원 기술’에서는 XML이나 vCard(위 참조), 혹은 DCMES 속성의 여러 ‘세목’을 개발하여 부호화하는 경향이 있었다(예를 들면 DC.Creator.Address). DC(아래 참조)를 RDF/XML로 부호화하게 되면 복수의 노드를RDF 그래프로 연계함으로써 관련된 메타데이터 레코드를 더 완전하게 모형화할 수 있다.

요약문

위에서 개관한 범주는 완전한 것이 아니며 이들 범주 간에는 분명 중복되는 부분이 있다. 예를 들어 레이블이 있는 문자열을 XML 이외의 마크업 언어 유형으로 볼 수도 있다. 게다가 마크업 텍스트(예컨대 MathML)를 관련된자원 기술로 볼 수도 있다.
그럼에도 불구하고 여기서 사용한 범주화의 목적은 현재 DC 메타데이터 어플리케이션에서 사용되는 복잡한 메타데이터 구조의 용법을 분석하기 위한 것이다. 여기서 제안하고 있는 추상 모델이라는 점에서 보면, 위에서개관한 모든 유형의 구조화된 값은 다음과 같이 더블린코어 추상 모델의 일부를 이루고 있다.

  • 레이블이 있는 문자열은 관련 기술로 취급되어야 한다(비록 DCSV와 이를 기반으로 구축된 각종 더블린코어 구문 부호화 체계(시대나 지역, 박스와 같은)는 현재 적절한 구문 부호화 체계와 함께 값 문자열로 부호화되고있다)
  • 레이블이 없는 문자열은 적절한 구문 부호화 체계와 함께 값 문자열로 취급되어야 한다.
  • 마크업 텍스트는 다양한 표현으로 취급되어야 한다.
  • 관련된 자원 기술은 관련 기술로 취급되어야 한다.

부록 B - 추상 모델과 RDF

이 부록에서는 더블린코어 추상 모델과 자원기술 프레임워크(RDF) 간의 관계에 대해 검토하고 있다.

현재 RDF는 이용 가능한 부호화 구문이란 점에서 더블린코어에 가장 풍부한 부호화 환경을 제공하고 있다. 따라서 여기서 설명한 추상 모델을 RDF 모델과 어떻게 비교되는지를 간략하게 살펴보고자 한다.

이렇게 비교하는 의도는 DC 메타데이터 레코드를 RDF로 부호화하는데 필요한 완전하고도 상세한 기술을 제공하고자 하는 것이 아니다. 그 대신 DC를 RDF에서 사용하기 위한 세 가지 간단한 예를 검토하기 위한 것이다.

사례 1: dc:creator

creator table case1
그림 3에서는 간단한 RDF 그래프(그리고 이 그래프를 표현하고 있는 RDF/XML 문서)를 보여주고 있다. 이 그래프는 하나의 속성(dc:creator)을 가진 자원을 보여주고 있다. 이 속성 값은 두 번째(공백) 노드로서 이자원의 저작자를 표현한 것이다. 이 두 번째 공백 노드는 여러 가지 속성을 가지는데, 저작자를 기술하기 위해 사용되었으며, 아울러 dc:creator 속성에 대한 값 문자열을 제공하기 위해 사용된 rdfs:label을 기술하기 위해사용되었다. figure3
그림3
그림 4에서는 동일한 정보를 두 개의 그래프로 구분하여 보여주고 있다. 이 경우 저작자를 기술한 관련기술은 독립된 RDF/XML 문서에 옮겨진 자원 기술과 더 분명하게 구분되어 있음을 볼 수 있다. 이렇게 하기 위해서 값을 표현하는 노드에는 값 URI가 배정되었는데, 이렇게 함으로써 두 개의 RDF/XML 문서에 있는 두 개의 노드는 동일한 사물을 표현한 것으로 볼 수 있다. figure4
그림4

사례 2: dc:subject

creator table case2
그림 5에서는 두 번째 간략 RDF 그래프(그리고 이 그래프를 표현한 RDF/XML 문서)를 제시하고 있다. 이 그래프는 하나의 속성(dc:subject)을 지닌 자원을 보여주고 있다. 이 속성의 값은 두 번째(공백) 노드로서, 그 자원의 주제를 표현한 것이다. 이 두 번째 공백 노드는 dc:subject 속성에 대한 값 문자열을 제공하기 위해 사용된 rdfs:label 속성을 가지고 있으며, 분류기호를 제공하기 위해 사용된 rdf:value 속성과 부호화 체계 URI를 제공하기 위한 rdf:type 속성을 가지고 있다. figure5
그림5
그림 6에서는 동일한 정보를 독립된 두 개의 그래프로 제시한 것이다. 이 경우 주제를 기술한 관련 기술은 독립된 RDF/XML 문서에 옮겨진 자원 기술과 더 분명하게 구분되어 있음을 볼 수 있다. 이렇게 하기 위해서 값을 표현한 노드에 값 URI를 배정하였으며, 이렇게 함으로써 두 개의 RDF/XML 문서에 있는 두 개의 노드는 동일한 사물을 표현한 것으로 볼 수 있다.

두 번째 RDF/XML 문서에 있는 관련 기술은 rdfs:seeAlso 속성과 RDF/XML 문서 URI을 사용하여 첫 번째 RDF/XML 문서와 연결되어 있다. 엄밀히 말해서 이런 방식으로 두 개의 그래프를 구분할 필요는 없다는 점에 유의하기 바란다. 그림 5에서와 같이 두 번째 그래프를 첫 번째 그래프의 하위 그래프로 표현하는 것도 완전히 타당한 것이다. 그러나 이 문서의 목적 상 기술과 관련 기술을 분명하게 구분하기 위해서 이 두 개의 그래프를 구분한 것이다. 어떤 경우에는 이렇게 구분하는 것이 좋은 방안일 수 있다. 예를 들면 일종의 용어 서비스에서 두 번째 그래프를 제공하기 위한 경우이다.

figure6
그림6

사례 3: dc:description

creator table case3
그림 7에서는 세 번째 간략 RDF 그래프(그리고 이 RDF를 표현한 RDF/XML 문서)를 보여주고 있다. 이 그래프는 하나의 속성(dc:description)을 지닌 자원을 보여주고 있다. 이 속성 값은 dc:description 속성에 대한 값 문자열을 제공하기 위해 사용된 rdfs:label 속성을 가진 두 번째(공백) 노드이다. 이 두 번째 노드 역시 다양한 표현과 연결된 rdfs:seeAlso 속성을 가지고 있는데, 이 경우 기술의 다양한 표현을 제공하는 HTML 마크업 텍스트이다.

마크업 텍스트를 하나의 RDF 그래프에 내장할 수 있다는 점에 유의하기 바란다(rdf:parseType="Literal"을 사용하여). 그러나 여기에는 제시하지 않았다.

figure7
그림7

요약

description
사례 2(그림 6)의 두 번째 그림을 다시 보면 위의 추상 모델에 사용된 용어가 RDF 그래프 위에 다른 층으로 제시될 수 있다.

비록 이 문서를 작성할 시점에서는 기술 집합을 가장 잘 처리하기 위한 몇 가지 문제를 더 해결할 필요가 있긴 하지만 더블린코어 추상 모델의 거의 모든 관점은 RDF 부호화 지침에서 지원되고 있다.

figure8
그림8

부록 C - 추상 모델과 XML

이 부록에서는 더블린코어 추상 모델과 더블린코어 권고사항인 ‘더블린코어를 XML로 구현하기 위한 지침’(Guidelines for implementing Dublin Core in XML )과를 비교하고 있다.

간략 DC


figure9
그림9

그림 9에서는 위의 XML 지침에 따라 부호화된 간략한 DC 기술의 예를 보여주고 있다. 이 사례에서는 부호화가 속성 URI와 더블린코어 추상 모델의 값 문자열, 값 문자열 언어 부문을 어떻게 지원하는가를 보여주고 있다. 이러한 구문으로 부호화된 모든 값은 비록 육안으로 봐서는 마치 URI처럼 보이긴 하지만 값 문자열로 표현된다는 점을 유의해야 한다.

확장 DC


figure10
그림 10

그림 10에서는 위의 XML 지침에 따라 부호화된 확장 DC 기술의 예를 보여주고 있다. 이 예에서는 더블린코어 추상 모델의 속성 URI와 값 문자열, 값 문자열 언어, 부호화 체계 URI, 자원 클래스를 부호화가 어떻게 지원하고 있는가를 보여주고 있다. 아울러 유의할 점은 비록 자원 클래스가 제시되어 있긴 하지만 이 클래스의 URI는 이 기술의 어디에도 부호화되지 않았다는 점이다.

요약

다음과 같은 더블린코어 추상 모델의 양상이 권고사항인 ‘더블린코어를 XML로 구현하기 위한 지침’(Guidelines for implementing Dublin Core in XML)에서 지원되고 있다.

  • 속성
  • 속성 URI
  • 값 문자열
  • 값 문자열 언어
  • 부호화 체계
  • 부호화 체계 URI
  • 자원 클래스

다음과 같은 제한점이 적용되었다.

  • 자원 URIs
  • 값 URIs
  • 다양한 표현
  • 관련 기술
  • 속성/하위속성 관계
  • 자원 클래스 URIs

다음과 같은 제한점이 적용되었다.

  • 각 속성은 하나의 값 문자열을 가질 수 있다(그러나 둘 이상은 불가능하다)
  • 어휘 부호화 체계와 구문 부호화 체계는 정확히 동일한 방식으로 처리된다.

작성 시점에서 자원 URI나 값 URI 어느 것도 XML 부호화 구문에서 명시적으로 부호화 될 수 없다는 점을 유의하기 바란다. 비록 일부 소프트웨어 어플리케이션에서 http://purl.org/dc/terms/URI이라는 구문 부호화 체계를 선정하여 값 문자열에 있는 URI가 자원 URI나 값 URI라는 점을 지시하는 것으로 해석되는 경우가 있지만 이것은 모든 경우에 메타데이터 레코드를 정확히 해석한다고 보증하기 어렵다.

부록 D - 추상 모델과 XHTML

이 부록은 더블린코어 추상 모델과 더블린코어 권고사항인 ‘HTML/XHTML 메타와 연결 요소에서 더블린코어 표현방법’(Expressing Dublin Core in HTML/XHTML meta and link elements)과를 비교한 것이다.

간략 DC


figure11
그림 11

그림 11에서는 위의 XHTML 지침에 따라 부호화된 간략 DC 기술의 예이다. 이 예에서는 더블린코어 추상 모델의 속성 URI와 값 문자열, 값 문자열 언어, 값 URI 양상을 부호화를 통해 지원하는 방법을 제시하고 있다. 다시 지적하고 싶은 것은 이 부호화 구문에서 표현된 DC 식별기호 속성 값은 비록 육안으로는 URI처럼 보일지라도 값 문자열로 부호화된다는 점이다.

확장 DC


figure12
그림 12

그림 12에서는 위의 XHTML 지침에 따라 부호화된 확장 DC 기술의 예를 보여주고 있다. 이 예에서는 더블린코어 추상 모델의 속성 URI와 값 문자열, 값 문자열 언어, 값 URI, 부호화 체계 URI, 자원 클래스 양상을 부호화를 통해 지원하는 방법을 제시하고 있다. 비록 자원의 클래스가 제시되어 있긴 하지만 이 클래스의 URI는 이 기술의 어디에도 부호화되지 않고 있다는 점을 유의할 필요가 있다. 마지막으로 비록 http://purl.org/dc/terms/URI 구문 부호화 체계가 의미하는 것은 소프트웨어를 통해서 DC 식별기호 값 문자열을 URI로 분명하게 해석할 수는 있긴 하지만 이것을 자원 URI로 해석해서는 안된다는 점을 유의할 필요가 있다.

요약

다음과 같은 더블린코어 추상 모델의 관점을 더블린코어 권고사항인 ‘HTML/XHTML 메타와 연결 요소에서 더블린코어 표현방법’(Expressing Dublin Core in HTML/XHTML meta and link elements)과 비교한 것이다.

  • 속성
  • 속성 값
  • 값 문자열
  • 값 문자열 언어
  • 값 URIs
  • 부호화 체계
  • 부호화 체계 URI
  • 자원 클래스

다음과 같은 더블린코어 추상 모델의 관점은 지원되지 않는다.

  • 자원 URI
  • 다양한 표현
  • 관련 기술
  • 속성/하위속성 관계
  • 자원 클래스 URI

다음과 같은 제한점이 적용되었다.

  • 각 속성은 하나의 값 문자열(둘 이상은 불가)이나 값 URI를 가질 수 있으나 두가지 모두를 가질 수 없다.
  • 어휘 부호화 체계와 구문 부호화 체계는 정확히 동일한 방식으로 처리된다.

작성 시점에서 자원 URI는 XHTML 부호화 구문에서 분명하게 부호화되지 않을 수 있다는 점에 유의할 필요가 있다. 그러나 자원 URI는 그 레코드가 내장된 자원의 URI로 묵시적으로 제시된다.