Logo

목차    이전 장 : 8. 등록관리기관    다음 장 : 어휘집

 

9. 운영절차

 

이장은 DOI®이름과 관련된 메타데이터의 등록과 유지보수를 위한 일반적인 절차와 규칙을요약한 것이다.등록관리기관들은 그들 자신의 세부 운영절차 채택하고 이 일반적인 가이드를 부가적으로 참고해야 할 것이다.

© 국제 DOI 재단   •   최종 갱신 : 2014년 3월 21일

 
9.1 DOI 디렉토리
      9.1.1 DOI 접두사 할당
      9.1.2 DOI 디렉토리 관리자에 의해 운영되는 로컬 핸들 서비스 사용
      9.1.3 로컬 핸들 서비스 실행하기
      9.1.4 관련 메타 데이터를 가진 DOI 이름의 등록
      9.1.5 다른 등록자로 DOI 이름 이전
      9.1.6 다른 등록관리기관으로 DOI 이름 이전
      9.1.7 DOI 시스템 오류 메세지
      9.1.8 접두사 할당 및 DOI 이름 저장 절차
9.2 핸들 시스템
      9.2.1 로컬 핸들 서비스 운영을 위한 요건
      9.2.2 해석 서비스 제공자를 위한 요구 사항
      9.2.3 핸들 시스템 클라이언트 소프트 웨어 개발하기
9.3 DOI 데이터 사전
9.4 보고
9.5 기술 정보
 

9.1 DOI 디렉토리

DOI 디렉토리는 등록관리기관들의 다양한 관리조치와 상관없이 모든 DOI 이름에 대한 백업과 관리, 신뢰도 높은 핸들 해석을 제공하기 위해 핸들서비스와 웹 프록시 설정으로 구성된 가상서비스이다. 이 접근은 등록관리기관에게 신뢰할 수 있는 서비스를 더욱 보장하면서 개인 비즈니스 모델을 개발하고 고객의 요구사항을 충족할 필요와 유연성을 제공한다.

디렉토리는 여러 핸들 사이트를 포함하는 local handle services (LHS)로 구성되어 있다. 자신의 핸들 서비스를 유지하고 싶지 않은 등록관리기관은 다음 9.1.2.절에서 설명하는 DOI 디렉토리 관리자에 의해 관리되는 로컬 핸들 서비스를 사용하도록 선택할 수 있다.

각 서비스는 주 사이트, 하나와 최소한 한 개 이상의 보조 혹은 미러사이트로 포함된다. 보조 사이트 중 일부는 자체 로컬 핸들 서비스를 운영하도록 선정된 등록관리기관들에 의해 관리하지만, IDF는 각각의 주 사이트에 최소한 IDF가 운영하는 보조 사이트가 1개 이상이 되도록 요구한다. 두 가지 방식 모두 별도의 핸들 서비스를 운영 및 디렉토리 관리자로 운영되는 서비스를 사용하고 있으며, 접두사를 생성하고 할당하기 위해서는 디렉토리 관리자가 필요하다.

디렉토리 인프라스트럭쳐는 프록시 서버들(모든 도메인 이름에 doi.org)또한 포함한다. 등록관리기관들 의해 통제된 시설과 호스팅사이트에서 운영 중인 여러 프록시 서버들이 지리적으로 분포되어 있지만, 이는 CNRI에서 개발한 소프트웨어를 사용한다. (이전에 사용되었던 프록시 서버 도메인 이름인 dx.doi.org는 더 이상 선호되지 않지만 지원되고 있다는 점을 유의하라.)

 

9.1.1 DOI 접두사 할당

접두사는 DOI이름의 첫 번째 부분을 구성하는 핸들 시스템의 Global Handle Registry® (GHR,예를 들어, 0.NA/10.1000)의 핸들로 저장되는 고유한 문자열이다. 등록관리기관이 수신하고 필요한 만큼의 접두사를 할당할 수 있다.

모든 DOI 이름 접두사는 10으로 시작하고, 순차적으로 할당된다. 더욱이 예약된 접두사는 요청될 수 없다. DOI 이름의 두 번째 부분은 접미사라고 하며 소유자 또는 그들을 대신하는 기관에 의해 할당된 로컬 문자열이다. (예를 들어, 10.1000/34004JFR ) 접두사와 접미사는 슬래시(/)로 구분된다. 접미사 번호에 대한 제안된 가이드라인은 2. 번호 할당을 참조하라.

이 접두사는 비즈니스 요구 사항에 대처하기 위해 적절한 수준에서 할당하는 것이 좋다. 일반적으로, 등록관리기관은 고객당 하나의 접두사를 발행할 수 있다. 그러나 그것은 또한 브랜드마다, 또는 (예를 들어, 게시자의 인쇄물) 인식 가능한 제품군에 접두사를 발행하는 것이 적절할 수 있다. 선택은 등록관리기관들의 몫이지만, IDF 및 기타 등록관리기관들 요구 사항을 논의하고 권고를 할 수 있다. 각각의 등록관리기관은 특별한 의미가 없는 일련번호들을 접두사로 할당할 수 있다. 자신의 지역 핸들 서비스를 실행하는

각 등록관리기관은 특히 그들의 접두사의 기본 설정을 이해해야 한다. 각 접두사는 그와 관련된 '서비스 정보'를 가지고 있다. 이러한 서비스 정보는 핸들 서비스의 맵/레이아웃이다. 서비스 정보는 서비스 핸들 (관리의 용이성을 위해 간접 또 다른 수준)에 포함된다.

접두사 다음과 같은 값들을 가질 것이다.

Prefix: 0.NA/10.1201
Data Value: 100:HS_ADMIN 0.NA/10:200 (CNRI admin that points to another handle)
Data Value: 101:HS_ADMIN 0.NA/10.1201:200 (RA admin that points to a group within the prefix record — see next in the list)
Data Value: 200:HS_VLIST (Group/list of administrators)
0.NA/10.1201:300
10.1.admin/user1:300
Data Value: 300:HS_PUBKEY (Public key for local server administration)
Data Value: 1:HS_SERV 0.SERV/10.1 (Service handle)

등록관리기관 뿐만 아니라, CNRI는 접두사에 대한 관리 권한를 유지한다. 이것은 관리를 위한 백업으로 사용된다. DOI이름 관리는 admin DOI의 사용을 필요로 할 것이다. 각 관리 DOI는 각 등록관리기관(RA)의 LHS에 따라 약간씩 다르며, 10.1.admin 또는 유사한 것으로 시작된다. 그것은 아마도 미러링 메커니즘을 방해 할 수 있는 모든 주요 거래의 경우에 대해 CNRI와 IDF에게 알려야 하는 것은 등록관리기관(RA)의 책임이다. 그들이 LHS에서 구성 변경사항을 CNRI에게 알려야 하는데 이 또한 등록관리기관(RA)의 책임이다. 접두사 할당 및 관리 서비스를 포함하는 접두사 할당에 관한 정보는, 디렉토리 관리자(jeuler@cnri.reston.va.us)에 의해 등록관리기관(RA)으로 제공된다.

 

9.1.2 DOI 디렉토리 관리자에 의해 운영되는 로컬 핸들 서비스 사용

등록관리기관은 디렉토리 관리자가 운영하는 서비스를 사용하기로 결정하고, 접두사, 또는 접두사의 블록에 대해 준비가 되어있는 경우, 등록관리기관은 서비스를 시작하기 위해 디렉토리 관리자에게 연락해야 한다. 각 접두사 또는 접두사의 세트에는 DOI 이름을 기탁할 때 인증이 요구되므로, 그것들과 관련된 사용자 이름과 암호를 가져야 할 것이다.

등록관리기관이 어떤 유형의 서비스를 사용하든지 간에, 어떤 수준의 세분화 정도로 무엇을 식별할 것인지, 각각의 식별자, 워크플로우, 권한 등과 관련된 정보가 무엇인지 처음부터 결정하는 것이 필수적이다. 현 시점에는 디렉토리 관리자가 운영하는 서비스에서는 메타데이터를 기탁하기 위한 메타데이터 데이터베이스 또는 메커니즘이 존재하지 않는다. 등록관리기관이 어떻게 자신의 메타데이터의 기탁 절차를 어떻게 구성할 수 있는지에 대해서는 아래의 9.14절을 참조하라.

 

9.1.3 로컬 핸들 서비스 실행하기

등록관리기관이 DOI 이름을 위한 로컬 핸들 서비스(LHS)을 설치하고 사용하고자 선택하더라도, 디렉토리 관리자는 여전히 접두사를 생성한다. 그러나 등록관리기관이 수행해야 할 추가적인 단계가 있다.

첫 번째 단계는 서버 배포판을 다운로드하는 것이다(현재 버전은 7). 다음으로 간단한 설치(SimpleSetup) 스크립트를 배포판에 포함된 지침에 따라 실행한다. 로컬 핸들 서비스를 서버를 설치하고 관리하려면 시스템 관리자 권한이 있어야 한다. 핸들 서버는 자바로 작성되어서 Windows 또는 유닉스에서 실행이 된다. 그러나 서버급 품질의 컴퓨터에서 실행하는 것을 권장한다. 핸들 서버는 인터넷 상에 존재해야 하고, 핸들 서버에 필요한 포트(2641 및 8000)가 수신 및 발신 요청에 의해 열려 있지 않으면 방화벽 뒤에서 실행할 수 없다.

간단한 설치 스크립트는 로컬 핸들 서비스에 대한 서비스 정보를 포함하는 sitebndl.bin라는 파일을 생성한다. 배포의 지시에 따라, 등록관리기관들은 파일을 hdladmin@cnri.reston.va.us (또는 직접 디렉토리 관리자인 jeuler@cnri.reston.va.us)로 전송해야한다. 이름, 조직 이름 및 어느 IDF 등록관리기관에서 오는 요청인지가 중요하다. 디렉토리 관리자는 10으로 시작하는 접두사를 생성하기 위해 알아야 하기 때문이다. 각 접두사는 GHR에 생성된다.
접두사는 고유 IP 주소와 서버의 공개 키와 같은 각 로컬핸들 서비스를 고유하게 식별하는 정보를 포함한다. GHR은 DOI 이름 해석 요청을 어디에 보낼지 결정할 때 이 정보를 사용한다.

이 시점에서 어쩌면 등록관리기관이 사용하고 싶어하는 인증 유형에 대한 논의가 있을 수 있다. 핸들 시스템은 개인/공개 키 또는 비밀 키를 사용한다. DOI이름을 만들 수 있는 권한은 접두사 수준에 있지만, 각 DOI 이름은 자신의 관리자(일반적으로 접두사 레코드의 그룹을 참조)를 가지고 있다. 추가 기술 정보는 핸들 시스템 기술 매뉴얼(Handle System Technical Manual)에서 찾을 수 있다.

CNRI에서 보조 서버 설치를 허용하기 위해 등록관리기관들은 자신의 핸들 서버의 구성 변경에 대한 책임을 져야하는 것은 IDF 정책이다. 보조 서버는 등록관리기관 서버의 DOI 이름들의 전체 데이터베이스를 수용할 것이다. 서버의 구성 파일에 약간의 변경을 필요로 한다. 이것은 디렉토리 관리자에 의해 조정될 것이다. 설정이 완료되면 보조 서버가 자신의 서버에 접속할 수 있는지 확인하기 위해 크론(cron)작업 역자주 : An automated task that runs at specific intervals 특정 간격으로 실행하는 자동화된 태스크 이 생성될 것이다. 연결에 문제가 있다면(즉, 서버가 종료된다면) 등록관리기관은 이메일로 통보받고 가능한 신속하게 문제를 해결해야 할 것으로 기대된다.

자신의 로컬 핸들 서비스를 실행하는 옵션을 선택하면 RA의 부분에 대한 더 많은 기술적 전문 지식이 필요할 것이다. 당신이 기술적인 어려움이 있는 경우, 디렉토리 관리자가 도와 줄 것이다. 그것은 아마 웹 서버 또는 메일 서버보다 시스템 관리자에게 덜 익숙할 것이지만, 다른 종류의 서버를 설정하는 것과 크게 다르지 않다.

로컬 핸들 서비스를 운영하는 것은 DOI 등록 등의 중요한 인프라 구성 요소인 비즈니스에 대해 즉시 제어하기를 원하는 등록관리기관들, 그들의 어플리케이션에 적합한 성능의 수준을 선택함으로써 관리와 해석을 위한 고성능의 표준을 구현할 계획이 있는 등록관리기관들, 그들의 비즈니스를 방해하지 않고 요구된 DOI 기탁 데이터의 escrow 역자주 : 어떤 조건이 성립될 때까지 제3자에게 보관해 둠 사본을 IDF에 기꺼이 제공할 수 있는 등록관리기관들과 IDF에 의해서 보다는 오히려 등록관리기관들에 의해 큰 비용과 운영 수입이 발생하는 상황에서 “운영 연맹” 구조로 빠르게 이동하기를 원하는 등록관리기관들에게 최선의 선택이 될 수 있다. “운영 연맹이 인수할 때까지 멤버쉽 비용으로 개발을 지원한다”는 기본적인 가정은 여전히 유효한 것으로 간주되지만, IDF는 마이그레이션을 장려한다.
만약 등록관리기관이 로컬 핸들 서비스를 운영하는 데 관심이 있다면, CNRI 직원과 기술 검토 회의를 예약하는 것이 현명하다. 회의 일정을 정하고 질문에 답하기 위해서는 디렉토리 관리자 (jeuler@cnri.reston.va.us)에게 이메일을 보내시오.

 

9.1.4 관련 메타데이터를 가진 DOI 이름의 등록

등록관리기관들은 관련 메타데이터 선언을 가진(DOI® 어플리케이션 프로파일을 사용) DOI 이름의 등록을 지원한다. 개별 등록관리기관들은 DOI 이름 등록과 메타데이터 저장 및 유지보수의 관리를 위한 자신들의 워크플로우와 절차를 개발하고, 자신들의 정보를 등록자 커뮤니티에 제공한다.

다음 절차는 선언된 메타데이터를 가진 DOI 이름의 등록을 위해 개별 등록관리기관이 뒤를 따르는 현재 프로세스에 대한 예이다. 이 절차는 등록관리기관에 의해 운영되는 DOI 시스템 중앙 메타데이터 디렉토리에 DOI 이름과 관련 메타데이터 레코드를 일괄 등록하는 것을 허용한다. 이 디렉토리는 나중에 조회될 수 있다.

특정한 XML 스키마에 의해 정의되는 현재 사용 중인 배치 파일의 형식은 XML이고, HTTP POST를 통해서 제출된다. 보안은 HTTP 기본 인증을 사용하고, PGP 암호화는 나중에 추가될 것이다. 일괄 수신은 송신자에게 이메일을 통해서 확인될 것이다.

메타데이터 생성: 등록자는 스키마에 따라서 배치 파일을 준비한다. 이들은 각 메타데이터 요소의 예상되는 내용을 정의하는, 데이터를 위한 일련의 규칙 의해서 더 제한된다. XML 배치는 수백개의 DOI 이름들을 위한 메타데이터를 포함할 수 있다. 메타데이터 내용의 유효성을 보장하기 위해 사용되는 품질 제어 방법의 개발과 구현은 등록자의 책임이다. 품질 제어 및 데이터 검사는 등록관리기관의 메타데이터 수집 과정에서 프로세스들에 의해 지원될 수 있다.

메타데이터 수집: XML은 스키마에 대한 수신시 검증된다. 만약 XML이 파싱되지 않는다면, 배치는 거절된다. 등록자는 XML을 수정하고 배치를 다시 제출해야 한다. XML 배치들은 HTTP POST에서 Java “servlet”을 통해서 명명된 HTTP 서버로 제출된다. 이 서버는 XML 파일을 파싱하고 검증한다. XML이 유효한지와 수락되었는지 여부를 실시간으로 등록자에게 알려준다. 제출과정은 XML을 검증하기 전에 DOI 시스템 접두사 홀더 로그인과 암호를 확인한다. XML 파일 자체는 배치에 대한 식별자로서 타임스탬프를 포함한다. 등록자가 그렇게 하고자 하는 경우, 각 DOI 이름 레코드가 자신의 타임스탬프를 가질 수 있다.

DOI 이름 기탁: servlet은 각 DOI 이름과 그것에 대응하는 URL을 타임스탬프 데이터 값을 추가하면서 DOI 시스템에 저장한다. 만약 DOI 이름이 새로운 것이 아니고 DOI 시스템 내에 이미 존재한다면, 기탁된 DOI 이름 데이터가 이미 시스템 내에 있는 데이터보다 새로운지 여부를 결정하는 데 있어 그 타임스탬프가 중요하다. 그렇다면, 기존의 DOI 이름 데이터가 갱신된다. 또한, 배치 안에서 DOI 이름 레코드의 총 개수, DOI 시스템으로 성공적으로 저장한 개수 및 실패한 개수를 나타내기 위해 각각의 배치에 대해 XML로 작성된 로그 파일이 생성된다. 각 실패에 대해서 실패의 원인과 함께 DOI 이름이 제공된다. DOI 시스템 실패가 시스템 오류의 결과일 수도 있지만, 이들은 더 오래된 데이터를 가진 기존의 DOI 이름을 덮어쓰는 시도에 의해 가장 일반적으로 야기된다.

메타데이터 데이터베이스 레코드 생성: 원본 XML 배치 파일은, 배치를 위한 로그 파일들과 함께, 색인되는 메타데이터 데이터베이스 기탁 프로세스에서 사용가능하고 검색될 수 있게 생성된다. 최종 XML 로그 파일은 DOI 이름 기탁 프로세스로부터 결합된 데이터베이스 기탁의 성공을 표시하시 위해 생성된다(다시 말해, 실패는 주로 네트워크 또는 시스템 오류에 기인한다). 결합된 XML 배치 진단은 등록자에게 이메일로 전송된다. 전체 메타데이터 수집 프로세스는 완성되고, 가능한 실시간으로 등록자에게 보고될 것으로 예상되고, 24시간이 합리적인 목표 시간으로 보여진다. 그러나, 등록자가 처음 기탁할 때, 과거 배치파일이 저장될 때 많은 과거 기록과 조정이 필요하다. 그렇지 않으면 시스템 성능이 영향을 받을 수 있다.

메타데이터 조회: 메타데이터 데이터베이스(MDDB)는 지정된 형식(수직 막대로 구분된 필드, 현재 분리된 선 위의 순수 ASCII 텍스트)으로 알려진 메타데이터 필드의 배치 파일을 제출함으로써 조회 할 수 있다. 일괄 인터페이스는 데이터베이스를 조회하고 대응되는 DOI 이름을 반환 하거나 (알고 있는 경우) 진단 메시지를 반환할 것이다. 일괄 질의 파일은 명명된 HTTP 서버로 HTTP POST에 의해 제출된다.

 

9.1.5 다른 등록자에게 DOI 이름을 전송하기

만약 다중 할당 DOI 이름의 컴파일(예: 논문들의 컬랙션을 포함하는 저널, 발행사항, 레코딩 목록 등)은 하나의 RA로부터 다른 RA로 전송된다면, 컴파일 내에서 DOI 이름 또한 전송된다. 각 RA는 적절한 전송을 위한 적절한 절차를 개발해야 할 것이다. 전송은 판매되거나 교환의 형태일 수 있고, 상업적이거나 아닐 수 있다. 만약 새로운 소유자가 이미 RA가 아니라면, 그 경우를 위해 특별히 준비될 필요가 있을 것이다. 필요하다면 안내를 위해 IDF와 상의하기 바란다.

개별 DOI 이름은 동일하게 유지된다. (DOI 이름이 식별하는 것은 변경되지 않는다) 이것은 기본적인 요구사항이다. DOI 이름 접두사는 변하지 않는다. (접두사는 의미가 없으며, 단지 DOI 이름을 생성하는데 편리를 위해 초기에 등록자에게 할당되어진다는 것을 상기 바란다. 역으로 찾기는 접두사로 유추되어질 수 없다.) 관리를 위한 값은 새로운 소유자가 그것의 데이터 값(아마도 URL 값)을 수정하기 위해 변경된다. 전송에 관여된 두 등록자들은 전송에 대한 허가를 받기위해 디렉토리 관리자(jeuler@cnri.reston.va.us)에게 이메일을 보낼 필요가 있다. 그 디렉토리 관리자는 효율적이고 성공적인 결과를 보장하기 위해 RA들에게 도움을 줄 것이다.

 

9.1.6 다른 등록관리기관으로 DOI 이름 전송하기

등록관리기관 협력 (Registration Agency collaboration) 에 관한 IDF의 정책은 고객들이 원한다면 하나 이상의 RA 서비스를 사용할 수 있다고 명기한다. RA 서비스는 다양하고, 만약 그들이 이동한다면 고객들은 같은 서비스를 꼭 액세스하지는 않을 것이다.

전송시에 가장 큰 기술적인 문제는 접두사와 로컬 핸들 서비스의 일대일 관계이다. 그러므로, RA들은 각 고객을 위해 최소 하나의 개별 접두사를 할당해야만 하며, 하나 이상에 적합한 곳에서, 주어진 접두사 아래의 모든 DOI 이름은 같은 핸들 서비스 내에 상주해야 한다는 근본적인 제한이 있기 때문이다 (이 일반적 아키텍처는 분산 서비스에는 논리적이고 효율적인 접근방식이며, 핸들 시스템의 고유함과는 거리가 있다).

한 서비스에서 다른 서비스로 DOI 이름의 전체 접두사 값을 이전하는 것은 쉽다. 같은 핸들 서비스를 사용하는 두 개의 관리부 사이의 접두사의 제어를 분리하는 것(별개의 접두사들을 발행함으로써 분리를 예상하는 것이 가능하지 않았을 때) 또한 가능하지만 좀 더 복잡하다. 일반적으로 두 개의 해결책이 있다. (1) 하나 또는 다른 서비스와 함께 그대로 두고(또는 DOI 디폴트 핸들 서비스가 IDF 대신에 CNRI에 의해 운영), ‘외국’ 관리 접근을 허용하는 서비스의 관리자처럼 관리자를 분리하는 방법, (2) 기존의 접두사 아래의 모든 DOI 이름과 새로운 RA에 의해 제어되는 새로운 접두사 아래의 DOI 이름을 연결하는 방법. 기존의 DOI 이름은 새로운 DOI 이름으로의 해석을 보장하는 것 이외의 것은 유지될 필요가 없다.

위의 모든 것은 엄격하게 DOI 시스템 관점으로부터이다. 내부 워크플로우 문제와 물론 RA에게는 특별할, 핸들 관리와 상호작용하는 것을 RA가 제공하는 부가가치 서비스를 언급하지 않는다.

 

9.1.7 DOI 시스템® 오류 메세지

성공적이지 않은 해석 시도는 오류 메시지를 야기한다. 이들은 RA 또는 중앙 DOI 시스템에 의해 제공될 수 있다. 대부분의 오류 보고서는 RA로 갈 가능성이 높다. 다음은 전형적인 오류 메시지를 보여준다. RA는 자신들의 서비스 내에서 비슷한 문구와 절차를 사용할 수 있다.

시스템에 없는 DOI 이름을 해석하면 “DOI 이름을 찾을 수 없다”라는 오류 메시지를 사용자에게 반환한다. 그 페이지는 DOI 도움 이메일 주소(doi-help@doi.org)를 사용자에게 안내한다. 만약 DOI 이름이 발견되지 않으면, 오류 메시지의 수신은 다음과 함께 응답 메시지를 통해 알려진다:

“이 DOI는 DOI 시스템 내에서 찾을 수 없다. 가능성 있는 이유들은:

사용자를 더 지원하기 위해, 오류 응답 시스템은 사용자가 DOI 접두사 단독 또는 오류를 발생시킬 수 있는 복수의 슬래시 또는 역슬래시을 포함하는 DOI를 해석하려고 시도했는지 점검하고, 맞춤형 응답 페이지를 통해서 사용자에게 조언을 한다.

CNRI는 발신자의 메시지를 RA에게 전달한다. RA는 적절한 조치를 취하며, (참조자로 doi-help@doi.org) 발신자와 CNRI가 취한 조치에 대해 통보했는지를 본다. 일부 경우에, 적절한 RA로 오류를 리다이렉트하기 위해 servlet이 사용된다.

 

9.1.8 접두사 할당 및 DOI 이름 저장 절차

IDF 회원들은 DOI 이름 접두사 할당에 대한 더 자세한(detail) 사항 및 특정 DOI 디렉토리 서비스와 사이트를 사용할 수 있다.

 

9.2 핸들 시스템®

핸들 시스템( Handle System®)은 CNRI에 의해 개발된 디지털 객체 아키텍처의 구성요소이다. 이것은 디지털 객체(“DOs”)와 다른 네트워크 자원들을 유일하게 식별하기 위한, 그리고 디지털 객체들에 대한 상태 정보를 포함하는 레코드들을 저장하고 검색하기 위해 핸들로 알려진 식별자들을 사용하기 위한 수단을 제공한다. 이것은 또한 시간이 지남에 따라 식별자들을 관리하기 위해 관리 메카니즘을 제공한다. DOI 시스템은 핸들 시스템을 사용하고, 그 시스템의 기본 정책과 절차를 상속한다. IDF는 CNRI로부터 로컬 핸들 시스템 소프트웨어 내의 저작권, 미국 특허 번호 6,135,646, 핸들 시스템과 글로벌 핸들 레지스트리® 상표 및 핸들 시스템 기술과 관련된 특정 노하우를 포함하는 기술과 소프트웨어에 대한 권리에 대한 면허를 획득했다.

CNRI와의 핸들 시스템 기술 상업적 라이센스 계약에 따라서, 핸들 시스템 기술에 국한된 부분적 라이센스가 IDF에 허가되었다. CNRI는 핸들 해석 서비스의 제공을 위해 기관과 개인에게 비용 복구 기반위에서 가용한 핸들 시스템 기술, 특히 HANDLE.NET® 소프트웨어를 만든다. 이것은 전체적 핸들 시스템 운영을 지원하면서 시스템의 무결성을 유지하기 위한 방법으로 이루어지고 있다. RA들을 포함하여 핸들 시스템 기술을 사용하는 해석 서비스를 제공하기를 원하는 모든 개인과 기관들은 로컬 핸들 서비스(LHS)로 등록해야 하며, 이 목적을 위해 CNRI와 계약을 체결해야 한다. 대부분의 경우에, 이것은 인터넷을 통해 가능하다.

 

9.2.1 로컬 들 서비스 운영을 위한 요건

핸들 시스템의 전체 무결성을 유지하는 것은 다음의 각각의 조건들이 LHS 관리자에 의해 만족되는 것을 보증하는 것을 수반한다. LHS 관리자는 인증이 유효한 동안 그들의 해석 서비스를 운영하는데 동의해야 한다. 아래 사용된 용어 “시스템”은 (1) 각 LHS 관리자에 의해 운영되는 그들의 LHS 구성요소와 (2) 글로벌 핸들 레지스트리(GHR)를 가진 이 구성요소와 LHS의 사용자들과의 상호작용을 가리킨다. LHS 관리자를 위한 운영 목표는 다음과 같다:

 

9.2.2 해석 서비스의 제공자를 위한 요구사항

해석 서비스 공급자는 자신의 DOI 접두사 및 DOI 이름의 적절한 유지 보수를 보장하기 위해 필요한 조치를 취할 책임이 있다. 그 책임은 다음과 같다:

성능, 보안, 운영을 커버하는 호환성 테스트 세트 규정 준수를 위한 요구가 소개될 수 있다.

 

9.2.3 핸들 시스템 클라이언트 소프트웨어 개발하기

핸들 시스템 클라이언트 구성요소를 개발하는 조직 또는 개인은 CNRI 클라이언트 소프트웨어(client software)와 그것과 함께 제공되는 표준 인터페이스를 사용하도록 권장된다. 그들은 시스템 클라이언트 소프트웨어 또는 GHR와의 상호 작용에서 특히 로컬 핸들 서비스나 다른 클라이언트 어플리케이션의 정상적인 작동을 방해하지 않아야한다. 조직 또는 개인이 자신의 인터페이스 소프트웨어를 사용하고자 할 경우에는, 핸들 시스템(Handle System) 웹 사이트에 게시하는 것과 같이, 시간에 따라 진화하는 현재 핸들시스템 인터페이스 명세와 호환성 유지를 보장해야 할 책임이 있다.

 

 

9.3 DOI 데이터 사전

커널이나 다른 스키마에 추가 용어를 더하기를 요구하는 RA들은 4. 데이터 모델, 4.3.3절에 설명된 DOI 메타데이터 스키마의 관리를 위한 절차를 따라야 한다.

지속적으로 DOI 데이터 사전에 추가할 수 있도록, 추가(비 커널) 메타데이터 용어 및 스키마에 대한 매핑을 개발하고자하는 RA들 역시 동일한 절차를 따르도록 강력하게 권장된다. 용어는 IDF의 활동의 일환으로 VMF에 추가된다. VMF 안에서 용어들이 등록되고 다른 용어들과 매핑되는 기술적 절차가 동일함에도 불구하고 RA들은 새로운 용어를 등록하기 위해 VMF 프로세스에 설명된 절차를 사용하거나 비용을 지불할 필요가 없다.

새로운 스키마와 새로운 메타데이터 어플리케이션을 개발하고자 하는 RA들도 무료로 모든 회원이 사용할 수 있는 IDF의 메타데이터 컨설팅을 활용하도록 권장한다.

 

9.4 보고

보고서는 IDF의 회원에게 기밀사항이며, IDF의 데이터 정책(Data Policy)의 적용을 받는다.

 

9.5 기술정보

RA에 대한 DOI-특정 프로세스 및 절차에 대한 기술 정보는 http://0-www.doi.org.ignacio.usfca.edu/RA_Docs/index.html에서 확인할 수 있다. 이러한 메타데이터 맵핑과 핸들 데이터 및 구성 파일과 같은 정보 범주들이 설명되어 있다. 그리고 각 문서마다의 추가 링크들과 설명이 제공된다.

 

목차    이전 장 : 8. 등록관리기관    다음 장 : 어휘집

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