Logo

목차    이전 장 : 1. 소개    다음 장 : 3. 해석

 

2. 번호 할당

 

핸드북의 이 장은 다른 객체들과 구별할 기능적인 요구가 있는 (디지털 혹은 물리적인) 물질적인 형태나 (텍스트 작업과 같은) 추상적인 것을 식별하기 위해 사용되는 DOI® 이름의 구문을 정의한다. DOI® 시스템은 (별도의 추가적인 기능을 아직 제공할 수 없는 다른 식별체계에 추가 기능을 제공하기 위해) 다른 식별 체계와 함께 사용될 수 있고, 다른 체계의 문자열은 DOI 메타데이터 레코드와 또는 DOI 구문을 통해 DOI 시스템에 통합될 수 있다. 이 장에서, 문자 세트, 대소문자 구분, 고유성, 인터넷 식별자 규격에 대해서도 설명한다.

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

 
2.1 번호 할당하기
2.2 DOI 이름의 구문
      2.2.1 일반 특성
      2.2.2 DOI 접두사
      2.2.3 DOI 접미사
2.3 이름 할당
      2.3.1 할당 원칙
      2.3.2 세분화 정도
      2.3.3 변경된 할목
      2.3.4 설명
      2.3.5 고유성
      2.3.6 영구성
2.4 대소문자 구별
2.5 문자 세트 및 인코딩
      2.5.1 인코팅 원칙
      2.5.2 인코딩 규칙
            2.5.2.1 UTF-8 인코딩
            2.5.2.2 URL에서 사용될 때 인코딩 권고사항
            2.5.2.3 인코딩 이슈
            2.5.2.4 DOI 기탁과 URL을 위한 필수 및 권장 인코딩
2.6 DOI 이름의 시각적 표현과 다른 표현
      2.6.1 스크린과 인쇄물에서의 표현
      2.6.2 URI 표현
      2.6.3 URN 표현
      2.6.4 다른표현
      2.6.5 원칙
2.7 DOI 시스템과 다른 ISO식별자 체계의 관계
      2.7.1 간략한 개요
      2.7.2 원칙
      2.7.3 DOI 시스템에서 다른 식별자 체계와의 관계표현
            2.7.3.1 다른 식별자 체계의 기존 식별자를 갖는 DOI 이름의 대상체
            2.7.3.2 기존 식별자와 DOI 이름의 통합
            2.7.3.3 추가 기능
2.8 DOI시스템과 다른 (비ISO)식별자 체계의 관계
      2.8.1 DOI 이름으로 기존 레거시 식별자들의 관계 표현
      2.8.2 기존 식별자와 DOI 이름을 사용하는 장점
      2.8.3 다른 식별자 체계에서 DOI의 표현
2.9 DOI 이름과 검사 숫자
2.10 shortDOI 서비스
2.11 DOI시스템과 인터넷 식별자 사양
 

2.1 번호 할당하기

각각의 DOI® 이름은 단 하나의 개체를 식별하기 위해 할당된 고유한 "숫자"이다. 비록 DOI 시스템은 동일한 DOI 이름이 두 번 발행되지 않는 것을 보장하지만, DOI 이름 접두사 내에서 각각의 객체를 유일하게 식별하는 역할의 주요 책임자는 개별 등록자(DOI 이름을 할당하는 회사 혹은 개인)와 등록관리기관이다.

고유성(유일한 한 대상체의 DOI 이름에 의한 명세)은 DOI 시스템에 의해 강제된다. 동일한 개체에 두 개의 이름이 할당되지 않는 것이 바람직하다.

DOI 시스템은 누구에게나 (유형 혹은 무형의, 물리적 혹은 디지털 형태의) 어떠한 형식의 지식재산권 항목에 대해서도 고유하게 이름을 쉽게 명명할 수 있는 방식으로 설계되었다. 기존 식별자는 DOI 이름 혹은 DOI 레코드의 일부로 사용될 수 있는데, 이것은 등록자들이 기존의 그들의 “콘텐트 자산"에 DOI 이름을 발행하는 것을 용이하게 한다. 조직들 간의 비즈니스 요구사항을 처리하기 위한 적절한 수준에서, 접두사를 할당할 것을 권유한다. 일반적으로, RA는 한 고객 당 하나의 접두사를 발행할 수 있으나, 한 브랜드에 한 개의 접두사를 붙이거나 혹은 제품들에 대한 인식 가능한 분류(예를 들어 출판사의 인쇄물)에 접두사를 붙이는 것 또한 적절하다.

그러나 DOI 시스템은 콘텐트를 더욱 세분화하여 식별할 수 있고, 기존 식별 체계 (혹은 레거시 식별자)에서는 없었던 지식재산권 유형을 식별할 수 있다는 점에서 대부분의 기존 식별자 체계 보다 훨씬 더 발전된 형태이다.

 

2.2 DOI 이름의 구문

핸드북의 이 장은 다른 객체들과 구별할 기능적인 요구가 있는 (디지털 혹은 물리적인) 물질적인 형태나 (텍스트 작업과 같은) 추상적인 것을 식별하기 위해 사용되는 DOI® 이름의 구문을 정의한다. DOI 시스템은 해석과 같은 추가적인 기능을 필요로 하는 다른 식별 체계와 함께 사용될 수 있으며, 다른 체계의 문자열은 DOI 메타데이터 레코드 또는 DOI 구문을 통해서 DOI 시스템과 통합될 수 있다.

DOI 이름의 구문은 처음에 ANSI/NISO Z39.84-2000(2005년, 2010년 개정)으로 표준화 되었다가, 후에 ISO 26324(2010)의 일부로 표준화 되었다.

사용중인 DOI 이름은 “모호한 문자열(opaque string)”, 혹은 “의미 없는 숫자(dumb number)”이다 - DOI 시스템 내에서 DOI 이름을 사용할 때, 그 숫자로부터 어떠한 것도 추론이 가능하지 않아야 한다. 특정 DOI 이름이 식별하고 있는 개체가 어떠한 정보를 가지고 있는지에 대한 유일한 안전한 방법은, 등록시점에 DOI 이름 등록자가 선언한 메타데이터를 찾아보는 것이다. 이것은 예를 들어, 특정 항목의 소유권이 변경될 지라도, 그 항목의 식별자는 영구적으로, 동일하다는 것을 의미한다. 이것이 바로, DOI 이름이 영구성을 가진 식별자라고 불리는 이유이다.

 

2.2.1 일반 특성

DOI 구문은 슬래시로 구분되는 DOI 접두사와 DOI 접미사로 구성된다.

DOI이름 또는 DOI 접두사, DOI 접미사의 길이에는 제한이 없다.

DOI 이름은 대소문자를 구분하지 않는다. 그리고 유니코드의 그래픽 문자에서 인쇄 가능한 어떤 문자라도 포함될 수 있다. 어플리케이션의 문자 사용에 대한 추가적인 제한(예를 들어, 언어별 알파벳 문자의 사용)은 ISO 26324 등록 기관(Registration Authority)에 의해 정의될 수 있다.

(특정 DOI 등록자에게 할당된) 고유한 DOI 접두사와 (특정 개체에 대해 등록자가 할당한) 고유한 DOI 접미사의 조합은 유일하고, 그래서 DOI 이름의 분산된 할당을 허용한다.

DOI 이름은 DOI 시스템의 목적을 위한 모호한 문자열이다. 특정 정보가 DOI의 특정 문자열로부터 추론될 수 없다. 특히, 특정 등록자에게 할당된 등록자 코드가 DOI 이름에 포함되는 것은 등록자의 지식재산의 현재 관리 책임이나 소유권에 대한 어떠한 증거도 제공하지 않는다. 이러한 내용은 관련 메타데이터에서 주장될 것이다.

 

2.2.2 DOI 접두사

일반

DOI 접두사는 디렉토리 지시자와 이 지시자 뒤의 등록자 코드로 구성된다. 이 두 구성 요소는 마침표(미국 period, 영국 full stop)로 구분된다.

디렉토리 지시자

디렉토리 지시자는 "10"이다. 디렉토리 지시자는 해석 시스템 내에서 접두사와 접미사로 구성된 문자열을 디지털 객체 식별자(DOI)로 인식한다.

등록자 코드

DOI 접두사의 두번째 요소는 등록자 코드이다. 등록자 코드는 등록자에게 할당된 고유한 문자열이다.

예 1
10.1000     DOI 접두사는 디렉토리 지시자 "10"과 이어지는 등록자 코드 "1000"으로 구성..

원하는 경우 관리의 편의를 위해 등록자 코드는 하위 요소로 분할될 수 있다. 등록자 코드의 각각의 하위 요소는 마침표가 선행되어야 한다. 이러한 하위 부분은 계층 관계를 의미하지 않는다. 각 등록자 코드는 분할 여부에 관계없이, DOI 시스템에서 동일하게 처리된다. 그러나 하위 분할 등록자 코드는 기술적으로 이름 해석에 영향을 미칠 수 있다. 등록자 코드 할당에 대한 자세한 내용은 ISO 26324 등록 기관(Registration Authority)에 문의하는 것이 좋다.

예 2
10.1000.10     등록자 코드에 하위 코드 "10"(참조 예 1) 이 있는 DOI 접두사

변경

DOI 이름이 한 번 할당되면, 대상체의 소유권 또는 관리에 대한 변경과 상관없이, DOI 이름은 변경 할 수 없다.

주석 : 원 등록자는 그 등록자 코드가 DOI 이름의 영구적인 요소로서 남아 있다 할지라도, DOI 이름 및 이와 관련한 레코드의 유지 관리에는 어떤 역할도 할 수 없다.

 

2.2.3 DOI 접미사

DOI 접미사는 등록자가 선택한 임의 길이의 문자열로 구성된다. 접미사는 앞의 접두사 요소에 대해 유일해야 한다. 고유한 접미사는 일련번호가 될 수도 있고, 등록자가 사용하는 다른 시스템에서 생성되거나 또는 다른 시스템에 기반을 둔 식별자들을 포함할 수 도 있다(예를 들어, ISAN, ISBN, ISRC, ISSN, ISTC, ISNI의 경우, 선호되는 접미사의 조합은, 예 1과 같이 구성될 수 있다).

예 1
10.1000/123456 DOI 접두사 "10.1000" 및 DOI 접미사 "123456" 으로 구성된 DOI 이름.
예 2
10.1038/issn.1476-4687    ISSN을 사용하는 DOI 접미사. (하이픈을 포함하는) ISSN을 사용하는 DOI 접미사를 구성하기 위해, 소문자 "issn"과 마침표를 ISSN 번호(즉, 1476-4687) 앞에 붙임.
 
 

2.3 DOI 이름 할당

 

2.3.1 할당 원칙

DOI 이름은 다른 ISO 식별체계의 대체물로서 사용될 수 없다. 자세한 내용은 2.7절을 참조하라.

어떤 객체가 다른 객체와 구별될 기능적인 필요가 있을 때마다, DOI 이름은 어떤 객체에도 할당될 수 있다.

"DOI”는 ("디지털 객체에 대한 식별자"가 아닌) “객체에 대한 디지털 식별자"라는 의미이다.

DOI 이름 할당 규칙은 DOI 어플리케이션 프로파일을 통해, 적합한 메타데이터를 기반으로 범위의 기능적인 정의를 포함할 수 있다.

 

2.3.2 세분화 정도

DOI 이름은 크기와 관계없이 더 큰 개체의 구성요소가 되는 어느 객체에도 할당될 수 있다. DOI 이름은 등록자가 적절한 것으로 판단한 정확도와 세분화 정도로도 할당될 수 있다.

예를 들어, 텍스트 자료의 세분화를 위해, 개체가 출판되었거나 입수 가능 하다면, DOI 이름은 분리된 텍스트의 각 영역–초록(abstract), 소설의 스페셜 에디션(special edition), 소설의 특정 단락, 특정 이미지, 인용 부분(quotation)뿐만 아니라 각각의 특정 표현에도 할당될 수 있다.

 

2.3.3 변경된 항목

이미 DOI 이름이 할당된 항목이 변경되었을 때 변경된 항목에 새로운 DOI 이름을 부여할지 여부는 기능적 세분화 정도(Granularity)의 하나이다. 개체가 구별될 필요가 있을 때마다 개체를 식별 할 수 있어야 한다. IDF는 여기에 대한 규칙을 규정하지 않으며, 개별 등록관리기관이 그들의 커뮤니티를 위해서 적절한 특정 규칙을 적용하는 것을 결정할 수 있다.

 

2.3.4 설명

DOI 이름을 할당할 때 등록자는 DOI 이름이 할당되는 객체를 설명하는 메타데이터를 제공해야한다. 메타데이터는 DOI 시스템 내에서 객체를 개별 개체로 구별하는데 필요한 정도로 객체를 기술해야한다.

 

2.3.5 고유성

각각의 DOI 이름은 DOI 시스템에서 오직 하나의 대상체를 명시해야 한다. 하나의 대상체에 하나 이상의 DOI 이름을 지정 할 수 있지만, 개별 대상체당 단 하나의 DOI 이름이 권장된다.

 

2.3.6 영구성

DOI 이름의 존속성에 대한 시간제한은 어떠한 할당, 서비스 또는 어플리케이션에서도 가정될 수 없다.

DOI의 이름과 대상체는 해당 대상체와 관련된 권리의 변경 또는 대상체의 관리 책임 변경에 영향을 받지 않는다.

DOI 시스템은 식별된 개체들에 대한 정보(최소, DOI 이름과 대상체에 대한 설명)를 교환함으로써, 지속적으로 상호 운용할 수 있는 수단을 제공한다.

 

2.4 대소문자 구별

DOI 이름은 대소문자를 구별하지 않는다. 즉, 문자를 비교하기 위해 ASCII 대소문자 접기(case folding)를 사용한다. (DOI 이름의 대소문자를 구별하지 않는 것은 ASCII 문자에만 적용된다. ASCII 문자가 아닌 유니코드 문자에서 대소문자의 DOI 이름은 서로 다른 식별자일 것이다.) 10.123/ABC는 10.123/AbC와 동일하다. 모든 DOI 이름은, 등록될 때 대문자로 변환되는데, 이는 대소문자를 구별하지 않는 서비스를 만드는 일반적인 실행 방법이다. 이것은 해석에서도 동일하다. DOI의 이름이 10.123/ABC로 등록된 경우, 10.123/abc는 해당 개체(10.123.ABC 개체)로 식별되며, 10.123/AbC를 (DOI 이름으로) 등록하려는 시도는 DOI 이름이 이미 존재한다는 에러 메시지와 함께 거부될 것이다.

문자 인코딩의 관점에서 본다면, 접미사는 대소문자가 구별(예를 들어, 10.123/ABC와 10.123/AbC는 서로 다르며, 두 개의 문자열은 서로 다른 식별자로 구별 된다)됨에도, IDF는 (대소문자 구별 이후에) 나타난 결과들을 상세하게 검토한 결과, 대소문자 구별을 제거하기로 결정했다. 핸들 시스템은 서비스에 의해 대소문자를 구별하거나 또는 대소문자 구별하지 않는 방식으로 설정될 수 있다. 그래서 핸들시스템은 이것을 허용한다. 이러한 제약사항은 초기 단계로부터 구현되었다. 그리고 IDF 등록관리기관들은 동일한 객체를 해석할 때 ASCII 대소문자만 다른 두 DOI 이름을 도입한 경우가 없었다.

데이터 무결성을 위한 고려사항이 (도서관 및 출판사의 사례, 인간의 가독성과 기대치 등의) 대소문자를 구별하는 장점보다 더 중요하다. 인터넷 어플리케이션마다 대소문자를 구별 하는 경우는 다양하다. DNS는 구분하지 않으며, URL의 마지막 부분은 예외이지만 어떤 경우는 구분하지 않지만 서버에 따라 다르다. Unix와 PC/Max 파일 이름(마이크로소프트 윈도우즈는 일반적으로 대소문자를 구분하지 않지만, ​​유닉스 운영체제는 항상 대소문자를 구분한다), 마크업 언어 태그 등은 예기치 않은 문제를 발생시킬 수 있고, 특정 소프트웨어가 대소문자 구별을 준수하고 구별되도록 의도된 두 DOI 이름을 하나로 합치지 않는 다는 것을 보장할 수 없다. 몇몇 검색 엔진과 디렉토리는 부분적으로 대소문자를 구별한다. 웹 브라우저가 다르면 대소문자를 다르게 처리할 것이다(웹 브라우저 개발자는 "저자들은 그들이 진정으로 표준과 호환되는 브라우저만을 위해 설계되지 않는 한 고유한 식별자를 생성하는 방법으로 대소문자 구별에 의존하지 말라"고 조언한다).

이것이 DOI 시스템의 향후 발전과 개발을 위한 더 안전하고, 견고한 선택인 대소문자를 구별하지 않는 것을 찬성하는 주장을 했다.

 

2.5 문자 세트 및 인코딩

 

2.5.1 인코딩 원칙

DOI 이름은 ISO/IEC 10646의 범용 문자 세트(UCS-2)의 인쇄 가능한 어떤 문자들도 포함할 수 있으며, 이 문자들은 유니코드 v2.0에 정의 된 세트이다. UCS-2 문자 세트는 오늘날 지구상에서 사용되는 모든 주요 언어 대부분의 문자를 포함한다. 그러나, 몇몇 인터넷 기술에서 어떤 문자의 특별한 사용 때문에(예를 들어, XML에서 각괄호 “<“, ”>“의 사용), 일상의 사용에 있어서 약간의 효과적인 제약이 있다(아래 내용 참조).

접두사, 접미사와 문자 세트에 대해서 고려할 때, DOI 시스템을 근본 기술인 핸들 시스템(Handle System)과 구분하는 것이 중요하다. DOI 시스템은 핸들 시스템의 구현물이다. 현재의 사용(단순히 사용 가능하거나 사용될 가능성이 있는 이용방식이 아닐지라도)은 대부분 완전히 (인터넷과 동일하지 않은) 월드 와이드 웹(World Wide Web) 안에서 발생하고, 차츰 발전하고 있는 IDF 정책들에 의해 통제된다.

접두사/접미사. 핸들 시스템과 DOI 시스템 정책도, 또한 현재 상상할 수 있는 모든 웹의 어떠한 사용도, 인코딩 외에는 접미사에는 어떤 제약도 부과하지 않는다(아래 참조). 핸들 구문은 접두사에 두 가지 제약을 부과한다. 슬래시와 마침표는 예약된 문자로, 슬래시는 접두사와 접미사를 구분해주며, 마침표는 하위 접두사를 확장하는데 사용된다. 핸들 시스템의 루트 관리자는 IDF가 DOI 이름으로 사용할 수 있도록, 모든 접두사는 “10.”으로 시작하도록 예약하였다(예를 들어, 10.1000, 10.1000.1, 10.23).

인코딩. 핸들 시스템은 중심에 UTF-8을 사용한다. UTF-8은 유니코드의 구현이고 순수한 형태에는 문자 세트의 제약조건이 전혀 없다. 즉, 어떤 문자도 핸들 서버에 전송되고, 저장되고, 검색될 수 있다. IDF는 추가적인 문자 세트 제약 조건을 부과하지 않는다. 그러나, 실제로는, 예를 들어, 어떤 종류의 브라우저가 사용되고 있는지와 같은 개별 사용자의 상황에 따라 현행 웹 환경에 의해 강제되는 문자 세트 제약 조건이 많다. (이것은 이동하는 목표물과 같은 것이다. - 예를 들어, 현재 브라우저가 한자를 표시하는가? 당신은 알고 있는가?). 현재 권장되고 있는 인코딩 목록은 다음 절에서 기술된다.

구현. 표준과 구현의 실제적인 사실을 함께 고려하는 것이 중요하다. 그래서 예를 들어, URL에서 문자 "#"은 16진수 인코딩(hex encode)을 필수적으로 해야 한다. 왜냐하면 이 문자는 URL의 한 부분에 대한 시작을 나타내는데 사용되기 때문이다. 이 문자는 핸들 시스템 또는 DOI 이름 구문에서 특별한 의미가 없다. 그럼에도 불구하고, URL에 포함된 핸들은 # 문자가 인코딩 되어야 한다. 그렇지 않으면 브라우저가 그 핸들을 # 표시에서 단축해 버릴 것이다. 이것은 모든 웹 구현에서 적용된다. 다른 문자(예를 들어, "<" 또는 ">")를 “16진수 인코딩”으로 표현해야할 필요성은 특정 브라우저의 구현에 따라 달라진다. DOI 이름 구문에서 그렇게 필요한 인코딩은 NISO 표준에서 고려된다. 보다 일반적인 의미에서, 디지털 환경에서 어떤 식별자의 구현은 맞닥뜨릴 수 있는 인코딩 문제처럼 검토할 필요가 있고, 문자 세트 제약조건과 웹과 같은 환경을 통해 그 문자들을 변경하지 않고 이동시킬 필요성을 고심해서 다루어야 한다.

 

2.5.2 인코딩 규격

이 표준에 의해 부과된 (유니코드 및 예약어 문자의 사용과 같은) 특정 요구 사항을 제외하고, DOI에서 사용되는 문자들에 대해서는 어떤 제약도 부과되지 않으며, 어떠한 추정도 없다. 이 절에서는 URL과 같은 특정 어플리케이션 상황에서 DOI를 HTTP 프로토콜과 함께 사용할 때 발생하는 몇 가지 인코딩 문제를 논의한다. DOI를 사용하는 그 밖의 어플리케이션 상황들은 유사한 유형의 요구사항이나 제약사항을 가질 수 있다. 그러나, 특정 문자를 사용하는 것에 대한 인코딩이나 제약사항에 대한 그러한 요구사항은 DOI가 특정 어플리케이션의 상황에서 사용될 때만 적용된다. 그것은 이 문서에서 정의된 DOI 구문의 일부가 아니다

URI와 URN을 포함하는 그 밖의 형식에서 DOI 이름을 표현하는 지침은 2.6절을 참조하고 ​​또한 정보지의 DOI® 시스템 및 인터넷 식별자 규격(DOI® System and Internet Identifier Specifications)을 참조하라.

2.5.2.1 UTF-8 인코딩

핸들 시스템은 DOI 문자열에 대한 인코딩으로 UTF-8을 명시한다. ASCII 문자는 UTF-8 인코딩에서 유지된다. ASCII 문자는 UTF-8 인코딩을 준수하기 위해서 변경할 필요가 없다. 유니코드의 기본 인코딩은 각 문자가 16 비트(2개의 8개 한 벌(2 octets))로 구성되어 있다는 것이다. UTF-8은 문자들이 한 개에서 여섯 개의 octet으로 인코딩되는 것을 허용하는 유니코드 인코딩의 변형이다. UTF-8은 ASCII가 아닌 문자들이 사용될 때 역할을 한다. 예를 들어, 일본어 단어 “nihongo"는 다음과 같이 적는다;

Japanese characters for nihongo

"nihongo"에 대한 한자를 표현하는 유니코드 배열은 65E5 672C 8A9E이다. 이들은 다음과 같이 UTF-8로 인코딩될 것이다. E6 97 A5 E6 9C AC E8 AA 9E. UTF-8 에 대한 더 자세한 내용은 "UTF-8, A Transform Format for Unicode and ISO10646", RFC 2044, 1996.10를 참조하라.

더욱 자세한 내용은 유니코드의 최신 버전을 참조하라. Unicode는 Unicode, Inc의 상표이다. 유니코드 표준은 일반적으로 Universal Character Set(UCS)이라고 불리는 ISO/IEC 10646:2003 Universal multiple-octet coded character set의 구현에 대한 추가적인 제한 조건을 부과한다.

2.5.2.2 URL에서 사용될 때 인코딩 권고사항

현재의 웹 브라우저 기술은 특정 브라우저가 DOI 식별자들을 완전하게 사용할 수 있도록 하기 위한 추가 기능을 필요로 한다. 즉, 추가적인 브라우저 기능들이 필요하다. 미래에는 해석을 지원하는 기능들이 브라우저에 공통적으로 내장될 것으로 예상된다.

핸들 시스템의 Other HANDLE.NET Software에서 무료로 이용 가능한 “해석 플러그인”을 내려 받을 수 있다. 일반적인 브라우저에 대해, 플러그인은 브라우저의 기능을 확장해서 브라우저가 핸들 프로토콜을 이해할 수 있게 된다.

대안으로, 웹 브라우저의 기능을 확장할 필요 없이, DOI는 기본 공용 DOI 프록시 서버인 http://doi.org(또는 http://dx.doi.org 이 구문은 초기 구문으로 완전히 지원되지만, 더 이상 선호되지 않음)를 사용할 수 있도록 구성될 수 있다. 이 경우 DOI의 해석은 URL 구문의 사용에 달려있다. 예를 들어, "doi:10.123/456"은 http://0-doi.org.pugwash.lib.warwick.ac.uk/10.123/456서 작성될 것이다.

DOI는 또한 HTML 페이지에서 주로 사용된다. DOI 10.1006/rwei.1999".0001은 HTML 페이지에서 하나의 링크로 다음과 같이 표현된다:

<a href="http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1006/rwei.1999%22.0001">10.1006/rwei.1999%22.0001</a>

“는 URL에 포함된 DOI를 둘러싸는 문자열과 구별될 수 있도록, 인코딩된 것에 주의 하라(다음 절 참조). 사용자들이 그들의 브라우저에 해당 DOI를 직접 입력할 수 있기 때문에, DOI는 인코딩된 형태로 표시된다.

2.5.2.3 인코딩 이슈

DOI가 HTML, URL 및 HTTP와 함께 사용될 때, 특별한 인코딩 요구 사항이 존재한다. URI(Uniform Resource Locator)에 대한 구문은 DOI에 대한 구문보다 훨씬 더 제약이 많다. URI는 URL(Uniform Resource Locator) 또는 URN(Uniform Resource Name)이 될 수 있다.

URL 또는 URN에서 허용되지 않거나 혹은 다른 의미를 갖는 DOI 내의 문자들에 대해서는 16진수(%) 인코딩을 사용해야 한다. 16진수 인코딩은 주어진 문자를 그 문자의 16진수 값과 그 앞에 퍼센트로 치환하는 것으로 구성된다. 그래서, #은 %23 이 되고, http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1000/456#789는 http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1000/456%23789로 인코딩된다. 브라우저는 이제 보통은 URL의 끝이고 한 부분의 시작으로 간주되는 그대로의 #과 맞닥뜨리지 않고, 그래서 #에서 멈추는 대신, 해석을 위한 DOI 서버의 네트워크에 전체 문자열을 보낸다. 참고 : 인코딩으로 인해 DOI 자체가 변경되는 것이 아니며, URL에서 단지 DOI의 표현만을 변경할 뿐이다. 인코딩 된 DOI는 DOI 레지스트리에 전송되기 전에 디코딩된다. 그 순간에 디코딩은 프록시 서버인 http://0-doi.org.pugwash.lib.warwick.ac.uk/에 의해 처리된다. 단지 인코딩되지 않은 DOI들만 DOI 레지스트리 데이터베이스에 저장된다. 예를 들어, 위의 숫자는 DOI 레지스트리에서"10.1000/456%23789"가 아닌, "10.1000/456#789"이다. URL에서 퍼센트 문자(%)는 항상 16진수로 인코딩(%25)되야 한다.

DOI 번호 문자열 그 자체에 대한 문자열 제약사항은 거의 없다. DOI가 URL에 포함 될 때는 URL 구문 규칙을 따라야 한다. 다른 상황에서는 동일한 DOI가 그 문맥 규칙을 따라야 할 필요는 없다..

2.5.2.4DOI기탁과 URL을 위한 필수 및 권장 인코딩

표 1 및 표 2는 DOI를 위한 인코딩 지침을 요약하고 있다. URL은 가장 엄격하게 제한된 문자 세트을 갖는다. 표 1은 항상 16진수로 인코딩되야 하는 문자들을 나열했다. 표 2는 16 진수 인코딩으로 대체되는 것이 권장되는 추가적인 문자열들을 나열하였다. 두 목록 사이의 차이는 현재의 웹브라우저에 대한 실제적인 경험과 URL 구문의 더욱 형식적인 규격 사이의 차이이다. DOI 디렉토리 내에서는 모든 문자들은 자신을 표현된다.

표 1 : 필수 인코딩 목록

Character Encoding
% (%25)
" (%22)
# (%23)
SPACE (%20)
? (%3F)

표 2 : 추천 인코딩 목록

Character Encoding
< (%3C)
> (%3E)
{ (%7B)
} (%7D)
^ (%5E)
[ (%5B)
] (%5D)
` (%60)
| (%7C)
\ (%5C)
+ (%2B)

또한 "/./"와 "/../"를 웹 브라우저가 다루는 것이 서로 일치하지 않을 수 있음을 유의하라. (예를 들어, "/./" 는 "/.%2F"로, "/../" 는 "/..%2F" 로 인코딩 되듯이) 슬래시 중 하나는 % 인코딩이 되는 것을 권장한다.

 

2.6 DOI 이름의 시각적 표현과 다른 표현

 

2.6.1 스크린과 인쇄물에서의 표현

화면이나 인쇄물에 DOI 이름을 표시할 때, 배경에 명확하게 DOI 이름이 내포되어 있음을 알려주지 않으면 DOI 이름 앞에 소문자 "doi:"가 붙는다. "doi:" 라벨은 DOI 이름 값의 일부가 아니다.

DOI 이름 "10.1006/jmbi.1998.2354"는 "doi:10.1006/jmbi.1998.2354"로 화면에 표시되고 인쇄된다.
 
 

2.6.2 URI 표현

소문자 문자열 "doi:"의 사용은, "ftp:" 및 "http:"와 같이 URI로서 표현을 위한 IETF 규격인 RFC 3986을 따른다. 웹 브라우저에 표시될 때, 표준 하이퍼링크를 통해서 DOI 이름이 해석될 수 있도록, DOI 이름은 적합한 프록시 서버의 주소에 첨부될 수 있다. 표준 웹 하이퍼링크를 통해서 DOI를 해석하기 위해서는, DOI 이름을 프록시 서버의 주소에 덧붙여야 한다.

DOI 이름 "10.1006/jmbi.1998.2354"는 "http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1006/jmbi.1998.2354"과 같은 동작 가능한 링크로 만들어 질 것이다.

URL에 이와 같이 표기되고 HTTP 프로토콜에 의해 전송되는 DOI 이름은 URI 표현을 위한 표준 IETP 지침을 따라야 하는 제약조건이 있다. URI에 대한 구문은 DOI를 위한 구문보다 더 엄격하다. 일부 문자들은 예약되어 있고 퍼센트 인코딩이 필요할 것이다.

참고 : 특정 클라이언트 또는 서버 소프트웨어의 경우, 원시의 해석 기술을 사용하여 DOI를 처리할 수 있을 것이다. (예를 들어, 프록시 서버 주소를 추가할 필요 없이, doi:10.1006/jmbi.1998.2354는 특정 브라우저에 의해 번역되고, 자동으로 해석될 것이다.)

참고 : DOI 시스템은 가능한 한 특정 기술의 구현에 대해서 독립적이다. 웹 어플리케이션은 DOI 이름을 HTTP URI로 표현 할 수 있다. 그렇게 하는 방법은 간단하게 http://0-doi.org.pugwash.lib.warwick.ac.uk/에 DOI를 덧붙이고, (필요한 경우) 앞서 2.5.2.4절에 언급된 것처럼, URL과 URN에 요구되는 16진수(%) 인코딩을 사용하는 것이다.

DOI 이름에 대한 웹 해석의 사용에 대한 자세한 내용은 3. 해석을 참고하라. 이것을 용이하게 하는 도구에 대한 정보는 DOI Tools를 참고하라. 인터넷 식별자 규격들과 관련된 DOI에 대한 자세한 내용은 DOI 시스템 자료인 DOI System and Internet Identifier Specifications을 참고하라.

 

2.6.3 URN 표현

URN에 대해 이미 표준화된 워크플로우에서 DOI를 사용 가능하게 하려고, DOI 프록시 서버는 DOI 이름의 첫 글자인 슬래시 대신 콜론으로 치환한 것을 이해한다. 예를 들어, DOI 이름 10.123/456을 http://0-doi.org.pugwash.lib.warwick.ac.uk/urn:doi:10.123:456과 같은 형태로 적어서, DOI 이름은 그래서 doi.org 도메인에서 URN으로 표현될 것이다. 그러나 DOI 접미사에는 다른 슬래시가 포함되는 것이 허용된다는 점을 유의해야 하고, 이런 상황이 발생했을 경우는 콜론(:)으로 대체하지 말고 % 인코딩을 해야 한다. 예를 들어, DOI 이름 10.123/456ABC/zyz은 마지막의 슬래시 문자를 %2F로 인코딩하여http://0-doi.org.pugwash.lib.warwick.ac.uk/urn:doi:10.123:456ABC%2Fzyz가 될 것이다.

 

2.6.4 다른 표현

DOI 이름은 특정 ​​상황(예, 정보 URI 체계 RFC 4452)에서 다른 형태로 표현될 수 있다.

특정 네트워크 또는 참조 상황에서 직접적으로 처리할 수 없거나 모호함이 발생할 수 있는 문자들(예, 빼기 기호, 하이픈, en-dash 등 모든 화면에 유사하지만 서로 다른 문자 값을 전달하는 문자들)은 피하거나 적합한 방법으로 인코딩해야 한다(예, URL을 UTF-8로 변환한 다음 % 인코드).

가독성을 높이면서 식별자 문자열의 길이를 최소화하는 것이 중요한 경우에, DOI 이름은 ShortDOI 서비스를 통해 제공될 수 있다. (shortdoi.org, 아래 2.10 참조)

특정 표현은 특별한 기술적 요구 사항을 충족하기 위해 합의될 수 있다. 예를 들어, ANSI 표준 "Digital Program Insertion Cueing Message for Cable"(SCTE 35:2013)은 프로그램이 방송되고 있는 대역에 케이블 TV 시스템이 EIDR DOI 이름을 포함하기 위한 표준 방법을 정의한다. 그것은 전체가 ASCII인 DOI 문자열 보다는 소형의 손실 없는 EIDR 표현을 사용한다(표 8-7). 이것은 더 많은 데이터를 모으기 위해, 그렇게 전송된 ID가 대역 외 메커니즘(out-of-band mechanism)을 통해 해석될 수 있음을 제안하면서, DOI 이름의 해석능력(resolvability)을 사용한다.

 

2.6.5 원칙

대부분의 콘텐트는 디지털과 인쇄 매체를 혼합하여 출판되기 때문에, DOI 이름이 인쇄 매체로 재생산되기 위한 요구 사항들이 있다. 발행인은 문서 이름에 DOI 이름을 넣어 항목을 다운로드하거나 인쇄 할 때마다 DOI 이름이 나타나는 것을 보장 할 수 있다. 또한 디지털 버전의 인쇄물에 나타날 수 있을 것이다. DOI 이름이 웹 페이지에서 버튼으로 표현된다면, 커서가 버튼 위를 이동할 때, 웹 브라우저는 브라우저 창의 아래에 DOI 이름을 표시할 것이다.

디지털 환경에서 DOI 이름은 상황에 맞춰지고 갱신 된다(즉, 그것이 참조하고 있는 활성 링크가 항상 올바르게 "연결"될 수 있다)고 가정될 수 있는 반면에, 인쇄 버전은 한번 발행되면, 갱신되거나 변경될 수 없다. DOI 이름을 인쇄버전 보여주는 예를 들어, 저널 기사는 사람들에게 기사의 DOI 이름이 무엇인지는 말해주지만, 웹에서 어떻게 기사에 접근할 수 있는지는 말해주지 않는다. 독자들은 DOI 이름이 동작할 수 있다는 것을 반드시 알게 되는 것은 아니다. 그것을 하기 위해, DOI 이름을 프록시 서버의 URL 형식과 같은 예를 들어, http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1002/prot.9999와 같은, 쉽게 인식 가능한 형태로 인쇄할 것이다. 그러나 URL 형태로 보여주는 것을 주저하는 몇 가지 이유가 있다. 즉, URL은 기사의 식별자가 아니고, DOI는 기사의 식별자이다. URL의 doi.org 형태는 가장 영구적인 형태가 아마 아닐 것이다. 인쇄물은 수십 년, 심지어 수세기 동안 존재하고 변하지 않는 다는 것을 기억해야 한다.

실제로 어떤 사용자는 doi.org 표현을 사용하는 것을 안전하게 느낄 수 있다. 몇몇 다른 정해진 형태에서 DOI 이름을 사용하는 것이 일반적일 때조차도, 오랫동안 계속 동작해야 한다. 그러나 우리가 향후 몇 세기를 얘기한다면, 우리는 가장 잘 알려진 접근 경로인 http://를 넘어서게 될 것이다. 그래서 불편할 수 있지만, 우리는 순수한 DOI 이름과 그것을 온라인에서 해석 할 수 있는 방법 둘을 보여주는 관습을 추천한다. (간단히 말하는 방법은 "이 기사의 DOI 이름은 10.1002/prot.999이고 현재의 정보는 http://0-doi.org.pugwash.lib.warwick.ac.uk/10.1002/prot.999이나 http://0-doi.org.pugwash.lib.warwick.ac.uk/...을 통해 웹에서 찾을 수 있다“ 또는 ”...는 http://doi.org를 통해 ...“).

특정 DOI 시스템 구현 및 등록관리기관은 관련된 특정 어플리케이션에 적합한 추가 권장 사항을 제공할 수 있다.

 

2.7 DOI 시스템과 다른 ISO 식별자 체계의 관계

DOI 시스템의 한 목적은 원한다면 기존의 번호를 부여하는 시스템을 유지하는 것이며, DOI 이름의 기능을 그들에 쉽게 추가되도록 하는 것이다. 자세한 내용은 다음 문서를 참조하라:

 

2.7.1 간략한 개요

하나의 자원에 대해 여러 식별자를 생성(공동 참조)하는 것은, 다양한 시스템 간의 상호 운용성에 의존하는, 연결된 데이터 세상 또는 시맨틱 웹 어플리케이션 등에서 잠재적인 문제를 만든다. 다른 공통 식별자의 존재가 알려지지 않으면 문제가 발생할 수 있으며, 잠재적으로 더 큰 문제는 두 식별자가 같은 대상체를 주장하고 있지만 실제로는 그렇지 않을 때 발생 한다(이런 경우 근본적으로 상호 운용성이 깨진다). 여러 온톨로지 및 참조 체계의 성공적인 융합은 가능한 체계들의 명확한 선언과 통합이 요구된다. 이 문제의 중요한 예가 DOI 시스템과 그 밖의 ISO 식별자 체계 사이의 관계이다.

우리가 DOI-X라 지칭할 DOI 어플리케이션 레지스트리와 우리가 ISXI라 지칭할 기존의 ISO 표준 레지스트리를 생각해 보자. 각각은 등록관리기관(DOI-X RA와 ISXI RA)을 보유하고 있다. 만약 DOI-X가 ISXI가 소유한 어떤 것을 식별하려고 생각한고 이것이 일반적인 것 같다면, DOIX RA는 ISXI RA에게 DOI 이름(단독 메타데이터 또는 구문 + 메타데이터)에서 ISXI를 가르키는 표준 방법에 동의하는 것을 원하는지 문의해야 한다(또는 ISXI에게 문의할 것을 IDF에게 요청해야 해야 한다). 만약 ISXI가 동의하고, 그런 메커니즘이 합의되면, 표준 방법을 사용해야 한다. ISXI가 동의하지 않으면, DOI-X는 실제 아직은 DOI 커널에 ISXI를 참조 식별자로서 표시해야 한다. 고려해야 할 주요 문제는 다음과 같다. (1) ISXI가 식별하는 것과 DOI-X가 기술하는 것이 정말 같은 것인가? (동의 할 때만 위의 것이 적용 된다.), (2) ISXI RA와 DOI-X RA가 레코드 교환에 합의하는 것을 바라는지? 그렇다면 어떤 조건으로? ISXI RA와 DOI-X RA가 동일한 단체인 경우에는, 이런 사례는 물론 간단한 내부 결정으로 축소된다.

다른 ISO TC46/SC9 표준 목록은 참고 문헌( Bibliography )에 나와 있다.

 

2.7.2 원칙

DOI 이름은 ISAN, ISBN, ISRC, ISSN, ISTC, ISNI 및 기타 일반적으로 인식되는 식별자를 대체하여 사용될 수 없다. 그러나 그들과 함께 사용되면 추가적인 DOI 시스템 기능으로, 그 시스템에 의해 제공되는 식별 기능을 향상시킬 수 있다.

DOI 시스템에서 다른 식별자 체계를 참조하기 위한 원칙은 잠재적인 사용자들의 유용성을 극대화하고, 또한 그 내부적인 관리의 효율성을 극대화하는 것이다.

 

2.7.3 DOI 시스템에서 다른 식별자 체계와의 관계 표현

2.7.3.1 다른 식별자 체계의 기존 식별자를 갖는 DOI 이름의 대상체

DOI 이름의 대상체가 일반적으로 공인된 식별자 체계의 기존 식별자를 갖는 경우, 그 관계를 표현하기 위해 다음과 같은 방법들 중에서 적어도 하나가 사용된다.

a) 식별자가 DOI 이름 구문에 통합되는 것과 관계없이, 기존의 다른 식별자를 DOI 메타데이터 필드인 “참조식별자(referentIdentifier)”(동일한 대상체를 공동으로 참조하고 있는 식별자)에 표기한다.

b) 기존의 다른 식별자를 대상체의 DOI 이름의 부분에 명시적으로 통합할 수 있다.

예 1과 2는 ISBN과 ISSN을 DOI 이름에 통합한 것을 나타낸다. 통합을 위해서 다른 합의된 구문도 가능하다. 국제 DOI 재단은 현재의 합의된 구문을 유지한다( DOI System® and Standard Identifier Schemes을 참고하라). 예제 3은 DOI 이름이 다른 식별자 체계에 대한 대체가 아니라는 것을 보여준다.

 

예 1
10.978.86123/45678 ISBN (978-86-123-4567-8)이 DOI 접두사와 접미사로 가능한 통합을 보여준다.
예 2
10.1038/issn.1476-4687    ISSN을 사용하는 DOI 접미사를 보여준다.
예 3
10.97812345/99990 이것은 DOI 이름이다. 이것은 ISBN POS(point-of-sale) 주문 시스템에 유효하게 제출될 수 없고, ISBN 바코드로 사용되기 위해 GS1 바코드로 변환될 수 없다. 이것은 ISBN 구문을 준수하지 않는다.
978-12345-99990 이것은 ISBN이다. 이것은 DOI 해석 서비스를 위해서 유효하게 제출될 수 없다. 이것은 DOI 구문을 준수하지 않는다.

그러나 두 식별자 문자열은 같은 대상체를 가지고 있다.

2.7.3.2기존 식별자와 DOI 이름의 통합

다른 체계의 기존 식별자를 DOI 이름의 일부분으로서 혼합을 허용하는 구문 규칙은 이 국제 표준의 일부가 아니다. 그런 경우는 다음과 같은 점들에 주의해야 한다.

a) 각 식별자 체계에서 별도의 개체로 구별될 필요가 있을 정도로, 동일한 대상체가 각 DOI 이름과 포함된 식별자 문자열로 표기될 것이다.

b) DOI 시스템 자체 내에서, DOI 이름은 모호한 문자열이다. 다른 식별자 체계와 관련된 정확한 정보가 DOI 이름에 사용되는 특정 문자열로부터 추론되지 않아야 하고, DOI 이름이 다른 식별자 체계를 위해 설계된 비 DOI 어플리케이션에서 활용 가능하다는 것이 보장되지 않는다(위의 예 3 참조).

c) 다중 식별자의 존재(세번째, 네번째, 등)는 DOI 이름에 통합에 의해서가 아니라, DOI 메타데이터 필드인 "referentIdentifier”(동일한 대상체를 여러 값으로 참조하는 다른 식별자들)에서 알 수 있어야 한다.

d) 다른 체계의 기존 식별자 통합에 대한 특정 구문 규칙은 ISO 26324 등록 기관(Registration Authority)에 의해 유지되어야한다.

2.7.3.3 추가 기능

DOI 시스템의 기능은 다른 기관들이 사용할 수 있는 다른 식별자 서비스를 보완하기 위해 제공될 수 있다(예, 다양한 상황에서 식별자의 해석). 식별자를 사용하는 서비스는 여러 공급자에 의해 제공될 수 있다. 특정한 식별자 시스템의 규칙은 단지 특정 선호되는 서비스 공급자의 사용을 필요로 할 수 있다. 이러한 경우, 식별자의 어플리케이션은 관련된 등록 기관(Registration Authority)의 규칙을 따라야 한다. 식별자 체계에 대한 개별 등록 기관은 자체의 체계 또는 커뮤니티 내에서의 사용 규칙에 대해 자율성을 가지고 있다. 국제 DOI 재단은 다른 식별자 체계와 함께 사용되기 위해 합의된 특정 메카니즘에 대한 현행 정보를 유지한다.

 

2.8 DOI 시스템과 다른 (비ISO) 식별자 체계의 관계

ISO 체계에 대한 동일한 원칙이 비-ISO 체계에 유지되었다. 등록자가 그렇게 하는 것이 편리하다는 것을 알게되면, 기존의 표준 식별 시스템 번호가 DOI 이름에 혼합될 것이다. 그 대신에, 기존의 표준 식별 시스템 번호가 DOI 메타데이터에 혼합될 것이다. 만약 기존의 표준 식별 시스템 번호가 DOI 이름에 혼합되면, 그 번호는 DOI 메타데이터에도 혼합되어야 한다. 모든 경우에, 정밀하게 DOI와 기타 시스템에 의해 동일한 개체가 식별되는 것이 가장 중요하다. DOI 시스템은 기존 식별자를 통합 할 수 있는 시스템에서 단독으로 수행되지 않는다. 예를 들어, 물리적 바코드는 ISBN을 표현하는데 사용될 수 있다.

기존 레거시 식별자는 DOI 이름이나 레코드에서 사용될 수 있기 때문에, 특정 DOI 시스템 구현은 이전에 존재하지 않던 상호운용성을 만들 수 있다. 예를 들어, DOI 시스템의 CrossRef 구현에서, 일부 출판사들은 접미사로 PII를 혼합하여 그들의 DOI 이름을 만들고, 다른 출판사들은 SICI을 접미사로 사용하였고; 또 다른 출판사는 미래에 접미사로 ISTC를 사용할 수 있으며, 그러나 또 따른 출판사는 전적으로 소유자의 내부 생산 번호를 접미사로 사용할 것이다. DOI 이름을 사용하여, 개별 출판사는 CrossRef 시스템에서 데이터에 대한 상호운용성의 이득을 얻지만, 그러나 다른 체계에서 이미 식별자가 할당된 개체에 대해 번호를 다시 부여할 필요는 없다.

DOI 이름에 대한 커널 메타데이터는 “식별자”를 반드시 포함한다는 것을 주목하라. (예를 들어, 기존 체계로 부터의) 고유한 식별자가 개체에 적용되었고, 존재한다면, 기존의 식별자를 포함하는 것이 정상이다. 기존의 (레거시) 식별자를 포함하는 데이터 세트에 대한 고려는 이런 요구사항이 존재하는 이유를 보여준다. 기존의 레거시 체계는 이 요소의 커널 선언을 사용하는 DOI 시스템 서비스에서 구조화된 메타데이터를 집어 드는 다른 자동화된 프로세스에 의해 사용될 수 있다. 앞서 언급한 것처럼, DOI 이름은 본질적으로 불투명하고, 구성요소를 분석할 수 없는 문자열이기 때문에, 기존의 식별자는 DOI 이름 접미사 자체로부터 안전하게 복구되지 않을 것이다(예를 들어, CrossRef 어플리케이션에서 이질적인 컬렉션을 고려하라). 그러나 기존 식별자를 접미사로 포함시키는 것은, 추가적으로, 편리할 수 있고, 인간이 DOI 이름을 쉽게 읽을 수 있도록 만든다. DOI 이름 생성에 대하 요구사항은 아니지만 관리적인 면에서 바람직하다.

 

2.8.1 DOI 이름으로 기존 레거시 식별자들의 관계 표현

개체 사이의 관계는 메타데이터를 통해 표현될 수 있다. 예를 들어 추상적인 작품의 단일 절은 (ISTC 메타데이타에 표현된 것처럼) 그 작품의 발췌이다. 그리고 한 작품으로 식별될 필요가 있으면, 또한 ISTC를 가질 수 있다. 한 규격이 개체들로 구성되면, 그들 사이의 관계는 메타데이터의 아이템으로 표현될 것이다(어떤 사람이 주장하는 관계가 두 개체사이에 존재한다). 어떤 요구되는 관계가 적합한 메타데이터를 제공하여 표현될 수 있다. DOI 시스템, 어플리케이션 프로파일과 DOI 시스템 서비스의 구체적인 기술적 아키텍처는 이것을 구체화하기 위해서 사용될 수 있다.

 

2.8.2 기존 식별자와 DOI 이름을 사용하는 장점

어느 DOI 이름도 공통적인 이득과 더불어서, 몇 가지 기존 표준 번호 체계를 DOI에 혼합하는 것에 대한 이점이 있다.

 

2.8.3 다른 식별자 체계에서 DOI의 표현

특정 어플리케이션 분야는 자신의 시스템 내에서 DOI 이름을 사용하기위해 공식적인 표현을 정의할 수도 있다. 예를 들어, 영화 및 텔레비전 엔지니어 협회(Society of Motion Picture & Television Engineers,(SMPTE))의 권고 조항 2079 (SMPTE RP 2079 : 2013 : "디지털 객체 식별자(DOI) 이름 및 엔터테인먼트 ID 레지스트리(EIDR) 식별자 표현")는 SMPTE 도메인에서 DOI 이름의 표현을 정의한다. 이와 관련된 SMPTE RP 2021-5:2013 “SMPTE BXF와 ATSC PMCP에서 Ad-ID와 EIDR을 보조 식별자로 사용”은 EIDR 등록 기관의 DOI 이름을 TV 세트 및 케이블 콘텐트 관리 시스템으로 유입되게 한다.

 

2.9 DOI 이름과 검사 숫자

DOI 이름은 모호한 문자열이다. DOI 시스템은 자체적으로 검사 숫자를 사용하지 않는다. 이것은 다음의 이유들 때문에 신중하게 고려되었다 :

그러나, 다른 어플리케이션의 경우 검사 숫자를 사용 할 수 있다. ​​그래서 몇몇의 다른 어플리케이션을 위해 유용할 경우는 검사합 숫자를 DOI 이름에 넣을 수 있다. 특정 DOI 시스템 어플리케이션에서 검사합의 사용은 해당 등록 기관이 그 어플리케이션의 규칙으로 도입 할 수 있다. 한 예가 EIDR 어플리케이션이다. 여기서는 검사 문자는 DOI 접두사에 대해서만 계산된다. 접두사가 잘못되면, DOI는 틀린 해석 시스템으로 멀리 가버린다. EIDR 레지스트리는 API를 통해 보내진 DOI의 접두사를 분리하여 검증한다.

 

2.10 shortDOI 서비스

short DOI 서비스는 누구에게나 공개되고, 종종 매우 긴 문자열인 DOI 이름에 대한 단축키를 생성하는 공공 서비스이다. short DOI 서비스는 URL에 대한 축약 서비스와 유사한 기능을 제공한다.

short DOI는 그 자체로 DOI가 아니다. short DOI는 DOI가 아니고 그래서 ISO 표준 구문과 다른 요구사항을 준수하지 않는다는 것에 주의하라. short DOI는 기존 DOI에 대해서만 생성될 수 있다. IDF는 핸들을 바탕으로 하는 두 개의 서비스를 운영한다. 즉 DOI 서비스와 short DOI 이다.

그 서비스는 10/abcde 형태의 짧은 핸들을 만들고, 이메일, 블로그, 모바일 메시징 등에서 사용되기에 이상적인 http://0-doi.org.pugwash.lib.warwick.ac.uk/abcde와 같은 짧은 HTTP URI를 가능하게 한다.

DOI시스템 프록시 서버가 http://doi.org에서 단지 완전한 DOI 이름만을 해석하는 것과 동일하게, http://doi.org의 shortDOI 서비스 프록시 서버는 짧은 것만을 해석한다.
(두 프록시에 대한 오류 페이지는 적절할 때 다른 프록시에 대한 링크를 제공할 것이다.) 그 서비스는 새로운 짧은 것을 생성하거나 이미 생성 된 경우는 기존의 짧은 것을 반환한다.

자동화를 목적으로, short DOI 서비스는 그 서비스를 위한 URL에 원래의 DOI 이름을 간단히 추가하여 사용할 수 있다. 형식 매개변수는 정보가 반환되는 방법을 지정하는 데 사용될 수 있다. 자세한 내용은 short DOI 서비스 웹 페이지를 참조하라.

 

2.11 DOI 시스템과 인터넷 식별자 규격

DOI 시스템과 URL, URN 그리고 URI와 같은 일반적인 식별자들 사이의 관계를 논의한 정보지가 이용가능하다. "DOI® 시스템 및 인터넷 식별자 규격"(DOI® System and Internet Identifier Specifications)을 참조하라.

 

목차    이전 장 : 1. 소개    다음 장 : 3. 해석

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