Logo

목차    이전 장 : 2. 번호 할당    다음 장 : 4. 데이터 모델

 

3. 해석

 

이 장에서는 해석(Resolution)에 관련된 DOI® 시스템의 구성 요소와 식별자 및 관련 데이터의 영구적인 연결을 제공하는 기능을 설명한다. 개요에서 DOI 이름 해석에 사용되는 핸들 시스템®에 대해 설명한다.

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

 
3.1 해석
3.2 단순해석
3.3 다중해석
3.4 DOI시스템을 위한 해석 요구사항
3.5 핸들 시스템 기술
      3.5.1 개요
      3.5.2 DOI 이름 해석에 대한 기술지원
      3.5.3 DOI 이름 사용에 대한 소프트 웨어 지원
3.6 DOI 이름의 상태 데이터 유지
3.7 핸들 시스탬의 해석 인터페이스
      3.7.1 사용자 정의 해석 소프트웨어
      3.7.2 원시 해석기
      3.7.3 프록시 서버
      3.7.4 프록시 검증, 모니터링 및 보고
      3.7.5 다른 메커니즘
3.8 DOI 시스템 프록시 서버의 기술적인 세부사항
      3.8.1 프록시 서버 시스템을 사용하는 DOI 해석
      3.8.2 프록시 서버 질의 매개변수
      3.8.3 프록시 서버 REST API
      3.8.4 추가 기능
            3.8.4.1 로컬 콘테트 서버(The "Appropriate Copy" 문제)
            3.8.4.2 매개변수 전달
            3.8.4.3 10320/loc 핸들 형식을 사용하는 여러 URL의 해석
 

3.1 해석

해석이란 식별자가 네트워크 서비스에 입력되고, 식별된 개체에 대한 하나 이상의 현재 정보(상태 데이터)(예를 들어, 위치(URL))를 반환하는 과정이다. DOI 해석기의 한 부분으로써 사용되는 핸들 시스템에 의해 가능한, 다중 해석(Multiple resolution)은 DOI 이름에 의해 식별된 개체에 관한 여러 가지 현재 정보의 결과물의 반환이다. (구체적으로 말하면, 적어도 하나의 URL과 관리를 허용하는 정의된 데이터 구조)

참조 구현으로써 핸들 시스템®을 사용하는 DOI 시스템®의 경우, 해석은, 예를 들어, 10.1000/140과 같은 하나의 DOI 이름에서 하나 이상의 (그래서 다중의) 유형이 정해진 데이터(예를 들어, 객체의 인스턴스를 나타내는 URL이나, 이메일 같은 서비스 또는 하나 이상의 메타데이터 항목들)까지이다. DOI 해석시스템은 매우 유연하고 새로운 요구에 민첩하게 대응할 수 있기 때문에, 새로운 유형이 언제든지 추가될 수 있다. 해석은 두 개의 데이터 개체 사이의 관계를 유지하기 위한 메커니즘으로서 간주될 수 있다. 메타데이터의 항목은 누군가가 두 개체 사이에 존재한다고 주장한 관계이다. 그러므로, 개체들 사이의 메타데이터 관계는 해석에 의해 연결되고 자동화될 수 있을 것이다.

다중 해석을 이용하여, 하나의 DOI 이름은 다중 URL, 다른 DOI 이름들, 또는 메타데이터의 항목을 나타내는 다른 데이터 유형 등의 관련된 임의 수의 다른 값으로 해석될 수 있다. 해석 요구는 현재 정보의 모든 연관된 값, 또는 하나의 데이터 유형의 모든 값을 반환할 수 있다. 이 반환된 값들은 특정한 “클라이언트” 소프트웨어 어플리케이션에서 추가로 더 처리될 수 있다. 가장 간단하게, 사용자에게 옵션의 목록이 제공될 수 있다. 더 정교한 자동화된 프로세스는 추가 처리를 위해 적절한 값을 자동으로 선택하는 것을 허용할 것이다.

 

3.2 단순 해석

DOI 이름은 영구적으로 특정 지식재산권 개체를 식별한다(그 개체는 인터넷에서 액세스 할 수 있는 파일이거나 또는 아닐 수도 있다). URL은 개체와 관련된 인터넷에서의 특정 주소를 제공한다. 이러한 식별 어플리케이션들은 완전히 다르다. 첫 번째 것은 개체를 식별하고, 두 번째 것은 (특정 개체가 찾아지거나 찾아지지 않을 수 있는) 위치를 식별한다.

DOI 시스템의 초창기 어플리케이션은, 영구 식별자를 제공( "404 찾을 수 없음" 메시지를 피하면서)하는, 간단한 단일 주소 해석을 위한 것이었다. 각 DOI 이름은 해석될 수 있는 하나의 URL을 갖는다. 이것은 DOI 레코드 안에 DOI와 DOI가 해석되는 URL 사이의 링크를 적극적으로 관리하여, 개체의 이름을 실행할 수 있는 식별자로 유지하면서 개체의 위치가 변경되는 것을 허용한다. 자세한 내용은 5. 어플리케이션)을 참조하라. URL의 영구성 결여는 DOI 시스템이 해결하기 위해 설계된 -가장 간단한- 첫 번째 도전 과제에 불과하다.

 

3.3 다중 해석

다중 해석(Multiple resolution)은 하나의 개체가 여러 데이터 또는 여러 개체로 해석되는 것을 허용한다.

DOI 이름의 해석은 다음과 같은 것으로 국한되지는 않지만, 위치(URL), 전자 메일 주소, 다른 DOI 이름 및 설명 메타데이터와 같은 연관된 값들로 해석되는 것을 포함할 수 있다. 대상체는 다양한 유형의 자료들이 될 수 있다. (예를 들어, 추상적인 "작품", 물리적 "표현", 또는 공연) 그리고 항상 디지털 파일 또는 다른 표현물의 형태로 직접 접근할 수 있는 것은 아니다. 즉, 해석은 객체의 인스턴스를 반환할 수도 있고 반환하지 않을 수 있다. 해석은 또한 하나 이상의 중간 매핑 작업을 포함 할 수 있다.

DOI 해석 레코드는 객체가 위치할 수 있고, DOI 이름이 할당된 객체에 대한 다른 정보가 제공되는 하나 이상의 URL을 포함할 수 있다. 이 레코드는 다음의 항목에 국한되지 않고 선택적으로 다음을 포함한다:

자동화된 다중 해석을 통해 DOI 이름은 (다중 URL, 다른 DOI 이름 및 다른 데이터 유형 등) 인터넷상의 임의 수의 다른 주소로 해석될 수 있다. 그 DOI 이름이 여러 가지 가능한 "해석"을 가리킬 수 있으면, 다양한 선택사항들 중에서 어떻게 그 선택을 하는가? 가장 간단하게는, 사용자에게 수동으로 선택할 수 있도록 목록을 제공하는 것이다. 그러나, 이는 점점 더 복잡하고 자동화된 환경에서 확장 가능한 해결책은 아니다. DOI 시스템은 DOI 이름에서 사용자(그리고 더 중요한 것은, 사용자의 어플리케이션 소프트웨어)가 필요로 하는 특정 서비스로 원활하게 전달될 수 있는 "서비스 요청"을 자동화할 수 있다.

multiple_resolution

그림 1. 서비스에 의한 데이터 자동 선택

다중 해석에 관한 현재의 기술 구현에 대한 자세한 내용은 아래 3.8.4.3 다중 URL의 해석(3.8.4.3 Resolution of Multiple URLs)이나, 5장의 5.3 다중 해석 어플리케이션(5.3 다중 해석 어플리케이션)을 참조하라.

 

3.4 DOI 시스템을 위한 해석 요구사항

ISO 26324는 DOI 시스템에서 해석(Resolution)이 만족시켜야 하는 기능적 요구사항을 포함하고 있다.

DOI 이름의 해석을 관리하기 위해 배포된 기술은 다음 목록 a에서 l까지의 기능을 지원한다.

  1. 효율적이고 무한히 확장 가능한 프로토콜
  2. 할당되는 식별자의 절대적인 수나 식별자 길이에 제한이 없다.
 

3.5 핸들 ® 시스템 기술

 

3.5.1 개요

이용 가능한 다른 기술에 비해 여러 가지 실질적인 장점을 제공함으로써 DOI 개념에 대해 식별된 요구사항에 알맞기 때문에 CNRI에 의해 개발된 핸들시스템(Handle System)기술이 DOI 시스템 내에서 해석을 위한 기술로 채택되었다:

다중적이고 확장 가능한 데이터 유형들에 대한 해석은 핸들 시스템 기술의 특징이다. 핸들 시스템에는 미리 존재하는 제약사항이 없으며, DOI 시스템은 핸들 시스템의 어플리케이션이다. 이 어플리케이션은 지식재산권 거래를 위해, 관심 있는 객체를 관리하는데 적합한 특정한 제약사항과 정의된 메타데이터 요소 및 운영정책을 추가한다. 핸들 시스템은 오랜 기간 동안 네트워크 상에서 정보가 관리될 수 있도록 설계된 디지털 객체 아키텍처(Digital Object Architecture)의 해석 구성요소이다. 일부 DOI 구현이 다른 구성 요소를 사용하는 것을 선택할 수도 있지만, DO 아키텍처의 다른 구성 요소(리포지토리 및 레지스트리 구성요소)는 DOI 시스템의 일부가 아니다. (5장 어플리케이션, 5.7절)

핸들 시스템은 로컬 핸들 서비스로 구성되어 있다. 로컬 핸들 서비스(LHS, local handle service)는 하나 이상의 사이트로 구성되고, 하나의 사이트는 하나 이상의 핸들 서버로 구성된다. 핸들 서버는 핸들을 저장한다. 하나의 로컬 핸들 서비스는 고유한데 그것은 Global Handle Registry®이며, “접두사” 핸들을 저장한다. 그 핸들은 LHS로 하여금 다른 모든 핸들들을 저장한 서비스를 찾도록 질의 한다. DOI 이름들은 Handle 구문의 부분으로서 할당된 접두사 10을 독점적으로 사용한다. 그리고 DOI 이름은 이 핸드북에 기술된 DOI 시스템에 전체적으로 사용되어 다른 핸들과 구별된다.

DOI 핸들의 사용에 대한 자세한 내용은 현황표(factsheet)를 참고하고, 핸들 시스템에 대한 다른 정보는 Handle System과 Handle.net Software에 관한 General and Technical FAQ를 참고하라.

 

3.5.2 DOI 이름 해석에 대한 기술지원

CNRI는 계약을 통해 DOI 시스템에 대한 기술 및 운영 지원을 지속적으로 제공한다. 기술 서비스에 대한 관련 계약의 더 자세한 사항은 잠재적인 혹은 현재의 등록 기관들이 사용할 수 있다..

 

3.5.3 DOI 이름 사용에 대한 소프트 웨어 지원

사용 및 개발 중인 도구들의 현재 목록에 대해서는 소스에 대한 설명과 링크를 포함하는 DOI 도구(DOI Tools)를 참조하라.

CNRI는 일부 사용자들과 프로그래머들이 유용하게 사용할 수 있는 servlet과 도구를 제공한다. (자세한 내용은 hdladmin@cnri.reston.va.us로 핸들 시스템 관리자에게 문의하라) 다음의 것들이 제공된다:

net.handle.batch.DOIBatch

DOI 이름에 대한 일괄 로더.

net.handle.apps.admin_servlets

웹을 통해 핸들을 관리하는데 사용되는 servlet, 로컬 웹 서버에서 DOI 이름을 관리하려 할 때 유용하다..

net.handle.apps.simple

자신의 핸들 소프트웨어를 가동하는 것을 결정하는 경우, 이 패키지는 핸들 클라이언트 라이브러리를 어떻게 사용하는지에 대한 많은 예제를 가지고 있다.

net.handle.apps.tools, net.handle.apps.site_tool

핸들 서버에 대한 낮은 수준의 유지 보수를 위한 여러 가지의 유틸리티이다. 어떤 것을 작성하기 전에 스스로 이 라인들을 따라서 확인하여야 한다.

어플리케이션 프로그래밍 인터페이스(APIs)

Java뿐만 아니라, Python, Perl, C에 대한 라이브러리가 사용가능하다. DOI 시스템의 특정 라이브러리는 Acrobat/DOI 시스템 서비스 프로토타입을 위해 개발되고 있다.

3.6 DOI 이름의 "상태 데이터" 유지

DOI 시스템의 효과적인 운영은 DOI 이름이 적합한 URL 또는 다른 데이터 유형으로 정확하게 해석 되는 것에 따라 좌우된다.

DOI Data

그림 2. DOI 이름 레코드

"상태 데이터"의 유지는 DOI 이름 등록자가 책임져야 하는 필수적인 요소이다. 오직 등록자 또는 등록자의 권한과 역할을 하는 서비스 조직에게만 상태 데이터를 유지하도록 허용된다. DOI 이름 레코드 내에서 DOI 이름 상태 데이터 레코드에 접근 권한에 대한 보다 정교한 모델을 생각할 수 있다. 이들에 대한 요구 사항은 현재 IDF에 의해 연구되고 있다.

DOI 이름이 인터넷 상에서 접근할 수 있는 어떤 데이터로도 해석되는 것을 허용하기 위해서, DOI 이름이 해석될 수 있는 데이터 유형들은 핸들 시스템 내에서 완전히 확장 가능하다.

(현재 가장 일반적인 어플리케이션) URL 데이터 유형과 함께 사용하기 위해, 우리는 DOI 이름의 데이터가 상대 경로보다 전체 경로(예를 들어 http://www.somepublisher.com/photo/photo#1.gif)로 입력할 것을 권장한다. 상대 경로 링크가 DOI 이름 데이터로 사용될 수 있지만, DOI 이름이 어떻게 해석 될지는 예측할 수 없다. (예을 들어 현재 기본 html 참조가 무엇인지?)

DOI 이름은 Java 애플릿이나 CGI 스크립트나 다른 동적 메커니즘으로 해석될 수 있다.

 

3.7 핸들 시스템의 해석 인터페이스

현재의 웹 브라우저 기술은 브라우저가 간단한 위치보다는 객체의 이름으로 처리 할 수 있도록 추가 기능을 요구한다(웹에서 이름에 대한 접근 방식의 공통적인 사실). 따라서, DOI 이름 해석 기능을 최대한 활용하기 위해, 추가적인 브라우저 기능이 필요하다. 미래에 이 기능이 브라우저에 일반적으로 내장될 것으로 예상되고, IDF는 이를 장려하기 위해 적극적인 토론을 벌이고 있다. 필요한 기능은 현재 다양한 방식으로 제공된다.

 

3.7.1 사용자 정의 해석 소프트웨어

개별 어플리케이션 또는 완전히 분리된 시스템에서 사용하기 위해, 핸들 시스템 클라이언트 라이브러리(Handle System Client Library)는 자유롭게 사용될 수 있고, 필요에 따라서 새로운 해석 클라이언트를 개발하기 위해 사용될 수 있다. 해석은 IDF와는 완전히 독립적으로 자유롭게 사용될 수 있지만, 우리는 다음 두 가지를 위해 우리에게 그들의 어플리케이션에 대해 알려주기를 바란다. 우리는 1) 그것이 공공인 경우 다른 사람들이 그것을 알 수 있게 하고 2) 개발자들과 함께 그들의 DOI 시스템에 대한 이해와 그들의 노력에 대한 성공을 향상시킬 것이다.

 

3.7.2 원시 해석기

프록시 서버의 사용 없이 "doi:10.123/456" 형식의 DOI 이름을 해석하기 위해 CNRI로부터 "해석 플러그인"(resolver plug-in)을 브라우저에 장착할 수 있다. 사용자는 간단하게 플러그인을 다운로드하고 설치한 후 DOI 이름을 단순히 클릭(혹은 브라우저에서 주소 표시 줄에 DOI 이름 타이핑)하기면 하면 DOI 이름이 바로 해석 된다. - 기타 HANDLE.NET®Software 를 참조해라.

 

3.7.3 프록시 서버

웹 브라우저의 '기능‘을 확장할 필요 없이, 대안으로, 사용자는 DOI 시스템 프록시 서버(선호되는 http://0-doi.org.pugwash.lib.warwick.ac.uk 또는 http://dx.doi.org)를 사용하여 DOI 이름을 해석할 수 있다. 이 경우 DOI 이름의 해석은 URL 구문의 사용에 따라 달라진다. 예를 들면, 우리가 계속 사용해 온 DOI 이름 doi:10.10.123/456은 주소: http://0-doi.org.pugwash.lib.warwick.ac.uk/10.123/456로부터 해석될 것이다. 표준 브라우저는 이와 같은 형태의 DOI 이름을 만나면 이것을 해석할 수 있을 것이다. 프록시 서비스(doi.org 및 dx.doi.org)는 IPv6를 통해 액세스할 수 있으며, DNSSEC를 지원한다.

프록시 서버(핸들 시스템과 HTTP 간 게이트웨이)의 사용은 HTTP 참조자 필드와 간섭되지 않는다. (즉, 사용자가 소스 주소 대신 doi.org 또는 dx.doi.org에서 오는 것처럼 보이지 않고, 링크의 소스 주소를 유지된다). 아무것도 프록시 서버를 "통하여" 가지 않는다. 프록시 서버는 현재 URL 또는 핸들 해석과 관련된 정보를 다시 본래의 클라이언트에 되돌려 준다. 그냥 그렇지 않은 것 같게, 사용자의 클라이언트는 최종 HTTP GET 요청을 보낸다.

HTTP 프록시 서버(http://doi.org의 url형태)를 통해 사용되는 DOI 이름은 지속적으로 영구성을 가지게 되는 조건은 다음과 같다. (1) 코어 DOI 시스템이 유지되는 한, 즉 소정의 DOI 이름 10.123/456이 핸들 시스템을 사용하여 해석될 수 있는 한, (2) doi.org라고 명명된 한 프록시 서버의 운영이 유지되는 한, (3) http 기반의 웹 기능을 가능하게 하는 코어 네트워크 서비스가 유지되면, 프록시를 통해 참조된 DOI 이름(http://0-doi.org.pugwash.lib.warwick.ac.uk/10.123/456)은 영구적으로 남게 될 것이다. 왜 그런지에 대한 이해의 핵심은 모듈화이다. 핵심 DOI 이름 해석 서비스는 프록시에 의해 사용되지만 프록시에 의해 제약을 받지는 않는다. doi.org 프록시의 지속적인 운영과 어떠한 방식으로든 간섭하지 않고 핵심 DOI 이름 해석 시스템에 접근하기 위해서, 추가적인 게이트웨이가 구축될 수 있고, 추가적인 방법이 사용될 수 있다.

프록시를 만들었고 사용하는 것을 지지하는 CNRI와 IDF는 프록시가 DOI 이름 기반 웹 링크의 수백만의 인스턴스의 무결성을 유지하는 필수 구성요소가 되도록 함으로서, 그것을 영구적으로 유지하기 위해 헌신하고 있다. 오랜 시간 동안 그들 링크의 유용성을 유지하는 것은 핵심 DOI 시스템과 특정 게이트웨이 서비스인 doi.org 둘을 유지하는 것이 필요할 것이다. 그들 링크는 doi.org를 참조해서 핵심 DOI 시스템에 대한 접근을 획득한다. 이것은 물론 모두 고유하지는 않으며, 서로 겹쳐진 계층 서비스인 인터넷 테마의 또 다른 변형이다. doi.org 자체는 IP 주소와 라우팅 등에 의존적인 도메인 이름 시스템(DNS)에 좌우된다. 핵심 DOI 이름 해석 설비가 다양한 방법으로, 여러 서비스에 사용되었기 때문에, 이 그림은 아마도 시간이 지남에 따라 더 복잡하게 성장할 것이다 (우리는 그러길 바란다). 예를 들어, OpenURL 해석기는 doi 이름을 원시 형태(예 id=doi:10.123/456)로 찾을 것이며, doi 프록시 서버를 사용하거나, 자신만의 doi 이름 프록시 서버를 구축하거나, 아니면 doi 시스템에 직접 질의를 날릴 핸들 프로토콜을 사용하는 중에서 선택할 수 있다.

프록시 정책(Proxy Policies)에 관련된 정보는 IDF 회원 및 RA들은 이용 가능하다.
 

3.7.4 프록시 검증, 모니터링 및 보고

IDF 회원은 프록시 검증 요구 사항, 모니터링 및 보고 정책의 요약을 이용할 수 있다.

 

3.7.5 다른 메커니즘

요구되는 기능성이 자바 스크립트와 같은 스크립팅 기능으로 브라우저에 탑재될 수 있다. 우리는 이것을 장기적 DOI 시스템 전략으로 권장하지 않는다. 왜냐하면, 스크립트가 브라우저에서 중장기적으로 지원되는 것을 보장할 수 없기 때문이다. 예를 들어, 다수의 보안 전문가들은 현재 자신의 전자 메일 시스템 환경 설정에서 자바 스크립트를 해제하도록 컴퓨터 사용자를 촉구하고 있다.

관련 어플리케이션의 경우, DOI는 info-URI 네임스페이스(IETF RFC 4452, 공공 네임 스페이스의 식별자와 정보 자산에 대한 "info" URI 스키마)안에 등록된 URI인 것을 참고하라. 정보지 "DOI 시스템 및 인터넷 식별자 규격"(DOI System and Internet Identifier Specifications)을 참조하라.

 

3.8 DOI 시스템 프록시 서버의 기술적인 세부사항

사용자는 DOI 시스템 프록시 서버(선호되는 http://0-doi.org.pugwash.lib.warwick.ac.uk 또는 http://dx.doi.org)를 통해 구조화된 DOI 이름을 해석할 것이다. 이 경우 DOI 이름의 해석은 URL 구문의 사용에 따라 달라진다. 예를 들어, DOI 이름 doi:10.10.123/456은 주소 http://0-doi.org.pugwash.lib.warwick.ac.uk/10.123/456로부터 해석될 것이다. 표준 브라우저는 이와 같은 형태의 DOI 이름을 만나면 이것을 해석 할 수 있을 것이다. 프록시 서비스(doi.org 및 dx.doi.org)는 IPv6를 통해 액세스 할 수 있으며, DNSSEC를 지원한다.

 

3.8.1. 프록시 서버 시스템을 사용하는 DOI 해석

DOI 시스템은 디지털 개체를 관리하기 위해 Handle System®을 사용한다(DOI 정보지 "DOI 시스템과 핸들 시스템(DOI System and the Handle System)“참조). 인프라스트럭처 수준에서 DOI 이름은 핸들이다.

DOI 시스템 프록시 서버는 기본적으로 핸들 시스템과 어떻게 대화하는지를 알고 있는 웹 서버이다. 이 글을 쓰는 시점에서, 웹에서 발견된 거의 모든 DOI® 이름은 DOI의 이름 해석을 위해 프록시 서버를 사용하는 URL에 내포된다. 예를 들면, 프록시의 도메인 명과 DOI 이름을 결합하는 HTTP 요청에 대해, 예를 들어,

http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1000/demo_DOI

프록시는 그 DOI 이름에 대해 핸들 시스템을 검색하고, 핸들 레코드 안의 URL을 가져 온다. (또는 핸들 레코드 안에 여러 개의 URL이 있으면 하나를 선택한다. 그 선택에는 특정한 순서가 없다.) 그리고 사용자의 웹 브라우저에게 그 URL로 방향을 바꾸는 HTTP를 보낸다.

DOI 이름의 증가는 하나의 기본 URL에 추가 데이터를 포함한다. 이것은 때때로 다중 해석이라고 언급된다. 이러한 추가된 값은 향상된 메타데이터 또는 관련 문서의 위치와 같은 여러 데이터의 이점을 활용할 수 있는 고급 어플리케이션에서 사용하도록 의도되었다.

URL 형식의 핸들 값 이외에도 프록시 서버는 10320/loc 유형의 핸들 값을 이해한다. 이러한 값들은 다중 리다이렉션 말단을 기술하는 XML과 프록시가 사용해야 하는 조건을 포함하고 있다. 자세한 내용은 3.8.4.3 10320/loc 핸들 형식을 사용하는 여러 URL의 해석 절을 참조하라.

프록시 서버는 DOI 이름을 찾을 수 없을 때 “DOI Name Not Found” 라는 오류 페이지를 표시한다.

DOI 이름 10.1000/demo_DOI와 10.1000/demo_DOI/는 둘 다 유효한 DOI 이름이다. 하지만 보통 마지막에 “/”를 포함하여 DOI 이름을 생성할 것 같지는 않다. 만약 프록시 서버가 마지막에 “/”가 들어있는 DOI 이름 해석을 요청 받고, 그 DOI 이름을 찾을 수 없으면, 그 프록시 서버는 요청된 DOI 이름이 “/”를 포함하고 있다는 경고와 "/"를 제외한 동일한 문자열 해석을 위한 클릭할 수 있는 링크를 포함하는 오류 보고를 반환할 것이다.

DOI 시스템 프록시 서버는 모든 서버들에 걸쳐서 로드가 고르게 분산되어, 여러 곳에서 가동되는 사실상 다중 서버들이다. 빠른 해석을 위해, 프록시 서버는 TTL(Time to Live)을 24시간으로 설정하고 핸들 값을 저장한다. 만약 핸들 값이 변경되면 새로운 값이 반환되기까지 24시간이 걸린다는 의미이다.

IDF 또한 shortDOI™ 서비스를 위해 프록시 서버를 가동하고 있다. 그 서버는 DOI 프록시 서버 규격의 일부가 아니다.

 

3.8.2 프록시 서버 질의 매개변수

noredirect
URL 또는 10320/loc 값을 사용하여 리다이렉션하지 말고, 대신 핸들 값을 표시한다.
ignore_aliases
보통 프록시는 입력 핸들 대신에 해석되야 하는 핸들이 되는 HS_ALIAS 유형의 핸들 값을 갖는다. 이 매게 변수가 있으면 HS_ALIAS 유형의 값은 무시된다.
auth
신뢰할 수 있는 질의. 프록시는 캐시를 우회하고 권위 있는 서버에서 핸들을 해석한다.
cert
인증된 질의. 프록시는 핸들 서버로부터 인증 응답을 요구 할 것이다. 일반적으로 최종 사용자는 필요 없다.
index
단지 지정된 인덱스의 핸들 값을 해석한다. 여러 인덱스를 해석하기 위해서는 반복될 수 있다.
type
단지 지정된 유형의 핸들 값을 해석한다. 여러 유형을 해석하기 위해서는 반복될 수 있다.
urlappend
이 매개변수의 값은 리다이렉션에 사용되는 URL의 끝에 추가된다.
locatt=key:value
다중 리다이렉션에 대한 키:값 쌍을 지정하여, 10320/loc 값에서 리다이렉션의 선택을 결정한다.
action=showurls
다중 리다이렉션에 대해 가능한 리다이렉션 위치의 XML 표현을 반환한다.
nols=y
일부 도서관과 다른 기관은 로컬 서비스를 사용하여, DOI 시스템 프록시 서버가 사용자들을 "적절한 복사본"으로 리다이렉션하도록 특별한 쿠키를 사용한다. 예를 들어, 사용자는 요금을 요구하는 랜딩 페이지 대신에, 도서관에 의해 이미 구매된 저널 기사의 원문으로 리다이렉트션될 수 있다. 사용자는 로컬 서비스 리다이렉션을 방지하기 위해 "nols=y" 질의 매개변수를 추가 할 수 있다.
 

3.8.3 프록시 서버 REST API

DOI 시스템 프록시 서버 REST API는 HTTP를 사용하여 DOI 이름 해석에 프로그래밍 방식으로 액세스 할 수 있다.

요청/응답의 예

REST API 요청의 표준 HTTP GET을 실행함으로써 생성될 수 있다 .

/api/handles/<handle>

API는 JSON을 반환한다.

예를 들어, http://0-doi.org.pugwash.lib.warwick.ac.uk/api/handles/10.1000/1는 다음과 같은 응답을 반환한다. {

{
  "responseCode": 1,
  "handle": "10.1000/1",
  "values": [
    {
      "index": 100,
      "type": "HS_ADMIN",
      "data": {
        "format": "admin",
        "value": {
          "handle": "0.NA/10.1000",
          "index": 200,
          "permissions": "011111111111"
        }
      },
      "ttl": 86400,
      "timestamp": "2000-04-13T15:08:57Z"
    },
    {
      "index": 1,
      "type": "URL",
      "data": { "format": "string", "value": "http://0-www.doi.org.pugwash.lib.warwick.ac.uk/index.html" },
      "ttl": 86400,
      "timestamp": "2004-09-10T19:49:59Z"
    }
  ]
}

응답형식

응답은 "responseCode" (Handle 프로토콜 응답코드를 지시하는 정수)를 포함하는 JSON 객체이다. 이는 핸들의 해석된 결과의 반환 값이다. 정상적일 경우 값들의 목록를 반환하고, 오류인 경우 그 오류를 설명하는 선택적 메시지를 돌려준다.

각 값은 일반적으로 다음 5가지의 속성을 가진 JSON 객체이다:

핸들 값 데이터는 "format" 문자열과 "값"을 가진 객체이다.

응답코드

질의 매개변수 / Query Parameters

DOI 시스템 프록시 서버 REST API는 CORS-호환성이 있다. 그러나 JSONP 콜백은 또한 "callback" 질의 매개변수를 사용하여 지원된다.

"pretty" 질의 매개변수는 서버에게 JSON 출력을 깔끔하게 할 것을 요청한다.

"auth" 질의 매개변수는 프록시 서버에게 자신의 캐시를 우회하여 새로운 핸들 데이터를 직접 1차 핸들 서버에서 조회하도록 명령한다.

"cert" 질의 매개변수는 프록시 서버에게 소스 핸들 서버로부터 인증된 응답을 요청하도록 명령한다. 일반적으로 최종 사용자는 필요하지 않다.

"type" 및 "index" 질의 매개변수는 해석된 응답이 특정 유형 및 인덱스로 국한될 수 있게 한다. 다중의 "type"과 "index" 매개변수가 허용되며, 지정된 유형 또는 인덱스와 일치하는 값들이 반환된다.

예를 들어, http://0-doi.org.pugwash.lib.warwick.ac.uk/api/handles/10.1000/1?type=URL&callback=processResponse는 다음과 같은 응답을 산출한다.

processResponse({
  "responseCode": 1,
  "handle": "10.1000/1",
  "values": [
    {
      "index": 1,
      "type": "URL",
      "data": { "format": "string", "value": "http://0-www.doi.org.pugwash.lib.warwick.ac.uk/index.html" },
      "ttl": 86400,
      "timestamp": "2004-09-10T19:49:59Z"
    }
  ]
});

 

3.8.4 추가 기능

DOI 프록시 서버를 사용하여 그들의 DOI 이름을 구조화하는 DOI 시스템 사용자에게 추가적인 서비스를 제공하기 위해서, DOI 시스템 프록시 서버에 몇 가지 추가적인 기능이 구축되었다.

3.8.4.1로컬 콘텐트 서버 (The "Appropriate Copy" 문제)

학술 및 기술 저널의 기사에 대한 DOI 이름은 일반적으로 출판사의 웹 사이트로 해석 된다. 해당 웹 사이트에서 기사를 검색하는 것은 일반적으로 비용을 지불해야 하거나 또는 구독을 해야 한다. 도서관은 일반적으로 자신의 사용자들을 위해 저널의 사본을 구입하여 로컬 컬렉션에 넣어 두며, 그들은 종종 소유하거나 또는 저널의 여러 사본을 구독한다. 이러한 기관의 사용자를 위해서, DOI 이름이 적합하게 해석돼야 하는 그 주소는 해석 요청을 하는 사용자의 위치 또는 소속에 따라 달라진다. 그리고 적합한 선택은 일반적으로 기관의 로컬 복사본 중의 하나이다.
국제DOI 재단, CrossRef, CNRI, 도서관 및 도서관 서비스 제공자들은 이것을 "적절한 복사 문제"라고 부르게 되었고, 해결책과 프로토타입 개발에 협력하기 시작하였다(자세한 내용은 D-Lib Magazine, September 2001, "Linking to the Appropriate Copy"를 참조하라.)
DOI 이름 해석 시스템, CrossRef 메타데이터 데이터베이스, OpenURL의 조합은 적절한 복사 문제에 대한 실용적인 해결책을 제공한다. 이 아키텍처의 주요 구성 요소는 다음과 같다. (1) 항목에 대한 질의를 도서관의 적절한 복사본에 맞출 수 있는 로컬 콘텐트 서버, (2) 로컬 콘텐트 서버에 질의를 리다이렉션 할 수 있는 DOI 이름 해석 시스템, (3) 질의 생성자가 적절한 로컬 콘텐트 서버를 식별하기 위한 해석 시스템으로의 경로, (4) 로컬 콘텐트 서버가 그 질의로 해당 복사본을 찾기에 충분한, 항목에 대한 메타데이터의 소스.
그 도서관 소속 회원에게 CrossRef에서 제공하는 해결책은 다음과 같다. 회원 기관의 사용자가 DOI 이름을 클릭하면, DOI 이름 및 (미리 "CookiePusher" 메커니즘을 통해 사용자의 웹 브라우저에서 설정된) 쿠키가 DOI 시스템 프록시 서버로 보내진다. 프록시 서버는 쿠키에서 식별된 로컬 콘텐트 서버를 인식하고, DOI 이름을 포함하는 OpenURL를 구성하여, 사용자 브라우저로의 HTTP "리다이렉션"을 통해, 사용자의 로컬 해석기로 보낸다. 로컬 해석기는 OpenURL 형식의 DOI 이름을 CrossRef로 보낸다. CrossRef는 그 DOI 이름에 의해 명명된 항목에 대한 메타데이터를 반환한다. 로컬 콘텐트 서버는 이것을 로컬에 보유하고 있는 기사로 인식하고, 그 항목을 지시하는 URL을 구성하여, HTTP "redirect"로써 사용자의 브라우저로 보낸다.
그 기사를 로컬에 보유하고 있지 않으면, 로컬 콘텐트 서버는 로컬에 복사본이 없다는 플래그를 설정하고, 프록시 서버로 요청을 반환한다. 그러면 프록시 서버는, 대개의 경우 그랬던 것처럼, 사용자의 브라우저를 출판사 사이트로 리다이렉트하는 DOI 이름 해석을 한다.
완전한 이 과정의 설명과, 어떻게 도서관들이 이 로컬 연결 솔루션에 참여할 수 있는지 알고 싶으면 그들의 웹사이트 ( documentation on local linking for CrossRef library affiliates )를 참조하라.
현재 해결책은, 이 문서가 작성되고 있는 시점에는, 문제에 관련된 대부분의 DOI 이름 및 관련 메타데이터의 소스를 유지하는 CrossRef에 국한된다. 이러한 상황은, 그러나, DOI 시스템의 지속적인 성장으로 변할 것이다. 그리고 일반적으로 메타데이터의 여러 소스가 미래에 함께 수용되어야 할 것으로 여겨진다. 이것은 DOI 이름 해석 데이터와 로컬 콘텐트 서버의 동작 양쪽에 대해 조정을 요구할 것이다. 초기에 "적절한 복사 문제"에 관한 이러한 인식을 해결하기 위해 함께한 그룹들은 그 주제에 대한 예비 토론을 개최하고, 상황이 발전함에 따라 추가적인 공동의 노력에 대한 필요성을 예상하고 있다.
"CookiePusher" 메커니즘(자세한 내용은 D-Lib기사 참조)은 사용자의 브라우저에 쿠키를 설정하는 데 사용된다. 이 쿠키는 프록시 서버에 의해 인식되며, 프록시 서버가 DOI 이름 해석 요청을 리다이렉션 할 URL을 포함하고 있다.권한이 없는 사용자가 쿠키를 설정하는 것과 그들 자신의 개인적인 해석기로 리다이렉션 하는 트레픽을 방지하기 위해, 권한이 부여된 로컬 콘텐트 서버의 URL을 담고 있는 BASE_URL 목록이 CookiePusher에 포함되어 있다. BASE-URL은 스크립트, 디렉토리, 또는 최상위 도메인에 대한 URL이 될 수 있지만, 그것은 꼭 서버가 알고 있는 OpenURL이어야 한다. 요청에 BASE-URL이 목록에 없는 경우, 스크립트는 쿠키를 설정하지 않을 것이며, "no cookie for you" 메시지를 반환한다. 가입 할 때 BASE-URL은 CrossRef 관계 기관에 의해 수집된다.

CookiePusher 스크립트는 DOI 시스템 웹 사이트 (http://www.doi.org).에서 실행된다. 프록시 서버 선호되는 (http://doi.org (또는) or http://dx.doi.org)는 DOI.ORG®도메인 아래에 있다. CookiePusher 스크립트의 URL은 음과 같다:

http://0-www.doi.org.pugwash.lib.warwick.ac.uk/cgi-bin/pushcookie.cgi

로컬 콘텐트 서버의 URL 접두사를 포함하는 CookiePusher에게 요청하는 예는 다음과 같다:

http://0-www.doi.org.pugwash.lib.warwick.ac.uk/cgi-bin/pushcookie.cgi?BASE-URL=http%3A//university.library.edu%3A9003/local_linking/
URI 16진수(%) 인코딩을 하는 것을 권고한다.

사용자의 웹 브라우저 쿠키 파일에 쿠키를 추가하는 요청은 일반적으로 투명한 GIF를 사용하여, 소개 또는 로그인 웹 페이지에서 숨겨진다.

<img src="http://0-www.doi.org.pugwash.lib.warwick.ac.uk/cgi-bin/pushcookie.cgi?BASE-URL=
http%3A//university.library.edu%3A9003/local_content_server/">transparent.gif</img>

(TTL이 24시간으로 설정된) 샘플 쿠키는 다음과 같다:

Name: Demo-OpenURL
Information: \"http://university.library.edu:9003/local_content_server"
Domain: .doi.org
Path: /
Server Secure: no
Expires: Wednesday, October 23, 2013 10:28:11 PM

쿠키가 설정된 후에, 프록시 서버는 쿠키에서 식별된 로컬 콘텐트 서버를 인식한다. 그리고 로컬 서버 URL과 DOI 이름을 포함하는 OpenURL을 구성한다:

http://university.library.edu:9003/local_content_server/openurl?doi=10.1000/demo_DOI
그리고 HTTP “리다이렉트”를 통해서 로컬 콘텐트 서버에 요청을 보낸다.

콘텐트의 로컬 복사본이 없는 경우, 로컬 서버는 "nols = y" 플래그를 설정하여 프록시 서버에게 그 요청을 돌려줘야 한다. 그 프록시 서버는 그러면 DOI 이름을 해석하고 출판사의 콘텐트로 사용자를 보낼 것이다. (프로토타입에 사용된, 더 이상 사용되지 않는 "nosfx = Y" 설정도 계속 지원되고 있다.) "no local service" 플래그를 정확하게 설정하는 것이 무한 루프를 피하기 위해 중요하다.

http://0-doi.org.pugwash.lib.warwick.ac.uk/openurl?id=doi:10.1000/demo_DOI&nols=y

3.8.4.2 매개변수 전달

DOI 시스템과 CrossRef가 존재하기 전에는 학술 출판 커뮤니티는 데이터를 교환하기 위해 표준 URL에 포함된 (이름/값 쌍) 매개변수를 사용한 양자 간 연결 계약을 체결했다. 이 행위는 다른 출판사 사이트나, 저널 및 기사와 같은 다른 사이트로부터 들어오는 요청들에 관한 정보를 수집할 수 있게 하였다. 그런 다음 특수 액세스 규칙을 구현하거나, 요청한 사람을 기준으로 그들의 콘텐트에 대한 가격을 설정할 수 있었다.
출판사들이 DOI 이름을 사용하기 시작할 당시에, 그들은 DOI 이름과 DOI 시스템의 프록시 서버가 어떻게 매개변수의 교환을 용이하게 하고, 양자 간의 연결 계약의 필요를 제거하기 위해 어떻게 사용될 수 있는지를 생각하기 시작하였다. 몇 년에 걸쳐 진전되고, 지금은 CrossRef의 회원이 된 출판사들에 의해 합의된 절차가 프록시 서버에 구현되었고 "매개변수 전달(Parameter Passing)“이라고 불리게 되었다.
매개변수 전달에서, 두개의 URL이 관련이 되는데, 둘은 질의 문자열 또는 포함된 매개변수일 것이다. 매개변수는 (1) 'referrer'가http://0-doi.org.pugwash.lib.warwick.ac.uk/ 에게 전송한 DOI 이름을 가지고 있는 해석 요청 (2) 'referent'의해 DOI 시스템에 등록된 그 DOI 이름과 연관된 URL. 매개변수 전달은 'out-bound' 링크를 형성하기 위해 두 URL의 질의 문자열을 함께 연결하는 것을 요구한다. 두 문자열에 사용된 매개변수의 이름은 고유해야 하며, 모든 당사자를 위해 정의된다. 이름 충돌의 가능성을 제거하는 데 사용할 수 있는 매개변수 이름의 세트를 기술할 수 있기 때문에, 그 URL을 위해 OpenURL 형식이 선정되었다.

DOI 시스템 프록시 서버는 OpenURL의 형태로 해석 요청을 받아들인다. 예를 들면 :

http://0-doi.org.pugwash.lib.warwick.ac.uk/openurl?url_ver=z39.88-2003&rfr_id=ori:rid:crossref.org&rft_id= doi:10.1256/003590&rfr_dat=cr_setver%3d01%26cr_pub%3dSource%20Publisher%26cr_work%3dSource %20Journal%20Title%26cr_src%3dSRC-NAME
이것은 매개변수 전달(parameter passing)로 프록시 서버에 의해 인식된다. 이것은 DOI 이름을 해석할 것이며, 매개변수 전달에 참여하는 기관들을 알아내기 위한 ‘사전 합의된’ 목록에 대해 URL의 도메인을 체크한다.

URL이 ‘사전 합의된’ 목록 안에 있는 경우, 프록시 서버는 새로운 URL을 다음과 같이 구성한다.

대상체는 중첩된 파라미터를 이용할 수 있는 서비스를 구현한 것으로 가정된다. 가정은 매개변수 전달에 참여하는 것에 의해, 출판사는 공통된 CrossRef 매개변수 세트에서 식별된 일부 또는 모든 매개변수를 받아들일 것이다.
혹은 OpenURL 형식의 변경 또는 매개변수 전달 참가자의 요구 사항 변화에 따른, 매개변수 변경은 CrossRef Help 도움말 문서에서 설명한다.

3.8.4.3 10320/loc 핸들 형식을 사용하는 여러 URL의 해석

DOI 시스템 프록시 서버 또는 웹 브라우저 플러그인을 사용하는 주요 용도 중 하나는, 자원에 대한 URL를 얻기위해 DOI 이름(handle)을 해석하는 것이다. 다중 URL 값을 갖는 DOI 이름의 경우, 프록시 서버 (http://doi.org에서, 그리고 http://hdl.handle.net에서 하나)는 단순히 DOI 이름 해석에서 반환된 값 목록 중 첫 번째 URL 값을 선택한다. 목록의 순서는 정해져 있지 않기 때문에, 클라이언트가 리다이렉션 할 URL 목록을 더 지능적으로 선택하는 것이 불가능하다. 핸들 및 다수의 URL이 포함된 DOI 이름 목록에서 특정 리소스의 URL 선택을 향상시키기 위해, 그리고 handle-to-URL 해석 프로세스에 기능을 추가하기 위해, 10320/LOC 핸들 값 유형이 개발되었다.
배경
모든 핸들, 즉 모든 DOI 이름은, 그것에 할당된 값들의 세트를 가지고 있으며, 이들 각각의 값은 구문과 데이터의 의미를 정의하는 유형을 갖는다. 관리를 위한 입력 된 값 중 일부는 소유자와 생성 날짜이다. 다른 것들은 클라이언트가 사용하기 위한 것이다. URL 문자열 또는 이메일 주소, 또는 바이너리 데이터, XML 코드, 또는 다른 핸들과 같은 복잡한 데이터 유형들이 그것이다.
사용자가 사용자 커뮤니티를 통해 등록 및 인식되지 않는 유형을 할당하는 경우 클라이언트가 충돌을 피하기 위해, 유형들은 자신의 핸들을 할당 받아서 정의되고 핸들 시스템에 등록될 수 있도록 하는 프로세스가 현재 개발 중에 있다. 임의의 다섯 자리 문자열인, 접두사 '10320‘은 핸들 유형을 식별하기 위한 핸들 시스템 관리자가 따로 선점해 두었다. 유형 10320/loc의, 접미사 'loc'는 단순히 위치에 대한 약어이다.
속성
유형 10320/loc는 위치 목록이 포함된 XML 형식의 핸들 값을 기술한다. 각각의 위치는 그 위치가 사용될지 또는 언제 사용될지를 결정하는 것을 도와주는 관련된 속성들의 세트를 갖는다. 위치의 전체 목록은 선택 방법의 정렬된 세트를 포함하고 있어서, 해석 클라이언트가 어떻게 위치를 선택해야 하는지에 관한 힌트를 포함할 수 있다. 프록시 서버(또는 임의의 다른 해석 클라이언트)는 해석기의 상황(프록시 서버의 경우에 HTTP 요청) 및 각 위치의 특성에 기초하여 위치를 선택하기 위해, 각각의 알려진 선택 방법을 적용 할 수 있다.
위치 세트뿐만 아니라, 세트 내의 각각의 위치 항목의 속성은, 개방형으로 역방향 호환 방식으로 미래에 기능을 추가 할 수 있다. 소수의 속성은 모든 해석기가 이해해야 하는 "표준"으로 정의되었다.
XML 구조의 최상위 수준에서 정의된 속성들은 다음과 같다:
chooseby (선택)
chooseby 속성은 쉼표로 구분된 선택방법 목록을 나타낸다. chooseby 속성이 지정되지 않으면 (현재로서는 "locatt, country, weighted")가 가정된다.
각 위치에 대해서는 다음과 같은 속성들이 정의되어 있다:
href (필수)
위치를 위한 URL.
weight (optional)
(0에서 1사이) 가중치(weight)는 임의의 선택을 수행 할 때 사용한다. 가중치를 0의 값으로 설정하면 그 위치의 것은 다음 세 가지 경우가 아니면 선택되지 않는다. a) 다른 속성에 의해 명시적으로 참조하는 경우, b) 다른 적합한 위치가 없는 경우, 또는 c) 위치가 국가나 언어와 같은 다른 선택 방법 중 하나를 기반으로 선택되는 경우. 위치에 가중치 속성이 없는 경우는 가중치가 1인 것으로 가정된다.
선택방법
현재 정의된 선택 방법들은 다음과 같다:
locatt
프록시/DOI 이름-URI 링크에 전달된 속성에서만 위치를 선택한다. 누군가 doi:10.123/456?locatt=id:1와 같은 링크를 생성하면, id 속성이 1인 위치를 반환한다(즉, 아래의 해석 예에서 두 번째 위치).
country
클라이언트의 국가와 일치하는 'country' 속성이 있는 경우에만 위치를 선택한다. 일치하는 위치를 찾을 수 없는 경우는 이것은 country 속성이 없는 위치를 선택한다(불일치가 아님).http://0-hdl.handle.net.pugwash.lib.warwick.ac.uk 및 http://0-doi.org.pugwash.lib.warwick.ac.uk 프록시는 GeoIP 검색을 사용하여 클라이언트의 국가를 결정한다.
weight
임의의 선택에 근거하여 하나의 위치를 선택한다. 프록시는 음수가 아닌 부동 소수점 수치인 각 위치에 대한 'weight' 속성을 관찰할 것이다. weight는 매우 기본적인 로드 밸런싱을 가능하게 하지만, 일부 위치에만 (예를 들면 country 또는 locatt 속성에 의해) 직접 선택될 수 있도록 하는 방법이다. 가중 선택 방법이 모두 음수 가중치(non-positive weight)를 갖는 위치들에만 적용되면, 위치 가중치들을 무시하면서 임의로 나머지 위치 중 하나를 선택한다.

단일 위치가 선택될 때까지 프록시는 순서대로 알려진 선택 방법을 반복할 것이다. 각 반복 후에 프록시는 다음의 네 단계 중 하나를 취할 것이다:

Resolution

아래의 위치 속성 목록이 들어있는 10320/loc의 값 유형을 갖는 DOI 이름 10.123/456의 참조를 위해:

      <locations>
        <location id="0" href="http://uk.example.com/" country="gb" weight="0" />
        <location id="1" href="http://www1.example.com/" weight="1" />
        <location id="2" href="http://www2.example.com/" weight="1" />
      </locations>

다음과 같은 선택들이 만들어 질수 있다:
Reference : 영국에 위치한 클라이언트로부터 10.123/456
Result : "country" 선택 방법은 첫 번째 위치의 ‘country’ 속성 및 클라이언트의 위치에 기초하여 첫 번째 위치를 선택한다.
Reference : 영국 외부에 있는 클라이언트로부터 10.123/456
Result : "country" 선택 방법이 'country' 속성을 기초로 고려하여 첫 번째 위치를 제거하고 "weight" 무작위 선택 방법을 사용하여 마지막 두 위치 중 하나를 선택한다.
Reference : 10.123/456?locatt=id:1
Result : "locatt" 선택 방법 및 'ID'속성에 기초하여 두 번째 위치가 선택된다.
Reference : 10.123/456?locatt=id:0
Result : "locatt"선택 방법 및 'ID' 속성에 기초하여 첫 번째 위치가 선택된다. 해석기는 "locatt" 선택 방법이 단 하나의 대응하는 위치 결과가 돼서, "country" 선택 방법은 결코 사용되지 않는다.
Reference: 10.123/456?locatt=country:uk
Result : "locatt"선택 방법과 'country' 속성에 근거하여 첫 번째 위치가 선택된다.
Reference : 10.123/456?locatt=country:us
Result : "country" 선택 방법이 'country’ 속성에 근거하여 첫 번째 위치를 고려대상에서 제거한다. 이는 US의 특정 위치를 찾지 못하고, "weight" 무작위 선택 방법을 사용하여 마지막 두 위치 중 하나를 선택한다.
특정 사용 사례 – CrossRef
DOI 이름 10.1177/1522162802239753이 현재는 발행이 중단된 Graft: Organ and Cell Transplantation 저널의 한 논문에 할당 되었다. DOI 이름은 이 논문을 제공하는 두 개의 아카이빙 서비스를 가리키도록 업데이트 되었다.

프록시가 리다이렉션에 사용하기 위해서, 다음 정보를 포함하는 10320/loc 유형이 레코드에 추가 되었다:

      <locations chooseby="locatt,country,weighted">
        <location id="1" cr_type="MR-LIST"
                  href="http://0-mr.crossref.org.pugwash.lib.warwick.ac.uk/iPage?doi=10.1177%2F1522162802239753" weight="1" />
        <location id="2" cr_src="clockss_su" label="CLOCKSS_SU" cr_type="MR-LIST"
                  href="http://graft.edina.clockss.org/cgi/reprint/6/1/18" weight="0" />
        <location id="3" cr_src="clockss_edina" label="CLOCKSS_Edina" cr_type="MR-LIST"
                  href="href="http://graft.edina.clockss.org/cgi/reprint/6/1/18" weight="0" />
      </locations>

‘chooseby' 속성은 (locatt, country, weight) 기본 설정이다. 이 예에서, 앞의 두 속성을 통한 평가는 실패하고, 프록시는 가중치 선택 기준을 사용한다. 첫 번째 위치(mr.crossref.org)가 가중치 1로 선택된다. 프록시는 mr.crossref.org로 리다이렉트 한다. 이 예제는 CrossRef 사이트에 있는 스크립트로 다음 형식의 DOI 이름을 해석할 때 사용자가 보는 페이지를 만든다:
http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1177/1522162802239753
결과 페이지는 두 개의 아카이브 서비스가 다운로드 할 문서를 제공하고 있음을 보여준다. id="2"와 id="3"인 10320/loc 데이터를 서비스들 중 하나에서 두 소스를 표시하기 위해 CrossRef 스크립트가 사용한다.
일반적인 메커니즘이 많은 다른 구성에서 사용될 수 있다. 하나의 파라미터로 두 위치중 하나의 속성을 가리키는 링크를 만드는 것을 포함하여, 이 경우, 사용자에게 CrossRef에 내장된 다중 해석 페이지를 보여 주지 않고, 사용자는 보통의 방법으로 그곳으로 리다이렉트 된다. 원래의 URL은 10320/loc를 이해하지 못하는 오래된 프록시들과 플러그인들을 대신해서 도와준다.
 

목차    이전 장 : 2. 번호 할당    다음 장 : 4. 데이터 모델

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