Logo

목차   이전 장 : 3. 해석    다음 장 : 5. 어플리케이션

 

4. 데이타 모델

 

이 장은 DOI® 시스템의 두 번째 주요 기술 요소인 DOI® 데이터 모델의 기초와 기존의 메타데이터 체계를 통해서 할당된 DOI 이름 메타데이터의 상호운용성을 보장하는 DOI 데이터 모델의 기능에 대해서 설명한다. 이 장은 DOI 시스템의 개요를 제공하고, DOI 데이터 모델 정책의 목적(상호운용성과 양질의 관리)과 메타데이터 시스템의 3가지 도구(커널 메타데이터, 데이터 사전, 메타데이터 교환을 위한 스키마)에 대해서 언급한다. 독자들은 이장과 함께 어휘 집 을 참조하길 바란다.

© 국제 DOI재단   •   최종 갱신 : 2013년 8월 12일

 

4.1 DOI® 데이터 모델의 개요
4.2 DOI 데이터 모델 정책의 목적
      4.2.1 상호운용성
      4.2.2 관리 능력
4.3 DOI 메타데이터
      4.3.1 DOI® 메타데이터 커널
      4.3.2 DOI 커널의 사용
      4.3.3 DOI 메타데이터 스키마의 관리를 위한 절차
            4.3.3.1 통제된 커널 어휘에 값 추가하기
            4.3.3.2 갱신 절차
      4.3.4 DOI 데이터 사전
      4.3.5 어휘 매핑 프레임워크(VMF)
      4.3.6 메타데이터 통합 : IDF의 목적
4.4 메타데이터 요구사항, ISO 26324
4.5 기반 온톨로지

 

4.1 DOI® 데이터 모델의 개요

메타데이터 없이, 식별자는 그 가치가 매우 작다. 이 상황에서 메타데이터는 식별된 대상체에 대한 정보로서 정의될 수 있는데, 메타데이터는 식별된 대상체를 사용할 수 있도록 할 필요가 있는 데이터를 인간과 기계에게 제공한다. 메타데이터는 이름, 식별자, 설명, 유형, 분류, 위치, 시간, 측정치, 관계 뿐 아니라 대상체에 관련한 그 밖의 다른 종류의 정보를 포함할 수 있다.

모든 IDF 등록 기관(Registration Agency: RA)은 두 가지 방법으로 메타데이터를 다룬다. RA는 대상체 공급자들로부터 입력 메타데이터(일반적으로, 대상체에 대한 설명 및 관련 권리와 정책)를 수집할 것이다. 그리고 RA는 DOI 시스템 서비스를 지원하기 위해 일정 수준의 출력과 서비스 메타데이터를 제공해야 할 것이다. 입력 메타데이터는 서비스 메타데이터의 (반드시 전체가 아닌) 일부를 제공할 것이다. 일부의 경우, 메타데이터 선언 자체가 완전한 DOI 시스템 서비스가 될 것이다(예를 들어, “이 대상체에 대해 ONIX 제품 메시지를 제공한다”). 메타데이터 선언의 이 두 가지 흐름은 <그림 4-1>에 나타나 있다.

Figure 1: Flows of metadata in and out of an RA

<그림4-1> RA 네트워크 내의 메타데이터의 흐름

입력 메타데이터가 DOI 커널에 내재된 최소 요구사항을 지원해야만 하는 경우를 제외하고는, DOI 시스템 정책은 RA의 입력과 서비스 메타데이터 선언의 형식과 내용에 제한을 두지 않는다(아래 참조). RA는 입력과 서비스 메타데이터 선언을 위해서 자신의 메타데이터 스키마와 메시지들을 명시하거나, 전부 또는 일부를 기존 방식으로 선언해도 된다.

DOI 데이터 모델 정책은 “RA 네트워크” 내에서 RA들 사이의 내부적인 관리와 메타데이터의 교환에 관련되며, 다음의 두 가지 목적을 달성하기 위해 설계 되었다:

  1. DOI 시스템 이용자의 네트워크 내에서 상호운용성을 촉진하기 위해,
  2. RA에 의한 DOI 이름 관리에 대한 최소 품질 기준을 보장하고, 전체적으로 DOI 시스템의 관리를 용이하게 하기 위해

DOI 데이터 모델은 메타데이터 정책을 지원하는 세 가지 도구를 가지고 있다:

  1. DOI® 커널 메타데이터 선언
  2. RA들 사이의 데이터 교환을 위한 DOI® 대상체 메타데이터 선언 스키마
  3. 데이터 사전("DD")

RA의 책임은 다음의 세 문장으로 요약될 수 있다:

  1. RA는 발행된 각각의 DOI 이름을 위한 커널 메타데이터 선언을 생성할 수 있어야 한다.
  2. DOI 시스템 서비스를 지원하는 RA들 사이에서 교환되는 메타데이터는 대상체 또는 서비스 유형에 대해 합의된 DOI 대상체 메타데이터 선언(Referent Metadata Declaration: “RMD”)을 사용하여 교환되어져야만 한다.
  3. 커널과 대상체 메타데이터 선언에서 RA에 의해 사용되는 독점 용어들(데이터 요소와 값)은 IDF의 데이터사전(“DD”)에 등록되어야만 한다.

이러한 책임은 모든 DOI 이름들에 대해 필수적인 것은 아니다. 예외는 다음 절에서 설명하는 상호운용성에 대한 요구사항의 관점에서 논의된다.

 

4.2 DOI 데이터 모델 정책의 목적

 

4.2.1 상호운용성

DOI 데이터 모델 정책의 첫 번째 목적은 DOI 이름의 사용자들의 네트워크 내에서 상호운용성을 촉진하는 것이다. 그것은 이 장에서 설명되는 서로 다른 RA들 사이의 “의미 호환성”을 달성하는 방법을 제공함으로써 수행된다. 상호운용성에 대한 IDF의 전략 보고서는 회원(members)들은 이용가능하다.

어떠한 종류의 표준화도 상호운용성의 필요에 의해 시작된다. 만약 특정 RA가 메타데이터 수집과 출력의 모든 면들을 통제할 수 있는 자신의 사적 도메인 내에서 대상체를 사용하기 위해 DOI 이름을 발행한다면, 표준화하거나 DOI 데이터 모델의 의무에 따를 필요가 없다. 그 RA는 자신의 스키마와 선언을 설계하고, 공급자들과 사용자들이 그것을 따르기를 바랄 것이다. 이런 상황은 DOI 시스템의 제한된 사용으로서 서술되고, 하나의 조직이 단지 자신의 사적 조직 내에서만 사용하기 위해 DOI 이름을 발행하려는 특정 목적으로 RA가 되는 곳에 일반적으로 적용된다.

그러나, 이러한 분리는 이례적인 것이다. 일반적으로, 하나의 DOI 이름이 대상체에 발행될 때, 상호운용성에 관한 하나의 기본적 가정이 만들어질지도 모른다. RA 또는 대상체 공급자는 그 DOI 이름이 다른 RA에 의해 제공된 서비스 내에서도 사용되어질 수 있기를 현재 또는 미래에 바랄지도 모른다. 예를 들면, 다수의 RA들이 서로 다른 출판사들로부터 저널 논문에 DOI 이름을 발행할 때, 일부 RA들과 출판사들은 자신들의 DOI 이름들이 다른 RA들에 의해서 지원된 저널 관련 서비스 안에 포함되어지길 원할 것이다.

비슷한 방법으로, 많은 RA들이 자신들이 제공하는 서비스 내에 다른 RA들에 의해 발행된 DOI 이름을 포함하여 사용할 수 있기를 바랄 것이다. 이러한 상호운용성은 DOI 시스템의 주요 장점 중의 하나이다.

RA 네트워크가 성장함에 따라, 이러한 요구들이 점점 나타나고 특정 기회들이 아직 존재하지 않은 곳에 그 요구들이 예상된다. 이러한 상황에서 RA와 대상체 공급자 모두 대상체를 위한 제2의 DOI 이름을 발행하기를 원하지 않을 뿐만 아니라, 그것의 소스로 부터 전부 다시 입력 메타데이터를 제공하거나 획득하기를 원하지 않는다.

또한, 일부 DOI 시스템 서비스는 미래에 RA의 직접적인 책임이 아닐 수도 있다. 상이한 어플리케이션 프로파일 하에서 다른 RA에 의해 발행된 DOI 이름들을 사용하는 모든 서비스 공급자는 메타데이터 상호운용성에 대한 의문에 직면하게 될 것이다.

상호운용성을 위해 의도된(발행하는 RA의 직접적인 통제 밖의 서비스 안에서 사용 가능성을 갖는) DOI 이름은 DOI 데이터 모델 정책의 대상이다. 따라서, 메타데이터 상호운용성의 목적은 다음의 두 가지 목표로 표현될 수 있다:

  1. 1. 서로 다른 RA들에 의해 보유된 메타데이터는 기본적으로 불일치하지는 않다는 것을 보장하는 것, 그리고
  2. RA들(미래의 다른 서비스 공급자들) 사이의 메타데이터를 전송하기 위해 효율적이고 확장 가능한 교환 수단이 존재한다는 것을 보장하는 것.

첫 번째 목표는 DOI 커널에 의해, 두 번째 목표는 RMD와 DD의 교환 규정에 의해 다루어진다.

 

4.2.2 관리 능력

DOI 데이터 모델 정책의 두 번째 목적은 “RA들에 의해 DOI 이름을 관리하는 데 있어 최소한의 품질 기준을 보장하고, 전체적으로 DOI 시스템의 관리를 용이하게 하는 것”이다. 이 목적 또한 상호운용성의 첫 번째 목적을 지원하는 것처럼 보일 수도 있다. 그러나 이것은 예비 RA가 책임감 있게 DOI 이름을 발행할 수 있으며, 모호한 DOI 이름들은 네트워크에 들어오지 않도록 보장할 필요가 있다고 분명하게 언급한다.

그 정책은 RA의 능력: DOI 커널 선언 능력(RA가 DOI 이름의 명확한 할당을 지원할 수 있는 내부 시스템을 갖고 있는지, 근본적으로 네트워크 내에서 상호운용성을 지원하기에 충분한지에 대한 것)에 대한 간단한 테스트를 제공한다. 또한, 데이터 모델 정책은 RA가 DOI 이름의 할당 날짜와 DOI 이름 할당을 대리하는 등록자의 신원에 대한 기록을 유지하는 것을 요구한다.

또한, DOI 데이터 모델 정책은 전체적으로 DOI 시스템의 관리를 용이하게 하기 위한 메카니즘의 향후 발전을 지원하기 위해 존재한다. 예를 들어, 유형에 따라, DOI 이름, 서비스 또는 어플리케이션 프로파일을 분류하기 위해 데이터 사전에 등록된 용어의 사용을 통해서 이것이 수행될 것이다.

 

4.3 DOI 메타데이터

DOI와 같은 식별자는 그 식별되는 것을 설명하는 몇 가지 관련 메타데이타가 없으면 가치가 없다. DOI의 메타데이터로의 접근방식은 두 가지 측면이 있다. 첫째, DOI 표준은 DOI 이름의 대상체를 표현하기 위해 XML 스키마에 의해 지원되는 특정한 최소한의 메타데이터 세트를 요구한다. 둘째, RA 자신의 스키마를 생성하는데 있어서 상호운용성을 촉진하고 RA를 돕기 위해, IDF는 커널 안에서 사용되는 모든 용어와 RA들에 의해 등록된 다른 용어들에 대한 데이터 사전이나 온톨로지를 제공하고, VMF라는 매핑 툴을 지원한다. 이러한 리소스들은 다음 절에서 설명된다.

 

4.3.1 DOI 메타데이터 커널

“DOI 커널”은 두 가지 목적(“인식”과 “상호운용성”)을 가진 최소한의 메타데이터 세트이다..

이 문맥에서 “인식”은 (다양한 분류에 의해) DOI 대상체가 어떤 종류의 것인지를 커널 메타데이터가 명확하게 보여주기에 충분해야 하며, 사용자가 (다양한 이름, 식별자 및 관계에 의해서) 특정 대상을 합리적인 정확도를 가지고 식별하도록 허용하는 것을 의미한다. 이 두 가지는 상호보완적이다. 예를 들면, 어떤 것이 “카사블랑카”라는 것을 모르면서 영화 또는 DVD인지를 아는 것이 가능하고, 그 반대도 가능한다. 인식은 대상체를 발견하기 위해 필요하며, 또한, 고의로 또는 우연히 대상체가 발견되어졌을 때 사용자에게 정보를 제공하기 위해 필요하다. 메타데이터의 사용자는 사람이나 기계가 될 수 있다. 커널의 구조는 항상은 아니더라도 종종 대상체에 대한 고유한 설명을 제공하기에 충분한데, 경우에 따라서는 전문화된 메타데이터 요소들이 요구될 수 있다. 사실 대상체 이름에 부연 설명를 추가함으로써 항상 고유한 설명을 만들 수 있다. 그런데, 만약 그 추가한 부연 설명이 정식 분류, 측정, 식별자, 시간 또는 다른 구조화된 맥락적 메타데이터를 대신하여 사용된다면, 부연 설명을 추가하는 것이 만족스러운 방법은 아니다. 왜냐하면 이 방법이 상호운용성의 두 번째 목적을 약화시키기 때문이다.

이 문맥에서 “상호운용성”은 서로 다른 RA들로부터의 커널 데이터가 의미적 매핑 또는 변환을 요구하지 않고도 동일한 소프트웨어에 의해서 결합 또는 질의되어질 수 있음을 의미한다. 상호운용성은 데이터 요소들 또는 그 값들이 다양한 메타데이터 스키마에 공통적일 때 달성되어질 수 있다. 커널은 핵심 요소 및 분류들의 공통 세트를 의무화함으로써 직접적으로 상호운용성을 제공하지만, 물론 단지 제한된 상호운용성만을 지원한다.

DOI 이름을 할당하려면 등록자가 DOI 이름이 할당 되어지는 객체를 설명하는 메타데이터를 제공해야 한다. 최소한, 이 메타데이터는 DOI 커널 메타데이터 선언 (또한 DOI 커널이라고도 함)으로 구성될 것이다. 현재 허용되는 값들과 XML 표현인 데이터 요소(하위 요소와 기수성을 포함하는)의 명세는 IDF(ISO 26324 등록 기관 Registration Authority)에 의해 유지보수 된다.

DOI 커널의 요소는 ISO 26324의 <표 B.1>과 <표 B.2>에 기반한 <표 4-1>과 <표 4-2>에 설명되어 있다. 아래 표들은 ISO 26324에 명시된 것 이외의 추가적인 용어들을 포함할 수 있다. 그러나, 새로운 항목들이 등록될 수 있는 열린 목록의 용어들만 포함될 수 있다. 그러므로 아래 표들은 ISO 26324와 완벽하게 호환된다. DOI 커널을 위한 XSD(XML schema)는 IDF에 의해 유지보수 된다. (최신 버전의 배포 노트와 스키마로의 연결에 대해서 DOI Kernel XML Schema 참조, DOI 커널 XML 스키마 정책(DOI Kernel XML Schema Policy Notes.) 참조) 이 스키마는 그 요소들을 위한 몇 가지 추가적인 하위 요소들을 포함하고 있다.

<표 4-2>는 DOI 커널 메타데이터 선언의 기본 관리 요소들을 보여 준다. 이 요소들은 DOI 이름의 발행과 등록 기록 그 자체와 관련된다.

DOI 커널 밖의 다른 요소들과 하위 요소의 경우, 필요에 따라 값이 개발될 수 있다. 공통 어플리케이션에 의해 상이한 소스들로부터의 DOI 데이터의 통합을 용이하게 하기 위해서 IDF(ISO 26324 Registration Authority)의 책임 하에 이러한 값의 세트가 데이터 사전에 등록되어질 수 있다.

<표 4-1> DOI 커널 메타데이터 선언의 서술적 요소

커널 요소(s) 발생 설명
DOI name 1 확인된 대상체에 할당된 특정 DOI 이름.
referentIdentifier(s) 0-n 동일한 대상체를 참조하는 다른 식별자(들)(예를 들어, ISAN, ISBN, ISRC, ISSN, ISTC, ISNI).

이 요소는 primaryReferentType에 적합한 유형 요소를 포함한다. 현재 스키마는 creationIdentifierType과 partyIdentifierType을 인식하며, 새로운 허용 값들을 등록 할 수 있는 열린 목록이다.
referentName(s) 0-n 대상체가 일반적으로 알려져 있는 이름(들)(예: title).

이 요소는 primaryReferentType에 적합한 형태 요소가 포함되어 있다. 현재 스키마는 creationNameType과 partyNameType을 인식하며, 새로운 허용 값을 등록 할 수 있는 열린 목록이다.

이 요소는 또한 언어(language) 요소를 포함한다. 허용되는 값의 목록은 ISO 639-2 코드 목록이다.
primaryReferentType 1 대상체의 주요 유형(예: creation, party, event). 이것은 열린 목록으로 새로운 primaryReferentTypes을 등록할 수 있다.
structuralType 1 대상체의 주요 structuralType.

creation에 대해, 전체 형태에 따라 분류를 허용하는 네 개의 상호 배타적 creationStructuralTypes(physical, digital, performance, abstraction)이 있다. structuralTypes이 서로에 포함 할 수 있는 경우, 대상체의 structuralType은 전체 형태에 의해 정의된다. [예를 들면, CD(physical)는 노래(abstraction)의 공연을 녹음한 것을 포함하는 파일(digital)을 포함할 수 있다] 콘텐트의 요소는 필요하다면 referentType 하에 추가로 더 분류될 수 있다.

parties 에 대해, 세 가지 상호 배타적 partyStructuralTypes(person, animal, organization)이 있다. 이 목록은 닫혀있다.
mode 0-n creation에만 관련, 대상체가 인지되도록 의도된 주요 감각 모드(들)(audio, visual, tangible, olfactory, tasteable, none). 모드는 단지 인식의 주요 의도된 모드를 식별한다. 대부분의 물리적 자원은 모든 오감으로 지각 할 수 있지만, 이러한 인식의 일부는 사소한 것 일 수 있다. 예를 들어, 인쇄 된 책은 만져지거나 냄새를 맡을 수 있지만, 이러한 것들은 콘텐트 사업자가 의도한 시각 모드의 보충적이거나 부수적인 것들이다. 그러나, 점자 책에서 촉각 모드가 주요 모드가 될 것이다. 이 목록은 닫혀 있다.
character 0-n creation에만 관련, 대상체의 콘텐트가 표현되어지는 통신의 기본적 형태, 네 가지의 값(music, language, image, other)이 있다.(이 목록은 닫혀 있음)
referentType 0-n parties 를 위한 대상체의 유형의 명세: : author, composer, book publisher, library, university, financial institution, film studio

creation에 대해, creationStructuralType과 상관없이 대상체의 내용의 추상적 본질은 일반적으로 creationType 으로 기술됨. 필요에 따라 형식과 장르 요소를 포함하도록 확장될 수 있음(예: audio file, scientific journal, musical composition, dataset, serial article, eBook, PDF).

parties에 대해, referentType 은 당사자가 관련되어 있는 역할이고, associatedPartyRole에 의해 기술된다.(예: Composer, Author, BookPublisher, JournalPublisher)

열린 목록임: 새로운 referentTypes을 등록 할 수 있다.
linkedCreation 0-n creation에 대해서만, referentCreation이 연관되어 있는 또 다른 creation.

이 요소는 creationRoleToCreation 요소를 포함하고 있으며 새로운 허용 값을 등록 할 수 있는 열린 목록이다.
linkedParty 0-n parties에 대해서만, referentParty와 연결되어 있는 또 다른 party.

partyRoleToParty 요소가 포함되어 있다. 이 요소는 새로운 허용 값을 등록 할 수 있는 열린 목록이다.
principalAgent 0-n creation에 대해서만, 주로 대상체의 생성 또는 출판을 책임지는 개체 또는 개체들.

이 요소는 특정 역할(예: Creator, Author, BookPublish)을 지정하는 agentRole 요소가 포함되어 있다. 새로운 허용 값을 등록 할 수 있는 열린 목록이다.
dateOfBirthOrFormation 0-1 parties에 대해서만, referentParty의 (개인 또는 동물의) 출생 또는 (조직을) 형성한 날짜.
dateOfDeathOrDissolution 0-1 parties에 대해서만, referentParty의 (개인 또는 동물의) 사망 또는 (조직을) 해체한 날짜.
associatedTerritory 0-n parties에 대해서만, referentParty가 연관되어있는지역(territory) (예: 출생지, 국적, 거주지). 허용되는 값 목록은 ISO 3166a2 지역 코드 목록이다.
 

Table 4.2: DOI 커널 메타데이터 선언의 관리 요소들

커널요소 발생 설명
registrationAuthorityCode 1 DOI 이름을 발행한 기관(ISO 26324 등록 기관(Registration Authority)에 의해 승인된)의 이름을 표시하기 위해 할당된 코드.
issueDate 1 DOI 이름이 발행된 날짜.
issueNumber 0-1 DOI 커널 메타데이터 선언의 특정 버전에 관련된 번호 또는 표식
 
 

4.3.2 DOI 커널의 사용

등록 기관(Registration Agencies: RA)은 최소한 각각의 발행된 DOI 이름을 위해 DOI 커널 메타데이터 선언을 생성하는 것을 보장해야 한다. 이것은 두가지 방법으로 수행된다. 선언이 DOI 커널 XSD를 사용하여 생성될 수 있거나, 또는 (더 일반적으로) DOI 커널의 요소들이 등록 기관에 의해 발행된 더 광범위한 메타데이터 스키마로 통합되어질 수 있다.

등록 기관은 요청이 없으면 DOI 커널 메타데이터를 생성하지 않도록 하는 옵션을 갖고 있다. 즉 내부 표현으로부터 요구가 있으면 전환 시킬 수 있다.

등록자가 관심을 가져야 하는 최소한의 메타데이터 세트는 비즈니스 요구사항을 만족시키는 최소한의 것이지, 항상 더 작은 커널의 기술적인 최소는 아니다. 커널 스키마는 매우 적은 수의 데이터 요소들만 필수적이다. 최소 세트는 등록자가 공급 체인 파트너와 의사소통할 필요가 있는 데이터가 무엇인지에 대한 질문을 고려하는 데 있어서 필요하지만 충분한 요구사항은 아니다.

 

4.3.3 1.1.1. DOI 메타데이터 스키마의 관리를 위한 절차

“스키마(schema)”는 DOI 사용을 지원할 특정 목적으로 설계된 소프트웨어 또는 메타데이터 요소들의 문서화된 세트의 모든 항목을 포함한다. 일반적으로, 스키마는 XML 스키마와 RDF 스키마, 또는 일부 프로세스에서 사용하기 위해 정의된 어휘 용어의 세트이다. 몇몇 기계가 읽을 수 있는 DOI 메타데이터 스키마(특히 “Linked Data”)를 구현하는 것의 이점에 대해 RA들 사이에서 관심이 증가하고 있다. 현재 두 가지 DOI 메타데이터 스키마가 있는데, 메시지 내에서의 사용을 위해 허용되는 값의 세트들을 포함하는 데이터 사전과 메타데이터 커널이다. 데이터 사전은 IDF 웹사이트의 회원 섹션 내에 전체가 게재된다. 커널은 IDF 웹사이트에 XML 스키마로 게시된다.

 

4.3.3.1 Adding values to the Kernel controlled vocabularies

많은 커널 요소들은 통제된 어휘들(또는 “허용되는 값 세트”)에 의해 결정된 값을 가진다. 이 요소들은 상기 표에 볼드체로 강조되어 표시된 것들이다. 이 목록들 중 일부인 다음 요소들은 목록이 닫혀 있어서 RA에 의해 값을 추가할 수 없다:

creationStructuralType
partyStructuralType
mode
character
language(ISO 639-2)
territory(ISO 3166a2)

반면, 일부는 열린 목록으로, RA들에 의해 새로운 값이 추가될 수 있다:

primaryReferentType
agentRole
creationType
creationIdentifierType
creationNameType
creationRoleToCreation
associatedPartyRole
partyIdentifierType
partyNameType
partyRoleToParty

RA들은 DOI 데이터 사전에 값들을 등록함으로써 위 목록에 새로운 값을 추가할 수 있다(아래 참조).

 

4.3.3.2 갱신 절차

기존 DOI 스키마를 변경할 수 있는 권한은 DOI-RATech 그룹에 있다. 그 그룹의 회원들은 언제든지 스키마를 갱신 또는 새로운 스키마를 도입하기 위해 제안할 수 있다. 변경을 구현하는 것은 IDF가 선택한 스키마의 관리자인 기술 공급자의 책임일 것이다. 그들은 각 제안을 인정하고 제안된 변경에 대한 범위와 복잡도에 따라 추정된 구현 가능한 시간을 제시할 것이다. 통상적인 변경은 대개 2주 이내에 처리될 것이다. 그 절차는 다음과 같다:

  1. 초기 제안
    DOI RA 회원이 DOI-RATech 메일 리스트 http://www.doi.org/idf-members/mail_list.html 를 통해서 스키마의 변경 또는 새로운 스키마에 대해 제안한다. 이것은 특정 제안서의 형태(예: 새로운 허용 값 또는 요소의 추가) 또는 요구사항 형태(예: 커널에서 독점 ID 스키마의 소유자를 식별하는 방법의 소개에 대한 요청)가 될 수 있다. 그 메일 리스트 상의 다른 사람들은 의견을 줄 수 있다.
  2. 제안 동의
    필요한 경우, 명료화를 위한 요청 또는 구현을 위한 의견과 제안을 할 수 있고, 메일 리스트 상의 누구든지 응답할 시간이 주어질 것이다. 변경을 위한 구현을 추진하기 전에 합의에 도달하는 것이 목표인데, 합의에 이르는 시간은 제안에 따라서 다양하다. 일부 제안들은 매우 신속하게 합의될 것이고, 만약 동의가 없으면 그 제안들은 폐기될 수도 있다.
  3. 초안 구현
    제안이나 요구사항이 명확할 때, 시간 프레임 내에서 적절한 스키마의 갱신과 새로운 초안의 발행을 위해 추정된 시간이 제공될 것이며, 어떤 이유에서든 지연될 예정이라면 미리 DOI-RATech 그룹에게 알린다.
  4. 갱신된 또는 새로운 스키마 초안 검토
    DOI-RATech 그룹은 초안에 대한 의견을 제시할 수 있는 기회(일반적으로 일상적인 변경을 위해 1주일)를 줄 것이다. 만약 추후 개정이 필요하다면, 3~4 단계가 반복될 것이다.
  5. 갱신된 또는 새로운 스키마의 발표
    갱신된 스키마가 동의되면, 그 스키마는 IDF 회원들이 접근 가능한 웹사이트에 올려 질 것이다.
 

4.3.4 DOI 데이터 사전

커널에서 사용되는 모든 요소들과 허용되는 값들은 DOI 데이터 사전에 포함되어 있다. 이 데이터 사전은 DOI 메타데이터의 순차적 개발을 지원하기 위해 만든 계층적 온톨로지이다. 이 데이터 사전의 소개에 그 범위, 구조 및 유지보수에 대한 자세한 정보를 포함하고 있다.

용어는 RA의 요청이 있을 때 메타데이터 커널 및/또는 그 허용되는 값을 수정하거나 메타데이터 커널에 추가적으로 다른 DOI 메시지 스키마를 게재함으로써 사전에 추가될 것이다. 어떠한 RA들도 IDF에 새로운 값을 등록함으로써 열린 허용 값 세트로 새로운 값들을 추가할 수 있다.

ISO 26324는 DOI 메타데이터 규격에 사용된 모든 데이터 요소와 허용되는 값(각 요소의 값들로 사용될 요소들)을 위한 레파지토리로 사용되는 데이터 사전은 모든 메타데이터 요소들에 대한 온톨로지 내의 정의를 모든 RA가 이용할 수 있게 할 것이며, 데이터 교환을 위해 요구되는 메타데이터 통합과 변환을 지원하기 위해 매핑을 제공할 것이라고 명시한다. 만약 원한다면, 메타데이터는 특정한 서비스를 위해 통합될 것이다. 이 경우에, 데이터 사전은 통합된 메타데이터가 단일 세트로부터 표현된 것처럼 보여 지도록, 데이터 매핑을 제공할 것이다. 커널 메타데이터 내에서 등록자에 의해 사용되는 모든 허용되는 값들은 데이터 사전에 등록될 것이다.

DOI 데이터 사전은 어휘 매핑 프레임워크Vocabulary Mapping Framework : VMF) 내에서 관리된 네임스페이스로서 구현 및 유지보수 된다.

이용자들은 데이터 사전을 사용하기 위해 데이터 사전의 기본 개념 및 구성을 이해할 필요는 없다. 데이터 사전의 주요 특징은 다음과 같다:

IDF의 기본 역할은 데이터 사전이 전문가의 검토를 받았고, 실제 구현으로 검증됐고, 견고한 원칙들에 기초한다고 사용자에게 보장해 주는 것이다. 데이터 사전의 방법론은 OWL-DL(W3C 온톨로지 언어)을 통해 검증되었다. 데이터 사전은 다양한 주요 메타데이터 체계에서 널리 받아들여지고 사용되는 기본 온톨로지를 사용하며, 콘텐트, 저자, 창작자, 도서관, 출판사 및 저작자 협회로 구성된 그룹들에 의한 영향력 있는 멀티미디어 메타데이터 프로젝트(1998-2000)인 indecs(interoperability of data in e-commerce: 전자상거래에서의 데이터의 상호운용성) 프레임워크에 그 기원을 두고 있다. 이 프레임워크는 디지털 트랜잭션을 통합하기 위한 하나의 해결책으로서 이벤트 기반 메타데이터의 모델을 개척했다. (“The indecs Framework" 참조)

 

4.3.5 어휘 매핑 프레임워크(VMF)

IDF는 RA 스키마들과 ONIX 또는 DDEX 메세지 표준과 같은 DOI 도메인 밖으로부터의 다른 스키마 및 온톨로지들 사이의 상호운용성을 촉진하기 위해 Vocabulary Mapping Framework(VMF)를 지원하고 권장한다. IDF는 VMF 웹사이트를 주관하며, 또한 VMF의 지배 구조의 일부이다. VMF는 커뮤니티를 통해서 상호운용성을 지원하기 위해 주요 콘텐트 메타데이터 표준으로부터 어휘들을 광범위하고 권위있게 매핑함으로써 의미적 상호운용성을 지원하는 다운로드 받을 수 있는 툴이다.

VMF는 기존 RDA/ONIX 프레임워크를 자원 관계자와 카테고리에 대한 광범위한 어휘로 확장한 것이다. 출판사/제작자, 교육 및 서지/문화유산 커뮤니티(CIDOC CRM; DCMI; DDEX; DOI; FRBR; MARC21; LOM; ONIX; RDA)로부터 주요 표준에서 사용된 어휘들의 확대집합이다.

IDF는 VMF의 개발을 지원해왔고, 커널과 비-커널 메타데이터 요소들과 다른 체계들의 매핑에서 RA에 의해 VMF가 사용되는 것을 장려하고, 기꺼이 VMF 기술 팀과의 논의를 촉진한다.

 

4.3.6 메타데이터 통합: IDF의 목적

IDF는 메타데이터의 자동화된 통합이 디지털 상거래와 문화를 위한 도구로서 DOI의 모든 잠재력을 실현시키는 비결임을 인식하고 있다. 이것은 또한 시맨틱 웹과 “linked data”의 기본 목표이다. 시맨틱 웹은 가능한 많이 현재의 형태로 인간의 소비에 대한 정보를 표현하는 문서의 네트워크로서, 구조화되고 상호 연결된 기계가 처리 가능한 정보를 위한 매체로서 보여져야 한다.

여기(the Kernel declaration, the DOI Data Dictionary and the VMF)에 언급된 툴들은 다른 DOI 대상체에 대한 메타데이터의 통합을 위한 모범 사례의 기초와 시작점을 제공하기 위한 것이다. Linked Open Data와 같은 이니셔티브들은 보다 본질적인 인프라를 제공하지만, 단지 기술과 구문으로 한정된다. 인간의 개입 또는 일대일 “silo” 솔루션의 과다한 도입 없이는, 그들은 완벽하게 상호작용하기 위해 다른 RA들과 parties이 서비스를 허용할 수 있는 서로 다른 데이터세트의 자동화된 통합을 위한 공유된 의미(“의미 정렬”) 수준의 솔루션을 제공하지 않는다.

이것의 핵심은 잘 구조화된 메타데이터 스키마 및 DOI 데이터 사전과 VMF와 같은 툴의 시맨틱 매핑 기능을 활용하는 서비스를 개발하는 것이다. IDF는 RA들이 이런 서비스를 개발하는데 협력할 경우 지원할 것이다.

 

4.4 메타데이터 요구사항, ISO 26324

DOI 시스템에 대한 규격인 ISO 26324는 다음의 DOI 메타데이터의 기능과 요구사항을 기술한다. 객체는 DOI 이름의 대상체를 원하는 정확도와 세분화 정도의 메타데이터와 연관시키는 것을 가능하게 하는 구조화된 데이터 모델에 기초하여 DOI 메타데이터에 의해 분명하고 정확하게 명시될 것이다. 이는 대상체와 관련된 식별, 설명 및 서비스를 지원하기 위함이다. 이것은 다음을 수행하기 위해 설계되었다.

DOI 메타데이터는 다음 기능들을 지원해야 한다.

예: 녹음 매체, 서적, 비디오와 사진을 서로 다른 특성을 가진 서로 다른 것들로 취급하는 대신, 그들 모두는 동일한 상위 속성에 대해 다른 값들을 갖는 창작물로 인식되어서, 그들의 메타데이터는 공통된 환경에서 지원될 수 있다.

  1. 미디어 (예: 단행본, 연속간행물, 청각자료, 시청각자료, 소프트웨어, 추상적 작품, 시각자료),
  2. 기능 (예: 목록화, 발견, 워크플로우, 권한 관리),
  3. 메타데이터의 수준(단순한 것에서 복잡한 으로),
  4. 의미 장벽
  5. 언어 장벽

DOI 이름이 할당된 객체를 설명하고 식별하는 메타데이터는 신속하고 정확하게 기록될 것이다. 선택된 기존의 체계와 상호운용성을 촉진하기 위해, DOI 메타데이터 규격에서 사용되는 데이터 요소와 허용되는 값은 레파지토리에 보관될 것이다. 데이터 사전은 모든 데이터 요소와 허용되는 값에 대한 레파지토리로 사용될 것이다. 메타데이터는 DOI 커널 메타데이터 선언의 최소 요구사항을 만족시킬 것이다.

 

4.5 기반 온톨로지

DOI 데이터 모델은 많은 다른 어플리케이션과 공유된 맥락적 온톨로지 접근방식을 기반으로 만들어졌다(1. 소개 중 1.6.5 절 참조). IDF는 데이터 모델이 유지되고 추후 확장과 응용이 가능하도록 보장한다. RA와 어플리케이션 개발자가 원한다면 그렇게 할 수도 있겠지만, 그들은 DOI 시스템을 사용하기 위해서 맥락적 온톨로지를 액세스할 필요는 없다. 높은 수준의 개념 모델의 예시 그림은 여기에서 제공되며, VMF와 관련 자료의 일부로서 추가 문서를 사용할 수 있다. 추가 정보에 대해서는 IDF에 문의하기 바란다.

 

목차   이전 장 : 3. 해석    다음 장 : 5. 응용 프로그램

 
DOI_disc_logo ®, DOI®, DOI.ORG®, 그리고 shortDOI®는 국제 DOI 재단의 상표입니다.