영구 균일 리소스 로케이터

Persistent uniform resource locator
"PURL"은 여기서 리디렉션된다. "purl"의 다른 의미는 Purl(동음이의)을 참조하십시오.

PURL(영구적 균일 리소스 로케이터)은 요청된 웹 리소스의 위치로 리디렉션하는 데 사용되는 균일한 리소스 로케이터(URL)이다. PURL은 HTTP 상태 코드를 사용하여 HTTP 클라이언트를 리디렉션한다.

원래 PURL은 purl.org 또는 다음을 포함하는 다른 호스트 이름에서 호스트되는 것으로 인식되었다. purl초기에는 많은 다른 호스트들이 원래의 OCLC PURL 시스템 소프트웨어의 후손을 사용했다. 그러나 결국 PURL 개념은 일반적이게 되었고 다음과 같은 리디렉션 서비스(PURL 확인자)를 지정하는 데 사용되었다.[1]

  • 해결사 참조로 "루트 URL"이 있음(예: http://myPurlResolver.example);
  • 루트 URL에 새 이름을 포함시킬 수 있는 수단을 사용자 커뮤니티에 제공(예: http://myPurlResolver.example/name22);
  • 각 이름을 URL에 연결하고(재연결할), 이 리디렉션-URL을 업데이트하는 수단을 제공한다.
  • 루트 URL 및 PURL 확인자 서비스의 지속성(예: 계약별)을 확인하십시오.

PURL은 URL 해결 프로세스를 큐레이션하기 위해 사용되므로 HTTP와 같은 위치 기반 URI 체계에서 일시적인 URI 문제를 해결한다. 기술적으로 PURL의 문자열 해상도는 SEF URL 해상도와 같다. 이 글의 나머지 부분은 OCLC(온라인 컴퓨터 라이브러리 센터)가 제안하고 시행하는 OCLC의 PURL 시스템에 관한 것이다.

역사

PURL 개념은 1995년 스튜어트 와이벨과 에릭 줄리에 의해 OCLC에서 개발되었다.[2] PURL 시스템은 Apache HTTP Server의 1.0 이전 버전을 사용하여 구현되었다. 이 소프트웨어는 2007년 제페이라가 OCLC와 계약을 맺고 현대화, 확장되었으며 공식 웹사이트는 http://purlz.org으로 이전하였다('Z'는 제페이라 이름에서 유래했으며, OCLC에서 운영하는 PURL 오픈소스 소프트웨어 사이트와 차별화하는 데 사용되었다).

PURL 버전 번호는 혼동된 것으로 간주될 수 있다. OCLC는 처음에는 OCLC Research Public License 1.0 License에 따라 1999년에 Apache 기반 소스 트리의 버전 1과 2를, 나중에는 OCLC Research Public License 2.0 License(http://opensource.org/licenses/oclc2))에 따라 출시했다. 제페이라는 아파치 라이선스 버전 2.0에 따라 2007년에 PURLz 1.0을 출시했다. PURLz 2.0은 2010년에 베타 테스트에서 출시되었지만 결코 출시가 확정되지 않았다. 캘리마코스 프로젝트는 2012년 1.0 릴리즈를 기준으로 PURLs를 구현했다.

가장 오래된 PURL HTTP resolvever는 1995년부터 2016년 9월까지 OCLC에 의해 운영되었고 , , , 및 에까지 도달했다.

다른 주목할 만한 PURL 해결사로는 연방예탁원 도서관 프로그램에 운영되어 1997년부터 운영되고 있는 미국 정부 인쇄소(http://purl.fdlp.gov)가 있다.

PURL 개념은 이전 PURL 서비스와 PURL 기술을 대체할 수 있는 w3id.org에서 사용된다.

2016년 9월 27일, OCLC는 인터넷 아카이브와의 협력을 발표하여 해결사 서비스와 그것의 관리 인터페이스를 인터넷 아카이브로 이전하였다. 이 서비스는 이전의 모든 구현과는 별도로 새로 생성된 소프트웨어에서 지원된다. 이전은 수개월 동안 OCLC 호스트 서비스에서 비활성화된 PURL 정의를 관리할 수 있는 기능을 다시 활성화했다. Internet Archive 서버에 호스팅된 서비스는 , , , 및 . .를 통해 액세스를 지원하며, 이제 의 DNS 요청을 로 리디렉션한다.

작동 원리

PURL 개념은 월드 와이드 웹에서 HTTP URI의 일반화된 URL 큐레이션을 허용한다. PURL은 URL 해상도와 자원 메타데이터 제공에 대한 제3자의 제어를 허용한다.

URL은 월드 와이드 웹에 있는 자원의 주소일 뿐이다. 영구 URL은 다른 웹 리소스로 리디렉션을 발생시키는 월드 와이드 웹 상의 주소다. 웹 리소스가 위치를 변경하면(따라서 URL) 이를 가리키는 PURL을 업데이트할 수 있다. PURL 사용자는 문제의 리소스가 이동했을 수 있지만 항상 동일한 웹 주소를 사용한다. PURL은 출판사가 자신의 정보 공간을 관리하거나 웹 사용자가 관리할 때 사용될 수 있다. PURL 서비스는 정보 게시자와 독립적이다. 따라서 PURL 서비스는 하이퍼링크 무결성 관리를 허용한다. 하이퍼링크 무결성은 월드 와이드 웹의 설계 절충이지만, 자원 사용자나 제3자가 URL이 해결되는 위치와 방법에 영향을 미치도록 허용함으로써 부분적으로 복원될 수 있다.

간단한 PURL은 타입 302("Found"라는 의미의 HTTP 상태 코드 302와 동일)의 응답을 반환하여 HTTP GET 요청에 응답함으로써 작동한다. 응답에는 HTTP "위치" 헤더가 포함되며, 이 값은 클라이언트가 새로운 HTTP GET 요청을 통해 후속적으로 검색해야 하는 URL이다.

PURL은 가상 리소스에 대해 하나의 영구 식별자 형식을 구현한다. 다른 영구적인 식별자 체계로는 DOI(디지털 개체 식별자), LSID(생명과학 식별자), INFO URI 등이 있다. 모든 지속적 식별 체계는 (아마도 변화하고 있는) 가상 자원에 대한 고유한 식별자를 제공하지만, 모든 체계가 큐레이션 기회를 제공하는 것은 아니다. 가상 자원의 큐레이션은 "향후 사용을 위한 디지털 데이터의 보존을 포함한 정보 전문가가 경영에 적극적으로 참여하는 것"[3]으로 정의되었다.

PURL은 URL을 해결해야 하기 때문에 PURL을 네트워크 위치에 묶어야 한다는 비판을 받아왔다. 네트워크 위치에는 도메인 이름 시스템 등록 및 호스트 종속성과 같은 몇 가지 취약성이 있다. PURL을 해결하지 못하면 다음과 같은 모호한 상태가 될 수 있다. 네트워크 장애로 인해 PURL이 해결하지 못한 것인지, 아니면 PURL이 존재하지 않았기 때문에 해결하지 못한 것인지는 분명하지 않을 것이다.[4]

PURL은 그 자체로 유효한 URL이므로 해당 구성 요소는 URL 사양에 매핑되어야 한다. Scheme 파트는 웹 브라우저와 같은 컴퓨터 프로그램에 주소를 결정할 때 사용할 프로토콜을 알려준다. PURL에 사용되는 계획은 일반적으로 HTTP이다. 호스트 파트는 연결할 PURL 서버를 알려준다. 다음 부분인 PURL 도메인은 URL의 리소스 경로와 유사하다. 도메인은 PURL을 구분하는 계층적 정보 공간이며 PURL이 서로 다른 유지관리자를 가질 수 있도록 허용한다. 하나 이상의 지정된 유지관리자가 각 PURL 도메인을 관리할 수 있다. 마지막으로 PURL 이름은 PURL 자체의 이름이다. 도메인과 이름이 함께 PURL의 "id"를 구성한다.

permalink와 비교

permalink와 PURL은 모두 영구/영구 URL로 사용되며 요청된 웹 리소스의 위치로 리디렉션된다. 대략적으로 말하면, 그들은 똑같다. 이들의 차이점은 도메인 이름과 시간 척도에 관한 것이다.

  • permalink는 일반적으로 URL의 도메인을 변경하지 않으며, 수년간 지속되도록 설계된다.
  • PURL 도메인 이름은 독립적으로 변경할 수 있으며 수십 년 동안 지속되도록 설계되었다.

종류들

가장 일반적인 유형의 PURL은 반환되는 HTTP 응답 코드와 일치하도록 이름이 지정된다. 모든 HTTP 응답 코드가 동일한 PURL 유형을 갖는 것은 아니며 모든 PURL 서버가 모든 PURL 유형을 구현하는 것은 아니다. 일부 HTTP 응답 코드(예: 401, 무단)는 HTTP 대화의 맥락에서 명확한 의미를 가지지만 HTTP 리디렉션 프로세스에는 적용되지 않는다. 세 가지 추가적인 PURL 유형("체인", "부분" 및 "클론")에는 그 기능과 관련된 니모닉 이름이 부여된다.

PURL 유형
유형 PURL의 의미 HTTP 의미
200 생성되거나 집계된 콘텐츠 네 알겠습니다
301 대상 URL로 영구 이동됨 영구적으로 이동됨
302 대상 URL로의 단순 리디렉션 찾았다
체인 동일한 서버 내의 다른 PURL로 리디렉션 찾았다
부분적 추적 경로 정보가 추가된 대상 URL로 리디렉션 찾았다
303 다른 URL 참조 기타 보기
307 대상 URL로 임시 리디렉션 임시 리디렉션
404 일시적으로 사라짐 찾을 수 없음
410 영구히 사라짐 갔다
클론 기존 PURL의 속성 복사 해당 없음

대부분의 PURL은 원하는 리소스에 대한 리디렉션을 제공하는 이른바 "단순 PURL"이다. 단순 PURL의 HTTP 상태 코드는 302이다. 302 PURL의 목적은 웹 클라이언트와 최종 사용자에게 PURL을 최종 해결된 URI가 아닌 요청된 리소스를 처리하기 위해 항상 사용해야 한다는 것을 알리는 것이다. 이는 PURL이 변경될 경우 리소스의 지속적인 해결을 허용하기 위함입니다. 일부 사업자는 301 유형의 PURL(향후 요청에서 최종 URI를 다루어야 함을 나타냄)을 사용하는 것을 선호한다.

"체인" 유형의 PURL은 PURL이 301 또는 302 리디렉션과 동일한 방식으로 다른 PURL로 리디렉션할 수 있도록 하며, PURL 서버는 효율성을 높이기 위해 내부적으로 리디렉션을 처리한다는 차이점을 갖는다. 이 효율성은 많은 재조정이 가능할 때 유용하다. 왜냐하면 일부 웹 브라우저들은 일단 설정된 한계에 부딪히면 재조정을 중단하기 때문이다(루프를 피하기 위한 시도).

유형 "200"의 PURL은 "Active PURL"로, PURL이 반환되는 메타데이터의 생성이나 집계에 적극적으로 참여한다. 액티브 PURL에는 출력을 생성하기 위한 일부 임의의 계산이 포함되어 있다. PURLz 2.0과 칼리마코스 프로젝트에서 활성 PURL이 구현되었다. 이러한 정보를 사용하여 런타임 상태 보고서를 수집하고, 분산 쿼리를 수행하거나, 영구 식별자를 원하는 다른 유형의 데이터 수집을 수행할 수 있다. 활성 PURL은 관계형 데이터베이스의 저장 프로시저와 유사하게 작용한다.[5]

"303" 유형의 PURL은 웹 클라이언트가 자원 자체를 반환하지 않고 요청한 자원에 대한 추가 정보를 제공하는 자원으로 연결하기 위해 사용된다. 이러한 미묘함은 요청된 HTTP URI가 정보 자원으로 나타낼 수 없는 물리적 또는 개념적 객체의 식별자로 사용될 때 유용하다. 303 유형의 PURL은 RDF(Resource Description Framework)의 직렬화 형식의 메타데이터로 리디렉션하는 데 가장 많이 사용되며, 시맨틱 웹 및 링크된 데이터 컨텐츠와 관련성이 있다. 이러한 303 HTTP 상태 코드의 사용은 월드 와이드 웹 컨소시엄의 기술 아키텍처 그룹의 http-range-14 결과와 일치한다.

307 유형의 PURL은 사용자에게 리소스가 일시적으로 표준과 다른 URL에 있음을 알려준다. 404형 및 410형의 PURL은 요청된 리소스를 찾을 수 없다는 점에 주목하며, 왜 그랬는지에 대한 정보를 제공한다. HTTP 307(임시 리디렉션), 404(Not Found) 및 410(Gone) 응답 코드에 대한 지원이 완전성을 위해 제공된다.

관리자가 수리가 필요한 PURL을 표시하도록 돕기 위해 "404" 및 "410" 유형의 PURL이 제공된다. 이러한 유형의 PURL은 대상 자원이 이동했지만 적절한 대체 자원이 확인되지 않은 경우 리소스 식별 실패의 보다 효율적인 표시를 허용한다.

"clone" 유형의 PURL은 기존 PURL 레코드를 새로운 PURL로 복사하는 편리한 방법으로 PURL 관리 중에만 사용된다.

URL 조각의 리디렉션

PURL 서비스는 부분 리디렉션이라고 알려진 개념을 포함한다. 요청이 PURL과 정확히 일치하지 않는 경우 요청된 URL을 확인하여 PURL 문자열의 일부 연속적인 전면 부분이 등록된 PURL과 일치하는지 확인한다. 그렇다면 요청된 URL의 나머지 부분이 대상 URL에 추가된 리디렉션이 발생한다. 예를 들어, 대상 URL oo.와 함께 http/purl.org/some/path/의 URL이 포함된 PURL을 고려하십시오.f http://example.com/another/path/. URL http//purl.org/some/path/and/some/more/data에서 HTTP GET 작업을 수행하려고 하면 http://example.com/another/path/and/some/more/data으로 부분 리디렉션될 수 있다. 부분 리디렉션의 개념은 각각의 자원이 자체의 PURL을 요구하지 않고 PURL을 통해 웹 기반 자원의 계층 구조를 처리할 수 있게 한다. 하나의 PURL은 단일 대상 서버의 계층을 위한 최상위 노드 역할을 하기에 충분하다. 새로운 PURL 서비스는 부분 리디렉션을 수행하는 PURL을 나타내기 위해 "부분" 유형을 사용한다.

URL 경로 수준의 부분 수정은 HTTP 1.1 규격의 일반적인 해석에 위배되지 않는다. 그러나 수정 사항 전반에 걸친 URL 파편 취급은 표준화되지 않았고, 아직 합의가 이루어지지 않았다. 조각 식별자는 리소스 내에서 보다 구체적인 정보에 대한 포인터를 나타내며 URI에서 # 구분 기호로 지정된다.[6]

단편 식별자가 존재하는 부분 리디렉션은 두 가지 상반된 해석이 가능하기 때문에 문제가 있다.[7] 파편이 "부분적" 유형의 PURL에 부착된 경우, PURL 서비스는 해당 파편이 대상 URL에 의미가 있다고 가정해야 하는가, 아니면 위치가 변경된 리소스도 콘텐츠를 변경하여 이전에 정의한 파편을 무효화할 수 있다고 가정하여 이를 폐기해야 하는가? Bos는 지정된 대상 URL에 이미 단편 식별자가 포함되어 있지 않은 한, HTTP 수정 중에 단편들을 보존하고 표적 URL로 전달하여 300(다중 선택), 301(영구적으로 이동), 302(Found) 또는 303(See Other) 응답을 얻어야 한다고 제안했다. 대상 URL에 조각 식별자가 이미 있는 경우 원래 URL의 조각은 폐기해야 한다. 안타깝게도 보스의 제안은 IETF 표준 트랙을 탐색하지 못했고 추가 작업 없이 만료되었다. 두보스트 외.는 W3C 노트(표준이 아닌 표준이 없는 경우 지침)에서 보스의 제안을 부활시켰다.[8] 브라우저와 같은 웹 클라이언트의 제작자들은 "일반적으로"[8] 보스의 지침을 따르지 않았다.

PURL 서비스는 PURLz 1.0 시리즈를 시작으로 브라우저 벤더의 문제·불일관한 행동을 준수[8]·피하기 위해 대상 URL에 단편적인 내용을 적어 단편 식별자를 포함한 부분적인 재조정을 실시한다.

참고 항목

참조

  1. ^ URN LEX, ELI 및 DOI, Permalink 등의 서비스에서는 PURL 개념을 직간접적으로 사용한다.
  2. ^ Weibel, Stuart; Jul, Erik (1995). "PURLs to improve access to the Internet". OCLC Newsletter (November/December): 19. Retrieved 17 December 2021.
  3. ^ Yakel, E. (2007). "Digital Curation". OCLC Systems & Services. 23 (4): 335–340. doi:10.1108/10650750710831466.
  4. ^ Martin, Sean (2006-06-30). "LSID URN/URI Notes". World Wide Web Consortium ESW Wiki. Retrieved 2011-01-05.
  5. ^ Hyland-Wood, David (2008-07-01). "Metadata Foundations for the Life Cycle Management of Software Systems". School of Information Technology and Electrical Engineering, The University of Queensland. Retrieved 2011-01-05. Cite 저널은 필요로 한다. journal= (도움말)
  6. ^ "Uniform Resource Identifier (URI): Generic Syntax, RFC 3986 (STD 66)". IETF Networking Working Group. January 2005. Retrieved 2008-03-01.
  7. ^ "Handling of Fragment Identifiers in Redirected URLs, Expired Internet Draft". IETF Networking Working Group. 1999-06-30. Retrieved 2008-03-01.
  8. ^ a b c "Common User Agent Problems, W3C Note". World Wide Web Consortium. 2001-02-06. Retrieved 2008-03-01.

외부 링크