DOI 핸드북 - 어플리케이션

이 장에서는 다중 해석 옵션 중에서, 가장 적합한 콘텐트로 DOI 이름을 해석할 수 있는 기능을 가진 어플리케이션을 제공하기 위해 이용할 수 있는 몇 가지 방법에 대해 설명한다. 이 옵션은 팝업메뉴를 통해 사용자가 직접 콘텐트를 선택하게 하는 방법과, 콘텐트 협상과 Linked Data를 통해서 일관된 자동 선택 방법을 포함할 수 있다.

5.1 소개
5.2 어플리케이션 설계
      5.2.1 기본 기능
      5.2.2 설계시 고려 사항
5.3 다중 해석 어플리케이션
5.4 링크드 데이터
      5.4.1 콘텐트 협상
5.5 어플리케이션 프로파일
5.6 DOI 이름들 간의 관계 표현하기
5.7 디지털 객체 레지스트리 기술을 갖는 DOI 시스템 사용
      5.7.1 디지털 객체 레지스트리
      5.7.2 디지털 객체 아키텍처
5.8 프래그먼트 식별을 위한 DOI 이름 사용

5.1 소개

항구적인 식별자를 유지하기 위해, 등록자와 협력하여 운영하는 능동적인 관리 서비스(management service)가 요구된다. 해당 관리 서비스를 가능하게 하기 위해, DOI 어플리케이션은 일반적으로 단순하게 DOI를 등록하는 것보다 많은 부가 가치를 제공한다. 일반적으로 등록 기관은 인용 연결 또는 메타데이터 관리와 같은 부가 가치 서비스(8. 등록관리기관 참조)를 제공한다.

DOI 이름은 다양한 형식의 콘텐트를 식별 할 수 있고, 그 콘텐트에 단순한 영구적인 간접 연결 이상의 방법으로 연결 할 수 있다. DOI 이름은 등록자 또는 제 3자가 제공한 그 객체에 관한 유용한 정보를 제공 또는 가리 킬 수 있다. 이러한 정보는 객체와 관련된 어떤 형식의 설명 메타데이터와 어떤 형식의 서비스라도 포함할 수 있다. 예를 들면, 권한 허가, 알림 서비스, 데이터 시각화 또는 임의의 다른 관련 정보 또는 서비스 등이 포함될 수 있다. 그 정보는 사용자의 요구을 만족시키기 위해 커스터마이즈된 DOI 어플리케이션에 의해 다양한 방법으로 이용될 수 있다.

이 장에서는, DOI 어플리케이션의 기초를 다루고, 시스템의 기능을 활용할 수 있는 새로운 서비스를 만들 때 개발자가 고려해야하는 디자인 요소를 논의하고, 등록 기관이 제공하는 DOI 이름 해석에 기반을 둔 몇 가지 서비스에 대해 예를 들어 설명한다. 더 나아가, 이 장에서는 어플리케이션 프로파일을 통해 서비스를 그룹화 하는 방법과, DOI 이름 해석과 상호 운용 가능한 시맨틱스(semantics)가 VMF(Vocabulary Mapping Framework)를 사용하여 어떻게 결합 되는지, 그리고 DOI 시스템이 디지털 객체 레지스트리 기술과 함께 어떻게 작동하는지를 설명한다.

5.2 어플리케이션 설계

DOI 이름과 관련된 모든 데이터는, 유형/값 쌍의 형태로 DOI 시스템에 고유 ID와 함께 각각 저장된다. 이는 매우 유연하고 개방적이다 : 새로운 유형이 언제든지 첨가될 수 있으며, 값들은 임의의 값이 될 수 있고, 유형/값 쌍은 관리(예를 들어, 만든 날짜, 권한, 등으로)하기 편하다. 또한, 잘 알려지고 표준화된 (예를 들어, URL, 이메일, 10320/LOC), 또는 특정 어플리케이션 목적으로 RA에 의해 정의된 (예를 들어, 이진 데이터 또는 특수한 형식의 문자열) 값일 수 있다. 거기에 DOI 이름과 연관된 많은 유형/값, 및 동일한 유형이 여럿일 수 있지만, 모든 DOI 이름은 적어도 하나의 "URL" 유형을 가지며, 그 값은 개체와 관련된 URL이다.

가장 기본적인 수준에서, 모든 DOI 어플리케이션은 DOI 이름을 해석하여 DOI 시스템을 조회한다. 그 요청은 DOI 이름과 연관된 모든 데이터를 요구하도록 구성될 수 있다. (특정 유형의 모든 데이터; 또는 특정 식별자를 갖는 데이터) (DOI 이름 해석에 대한 기본적인 자세한 내용은 제3장 해석(Resolution)을 참조) 어플리케이션은 형식 중 하나 이상을 형식을 이해하고, 구문분석하며, 평가하고 해당 값에 근거하여 조치를 취한다.

핸들 해석으로부터 반환된 유형/값 쌍을 검토하고 특정 정보를 제공하기 위해 구축된 간단한 서비스의 예는 dx.doi.org 프록시 시스템이다. 이 서비스는 특정 DOI 또는 DOI 그룹에 대해 담당하고 있는 DOI 등록 기관의 명칭을 반환한다.

DOI 이름이 문자열 “http://doi.org/doiRA/” 뒤에 추가되면, 해당 URL의 해석 (HTTP GET)은 RA의 이름을 기술하고 있는 JSON 비트를 반환한다.

여러 DOI를 구분하기 위해 URL 문자열에 쉼표를 사용하여 하나의 요청에 대해 여러 결과를 반환할 수 있다.

유연성과 확장성은 잘 설계된 DOI가 구동되는 서비스의 중요한 특징이다. 가장 유연하고 확장 가능한 방식은, 잘 구조화된 데이터로 식별자를 해석하는 간단한 리다이렉션 메커니즘으로 DOI 시스템을 사용하는 것이다. 이 방법은 리다이렉션의 단일 수준을 넘어서 DOI 관련 서비스를 제공하는데 사용될 수 있다. 단순히 한 개의 DOI 이름을 해석하여 한 개의 URL을 가져 오는 것 외에, DOI 등록 기관은 다중 해석 서비스를 제공 할 수 있다. 즉, 한 개의 DOI 이름을 콘텐트(예, 서지 메타데이터)에 대한 여러 선택사항들과 연결하고, 이 선택사항들은 메타데이터에 대한 특정한 표현이나, 특정 상황에만 사용가능한 메타데이터를 요청하는 것을 포함할 수 있다. 개발자는 DOI 시스템 자체에 서비스에서 제공하는 모든 혹은 대부분의 정보를 넣어서 DOI 시스템이 일차적인 서비스 제공자가 되게 하거나, 또는 대안으로 원하는 정보와 기능을 제공할 수 있도록 DOI 시스템이 하나 혹은 여러 개의 외부 서비스를 가르키도록 할 수 있다.

예를 들어, DOI 시스템은 사용자가 선택할 수 있도록 간단한 라벨 선택 메뉴를 표시하는데 필요한 모든 데이터를 저장하는데 사용될 수도 있지만, 가시화 도구를 위한 방대한 양의 과학데이터나 다중 이미지 파일들을 저장하는 외부 서비스로 리다이렉션하는 것이 DOI 시스템에 데이터를 저장하는데 선호될 것이다. 표준화된 형식으로 고품질의 기계가 읽을 수 있는 데이터를 저장, 사용 및 공유하는 어플리케이션을 개발하는 것은 한 발 더 나아가는 설계 고려 사항이다. DOI 어플리케이션은 링크드 데이터(Linked Data)의 모범 사례를 따르도록 설계될 수 있다. Linked Data는 표준 HTTP 웹 프로토콜의 콘텐트 협상(content negotiation) 기능을 이용하여 기계가 읽을 수 있는 형태로 데이터를 노출시키는 잘 알려진 개념이다.

여러 RA 어플리케이션에 걸쳐서 일관성을 유지하기 위해 DOI 구조 데이터를 활용하는 서비스를 창출하는 것이 권장된다. 협업은 가능한 언제나 권장된다. IDF의 일부가 아닌 제3자 어플리케이션 개발자들 또한 구조화된 DOI 데이터를 활용하는 서비스를 창출하는 과정의 일부가 될 것이 권장된다.

다중 해석(multiple resolution)과 콘텐트 협상을 기반으로 하는 DOI 응용 서비스들의 예를 아래에 설명한다. 신규 서비스는 언제든지 만들어 질 수 있다. 궁금한 점은 contact@doi.org.에 문의할 수 있다.

5.3 다중 해석 어플리케이션

가장 기본적인 DOI 어플리케이션은 하나의 DOI를 하나의 "URL" 형식으로 해석하는 것이다. 즉, 간단한 단일 포인트 해석이다. 프록시는 DOI 이름을 해석하고, URL 유형을 보고, 관련 데이터가 웹 브라우저와 같은 최종 사용자 클라이언트에게 HTTP 리다이렉트를 통해서 반환될 수 있음을 안다. 이 서비스는 다음과 같은 이유 때문에 성공한다. 1) dx.doi.org 프록시 서비스 형태의 클라이언트 소프트웨어는 URL 유형을 찾아 값을 추출하고, HTTP 리다렉트에 그 값을 넣어서, 사용자 클라이언트에게 다시 보내도록 프로그래밍 되었고 2) 특정한 DOI 이름의 관리자가 URL 유형을 이해하고 적절한 유형/값 쌍을 추가했기 때문이다.

다중 해석은 개체가 여러 개의 데이터 또는 개체의 여러 조각으로 해석 되는 것을 허용 한다. 다중 유형/값 쌍은, URL 유형에 한정되지 않고, 최종 사용자 클라이언트에 반환 된다. 클라이언트는 그 다음 행동을 결정하기 위해 데이터를 평가(분석)할 수 있다. (제 3장 다중 해석, 3.3 절 참조) XML 또는 다른 기계가 읽을 수 있는 데이터를 DOI 이름과 연결하는 것은 다중 해석의 사용성을 더욱 넓혀 준다. 즉, 여러 기능을 추가하고, 콘텐트 협상에 대한 더 많은 옵션을 제공하며, Linked Data 어플리케이션의 생성을 촉진해 준다.

다중 해석은 그래서 어떤 기준에 따라 가능한 결과 세트에서 선택하는 평가를 요구하는 어플리케이션을 구축하는데 유용하다. 어플리케이션 개발자는 사용자가 DOI 이름을 해석할 때, 사용자에게 옵션 메뉴를 제공하기 위해 클라이언트에 의해 사용되는 값을 저장하는 새로운 유형을 생성할 수 있다. 문서의 경우를 살펴보면, 문서를 보거나, 문서 메타데이터를 보거나, 동료에게 문서의 URL을 이메일로 공유하거나, 저자의 블로그를 방문 할 수 있는 등의 선택 사항들이 사용자에게 제공될 수 있다. 데이터 세트의 경우는, 랜딩페이지에서 전체 데이터 세트를 보거나, 또는 일부 선택된 데이터를 보거나, 또는 DOI 이름의 식별을 통해서 클라이언트에게 이용 가능하도록 만들어진 정보를 기반으로 몇 가지 다른 데이터 세트와 상호작용하는 선택들이 사용자들에게 제공될 수 있다.

사례 : 학술 저널 논문은 하나의 DOI 이름이 할당되지만, 여러 웹 사이트에서 사용될 수 있으며, 독자는 그들이 구독중인 서비스에서 해당 논문을 다운로드 할 수 있기를 바랄 것이다. CrossRef는 아래 그림 1에 나타낸 바와 같이, 사용자들이 논문의 DOI 이름을 해석하여 어떤 버전의 논문을 보고 싶어 하는지를 선택할 수 있도록 다중 해석을 사용한다.

이 서비스는 "10320/LOC" 유형을 이용하여 가능해졌다. 이 유형에는 기계가 읽을 수 있는 XML 형식의 값이 기술된다. 그 값은 DOI 이름을 해석할 때 취할 수 있는 동작을 선택하기 위해서, 클라이언트에게 동작의 선택, 혹은 ‘choose-by‘ 선택을 제공하기 위한 “location” 목록을 포함하고 있다. 그것은 많은 선택 가능한 경우로부터 특정한 URL 또는 다른 정보를 선택하기 위한 표준화된 메커니즘을 제공한다. 해석기는 해석기의 상황(프록시 서버의 경우에 HTTP 요청)과 각 위치의 속성을 근거로, 한 위치를 선택하기 위해서 알려진 선택방법을 목차로 적용할 수 있다. ('choose-by' 메커니즘의 원리에 대해 3. 해석의 3.8.1.3절에 설명)

10320/loc 유형은 DOI 서비스에 대한 옵션을 크게 확장 한다. 그림 1에 도시된 "사용자 선택" 옵션 외에도, 데이터 타입 10320/loc에 저장된 데이터는 주어진 기준을 근거로 클라이언트가 어떤 DOI 이름 해석의 결과가 어느 특정 사용자를 위한 것인지를 선택하게 하는데 사용될 수 있다. 아래 그림은 DOI 이름 10.1525/bio.2009.59.5.9와 관련된 값을 보여준다. 이 DOI 이름이 등록되었을 때 하나의 URL 값(URL 유형과 값, 일명 JSTOR URL과 동일한 데이터)만을 가지고 있었다. 10320/LOC 유형이 다른 해석 옵션을 제공하기 위한 명령을 제공하기 위해 추가되었다. 이 레코드가 프록시에 반환될 때, 프록시는 10,320/LOC 유형을 인식하고, 그렇게 하도록 요청되는 경우, 주어진 기준에 따라 위치 값들을 분석한다.

그림 2는 자동으로 사용자가 리다이렉션되는 URL을 선택하기 위해 클라이언트가 사용할 수 있는 지리적 위치를 포함하는 10320/LOC 유형의 데이터를 갖는 동일한 DOI 이름들을 보여준다.

Values for: 10.1525/bio.2009.59.5.9
Index	Type	Timestamp	Data
1	URL	Sun Jan 02 2011 13:32:18 EST	http://www.jstor.org/stable/25502450
1000	10320/LOC	Mon Jul 27 2009 13:18:25 EDT	<locations chooseby="locatt,country,weighted"> <location id="1" cr_type="MR-LIST" href="http://mr.crossref.org/iPage?doi=10.1525%2Fbio.2009.59.5.9" weight="1" /> <location id="2" cr_src="unca" label="SECONDARY_BIOONE" cr_type="MR-LIST" href="http://www.bioone.org/doi/full/10.1525/bio.2009.59.5.9" country="uk" weight="0" /> </locations>

10320/LOC 유형을 이해하지 못하는 클라이언트는 해당 유형/값 쌍을 무시하고 단순히 URL 형식을 사용하는 단일 수준의 리다이렉션을 사용할 것이다. 우리가 알고 있는 모든 기존의 DOI 클라이언트는 이 방식으로 작동한다. 이것은 이미 존재하는 수백만 개의 DOI 이름을 훼손하지 않고 DOI 해석에 새로운 기능을 추가 할 수 있게 한다.

이 방법은 어느 한 RA가 소유한 수백만 개의 기존 DOI 이름에 적용되더라도, 모든 DOI 레코드를 변경할 필요가 없다는 것을 알아야 한다. DOI 시스템의 인프라스트럭처는 주어진 DOI 접두사 아래의 모든 DOI 이름에 적용되는 어떤 정보라도 그 접두사를 담당하는 서비스를 식별하는 DOI 접두사 레코드에 기록될 수 있고 클라이언트들은 해석 과정을 통해 다양한 방법으로 그 정보를 전달할 수 있도록 설계되었다. 따라서, RA는 어느 시점에는 연결된 데이터와 다른 서비스를 가리키는 그들의 접근 방식을 바꾸거나 다른 매개변수를 사용할 필요가 있다. 그 변화는 하나의 DOI 접두사에 적용될 수 있으며, 자동으로 수백만 개의 DOI 이름 전부에 적용될 것이다.

Schema.org 가 주요 검색엔진이 웹페이지에서 구조화된 데이터를 인식하는 방식으로 기술문서를 제공한다는 것이 흥미롭다. 그 방식은 사이트로부터 풍부한 콘텐트와 데이터 조각을 얻어서 검색엔진의 결과 페이지로 직접 보내는 것이다. Schema.org는 단순한 HTML5 마크업 언어를 선호하며 RDFa는 꺼린다. 그 개념은 "rich snippet"이 검색 엔진으로 하여금 웹 콘텐트의 의미 있는 시맨틱을 읽을 수 있도록 하는 것이다. 이러한 "rich snippet"은 10320/loc와 'chooseby' 접근 방식으로 정확히 수행된다. schema.org이 관심 있는 조각을 정의하고, 그것이 충분히 중요할 경우, 조각들이 쉽게 값으로 기록되고 프록시로부터 생성된다.

5.4 링크드 데이터

위에서 기술된 ‘choose-by' 메커니즘이 두드러지게 사용되는 것은 Linked Data 서비스로의 리다이렉션이다. 연결된 데이터는 표준 HTTP 웹 프로토콜의 콘텐트 협상 기능을 사용하여 기계가 판독 할 수 있는 형식으로 데이터를 노출시키는 모범 사례들의 세트에 대한 일반적인 용어이다. 이러한 성공 사례는 연결 도구의 개발을 지원한다. 그리고 다양한 자산과, 비호환적인 API들을 다룰 필요 없이 다양한 웹 소스로 부터의 데이터를 사용할 수 있게 한다. 그리고 사람이 읽을 수 있는 표현 대신 기계에게 의미 있는 구조화된 폼으로 데이터를 요청하는 HTTP를 사용할 수 있게 한다. 웹의 초창기에는 사람이 대부분의 URL들을 따라다녔지만, 그리고 DOI 웹 프록시 단독으로 DOI 이름을 사람이 읽을 수 있는 웹페이지로 해석할 수 있었지만 이것은 더 이상 그렇지만은 않다.

dx.doi.org의 DOI 프록시는 DOI 이름에 대한 콘텐트 협상을 지원하기 위해 사용될 수 있다. Linked Data 어플리케이션에서, 프록시 서비스로 들어오는 HTTP 요청에 대한 평가 과정은 그것이 application/rdf+xml 형식의 콘텐트에 대한 요청인지 또는 일반적으로 Linked Data를 위한 요청으로 인식되는 유사한 타입 중의 하나인지를 결정하게 된다. 특별한 콘텐트 유형에 대한 이러한 요청은 자동화된 프로세스 또는 특별한 '연결된 데이터’ 브라우저에서 온 것이며, 일반적으로 최종 사용자로부터 오지는 않는다. 이것은 유용성은 물론, 외부 개발자가 부가가치 서비스 구축을 위해 IDF의 RA가 유지하고 있는 광범위하고 신뢰할 수 있는 메타데이터 레코드 세트를 조회 할 수 있도록 허용하는 것이다.

콘텐트 협상은 데이터를 연결하는 목적을 달성하는 인정된 방법이다. 웹 서버 및 DOI 프록시 서버에게 콘텐트 협상은 '나는 무엇을 되돌려 전송해야 하는지'를 의미 한다. 이것은 사용자가 웹 자원의 특정 표현을 요청할 수 있게 한다. 예를 들어, DOI 해석기는 DOI 이름과 관련된 메타데이터의 다른 표현을 제공하는 콘텐트 협상을 사용할 수 있다. DOI의 해석기에 대한 콘텐트 협상 요청은, 서버가 주도하는 협상이 클라이언트가 제공하는 허용되는 콘텐트 형식의 목록을 기반으로 진행되는 것을 제외하고는, 표준 HTTP 요청과 매우 유사하다.

몇몇 DOI RA들은 그들의 모든 DOI 이름에 기계가 읽을 수 있는 공통된 형식으로 메타데이터를 반환하는 서비스를 제공하는 방법을 사용하고 있다. DOI에 등록된 객체에 Linked Data 원칙과 기술을 적용하는 것의 중요한 이점은 '연결할 가치 있는 데이터' 라는 것이다. 그것은 큐레이션되고, 가치가 부여된 데이터이다. 이것을 등록 기관이 관리, 교정, 갱신 및 지속적으로 유지한다. 이것은 '비트 부패'(bit-rot, 소프트웨어 부패라고도 하며 시간이 가면 환경변화 때문에 소프트웨어가 더 이상 동작하지 않는 것) 되지 않고, 또한 영구적이다. 실제로, Linked data의 구현 품질은 단지 연결하고자 하는 그 데이터, 그리고 사용되는 의미와 맥락과 같은 수준이다. DOI 시스템은 일관되고, 관리되고, 연결하는 “큐레이션된 데이터”를 제공하여, 표준 Linked Data 기술을 여전히 사용하면서, 다른 “품질을 갖춘 데이터”에 확신을 갖고 연결할 수 있도록 해준다.

콘텐트 협상은 사용자를 위한 부가가치 메타데이터 표현을 특별히 제공하기 위해, DOI 이름을 담당하는 DOI 등록 기관에 의해 구현되고 있다. 일부는 RA들에게 공통된, 많은 인용 스타일이 지원되고 있다. 콘텐트 협상을 사용하면, 특정 RA에 국한된 콘텐트 유형을 선호하는 요구를 만들 수 있지만, 다른 RA를 위한 표준 콘텐트 유형의 응답은 저하된다. 이러한 서비스에 대한 요청은 자동화된 프로세스 또는 특수한 'linked data’ 브라우저에서 온 것이며, 일반적으로 최종 사용자로부터 오지는 않는다. 이것의 유용성은 외부 개발자가 부가가치 서비스를 구축할 수 있도록 IDF의 RA에 의해 유지되는 광범위하고 안정적인 메타데이터 레코드 세트를 조회할 수 있도록 하는 것이다. CrossRef, DataCite 및 mEDRA는 각각 http://data.crossref.org, http://data.datacite.org, and http://data.medra.org 서비스를 통해 콘텐트 협상된 DOI 이름을 지원한다. 이들 사이트에서 형식을 갖춘 메타데이터를 질의할 수 있다.

HTML 페이지 헤더가 GET "Accept: text/html"을 포함하는 일반 브라우저의 요청에 대해서, DOI 이름은 해석되고 사용자는 출판사의 랜딩 페이지 URL로 리다이렉션 된다. 예를 들어, DOI "10.1126/science.169.3946.635"는 "The Structure of Ordinary Water" 기사를 설명하는 랜딩 페이지로 리다이렉션 된다. 콘텐트 협상된 요청을 만드는 것은 대신에 “Accept" HTTP 헤더의 사용을 요구한다. 여기서 GET이 클라이언트에게 허용된 다른 알려진 콘텐트 유형을 포함하고 일반적으로 연결된 데이터에 대한 요구로 이해된다. GET 헤더 Accept: application/rdf+xml 이라는 브라우저 요청에 대해, 위에서 참조한 같은 DOI 이름을 해석하면 사용자는 RA의 메타데이터 서비스로 리다이렉트 할 것이다. 또한, 클라이언트가 citeproc JSON이 이용 가능하여 받기를 원한다면, "application/citeproc+json“과 "application/rdf+xml" 두 가지를 나열하는 Accept 헤더를 포함하는 요청을 만들 것이다. 그러나 만약 citeproc JSON이 이용 불가능하면 RDF XML을 처리할 수 있다.

10320/loc 유형은 프록시에 의해 해석되면, GET 방식에 기초하여, 위치 값은 사용자에 대한 응답을 만드는 적절한 메타데이터 서비스로 리다이렉션 하는데 사용된다. CrossRef, DataCite 및 mEDRA의 DOI 이름의 경우, "text/html" 유형이 아닌 콘텐트를 dx.doi.org에 요청하면 DOI 이름의 등록 기관에 의해 호스팅되는 메타데이터 서비스로 리다이렉션 된다.

설명을 위해 위의 DOI 이름을 사용하며, URL 유형 외에 모든 CrossRef DOI 이름은 10320/LOC 유형을 갖는다:

Values for: 10.1126/science.169.3946.635
Index	Type	Timestamp	Data
1	URL	Tue Jan 17 2012 14:39:18 EST	http://www.sciencemag.org/cgi/doi/10.1126/science.169.3946.635
1000	10320/LOC	Tue Jan 17 2012 14:39:18 EST	<locations chooseby="locatt,country,weighted"> <location weight="0" http_role="conneg" href_template="http://data.crossref.org/10.1126/science.169.3946.635" /> </locations>

모든 콘텐트 협상 질의는 인수로 요청된 DOI 이름을 사용하여 data.crossref.org의 서비스로 리다이렉션 된다. (동일한 DOI 이름이지만 특별한 ‘linked data' 콘텐트 협상의 표시가 없는 해석 요청은 - 예를 들어, 기존의 모든 웹 브라우저의 트렌젝션 - 다시 예상되는 URL 형식으로 돌아가서 기존의 DOI 리다이렉션을 되돌려줄 것이다.) 아래 그림은 콘텐트 협상 요청에 대한 Accept 헤더를 보여주며, 서비스에 의해 반환된 메타데이터와 "application/citeproc+json"과 "application/rdf+xml” 모두가 나열되어 있다. 이 Linked Data 어플리케이션에 대한 더 많은 정보는 http://crosscite.org/cn/. 에서 찾을 수 있다.

프록시는 DOI가 해석될 때마다 "Vary:Accept" HTTP 헤더를 반환할 것이다. 콘텐트 협상 요청에 대해서는 분리된 해석을 한다. 개발자들은 어느 DOI가 콘텐트 협상을 지원하는 것을 제공할지 결정할 때 이것을 사용 할 수 있다.

Linked Data의 목표는–사람과 에이전트 둘 다 객체에 대한 정보를 RDF와 XML과 같은 표준 형식으로 사용할 수 있도록 HTTP URI를 사용하는 콘텐트 협상–DOI 시스템의 영구적이고 고품질 데이터를 이용하여 달성될 것이다. Linked Data 어플리케이션의 수는 계속 증가할 것이다. 새로운 서비스에 대한 요구 사항이나 아이디어가 있으면, 추가 정보를 contact@doi.org에 문의하기 바란다.

5.5 어플리케이션 프로파일

DOI 이름은 서비스를 정의하는 어플리케이션 프로파일(Application Profiles)로 그룹화될 수 있다. 그 서비스는 DOI 이름의 세트에 사용할 수 있는 메타데이터 서비스를 포함한다. 각각의 DOI 이름은 하나 또는 그 이상의 AP의 구성원이 될 수 있다. 기본적으로, 예를 들면, 모든 DOI 이름은 DOI 이름에 대한 적어도 최소한의 커널 메타데이터를 포함하는 어떤 네트워크상의 위치로 DOI 이름을 해석할 수 있는 어플리케이션 프로파일의 일부이다. 어플리케이션 프로파일은 개념적인 그룹핑을 통해 유용해질 수 있지만, 기술적으로는 해석 메커니즘의 일부로서 DOI 데이터 모델로 표현될 수 있다. 공식적으로 AP를 등록하고 개별 DOI 해석에 반환되는 구조화된 데이터의 일부(예를 들어, 라벨)로서 그들을 포함시키는 메커니즘은 어플리케이션의 요구사항에 따라 달라진다. 잠재적인 사용자는 IDF와 논의하여야 한다.

5.6 DOI 이름들 간의 관계 표현하기

특정 관계(또는 기존 식별체계로 부터의 대응)를 정의하기 위해, Vocabulary Mapping Framework(VMF) 를 사용하여 단순하고, 유용하며, 상호 운용 가능한 시맨틱이 결합된 해석 능력을 제공해서, DOI 시스템은 Linked Data나 DOI 이름으로 식별되는 개체들의 관계를 위한 다른 메커니즘의 개발을 더욱 지원할 수 있다. 이 기능의 잠재적인 사용자는 IDF 커뮤니티와 꼭 논의해야 한다.

다음의 Relator 세트는 유형 관계(“정의된 유형의 관계에 의해 이 DOI 이름이 다른 DOI 이름과 연계된다“)를 고안하고 있는 등록 기관에 권고되고 있다.

여기에 적절한 의미는 "relators" 또는 (OWL/RDF 용어) “properties” 이다. 이들은 자원 또는 파티를 표현하는 두 개의 DOI 이름을 결합한다. IDF는 자신 소유의 네임스페이스의 데이터 사전에 소수의 “key” 관계자를 추가하였다. 이 관계자들은 기존 콘텐트 표준과 데이터베이스에 있는 자원들과 파티들 사이의 가장 일반적이고 중요한 관계를 표현한다.RA들이 그들의 구조(schema) 안에서 그 관계자를 사용하는 것이 권고된다. 다음의 문자열로 시작하는 다섯 개의 resource-to-resource 관계자와 하나의 party-to-resource 관계자가 제안되었다.

이 목록은 콘텐트 표준 및 데이터베이스를 기반으로 하는 출발점이다 : 각각은 VMF의 핵심 개념을 나타낸다. 그러나 RA들은 종종 이미 자신의 관계자(Relators)들을 가지고 있거나, 더 전문적인 관계자들(Relators)을 사용하길 원할 것이다. 예를 들어, 어떤 RA는 단지 Derivations보다는 Adaptations, Extracts 또는 Editions를 기술하길 원할 수 있다. 원칙적으로 어떤 세분화 정도의 수준으로도 확장할 수 있다. VMF를 사용하여, 이들 key relators의 각 sub relators의 계층 구조를 제공 할 수 있다. 예를 들어:

IsDerivedFrom
IsAdaptedFrom
IsTranslatedFrom
IsAutomaticallyTranslatedFrom
IsCompiledFrom
IsExtractedFrom
IsUpdatedVersionOf
IsCreatedFromBasis
IsReplicaOf
etc

이들은 RA에 의해 필요에 따라 DOI 데이터 사전에 추가될 수 있다. 이것은 VMF의 아주 작은 집중된 부분 집합이다 : 사용된 모든 예는 VMF 안의 다른 이름들, 그리고 많은 다른 것들 아래에 이미 있는 것들이다.

이 미니-온톨로지는 또한 RA 자신의 스키마, 또는 DC 또는 foaf와 같은 다른 스키마에서 특정 관계자에 대응하는 "IsSameAs"를 포함 할 수 있다. 예를 들어:

명백한 상호 운용성을 위하여, 구조적 관계자는 RDF/OWL 표준(예 : owl:equivalentProperty, rdfs:subPropertyOf)을 사용한다. 이 구조는 작지만 강력한 계층적이고 동등한 Relator Ontology를 제공한다. 이 온톨로지는 RA들이 그들이 선호하거나 요구하는 용어로 번역하기 위한 기본적인 추론의 도움을 받아서, DOI 이름과 관련된 연결된 데이터를 생성하거나 얻을 수 있도록 해준다. Relator Ontology의 크기와 범위는, 초기 key relator 이상으로 확장될 수 있고, RA 요구 사항에 따라 결정될 수 있다.

관계자	정의
doi:IsDerivedFrom	하나의 파생(Derivation) 된 것 (예를 들어, Adaptation, Excerpt 또는 Compilation)과 그것이 얻어진 소스사이의 관계자
doi:IsManifestationOf	하나의 표시(Manifestation)(예를 들어 Fixation, 또는 Performance)와 그것이 실현된 결과물(work) 사이의 관계자
doi:HasSubject	생성(Creation)된 것과 그것에 의해 참조되어진 개체 사이의 관계자
doi:IsReplacementFor	생성(Creation)된 것과 그것이 대체된 것(예를 들어, 업데이트된 버전의 소프트웨어)과의 관계자
doi:IsPartOf	생성(Creation)된 것과 그것의 일부(Part)와의 관계
doi:HasContributor	생성(Creation)된 것과 그것을 생성하는데 일조한 제3자의 관계

각 주요 관계자(Key Relators)는 몇 개의 특별한 자식을 갖는다. (자식은 데이터 사전에 임의의 지점에서 첨가될 수 있다). 예는 아래아 같다:

IsDerivedFrom
IsAdaptedFrom
IsTranslatedFrom
IsCompiledFrom
IsExtractedFrom
IsUpdatedVersionOf
IsCreatedFromBasis
IsReplicaOf
etc

5.7 디지털 객체 레지스트리 기수을 갖는 DOI 시스템 사용

몇몇 DOI 구현에 적용된 선택적인 경로는 보완적인 기능을 제공하는 CNRI의 디지털 객체 레지스트리( Digital Object Registry) 소프트웨어를 가진 DOI 시스템을 사용하는 것이다. Handle System과 디지털 객체 레지스트리 둘 다 더 넓은 의미에서 디지털 객체 아키텍처(Digital Object Architecture)의 일부이다. 일부 기본적인 기술의 변경이 필요할 수도 있다 : 이는 CNRI 또는 다른 주체들에(이 레지스트리 기술은 DOI 시스템의 일부도 아니고, IDF 의해 관리되는 것도 아니지만, DOI와 함께 사용되는 것은 권장된다) 의해 수행될 수 있다.

디지털 객체(DO) 레지스트리 소프트웨어는 핸들 시스템(DOI 시스템에서 사용)을 보완하기 위해 CNRI에 의해 개발되었다. 이것은 카드 카탈로그나 전화번호부에서와 유사하게 등록된 속성들을 검색해서 식별자를 알아내는 역으로 찾기(reverse-lookup) 기능을 제공한다. 이 소프트웨어는 공개되어 있어서 자유롭게 사용할 수 있고 DOI 어플리케이션(예를 들어: 엔터테인먼트 ID 레지스트리-EIDR를 위한 영화와 텔레비전 산업에 의해)을 포함하여 서로 다른 많은 영역에서 사용되어 왔다. 레지스트리는 상대적으로 저렴한 비용으로 오늘날 일상생활에서 많이 쓰이는 시스템을 사용하여 빠르게 구축될 수 있다. 정부의 많은 자금 지원으로 CNRI에 의해 만들어진 DO 기술은 저렴한 가격으로 또는 무료로 자유롭게 사용할 수 있다.

DOI 시스템과 함께 사용하는 레지스트리 소프트웨어는 다양한 방식으로 분산된 데이터 소스를 연합하는 데 사용될 수 있다. 즉, 복수의 네트워크 아키텍처가 가능하다. 간단한 방법은 하나의 검색 레지스트리에 정의된 개체들의 메타데이터를 제출하는 권한을 등록대행기관들에게 부여하는 것이다. 제출은 주어진 메타데이터 스키마를 준수하여 구축되어서, 제출된 것은 구문 검사를 거치고, 식별자를 갖고 있지 않으면 식별자(DOI)를 부여 받는다. 메타데이터는 색인되고 검색될 수 있게 된다. 검색은 임의의 트랜잭션 또는 상황에서 식별된 개체를 참조하는데 사용될 수 있는 식별자를 포함하는, 하나 이상의 항목을 반환한다.

간단한 시나리오 내에서 몇 가지 문제와 가능한 변형들이 있고, 시나리오 자체에도 구조적 변형이 있다. 그 시나리오에서, 레지스트리나 식별자 해석 시스템 내부에 유지되거나, 또는 등록대행기관(Registrar)이 가지고 있는 특정 데이터는 모두 다를 수 있다. 예를 들어, 레지스트리는 최소한의 참조 데이터를 가지고 있고, 등록대행기관은 추가적으로, 잠재적으로 표준이 아닌 레지스트리에는 없는 데이터를 제공하는 서비스를 운영할 수 있고, 식별자 시스템은 단지 그 레지스트리로 돌아갈 수 있는 주소를 가지고 있을 수 있다. 대안으로, 해석 시스템이 코어 데이터를 유지하며, 레지스트리는 방대한 데이터를 저장하고 있고, 등록대행기관의 역할은 데이터를 제출하는 것으로 끝날 수 있다. 구조적으로, 레지스트리 소프트웨어는 단일 중앙집중식 레지스트리에 한정되지 않는다. 다중 레지스트리는 새로운 엔트리 또는 엔트리의 변화가 즉시 다른 곳에도 반영 되도록, 서로 병렬로 실행되도록 구축될 수 있다.

이러한 프로토타입 시스템에 필요한 노력의 수준은 특정 기능적 요구 사항에 따라 크게 좌우된다. 주요 업무은 기존 소프트웨어를 설정하거나 재배치하기 위한 요구사항을 결정하기 위한 선행 분석이다.

DOI 시스템에서 정의된 객체들은 다양한 형태이다. DOI 이름은 물리적인, 디지털인 또는 추상적인`어떤 개체에도 할당될 수 있다. 디지털 객체 아키텍처에 정의된 객체는 디지털만 가능하다. 어떤 개체는 디지털 표현으로 다뤄질 수 있어서, 이 두가지 접근 방법에는 충돌이 없다. 이것은 아래 다이어그램에서 언급되어, 설명의 수준으로 사용되는 "기존 또는 미래의 정보 저장 시스템의 오버레이"의 단순한 다른 하나이다.

그림 3. 디지털 객체 클라우드, DOI 시스템에서 사용되는 핸들 시스템이 디지털 객체 아키텍처의 구성요소로 예상된다.

우리는 항상 여러 수준에서 그런 오버레이를 다룬다. 예를 들면, 스프레드시트는 데이터 셀 행렬 위에 있는 오버레이이다. 데이터 셀은 다음으로, 기저의 기계 코드 위에 있는 오버레이 이다. 재무 시스템은 스프레드시트 위에 있는 오버레이이다. 추상화된 작업은 개별 작업 표현 위에 있는 오버레이 이다. "자기 설명(self-explaining)" 이라는 것은 디지털 객체들이 자신의 콘텐트의 일부로서 직접적으로, 또는 다른 메타데이터로 연결하는 간접적으로, 어플리케이션에서 모호하지 않게 사용될 수 있도록 그 객체에 대한 충분한 정보를 가지고 있다는 것을 나타낸다.

5.8 프래그먼트 식별을 위한 DOI 이름 사용

어떤 경우에는 어플리케이션이 객체 전체를 식별하기 보다는 개체의 부분(fragment)를 식별하는 것을 요구할 수 있다. 이렇게 하는 것이 유용할 경우(책 내용의 특정 테이블이 여러 번 재사용될 가능성이 있는 경우)에 각각의 이러한 부분들도 별도의 DOI 이름이 할당될 수 있다. DOI 해석 http://doi.org/10.5446/12780#t=00:20,00:27 에서 볼 수 있듯이 DOI 등록 기관인 DataCite는 표준 #-프래그먼트를 사용하고 있으며 또한 표준으로 받아들여지는 W3C MFIDs(Media Fragment Identifier)를 사용하는 DOI 리다이렉션과 스크립팅을 사용하고 있다.

그러나, 이것이 항상 가능한 것은 아니다 : 어떤 사람은 실행시에 필요로 할 때 “이 개체의 어떤 프래크먼트”라도 식별하고 싶을 수 있다. 그러한 경우에는 "Template handles"의 사용이 필요할 수도 있다. 하나의 DOI 템플릿 핸들은 기초적인 형식의 형태로 포함되어 있을 수 있다. 이 형식은 개별적으로 등록될 필요 없이 패턴에 따라 그 기초 위에 많은 확장본을 만들 수 있다. 단일 템플릿 DOI 핸들은 개별적으로 등록하지 않아도, 어떤 패턴을 따라서, 전체 DOI 핸들로 해석되기 위해 그 기초에 대한 어떤 수의 확장도 허용되는 기초 형식(base formula)의 형태로 포함될 수 있다. 이러한 방식을 통해, 예를 들어, 한 비디오 안에서 무제한 수의 부분을 참조하기 위해 DOI 이름을 사용하는 것은 부분을 분리된 핸들로 등록하지 않고도 가능하다. 패턴이 변경될 필요가 있으면, 예를 들어, 비디오가 옮겨지거나 다른 서버가 비디오를 전송하게 된 경우, 이전에 만들어진 무제한의 확장본들이 지속적으로 알맞게 해석될 수 있도록 하기 위해서 오직 하나의 기초 DOI 이름(핸들)만 변경되면 된다.

5. 어플리케이션