 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
더블린코어 메타데이터에서 서지인용정보의 입력지침
1. 서론과 범위이 문서는 더블린코어 기술 내에 서지인용정보를 기록하기 위한 지침을 제공하기 위한 것이다. 이 문서에서는 주로 다음과 같은 사항을 중요하게 다루고 있다.
레코드를 검색하고 나서, 육안으로 탐색하고 읽을 수 있도록 서지인용정보를 기술할 필요가 있고, 여기에 더해서 일부 어플리케이션에서는 기계가 판독하기에 적절한 포맷으로 이 정보를 부호화하고자 하는 욕구가 있다. 이 지침에서는 별도의 더블린코어 구문을 작성하는 대신 OpenURL 프레임워크 표준(Z39.88-2004)[1]에서 적용한 기술방식(description)을 사용하도록 제안하고 있다. 대부분의 구현에서는 학술지의 논문을 기술하는 방법을 필요로 하였으나 아무런 지침이 없었기 때문에 여러 가지 특수한 해결방안을 개발하였는데, 이러한 방안을 통해서 자체의 문제를 해결할 수는 있었지만 상호 운용성을 저해하게 되었다. 따라서 이 지침에서는 더블린코어 기술에서 서지인용정보를 부호화하기 위해 추천할 만하면서도 상호 운용 가능한 방식을 제시하고 있다. 자원을 탐색하기 위하여 서지자료를 기술하거나 혹은 단순히 상호 운용 가능한 자원 기술을 위하여 더블린코어 메타데이터를 사용하고자 하는 경우, 이 지침이 유용하리라고 생각된다. 이 지침은 아주 복잡한 메타데이터 기술을 필요로 하는 상황에 대한 해결책을 제공하는 것이 목적이 아니며, 또 그러한 해답을 제공해야 하는 경우에 적절한 메타데이터 체계를 대체하기 위한 것도 아니다. 서지자료를 XML로 기술하기 위한 더 구체적인 방법에 대해서는 PRISM[2] 이나 [3], NLM 데이터 [4] 와 같은 다른 체계가 더 적절할 수도 있다는 점도 제안되고 있다. 이 문서에서는 더블린코어에서 서지인용정보를 XML로 부호화화기 위한 구체적인 지침을 제시하지 않고 있다. XML로 입력하기 위한 지침은 장차 별도의 문서로 간행될 예정이다. 이하에 제시된 여러 표를 통해서, ‘값 문자열’(value strings)이라고 하는 간단한 용어열인 속성 값과 ‘값 URIs’라고 해서 URIs로 해석되어야 하는 속성 값 간을 구분하였다. 오직 어휘 입력 체계를 사용해야 하는 곳은 값 문자열로 표시되었다. 이 문서에서는 더블린코어 이름공간에 대해 다음과 같은 약어를 사용하였다.
이 지침은 더블린코어 인용 워킹 그룹(DCMI Citation Working Group)이 수년에 걸쳐 검토해 온 결과이다[5]. 이 지침은 더블린코어 용어관리위원회(DCMI Usage Board)에서 승인된 권고사항 이외에 다른 실무진이 이전에 제안한 권고사항을 대체하거나 반대한다. 더블린코어에서 사용하는 ‘bibliographicCitation’이라는 용어가 도입되기 이전까지, 더블린코어 메타데이터를 사용하여 학술지 논문을 완전하게 기술하는 방법이 분명하게 제시되지 않았다. 논문 제목이나 권호, 면수와 같은 구체적인 사항과는 별개로, 일반적인 기술의 일부로서가 아닌 학술지의 표제를 기술할 수 있는 적절한 속성이 더블린코어에는 없었다. 여러 가지 다양한 해결방안이 제안되었으며, 그 중에서 학술지와 권호 정보를 기술하기 위한 가장 좋은 방안으로 'isPartOf' 관계가 제안되었으나 이 관계는 논문 자체와 관련된 면수와 관련된 사항은 포함되지 않는다. 2 확장 더블린코어에서 서지인용2.1 기술된 자원에서 인용정보권고사항 1.자원에 대한 서지인용정보를 기록하기 위하여 dcterms:bibliographicCitation을 사용하라. 자원에 대한 서지인용정보를 자원 자체의 메타데이터 내에 기술하도록 권장된 속성은 dcterms:bibliographicCitation이다. 이 속성은 'dcterms' 이름공간에서 정의된 dc:identifier의 요소 세목이다. 이 속성의 값은 서지자료 내에서의 자원의 위치와 함께 해당 자원이 수록된 서지자료에 대한 구체적인 사항을 포함하게 된다. 따라서 학술지 논문의 경우, 학술지명과 권호, 면수, 발행일을 기록할 수 있으며, 단행본의 장인 경우에는 해당 단행본에 관한 구체적인 사항과 면수를 기록할 수 있다. 자원의 제목과 저작자와 같은 기타 사항은 더블린코어의 일반적인 속성을 사용하여 기술될 것이다. 다시 지적하지만 이와 같은 구체적인 사항은 선택사항으로 인용에 포함될 수도 있다. 학술지의 ISSN이나 단행본의 ISBN을 dcterms:isPartOf 관계속성 내의 값 URI로 기술할 수도 있다. 학술지의 논문과 회의발표논문에 대한 더블린코어 메타데이터 기술을 예1과 2에서 제시하고 있다. 이들 예에서는 어떤 특정한 구문 대신 표 형식으로 이들 기술을 제시하였는데, 권장되는 더블린코어 구문이라면 어떤 구문에서도 사용해도 좋을 것이다. 예 1: 학술지 논문에 대한 더블린코어 기술
예 2: 회의발표논문에 대한 더블린코어 기술
2.2 텍스트 인용문권고사항 2. 항상 평이한 텍스트로 인용문을 작성하라. 일반적인 자원 탐색이나 육안으로 읽기 위해서는 bibliographicCitation 속성의 값을 읽기 쉬운 텍스트로 제시해야 한다. 비록 기계를 사용하여 인용문을 분석하는 경우일지라도 이와 대응되는 인용문은 평이한 텍스트로 반복하여 제시하도록 권고되고 있다. 평이한 텍스트로 작성된 인용문은 공인된 인용양식에 따르게 될 것이다. 더블린코어 인용 워킹 그룹에서는 여러 가지 인용양식을 검토하였고 이들 양식을 인용양식[6] 으로 제시하였다. 그러나 어떤 양식을 선택할 것인지에 대해서는 특별히 권고하지 않고 있다. URI를 가지고 있는 경우에는 사용된 양식을 입력 체계로 제시할 수도 있다. 그 밖의 경우에는 인용양식을 제시하기 위해 더블린코어가 보증하는 입력 체계는 없다. 권고사항 3. 텍스트로 작성된 서지인용문은 해당 자원을 식별하기에 충분한 요소를 포함해야 한다. 텍스트로 작성된 서지인용문은 그 인용문을 통하여 해당 자원을 식별할 수 있도록 구체적인 사항을 충분히 포함해야 한다. dcterms:bibliographicCitation은 dc:identifier의 요소 세목으로서, 해당 자원의 인용정보를 통해 서지자원을 효과적으로 식별하기 위한 것이다. 따라서 학술지 논문의 경우, dcterms:bibliographicCitation 속성의 값으로 최소한 다음과 같은 사항이 포함되어야 한다. 즉 학술지의 표제(혹은 해당 학술지에 대한 다른 식별기호)와 적절한 권호와 편차 표시, 시작 쪽수 혹은 전자적인 형태로만 간행된 논문에 대해서는 해당 학술지의 특정 호에 기재된 기타 식별기호 등이 포함되어야 한다. 아울러 다음과 같은 사항을 제시하는 것도 아주 합리적이라고 할 수 있다. 즉 완전한 면수 정보로서 예를 들어 마지막 쪽수를 포함하고 또 별도의 dcterms:issued 속성 값으로 반복해서 표현되기도 하는 발행일자를 포함하는 것이다. 평이한 텍스트 인용문에 대한 일부 표본을 예 3에 제시하였다. 예 3: 텍스트 인용문의 예
2.3 기계분석이 가능한 인용문권고사항 4. 기계가독 인용문에 대해서는 OpenURL의 ContextObject를 사용하라. 디지털 상호 운용성을 증진시킬 수 있도록 기계로 분석 가능한 인용문을 작성하도록 권장되고 있다. ‘문맥인식 서비스를 위한 OpenURL 프레임워크’(OpenURL Framework for Context-Sensitive Services)는 ANSI/NISO 표준 Z39.88-2004로 제정되어 있다. 이 표준은 참고문헌의 문맥을 구성하는 관련된 자원과 함께, 참조된 자원을 기술하는 방법을 제시하고 있다. 이 패키지를 'ContextObject'라고 한다. 아울러 이 표준은 'OpenURL'의 특성을 정의하고 있는데, 이 'OpenURL'은 네트워크로 연결된 시스템 간에 이들 기술을 전송하는 방법을 정의한 것이다. 'ContextObject'는 OpenURL에서 가장 중요한 부분이긴 하지만('payload') 자율적인 데이터 객체이기도 하며, 따라서 더블린코어 속성의 값이다. OpenURL 프레임워크 표준에 대한 더 구체적인 사항은 Appendix A에 제시되어 있다. 현재 OpenURL 프레임워크에서는 그 첫 번째 레지스트리에서 메타데이터 포맷을 정의하고 있으며[7], 따라서 표준의 일부로서 학술지와 학술지의 구성요소, 회의발표자료와 여기에 수록된 논문을 포함하여 단행본과 단행본의 장절, 보고서, 간단한 문서, 학위논문, 특허 등에 대해 정의하고 있다. 앞으로는 더 많은 메타데이터 포맷을 정의하게 될 것이다. 이러한 메타데이터 포맷은 키/부호화 값(Key/Encoded-Value: KEV)과 XML 포맷이라는 두 가지로 이용되고 있다. XML 포맷의 용법에 대해서는 앞으로의 문서에서 설명할 것이다. 그러나 XML 어플리케이션 이외의 여러 가지 용법과 관련해 볼 때 KEV 포맷이 가장 적절할 것이다. KEV 포맷은 ‘&’로 한정된 짝으로 구성된 문자열로서, 각각의 짝은 레이블 즉 키(key)와 이와 관련된 값이 ‘등호’로 구분되어 있다. 이 값을 ‘URI-부호화’(URL-encoded)라고 하는데, 이것은 HTTP로 전송할 때 특수문자의 오류를 방지하기 위하여 이와 대등한 16바이트 문자열로 번역된다는 의미이다(예를 들어, '/'는 '%2F'로, ':'는 '%3A'로 표현된다). 예 4와 6에서는 예 1과 2에서 제시한 것과 동일한 학술지 논문과 회의발표논문에 대한 서지인용정보에 대한 키(key)와 값을 보여주고 있다. 예 5와 7에서는 XHTML로 입력된 bibliographicCitation 속성 내에서 같은 예에 대한 URL로 부호화된 완전한 ContextObject를 보여주고 있다. 아울러 예 5에서도 dcterms:isPartOf 속성의 값 URI로서 학술지의 ISSN을 포함하고 있다. 이들 예는 자원을 기술하기 위해 무엇이 가장 일반적으로 사용되는 ContextObject 키(key)인지를 포함하고 있다. 즉 OpenURL 프레임워크에서 사용되는 용어로 말하면 ‘대상’(referent)이 무엇인지를 예시하고 있다. 완전한 메타데이터 포맷은 OpenURL 레지스트리에 정의되어 있으며[7], 이들 예에서는 학술지 메타데이터 포맷[8]과 단행본 메타데이터 포맷[9]. 을 사용하고 있다. KEV 구현 지침에는 더 많은 사례를 제시하고 있다[10]. ContextObject에는 논문의 제목과 저자와 같은 구체적인 사항을 선택사항으로 추가로 포함할 수 있지만 이들 사항은 더블린코어 기술에서 이미 사용되고 있어 중복되는 사항이다. 권고사항 3으로 인해서 자원을 식별하기 위해 ContextObject 내에 충분한 정보가 포함되어야 한다는 점을 유의할 필요가 있다. ContextObject에는 ContextObject의 작성자인 ‘참조작성자’을 선택사항으로 포함할 수도 있는데 이렇게 함으로써 ContextObject의 기원을 제시하게 된다. 이들 예에서 참조작성자는 Zetoc 현황주지서비스 및 문헌전송서비스(Zetoc current awareness and document delivery service)이다. 참조작성자는 이 서비스의 DNS 이름을 사용하여 'info:sid/' 체계 의 URI로 식별되며, 그 다음에 선택사항으로 데이터베이스 이름, 즉 info:sid/mimas.ac.uk:zetoc가 온다. 인용문을 작성하기 위해 여기에 사용된 KEV ContextObject는 'info:ofi/fmt:kev:mtx:ctx'라는 URI로 식별되고 있다. 더블린코어를 XHTML로 표현하기 위한 지침과 일관성을 유지하기 위해서 XHTML로 작성된 예에서 KEV ContextObject는 'KEV'로 명명된 스키마 'info:ofi/fmt:kev:mtx:'의 요소인 'ctx'로 참조되어 있다. 필수로 사용해야 하는 선언부는 예 5의 첫 머리에 제시되어 있다. 더블린코어 간략 모형에서 사용하는 용어로 말하면[11] dcterms:bibliographicCitation 속성의 값은 KEV ContextObject 부호화 체계에 따라 부호화된 값 문자열이다. 이 문자열은 자원의 식별기호로 사용하기 위한 것이 아니며, 학술지 논문의 경우에는 아마도 DOI와 같은 적절한 URI 체계를 사용하게 될 것이다. 예 4: 학술지 논문에 대한 ContextObject 키(Keys)와 값
예 5: 학술지 논문에 대한 서지인용 더블린코어 속성 <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" /> <link rel="schema.KEV" href="info:ofi/fmt:kev:mtx:" /> <meta name="DCTERMS.bibliographicCitation" content="Library and Information Science Research 22(3), 311-338" /> <meta name="DCTERMS.bibliographicCitation" scheme="KEV.ctx" content="&ctx_ver=Z39.88-2004 &rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal &rft.jtitle=Library+and+Information+Science+Research&rft.stitle=LISR &rft.volume=22&rft.issue=3&rft.spage=311 &rfr_id=info%3Asid%2Fmimas.ac.uk%3Azetoc" /> <link rel="DCTERMS.isPartOf" href="urn:ISSN:0740-8188" /> [주의: ‘내용’(content)의 행 간격은 단지 표현을 위한 것이다. ContextObject는 단절되지 않고 하나의 행으로 되어야 한다] 예 6: 회의발표논문에 대한 ContextObject 키(Keys)와 값
예 7: 회의발표논문에 대한 서지인용 더블린코어 속성 <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" /> <link rel="schema.KEV" href="info:ofi/fmt:kev:mtx:" /> <meta name="DCTERMS.bibliographicCitation" content="Proceedings of the International Conference on Dublin Core and metadata for e-communities, 2002; DC-2002: Metadata for e-Communities: Supporting Diversity and Convergence, Florence, Italy, 13-17 October 2002, pp 71-80" /> <meta name="DCTERMS.bibliographicCitation" scheme="KEV.ctx" content="&ctx_ver=Z39.88-2004 &rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook &rft.btitle=Proceedings+of+the+International+Conference+on+Dublin+Core+and+ metadata+for+e-communities%2C+2002%3B+DC-2002%3A+Metadata+for+e-Communities %3A+Supporting+Diversity+and+Convergence%2C+Florence%2C+Italy%2C+13-17+October+2002 &rft.spage=71&rft.isbn=8884530431&rfr_id=info%3Asid%2Fmimas.ac.uk%3Azetoc" /> [주의: ‘content’의 행 간격은 단지 표현을 위한 것이다. ContextObject는 단절되지 않고 일행으로 되어야 한다] 2.4 참고문헌으로서의 인용권고사항 5. 자원으로부터 참조용 인용정보를 기술하기 위해서 dcterms:references를 사용하라. 기술된 자원에 의해 참조된 다른 자원에 관한 서지적 사항을 dcterms:references 속성 값으로 기술할 수 있으며, 이 속성은 dc:relation의 요소 세목이다. dcterms:bibliographicCitation의 값을 부호화하기 위한 앞서의 권고사항 3과 4도 dcterms:references의 값으로 사용할 수 있다. 그러나 가능하다면 인용하는 자원에 수록된 참고문헌의 텍스트를 이중화하여, 참조된 자원의 표제와 저자와 같은 구체적인 사항을 추가할 수 있을 것이다. 예 8에서는 두 개의 참고문헌을 수록한 학술지 논문에 대한 메타데이터를 표 형식으로 보여주고 있다. 예 9와 10은 XHTML로 작성된 학술지 논문에 대한 하나의 참고문헌을 각각 보여주고 있다. 첫 번째 예는 평이한 텍스트로 작성된 인용문이고 두 번째 예는 OpenURL의 ContextObject로 부호화된 값 문자열이다. 자원 자체의 서지사항과 달리 참고문헌은 육안으로 읽을 수 있도록 평이한 텍스트 인용문이거나 아니면 기계로 판독할 수 있는 OpenURL ContextObject 중 한 가지 방식으로 제시되어야 한다. 하나의 참고문헌을 부호화를 달리한 두 개의 사례로 제시해서는 이를 연결하는 방법이 없기 때문에 참고문헌을 중복해서 제시하는 것은 적절치 못하다. 예 8: 참고문헌을 포함한 학술지 논문 OpenURL ContextObjects는 URL로 부호화되지 않으며 식별을 위해 행 간격을 두었음을 유의하기 바란다.
예 9: XHTML로 부호화된 평이한 텍스트 인용문으로서의 학술지 논문에 대한 참고문헌 <meta name="DCTERMS.references" content="Apps , A., MacIntyre, R. zetoc: A Dublin Core Based Current Awareness Service. Journal of Digital Information (2) (2002)" /> 예 10: XHTML로 부호화된 OpenURL ContextObject로서의 학술지 논문에 대한 참고문헌 <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" /> <link rel="schema.KEV" href="info:ofi/fmt:kev:mtx:" /> <meta name="DCTERMS.references" scheme="KEV.ctx" content="&ctx_ver=Z39.88-2004 &rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal &rft.aulast=Carnall&rft.auinit=D &rft.atitle=Website+of+the+week%3A+Email+alerting+services &rft.jtitle=British+Medical+Journal &rft.volume=324&rft.spage=56&rft.date=2002" /> [주의: ‘content’의 행 간격은 단지 표현을 위한 것이다. ContextObject는 단절되지 않고 일행으로 되어야 한다] 3. 간략 더블린코어에서 서지인용간략 더블린코어에서 서지인용을 제공하기 위한 권고사항은 없다. 간략 더블린코어는 입력 체계 및 속성 값을 한정하기 위한 제어어휘와 같은 개념을 포함하지 않고 있으며, 모든 값은 평이한 텍스트 값 문자열로 취급된다. 그래서 자체 규정에 따른 것을 제외하면 간략 더블린코어에서 기계가 판독할 수 있는 사항을 제공할 수가 없다. 간략 더블린코어 기술에서는 다음 중 하나의 방법으로 서지인용정보를 사용하도록 제안되고 있다. 즉
KEV OpenURL ContextObject는 간략 더블린코어의 dc:identifier 속성의 값으로 포함될 수 있으며, 예 11에서와 같이 기계가 이해할 수 있는 어떤 가능성을 제시하기 위하여 이 값과 동일한 평이한 텍스트 인용문으로 포함될 수도 있으나 보증할 수는 없다. 더블린코어 추상 모델 문서의 부록 D에 제시된 바와 같이, XHTML로 부호화되어 사용되는 경우에 DC.identifier의 값은 비록 육안으로는 URI나 그 일부처럼 보이긴 해도 값 문자열이다. 예 11: 학술지 논문에 대한 간략 더블린코어 서지인용 <meta name="DC.identifier" content="Library and Information Science Research 22(3), 311-338" /> <meta name="DC.identifier" content="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal &rft.issn=0740-8188&rft.volume=22&rft.issue=3&rft.spage=311&rfr_id=info%3Asid%2Fmimas.ac.uk%3Azetoc" /> [주의: ‘content’의 행 간격은 표현을 위한 것일 뿐이다. ContextObject는 단절되지 않고 일행으로 되어야 한다] 간략 더블린코어에 기술된 자원에 의해 참조된 다른 자원에 대한 인용정보는 dc:relation 속성의 문자열 값으로 기술될 수 있다. 다시 지적하지만 값 문자열인 경우, 이것은 KEV ContextObject를 사용하여 기술될 수 있다. 예 12: XHTML로 입력된 OpenURL ContextObject로서 학술지 논문에 대한 간략 더블린코어 참조 <meta name="DC.relation" content="ctx_ver=Z39.88-2004 &rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal &rft.aulast=Carnall&rft.auinit=D &rft.atitle=Website+of+the+week%3A+Email+alerting+services &rft.jtitle=British+Medical+Journal &rft.volume=324&rft.spage=56&rft.date=2002" /> [주의: ‘content’의 행 간격은 표현을 위한 것일 뿐이다. ContextObject는 단절되지 않고 일행으로 되어야 한다] 4. 서지인용의 XML 입력서지인용정보를 XML로 부호화하기 위한 권고사항은 앞으로의 문서에서 제시될 것이다. 서론에서 제안한 바와 같이, 복잡한 XML 메타데이터 기술을 필요로 하는 어플리케이션에서는 OpenURL 프레임워크[1], PRISM [2], MODS [3], NLM Data [4]와 같이 서지자료용으로 특별히 설계된 다른 메타데이터 체계가 더 적절할 것이다. 5. 기타 문제더블린코어에서 서지인용정보의 기술과 관련된 여러 가지 다른 문제는 다음과 같다. 5.1 저자의 소속권고사항 6. dc:contributor를 사용하여 저자의 소속기관을 기술하라. 서지자료 특히 학술지의 논문의 경우, 자원의 기술에서는 물론이고 자원의 탐색에서도 저자의 소속기관은 중요한 정보이다(예: ‘맨체스터 대학에 적을 둔 교수들이 발표한 마그네슘에 관한 모든 논문을 탐색하는 경우’). 학술지의 논문이나 회의발표논문에서 소속기관은 해당 자원과 관련되어 있다. 해당 자원을 집필하였을 때나 심지어 다른 기관으로 소속을 변경한 경우에도 저자의 소속기관은 관련을 가진다. 따라서 이것은 저자의 속성이 아니라 자원의 속성과 관련된 것이다. 저자의 소속기관이 해당 자원의 제작에 기여하였다는 점을 인정해서 이 소속기관을 dc:contributor 속성의 값으로 기술하는 방안이 제안되고 있다. 논문 작성자가 아니라 소속기관이 자원의 속성이기 때문에 특정 저자와 그 소속기관과를 관련짓는 방법이 없다는 사실은(복수의 작성자가 있는 경우) 문제가 되지 않는다. 예 13: 저자의 소속기관을 포함한 회의발표논문의 더블린코어 기술
5.2 식별기호권고사항 7. 범용 식별기호를 URIs로 입력해야 한다. 서지자료에 적절한 범용 식별기호가 다수 존재하고 있다. 예를 들어 연속간행물에는 ISSN, 단행본에는 ISBN, SICI(연속간행물과 논문 식별기호), 디지털 객체 식별기호(DOI) 등이다. 이러한 식별기호를 더블린코어 속성 값의 값 URI로 부호화되어야 한다. 표 1은 이러한 식별기호 중 일부를 제시한 것이다. 이들 식별기호 중 일부는 새로운 'info' URI 체계를 사용하고 있다[12]. 이 체계를 도입하기 전까지 서지자료에서 공통으로 사용되는 이들 식별기호에 대한 범용 URI 이름공간은 없었다. 표 1: 서지자료에 대한 식별기호
5.3 전자형태로만 간행된 논문(Electronic-only Articles)학술지에 수록된 논문에 대한 서지인용정보를 기술하기 위하여 위에서 제시한 권고사항은 그 논문이 인쇄형태의 학술지의 한 호에 게재되고 해당 호 내에서는 그 논문의 시작 쪽으로 식별된다는 것을 전제로 한 것이다. 비록 지금은 대다수의 학술지 논문을 전자적으로 이용하고 있긴 하지만 이들 논문은 여전히 시작 쪽이라는 개념과 더불어 한 호 내에 여전히 포함되어 있다(실제로 이들 논문은 전자적으로는 물론이고 인쇄형태로도 발표되고 있다). 그러나 인쇄버전 없이 ‘처음부터 디지털’로 발행되는 전자저널이 점차 증가하고 있는데, 이 전자저널에서는 쪽 번호라는 개념이 존재하지 않는다. 또 연구 활동이 활발한 분야의 학술지 논문 중 일부는 학술지의 특정 호에 수록되기 전에 미리 발표되고 있다. 따라서 전자형태로만 간행된 학술지 논문을 기술하기 위해서는 해당 학술지의 호 내에서나 혹은 별도로, 이들 논문을 식별할 수 있는 수단이 필요하다. 이 식별수단은 특정 논문과 그 논문이 수록된 출판물의 환경에 따라 결정될 것이다. 전자저널의 특정 호에 수록된 논문에 대해서는 예 14에서와 같이, 해당 호 내에서 그 논문을 식별하게 될 것이다. 가능하다면 디지털 객체 식별기호(DOI)나 해당 논문을 읽을 수 있는 위치를 지시한 URL과 같은 식별기호를 통하여 전자 논문을 기술하는 것이 더 적절할 것이다. 예 14: 전자저널의 논문에 대한 서지인용
5.4 자원의 유형학술지의 논문이나 회의발표논문과 같이, 서지자료의 자원 유형을 제시하는 것이 바람직한 경우가 있다. 공인된 어휘 중의 용어를 dc:type 속성의 값으로 사용하는 방안이 제안되고 있다. Example 15. A Resource Type Indicating a Journal Article <meta name="DC.type" scheme="DCTERMS.MESH" content="Journal Article [Publication Type]" /> 5.5 더블린코어 인용 실무진의 이전의 제안DCMICite 더블린코어 구조 값을 반대한다. 서지인용정보를 기계로 분석하고 동시에 육안으로도 읽을 수 있는 형식으로 기술하기 위하여 더블린코어 인용 워킹 그룹에서는 그 실무진이 활동하던 시기에 더블린코어 구조 값(Dublin Core Structured Value: DCSV)인 DCMICite를 제안한 바 있다. 이 제안의 여러 버전이 각종 논문에 게재되었으며 다수 구현되었는데, 이런 결과를 가져 온 주된 요인은 적용해야 할 다른 어떤 권고사항도 없었기 때문이다. 이 제안은 현재 채용되지 않고 있으며 따라서 특정 기관의 어플리케이션을 제외하고는 사용되어서는 안된다. 왜냐하면 이 제안을 더블린코어 용어관리위원회(Usage Board)이 인정하지 않았기 때문인데, DCMICite를 사용하게 되면 장차의 상호 운용성을 보장할 수 없다. 이 제안은 DCSV에 기초한 것으로 이 구문 역시 채택되지 않은 것이다. 이 제안은 더 이상 서지인용기술에서 필요하지 않으며, 그 대신 OpenURL 프레임워크 메타데이터 포맷이 사용되고 있다. 부록 A: 문맥의존서비스를 위한 OpenURL 프레임워크‘문맥인식서비스를 위한 OpenURL 프레임워크’(OpenURL Framework for Context-Sensitive Services)은 ANSI/NISO 표준인 Z39.88-2004이다[1]. 이 표준은 참조의 문맥을 구성하는 관련된 자료와 함께, 참조된 자원을 기술하기 위한 방법을 제시하고 있다. 이 패키지를 'ContextObject'라고 한다. 아울러 이 표준은 네트워크로 연결된 시스템 간에 이들 기술을 전송하기 위한 방법인 'OpenURL'의 특성을 정의하고 있다. ContextObject는 OpenURL의 '핵심'(payload)이지만 자율적인 데이터 객체이기도 하다. 예를 들어 전자저널의 논문에 대한 참고서목 중의 인용문 이외에, 일반적으로 디지털 도서관 환경에서 이용자는 HTML 페이지에 있는 OpenURL 링크를 클릭하게 된다. 참고문헌에 대한 OpenURL은 연결 서버인 리졸버로 전송되고, 이 리졸버는 인용된 논문과 관련된 자원을 선정할 수 있도록 다시 이용자에게 회송되는데, 가급적 논문의 전체 텍스트에 대한 적절한 복제물과 연결되는 링크를 포함하게 된다. ContextObject는 개체를 여섯 개까지 수록할 수 있다. 그 중의 하나인 ‘대상’(referent)은 참조된 자원에 관한 정보를 지니게 된다. 이 대상은 항상 ContextObject에 포함되어야 한다. 나머지 다섯 개의 개체는 다음과 같다. 즉 참조를 한 자원(참조하는 개체), 이용자(신청자), 신청서가 전송되는 서비스(리졸버), OpenURL을 생성한 서비스(참조자), 신청된 서비스의 유형이다. ContextObject 내에서 각 개체에 관한 정보는 네 가지 방식에 의해 구체적으로 기술된다. 지시된 이름공간 내의 식별기호는 자원을 정의하게 될 것이다. 'by-value'나 'by-reference' 중 하나로 입력된 일련의 메타데이터는 해당 개체를 기술하게 될 것이다. 이 두 가지 방식의 차이는 by-value 메타데이터 기술은 ContextObject 내에 포함되는데 반해서, by-reference 메타데이터 기술은 ContextObject에서 식별되는 URI와 다른 곳에 포함된다. 네 번째 유형은 리졸버와 참조자 사이에서 사전 이해를 필요로 하는 정의되지 않은 독립된 데이터이다. 개체는 ‘키/부호화-값’(Key/Encoded-Value: KEV) 포맷이나 XML 중 한 가지 방식으로 부호화된다. KEV는 ‘&’-한정어의 짝으로 구성된 문자열로서, 각 짝은 레이블 즉 키(key)와 관련된 값으로 구성되며 ‘등호’로 구분되어 있다. 값은 ‘URL로 부호화’(URL-encoded)되어 있는데, 이것은 HTTP로 전송할 대 특수 문자의 오류를 방지하기 위하여 그 문자와 대등한 16진수 바이트로 변환된다는 것을 의미한다. OpenURL 프레임워크는 아주 일반적이고, 다양한 어플리케이션 영역과 여러 분야에서 사용될 수 있는 잠재력을 지니고 있다. 이 프레임워크의 핵심 구성요소에 대해서는 OpenURL 레지스트리에서 정의하고 있다[7]. 이 레지스트리에는 식별기호 이름공간과 메타데이터 포맷에 관한 리스트가 포함되어 있다. 이 레지스트리에서 특정한 어플리케이션 영역에 적합한 일련의 일관된 구성요소를 선정하게 되는데 이것이 ‘커뮤니티 프로파일’(Community Profile)로서, 이것 역시 레지스트리에서 정의되고 있다. OpenURL 프레임워크에 대해서 더 구체적인 사항이나 설명을 필요로 하는 경우에는 KEV 구현 지침[10] 과 해당 표준 [1] 자체를 참고하기 바란다. 참고문헌
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
COPYRIGTH (C) 2006 THE NATIONAL LIBRARY OF KOREA, ALL RIGHT RESERVED
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
