 |
홈 | 핸드북 | FACTSHEETS | 자주 묻는 질문 | 자원 | 등록관리기관 | 뉴스 | 회원 영역 |
목차 이전 장 : 2. 번호 할당 다음 장 : 4. 데이터 모델
이 장에서는 해석(Resolution)에 관련된 DOI® 시스템의 구성 요소와 식별자 및 관련 데이터의 영구적인 연결을 제공하는 기능을 설명한다. 개요에서 DOI 이름 해석에 사용되는 핸들 시스템®에 대해 설명한다.
© 국제 DOI 재단 • 최종 갱신 : 2014년 8월 7일
해석이란 식별자가 네트워크 서비스에 입력되고, 식별된 개체에 대한 하나 이상의 현재 정보(상태 데이터)(예를 들어, 위치(URL))를 반환하는 과정이다. DOI 해석기의 한 부분으로써 사용되는 핸들 시스템에 의해 가능한, 다중 해석(Multiple resolution)은 DOI 이름에 의해 식별된 개체에 관한 여러 가지 현재 정보의 결과물의 반환이다. (구체적으로 말하면, 적어도 하나의 URL과 관리를 허용하는 정의된 데이터 구조)
참조 구현으로써 핸들 시스템®을 사용하는 DOI 시스템®의 경우, 해석은, 예를 들어, 10.1000/140과 같은 하나의 DOI 이름에서 하나 이상의 (그래서 다중의) 유형이 정해진 데이터(예를 들어, 객체의 인스턴스를 나타내는 URL이나, 이메일 같은 서비스 또는 하나 이상의 메타데이터 항목들)까지이다. DOI 해석시스템은 매우 유연하고 새로운 요구에 민첩하게 대응할 수 있기 때문에, 새로운 유형이 언제든지 추가될 수 있다. 해석은 두 개의 데이터 개체 사이의 관계를 유지하기 위한 메커니즘으로서 간주될 수 있다. 메타데이터의 항목은 누군가가 두 개체 사이에 존재한다고 주장한 관계이다. 그러므로, 개체들 사이의 메타데이터 관계는 해석에 의해 연결되고 자동화될 수 있을 것이다.
다중 해석을 이용하여, 하나의 DOI 이름은 다중 URL, 다른 DOI 이름들, 또는 메타데이터의 항목을 나타내는 다른 데이터 유형 등의 관련된 임의 수의 다른 값으로 해석될 수 있다. 해석 요구는 현재 정보의 모든 연관된 값, 또는 하나의 데이터 유형의 모든 값을 반환할 수 있다. 이 반환된 값들은 특정한 “클라이언트” 소프트웨어 어플리케이션에서 추가로 더 처리될 수 있다. 가장 간단하게, 사용자에게 옵션의 목록이 제공될 수 있다. 더 정교한 자동화된 프로세스는 추가 처리를 위해 적절한 값을 자동으로 선택하는 것을 허용할 것이다.
DOI 이름은 영구적으로 특정 지식재산권 개체를 식별한다(그 개체는 인터넷에서 액세스 할 수 있는 파일이거나 또는 아닐 수도 있다). URL은 개체와 관련된 인터넷에서의 특정 주소를 제공한다. 이러한 식별 어플리케이션들은 완전히 다르다. 첫 번째 것은 개체를 식별하고, 두 번째 것은 (특정 개체가 찾아지거나 찾아지지 않을 수 있는) 위치를 식별한다.
DOI 시스템의 초창기 어플리케이션은, 영구 식별자를 제공( "404 찾을 수 없음" 메시지를 피하면서)하는, 간단한 단일 주소 해석을 위한 것이었다. 각 DOI 이름은 해석될 수 있는 하나의 URL을 갖는다. 이것은 DOI 레코드 안에 DOI와 DOI가 해석되는 URL 사이의 링크를 적극적으로 관리하여, 개체의 이름을 실행할 수 있는 식별자로 유지하면서 개체의 위치가 변경되는 것을 허용한다. 자세한 내용은 5. 어플리케이션)을 참조하라. URL의 영구성 결여는 DOI 시스템이 해결하기 위해 설계된 -가장 간단한- 첫 번째 도전 과제에 불과하다.
다중 해석(Multiple resolution)은 하나의 개체가 여러 데이터 또는 여러 개체로 해석되는 것을 허용한다.
DOI 이름의 해석은 다음과 같은 것으로 국한되지는 않지만, 위치(URL), 전자 메일 주소, 다른 DOI 이름 및 설명 메타데이터와 같은 연관된 값들로 해석되는 것을 포함할 수 있다. 대상체는 다양한 유형의 자료들이 될 수 있다. (예를 들어, 추상적인 "작품", 물리적 "표현", 또는 공연) 그리고 항상 디지털 파일 또는 다른 표현물의 형태로 직접 접근할 수 있는 것은 아니다. 즉, 해석은 객체의 인스턴스를 반환할 수도 있고 반환하지 않을 수 있다. 해석은 또한 하나 이상의 중간 매핑 작업을 포함 할 수 있다.
DOI 해석 레코드는 객체가 위치할 수 있고, DOI 이름이 할당된 객체에 대한 다른 정보가 제공되는 하나 이상의 URL을 포함할 수 있다. 이 레코드는 다음의 항목에 국한되지 않고 선택적으로 다음을 포함한다:
자동화된 다중 해석을 통해 DOI 이름은 (다중 URL, 다른 DOI 이름 및 다른 데이터 유형 등) 인터넷상의 임의 수의 다른 주소로 해석될 수 있다. 그 DOI 이름이 여러 가지 가능한 "해석"을 가리킬 수 있으면, 다양한 선택사항들 중에서 어떻게 그 선택을 하는가? 가장 간단하게는, 사용자에게 수동으로 선택할 수 있도록 목록을 제공하는 것이다. 그러나, 이는 점점 더 복잡하고 자동화된 환경에서 확장 가능한 해결책은 아니다. DOI 시스템은 DOI 이름에서 사용자(그리고 더 중요한 것은, 사용자의 어플리케이션 소프트웨어)가 필요로 하는 특정 서비스로 원활하게 전달될 수 있는 "서비스 요청"을 자동화할 수 있다.
다중 해석에 관한 현재의 기술 구현에 대한 자세한 내용은 아래 3.8.4.3 다중 URL의 해석(3.8.4.3 Resolution of Multiple URLs)이나, 5장의 5.3 다중 해석 어플리케이션(5.3 다중 해석 어플리케이션)을 참조하라.
ISO 26324는 DOI 시스템에서 해석(Resolution)이 만족시켜야 하는 기능적 요구사항을 포함하고 있다.
DOI 이름의 해석을 관리하기 위해 배포된 기술은 다음 목록 a에서 l까지의 기능을 지원한다.
이용 가능한 다른 기술에 비해 여러 가지 실질적인 장점을 제공함으로써 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를 참고하라.
CNRI는 계약을 통해 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 시스템 서비스 프로토타입을 위해 개발되고 있다.
DOI 시스템의 효과적인 운영은 DOI 이름이 적합한 URL 또는 다른 데이터 유형으로 정확하게 해석 되는 것에 따라 좌우된다.
"상태 데이터"의 유지는 DOI 이름 등록자가 책임져야 하는 필수적인 요소이다. 오직 등록자 또는 등록자의 권한과 역할을 하는 서비스 조직에게만 상태 데이터를 유지하도록 허용된다. DOI 이름 레코드 내에서 DOI 이름 상태 데이터 레코드에 접근 권한에 대한 보다 정교한 모델을 생각할 수 있다. 이들에 대한 요구 사항은 현재 IDF에 의해 연구되고 있다.
DOI 이름이 인터넷 상에서 접근할 수 있는 어떤 데이터로도 해석되는 것을 허용하기 위해서, DOI 이름이 해석될 수 있는 데이터 유형들은 핸들 시스템 내에서 완전히 확장 가능하다.
(현재 가장 일반적인 어플리케이션) URL 데이터 유형과 함께 사용하기 위해, 우리는 DOI 이름의 데이터가 상대 경로보다 전체 경로(예를 들어 http://www.somepublisher.com/photo/photo#1.gif)로 입력할 것을 권장한다. 상대 경로 링크가 DOI 이름 데이터로 사용될 수 있지만, DOI 이름이 어떻게 해석 될지는 예측할 수 없다. (예을 들어 현재 기본 html 참조가 무엇인지?)
DOI 이름은 Java 애플릿이나 CGI 스크립트나 다른 동적 메커니즘으로 해석될 수 있다.
현재의 웹 브라우저 기술은 브라우저가 간단한 위치보다는 객체의 이름으로 처리 할 수 있도록 추가 기능을 요구한다(웹에서 이름에 대한 접근 방식의 공통적인 사실). 따라서, DOI 이름 해석 기능을 최대한 활용하기 위해, 추가적인 브라우저 기능이 필요하다. 미래에 이 기능이 브라우저에 일반적으로 내장될 것으로 예상되고, IDF는 이를 장려하기 위해 적극적인 토론을 벌이고 있다. 필요한 기능은 현재 다양한 방식으로 제공된다.
개별 어플리케이션 또는 완전히 분리된 시스템에서 사용하기 위해, 핸들 시스템 클라이언트 라이브러리(Handle System Client Library)는 자유롭게 사용될 수 있고, 필요에 따라서 새로운 해석 클라이언트를 개발하기 위해 사용될 수 있다. 해석은 IDF와는 완전히 독립적으로 자유롭게 사용될 수 있지만, 우리는 다음 두 가지를 위해 우리에게 그들의 어플리케이션에 대해 알려주기를 바란다. 우리는 1) 그것이 공공인 경우 다른 사람들이 그것을 알 수 있게 하고 2) 개발자들과 함께 그들의 DOI 시스템에 대한 이해와 그들의 노력에 대한 성공을 향상시킬 것이다.
프록시 서버의 사용 없이 "doi:10.123/456" 형식의 DOI 이름을 해석하기 위해 CNRI로부터 "해석 플러그인"(resolver plug-in)을 브라우저에 장착할 수 있다. 사용자는 간단하게 플러그인을 다운로드하고 설치한 후 DOI 이름을 단순히 클릭(혹은 브라우저에서 주소 표시 줄에 DOI 이름 타이핑)하기면 하면 DOI 이름이 바로 해석 된다. - 기타 HANDLE.NET®Software 를 참조해라.
웹 브라우저의 '기능‘을 확장할 필요 없이, 대안으로, 사용자는 DOI 시스템 프록시 서버(선호되는 http://doi.org 또는 http://dx.doi.org)를 사용하여 DOI 이름을 해석할 수 있다. 이 경우 DOI 이름의 해석은 URL 구문의 사용에 따라 달라진다. 예를 들면, 우리가 계속 사용해 온 DOI 이름 doi:10.10.123/456은 주소: http://doi.org/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://doi.org/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 시스템에 직접 질의를 날릴 핸들 프로토콜을 사용하는 중에서 선택할 수 있다.
IDF 회원은 프록시 검증 요구 사항, 모니터링 및 보고 정책의 요약을 이용할 수 있다.
요구되는 기능성이 자바 스크립트와 같은 스크립팅 기능으로 브라우저에 탑재될 수 있다. 우리는 이것을 장기적 DOI 시스템 전략으로 권장하지 않는다. 왜냐하면, 스크립트가 브라우저에서 중장기적으로 지원되는 것을 보장할 수 없기 때문이다. 예를 들어, 다수의 보안 전문가들은 현재 자신의 전자 메일 시스템 환경 설정에서 자바 스크립트를 해제하도록 컴퓨터 사용자를 촉구하고 있다.
관련 어플리케이션의 경우, DOI는 info-URI 네임스페이스(IETF RFC 4452, 공공 네임 스페이스의 식별자와 정보 자산에 대한 "info" URI 스키마)안에 등록된 URI인 것을 참고하라. 정보지 "DOI 시스템 및 인터넷 식별자 규격"(DOI System and Internet Identifier Specifications)을 참조하라.
사용자는 DOI 시스템 프록시 서버(선호되는 http://doi.org 또는 http://dx.doi.org)를 통해 구조화된 DOI 이름을 해석할 것이다. 이 경우 DOI 이름의 해석은 URL 구문의 사용에 따라 달라진다. 예를 들어, DOI 이름 doi:10.10.123/456은 주소 http://doi.org/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://doi.org/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 프록시 서버 규격의 일부가 아니다.
DOI 시스템 프록시 서버 REST API는 HTTP를 사용하여 DOI 이름 해석에 프로그래밍 방식으로 액세스 할 수 있다.
요청/응답의 예
REST API 요청의 표준 HTTP GET을 실행함으로써 생성될 수 있다 .
/api/handles/<handle>
API는 JSON을 반환한다.
예를 들어, http://doi.org/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://www.doi.org/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://doi.org/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://www.doi.org/index.html" },
"ttl": 86400,
"timestamp": "2004-09-10T19:49:59Z"
}
]
});
3.8.4.1로컬 콘텐트 서버 (The "Appropriate Copy" 문제)
CookiePusher 스크립트는 DOI 시스템 웹 사이트 (http://www.doi.org).에서 실행된다. 프록시 서버 선호되는 (http://doi.org (또는) or http://dx.doi.org)는 DOI.ORG®도메인 아래에 있다. CookiePusher 스크립트의 URL은 음과 같다:
http://www.doi.org/cgi-bin/pushcookie.cgi
로컬 콘텐트 서버의 URL 접두사를 포함하는 CookiePusher에게 요청하는 예는 다음과 같다:
http://www.doi.org/cgi-bin/pushcookie.cgi?BASE-URL=http%3A//university.library.edu%3A9003/local_linking/
사용자의 웹 브라우저 쿠키 파일에 쿠키를 추가하는 요청은 일반적으로 투명한 GIF를 사용하여, 소개 또는 로그인 웹 페이지에서 숨겨진다.
<img src="http://www.doi.org/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
콘텐트의 로컬 복사본이 없는 경우, 로컬 서버는 "nols = y" 플래그를 설정하여 프록시 서버에게 그 요청을 돌려줘야 한다. 그 프록시 서버는 그러면 DOI 이름을 해석하고 출판사의 콘텐트로 사용자를 보낼 것이다. (프로토타입에 사용된, 더 이상 사용되지 않는 "nosfx = Y" 설정도 계속 지원되고 있다.) "no local service" 플래그를 정확하게 설정하는 것이 무한 루프를 피하기 위해 중요하다.
http://doi.org/openurl?id=doi:10.1000/demo_DOI&nols=y
DOI 시스템 프록시 서버는 OpenURL의 형태로 해석 요청을 받아들인다. 예를 들면 :
http://doi.org/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
URL이 ‘사전 합의된’ 목록 안에 있는 경우, 프록시 서버는 새로운 URL을 다음과 같이 구성한다.
3.8.4.3 10320/loc 핸들 형식을 사용하는 여러 URL의 해석
단일 위치가 선택될 때까지 프록시는 순서대로 알려진 선택 방법을 반복할 것이다. 각 반복 후에 프록시는 다음의 네 단계 중 하나를 취할 것이다:
아래의 위치 속성 목록이 들어있는 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>
프록시가 리다이렉션에 사용하기 위해서, 다음 정보를 포함하는 10320/loc 유형이 레코드에 추가 되었다:
<locations chooseby="locatt,country,weighted"> |
목차 이전 장 : 2. 번호 할당 다음 장 : 4. 데이터 모델
|
®, DOI®, DOI.ORG®, 그리고 shortDOI®는 국제 DOI 재단의 상표입니다. |