ccREL: 크리에이티브 커먼즈 권리표현언어
(Creative Commons Rights Expression Language)
W3C Member Submission 2008년 5월 1일
번역본 최종수정 : 2009-11-30, 23:30 (KST)
- 이번판:
- http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/
- 최신판:
- http://www.w3.org/Submission/ccREL/
- 공동저자:
- Hal Abelson (Creative Commons)
- Ben Adida (Creative
Commons)
- Mike Linksvayer (Creative Commons)
- Nathan Yergler (Creative
Commons)
- 번역자:
- 이정표(크리에이티브 커먼즈 코리아), lee.jungpyo(gmail), twitter@jungpyo
- 최영은(크리에이티브 커먼즈 코리아)
- 검토자 및 도움주신 분:
- 이미영님(어슬렁), 고영민님(달려라레오), 주원기님(산타), 김병정님(세케르), 서영교님(데니)
- 강현숙님(제니퍼), 김석준님, 윤종수님(게스후), 박형원님(달크로즈), 배수현님(션)
Copyright © 2009 크리에이티브 커먼즈 코리아(CC Korea).
원문의 저작자는 크리에이티브 커먼즈 (Creative Commons) 입니다. 크리에이티브 커먼즈 저작자표시 3.0 라이선스를 적용하고 있습니다.
본 번역본의 저작자는 2009 크리에이티브 커먼즈 코리아(혹은 CC Korea)입니다.
본 문서는 크리에이티브 커먼즈 저작자표시 2.0 대한민국 라이선스로 배포합니다.
이 번역본을 배포할 시에는 저작자가 CC Korea 라는 것과
출처(http://www.cckorea.org/ccrel-kr.html)를 표시해주시기 바랍니다.
이 문서의 상태
이번 장은 이 문서가 발행될 당시의 상태를 설명한다.
다른 문서가 이 문서를 대체할 수도 있다.
W3C 출판물 현재 목록과 이 기술보고서의 최신판은 http://www.w3.org/TR/의
W3C 기술보고서 색인에서 찾을 수 있다.
이 문서를 발행하면서, 우선 W3C는 이러한 공식문서를 제출한
공동저자(Submitting Members)들에게 감사를 표하고 싶다.
다만 W3C가 이 문서를 발행하는 것이 그 내용을 W3C가 승인하였다는 것을 의미하지는 않으며,
또한 W3C가 여기서 다루는 이슈를 위해 인력을 할당했거나, 하거나, 할 거라는 것도 아니다.
이 문서는 W3C 그룹의 공인된 결과물도 아니며, W3C 승인을
위해 제출된 제안서로써 출판된 것이다.
이 제출안에 대한
W3C 팀 커멘트도 함께 발행하였다.
인정된 제출안(acknowledged Member Submission)을 W3C 사이트에 발행하는 것은
W3C 회원에게 제공하는 혜택 중 하나이다.
W3C Patent Policy의 3.3.장 Member Submission과 관련된 요건들을 참조.
인정된 W3C 제출안의 전체 목록을 참조.
이 문서는 크리에이티브 커먼즈 권리표현언어(Creative Commons Rights
Expression Language, ccREL)를 소개한다. ccREL은 크리에이티브 커먼즈(CC)가
권고하는 표준으로 저작권 라이선스에 관련된 용어 및 정보를 컴퓨터가
처리할 수 있도록 하는 표현방법이다.
주1 이전에 크리에이티브 커먼즈가 권고했던 라이선스 메타데이터 표현방법은
모두 이 문서에서 설명하는 ccREL로 대신하게 된다. ccREL 권고표준은
이전과 동일하게 W3C의 자원 기술 프레임워크(RDF)에 기초를 두고 있다.
주2
하지만 ccREL 권고표준은 이전에 비해 쉽게 콘텐츠 제작자와 웹 개발자가 제작할 수 있고,
유저 커뮤니티와 툴 개발자가 좀 더 편리하게 사용, 확장, 재배포할 수 있게 되었다.
주3
ccREL을 한마디로 정의한다면 '라이선스를 적용한 문서에 관련된 프로퍼티(properties)를 모아놓은
확장집합으로 이것을 특정 문법에 얽매이지 않게 추상적으로 기술한 것이다'라고 할 수 있다.
따라서 웹 개발자는 어떤 문법이든 필요에 따라 선택할 수 있다.
조건이 있다면 프로퍼티 추출 과정을 알 수 있도록 해야 하고,
툴 개발자가 ccREL을 적용한 웹 페이지나 문서의 프로퍼티를 가져올 수 있도록 해주어야 한다는 것이다.
한편 추출방식에는 관심이 없고 단지 CC라이선스만 사용하고 싶은 콘텐츠 제작자나 웹 개발자가 있다면
HTML 웹 페이지에는 RDFa를 사용하고, 거기에 포함되는 리소스(파일)에는 XMP를 사용하도록 권고하고 있다.
주4
본 신규 권고표준을 이용하게 되면 웹 개발자는 크리에이티브 커먼즈 라이선스를
다음과 같이 간단하게 HTML 마크업으로 나타낼 수 있다:
<div about="http://lessig.org/blog/" xmlns:cc="http://creativecommons.org/ns#">
This page, by
<a property="cc:attributionName" rel="cc:attributionURL"
href="http://lessig.org/">
Lawrence Lessig
</a>,
is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
Creative Commons Attribution License
</a>.
</div>
위 마크업에서 http://lessig.org/blog/는
크리에이티브 커먼즈-저작자표시-라이선스 v3.0을 적용하였고,
http://lessig.org/ 라는 주소에
"로렌스 레식" 이라는 저작자를 표시하였다는 것을 툴(tool)도 정확히 알아낼 수 있다.
이 문서는 권고표준의 설계원칙을 설명한다. 그리고 ccREL을 지원하는 몇몇 애플리케이션을 예로 설명한다.
또한 크리에이티브 커먼즈가 2002년에 처음 만든 권고표준을 되돌아보고, 크리에이티브 커먼즈가 성장하면서
왜 이 권고표준을 버리게 되었는지도 설명한다. 그리고 프로퍼티를 모아놓은 어휘(vocabulary)로써, 특정 문법에
얽매이지 않는 방식으로 만든 ccREL을 소개하고, (이를 다룰 때) 추천할 만한 구체적인 문법을 보여주고자
한다. 추가로 마이크로포맷처럼 다른 프레임워크에서는 어떻게 ccREL과의 호환성을 갖도록 할 수 있는지
설명한다. 끝으로 구체적인 사용 예(use cases)와 ccREL를 이용하여 만들었으면 하는 여러 종류의 툴에
대해 알아보고자 한다.
크리에이티브 커먼즈는 2002년 12월에 공식 출범했지만, 기원은 2000년 여름에 있었던 논의로 거슬러
간다. 논의내용은 경직되고 불합리한 저작권을 인터넷시대에 맞도록 유연하고 합리적으로 만드는
방안이었다. 당시에는 창작자가 문서나 파일을 온라인에 공개하고자 할 때 본인의 일부 권리를 포기하고
일반에 공개할 수 있도록 하는 법적 표준이 없었다. 또한 라이선스를 얻고자 해도 그 권리소유자를
찾아내는게 매우 어려웠고, 이용 허락을 받는데 들어가는 거래비용도 부담이 되었다. 디지털 네트워크를
통해 모든 분야에서 아주 싼 값으로 콘텐츠를 만들고, 사용하고, 재활용할 수 있게 된 반면, 융통성 없는
라이선스로 인한 부담은 오히려 커져만 갔다.
그 다음 해가 지나서, 크리에이티브 커먼즈 창립자들은 이런 문제에 대응하는 두 갈래의 해법을
채택했다. 하나는 법적/사회적 측면으로: 조건부 재사용과 공유를 허락하면서, 사람들이 쉽게 이해할 수
있는 라이선스를 만들어 널리 배포하는 것. 또 다른 하나는 작품을 쉽게 가공하고, 찾을 수 있도록 디지털
네트워크를 레버리지 하는 것; 즉, 일부 권리가 공개된 작품에 대한 검색 및 거래비용을 낮추는 것이다.
이 기술의 핵심은 컴퓨터가 라이선스와 관련된 용어들을 얼마나 자동으로 탐지하고, 해석할 수 있는가이다.
프로그램은 다음 질문에 답할 수 있어야 했다:
- 저작권자가 사용한 라이선스는 무엇인가? 추가적인 이용 허락과 제한사항은 무엇인가?
- 영리적으로 이용할 수 있는가?
- 2차 저작물을 만들 수 있는가?
- 원작자에 대한 정보를 어떻게 알 수 있는가?
또한 중요한 것은 웹에 있는 (구조적인) 라이선스 정보를 알리거나, 알아낼 수 있도록
하는 안정적인 인간과 컴퓨터간 매개체를 만드는 것과 협업과 리믹스를 쉽게 할 수 있는
툴을 만들도록 독려하는 것이었다. 예를 들어, 어떤 웹 페이지에 그림이 여러 개
있는데 각각 다른 라이선스로 되어 있다고 하자. 이용자가 어떤 그림에 어떤
라이선스가 적용되었는지 쉽게 알 수 있는가? 그 중 원하는 그림을 쉽게 가져올 수
있는가? 2차 저작물을 만들 수 있는가? 원작자를 명시적으로 알린다면 재배포가
가능한가? 즉, 사람이 보는 것과 컴퓨터가 분석한 것 사이에 명확하고 의미있는 관계가 있는지 여부이다.
ccREL의 목표는 이런 작업을 쉽게 따라할 수 있도록 이끌어 주는 표준이 되는 것이다.
2001년 초가을에 크리에이티브 커먼즈는 그 당시 W3C에서 시맨틱 웹 액티비티
주5의 일환으로 만들었던
RDF를 이용하여 컴퓨터가 인식할 수 있는 라이선스를 만들었다.
그리고, RDF를 사용하는 것이 사람들이 서로의 작품을 이용하여 협업하고 창작물을
쉽게 공유하도록 하여 학술적, 문화적 발전을 촉진한다는 크리에이티브 커먼즈의
비전과 밀접하다고 생각하여 2001년부터 지금까지 사용하고 있다.
협동작업을 쉽게 하기 위해서 중요한 것은 라이선스 정보와 데이터를 표기할 때 이들이 '상호호환(interoperable)'되는 것이다.
'상호호환성(interoperability)'의 의미는 프로그램이 달라져도 특정 메타데이터 프로퍼티를 읽어낼 수 있고,
(관련 프로퍼티를 모아놓은 집합인) 어휘를 개선하거나 확장할 수 있어야 한다는 것이다.
이는 작가, 음악가, 사진가, 영화제작자, 생물학자, 지리학자 등과 같은 많은 공동체에서
다양한 방식으로 일이 진행되다 보면 지금은 없는 형식의 라이선스 조건들이 생겨날 수 있기 때문인데,
이때 또 중요한 것이 바로 '하위호환(backward compatible)'이다.
나중에 새로운 프로퍼티가 추가되었다고 해서 지금 쓰고 있는 툴이
중단되지 않아야 하고, 신규 프로퍼티에 대해서도 기본적인 수준의 처리는 해주어야 한다.
바로 이 내용들이 RDF를 만들때 고려했던 '의미적 상호호환성(interoperability of meaning)'이라고 할 수 있다.
RDF는 웹에 존재하는 엔티티(entity)를 기술하는 프레임워크이다. 이것은 상호호환성과
확장성이라는 특징이 있다. RDF의 모든 엔티티는 URI로 지정한다.
URI는 웹 사용자들에게 잘 알려진 URL을 일반화한 형태인데 간단하면서 널리 사용되고, 광범위한 주소표현이 가능한 방식이다.
주6
로렌스 레식 블로그를 예로 들면, URL이 http://lessig.org/blog/ 인 문서는
크리에이티브 커먼즈 저작자표시 라이선스라는 것을 알 수 있다.
이 라이선스는 URL이 http://creativecommons.org/licenses/by/3.0/ 인 문서이다.
보통 '무슨 라이선스를 적용한'이라고 사용되는 '라이선스' 프로퍼티는 그 자체가
URL로 식별되는 웹 오브젝트라고 할 수 있다. 여기서의 URL은
http://www.w3.org/1999/xhtml/vocab#license 이고,
'라이선스' 프로퍼티를 설명하는 정보가 있는 웹 페이지를 나타낸다.
이 특수한 웹 페이지는 W3C가 관리하며, XHTML 표준 주7에서
지원하는 어휘를 기술하는 문서이다.
프로퍼티를 URL로 표시함으로써 누구라도 서술내역을 체계화하는데 이들 프로퍼티를 사용할 수 있고,
URL로 지정한 페이지를 찾아봄으로써 기존 프로퍼티의 상세정보를 알 수 있으며,
또한 새로운 프로퍼티를 만들어 내는 것도 단지 이들 프로퍼티를 기술하고 있는 URL을 알려주는 것으로 해결된다.
예를 들면, 크리에이티브 커먼즈는 처음에는 자체적으로 "라이선스(license)" 프로퍼티를 정의하여
http://creativecommons.org/ns#license 주8 에
공개했었는데, 이는 그 당시 아무도 RDF로 저작권 라이선스라는 개념을 정의해 놓지 않았기 때문이었다.
2005년 XHTML 워킹그룹이 자체적인 라이선스 프로퍼티를 만들었을 때,
우리는 CC의 견해가 들어간 우리 자신의 라이선스를 유지하기 보다는 워킹그룹 버전을 사용하기로 했다.
http://creativecommons.org/ns#license와 새 프로퍼티인
http://www.w3.org/1999/xhtml/vocab#license가 동일하다라고
알리기 위해서 단지 http://creativecommons.org/ns#license에 서술내역을 약간 고치는 것으로 끝낼 수 있었다.
여기서 중요한 것은 RDF는 이런 식으로 '동일성' 판단을 사람이 직접 하는 게 아니라 프로그램이 할 수 있도록 하는데,
그럼으로써 "과거"에 선언된 RDF 라이선스가 자동으로 "현재"어휘를 이용하여 해석될 수 있도록 한다.
통상 RDF를 기술하는 최소단위를 트리플이라 한다. 각 트리플은 주어, 프로퍼티, (주어의 프로퍼티에 대한) 값으로 구성된다.
레식 블로그의 라이선스를 나타내는 트리플은 그림 1 처럼 도식화 할 수 있다. 블로그 URL이 붙은 첫 번째 점(주어),
라이선스 URL이 붙은 두 번째 점(값), 블로그에서 라이선스로 향하는 방향에 "라이선스"라는 의미를 설명하는 URL이
붙은 화살표(프로퍼티)이다. 보통 트리플 집합으로써의 RDF 모델은 엘리먼트 관계를 그래프 형태로 나타내며,
양끝과 꼭지에 URL를 붙인다.
그림 1: RDF 트리플은 양끝과 가운데 꼭지를 갖는 그래프로 표현한다.
 |
추상적인 RDF 그래프를 텍스트로 나타내는 방법은 여러 가지가 있다.
그 중 많이 사용되는 표기법인 RDF/XML은 XML 문법을 이용한다.
레식 블로그 라이선스를 나타내는 RDF/XML은 다음과 같이 표기한다:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xhtml="http://www.w3.org/1999/xhtml/vocab#">
<rdf:Description rdf:about="http://www.lessig.org/blog/">
<xhtml:license rdf:resource="http://creativecommons.org/licenses/by/3.0/" />
</rdf:Description>
</rdf:RDF>
RDF/XML 표기법의 특징 중 하나는 완벽하게 독립적이라는 것인데,
이는 완전한 형식(fully qualified)의 URL만을 식별자(identifier)로 사용한다는 것이다.
반면 RDF/XML 표기법은 표기할 내용이 너무 많아서 단축표현(shorthand)을 사용하지 않는다면
읽고 쓰기가 매우 번거롭다.
앞에 예문도 (복잡해 보이지만) 단축표현을 사용한 간단한 예제이다:
즉, 두 번째 줄 http://www.w3.org/1999/xhtml/vocab#을 "xhtml:"으로 정의한
단축표현(xmlns:xhtml)이고, 넷째 줄에 라이선스 프로퍼티를 xhtml:license라고 짧게 표현했다.
웹 컨소시엄에서는 RDF를 만든 후에 이를 표현할 좀 더 간결한 대체문법을 개발했다.
예늘 들면, N3 구문을 이용하면 위의 트리플을 좀 더 간결하게
9 표현할 수 있다.
<http://lessig.org/blog/>
<http://www.w3.org/1999/xhtml#license>
<http://creativecommons.org/licenses/by/3.0/> .
http://www.w3.org/1999/xhtml/vocab# 부분을 xhtml:로 정의하면
위에 RDF/XHTML 예제를 다음과 같이 간단하게 표현할 수 있다.
@prefix xhtml: <http://www.w3.org/1999/xhtml/vocab#> .
<http://lessig.org/blog/> xhtml:license <http://creativecommons.org/licenses/by/3.0/> .
하지만 앞에서처럼 단축표현한 접두사(@prefix)를 단 한 번만 사용하면 간결함이나 가독성에 도움이 되지 않는다.
N3 표기법의 경우에, 보통 동일 어휘에 속한 여러 개의 프로퍼티를 표현할 때와 같이
한 번 이상 단축표현을 쓰게 될 때만 접두사를 사용한다.
RDF/XML 표기법의 경우에는, XML 방식이라 유연함이 별로 없기 때문에:
술어(predicate)만이 단축표현을 쓸 수 있고, 주어는 완전한 형식의 URI로만 쓸 수 있다.
2002년에 크리에이티브 커먼즈는 컴퓨터가 인식할 수 있는 라이선스를 공개하면서
웹 개발자에게 라이선스 프로퍼티를 표현할 때 RDF/XML을 사용할 것을 권고했다.
CC 웹사이트에 라이선스 생성기(license generator)를 포함시켜서, 웹 개발자가 몇 가지
질문에 답을 하면 이에 맞는 라이선스를 알려주고, 동시에 HTML 주석부분에 넣을 수 있는
RDF/XML 구문도 생성하도록 했다.
<!-- [RDF/XML HERE] -->
그 당시에도 복잡한 RDF/XML을 HTML 주석문에 사용하는 방식이 불편한 방식이라는 것을 알았지만
그 때에는 RDF/XML이 RDF를 표기하는 유일한 표준이었다.
게다가 웹 컨소시엄의 시맨틱 웹 액티비티는 데이터베이스와 웹을 통합하는 조직구성에 집중하고 있어서
시맨틱 정보와 웹 정보(element)를 통합하는 문제에는 신경쓸 여력이 없었다.
이 문제를 해결하려고 태스크포스를 구성하긴 했으나 HTML 페이지에 RDF를 삽입하는 W3C 표준은 없었다.
지금은 수 많은 웹 페이지에 메타데이터와 크리에이티브 커먼즈 라이선스가 포함되었지만,
이러한 초기 설계의 제한으로 인해서 툴 개발자가
메타데이터에 접근할 수 있는 일관되고 확장가능한 방법이 없으며,
기존 툴도 메타데이터를 얻어내기 위해 임시적인 기술(ad-hoc technique)을 사용하고 있는 상황이다.
2004년부터 크리에이티브 커먼즈와 웹 컨소시엄은 HTML문서에 RDF를 삽입하는 좀 더 간단하고
제한이 적은 방법을 함께 개발하고 있는데, 이런 새로운 방식이 현재 W3C 표준화 절차를 통해 진행 중이다.
따라서,
CC는 라이선스 정보를 표현하기 위해 HTML 주석에 RDF/XML를 사용하는 것을 더 이상 권고하지 않는다.
본 문서는 이전 권고표준을 대신한다.
우리는 이 문서에서 제안하는 새로운 표준인 ccREL이 크리에이티브 커먼즈 라이선스를 이용하는 툴 개발자와 웹 개발자에게 더 일관되고 안정적인 플랫폼이 되기를 바라고 있다.
이번 장에서는 ccREL에 대해서 설명한다.
ccREL은 라이선스 정보를 추상화하여 특정 문법에 의존하지 않도록 하고,
이를 컴퓨터가 인식할 수 있도록 하는 새로운 권고표준이다.
추상화에 대한 명세인 ccREL은 라이선스가 붙는 대상(객체)과 함께 제공되어야 하는 RDF 프로퍼티로 이루어져 있다.
이 추상화 명세는 CC 프로퍼티를 도입한 2002년 이후 계속 개선된 것이다.
주목할 만한 것은 이런 1세대 라이선스를 신규표준에서도 그대로 사용할 수 있다는 것인데
이는 대부분 RDF의 주요특징인 프로퍼티 확장성 덕분에 가능한 것이다.
ccREL 추상화 모델에서는 프로퍼티를 두 종류로 구분한다:
- 작품 프로퍼티 (Work properties)는 작품의 특성을 다루며,
작품에 적용한 라이선스도 포함한다.
- 라이선스 프로퍼티 (License properties)는 라이선스의 특성을 다룬다.
작품의 라이선스를 표기하는 일을 하는 웹 개발자라면 작품 프로퍼티만을 다루면 될 것이다.
라이선스 프로퍼티는 크리에이티브 커먼즈가 제공하는 여러 종류의 라이선스를 공식적으로 정의할 때 사용한다.
각 기관들도 이들 요소를 이용해 자신만의 라이선스를 정의할 수 있다. 하지만 그렇게 정의된 라이선스는
비록 크리에이티브 커먼즈 라이선스와 유사하더라도 크리에이티브 커먼즈 라이선스는 아니며
또한 크리에이티브 커먼즈가 보증하지도 않는다.
웹 개발자가 크리에이티브 커먼즈 라이선스를 작품에 적용하려면 최소한 1개의 RDF 트리플을 사용해서,
작품의 라이선스 프로퍼티(예를 들면, 작품에 적용한 라이선스) 값을 지정해주어야 한다. 예를 들면,
<http://lessig.org/blog/> xhtml:license <http://creativecommons.org/licenses/by/3.0/> .
이것이 최소한 정보라고 할 수 있지만, 웹 개발자에게 바라기는 라이선스를 적용한 작품에 대한
제목, 이름, 저작자 URL, 문서형태 같은 추가정인 정보를 주는 트리플도 넣었으면 한다. 예를 들면,
<http://lessig.org/blog/> dc:title "The Lessig Blog" .
<http://lessig.org/blog/> cc:attributionName "Larry Lessig" .
<http://lessig.org/blog/> cc:attributionURL <http://lessig.org/> .
<http://lessig.org/blog/> dc:type dcmitype:Text .
작품 프로퍼티의 상세는 다음과 같다.
- dc:title - 문서의 제목. 여기서 dc:는 더블린 코어 메타데이터 이니셔티브에서 관리하는
http://purl.org/dc/elements/1.1/ 에 정의된 더블린 코어주10 어휘에 대한 단축표현이다.
- cc:attributionName - 크리에이티브 커먼즈 라이선스
주11에 결합된 조건에 따라 작품이 수정,
재배포될 경우 알려야 하는 원작자의 이름. 접두어 cc: 는 위에 언급한 것처럼
http://creativecommons.org/ns#의 단축표현이다.
- cc:attributionURL - 저작자 정보를 알려주는 링크 URL.
- dc:type - 라이선스를 적용한 문서의 형식. 예를 들면 텍스트는 dcmitype:MovingImage 이다.
레식 블로그에는 때로 비디오가 올라가는데 이 경우에는 dcmitype:MovingImage 이다.
http://dublincore.org/documents/dces/ 에 가면 dc:type 에 대한 권장 사용법이 있다.
dcmitype:Text나 dcmitype:MovingImage 값들은 DCMI 어휘 중에 하나이다.
덧붙이자면, 위 4개의 트리플은 N3 세미콜론 방식으로 바꿔 표현할 수 있으며,
이 경우 다음처럼 동일 주어를 가지는 트리플의 목록으로 나타낼 수 있다:
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix cc: <http://creativecommons.org/ns#> .
@prefix dcmitype: <http://purl.org/dc/dcmitype/> .
<http://lessig.org/blog/>
dc:title "The Lessig Blog" ;
cc:attributionName "Larry Lessig" ;
cc:attributionURL <http://lessig.org/> ;
dc:type dcmitype:Text .
웹 개발자가 이용할 수 있는 작품 프로퍼티는 다음 2개가 더 있다:
-
dc:source - 작품을 변경했을 경우 원작에 대한 정보를 URL로 표시한다, 예를 들면,
<http://randomblog.example.org/modified_lessig_presentation> dc:source
<http://lessig.org/> .
-
cc:morePermissions - CC 라이선스에서 언급한 것들 외에 추가 이용 허락 정보를 표시한다.
예를 들면, 저작자표시라는 CC 라이선스가 붙은 문서라도 특정한 상황에서는 저작자표시 없이 사용하도록 할 수 있다.
또는 영리 목적 이용금지 조건의 문서라도 특정한 조건에서는 영리 목적 이용이 가능하도록 할 수 있다.
보통 다음과 같이 표현한다:
<http://randomblog.example.org/insightful_posting>
cc:morePermissions <http://randomblog.example.org/attribution_free_licensing> .
라이선스에 결합된 추가 이용 허락에 대한 정보를 지정된 URL에 두고 관리하는 것은 전적으로 웹 개발자의 소관이나,
추가 이용 허락은 반드시 추가적인 허락이어야지,
크리에이티브 커먼즈 라이선스에서 이미 부여한 권리를 제한해서는 안 된다.
즉, morePermission 프로퍼티 없이도 이용할 수 있던 것은 morePermission을 사용할 때도 가능해야 한다.
이상의 내용이 현재의 ccREL 작품 프로퍼티이다.
앞으로 크리에이티브 커먼즈나 누군가가 신규 프로퍼티를 추가할 수도 있을 것이다.
이 경우 트리플만 추가하면 새 프로퍼티를 사용할 수 있게 되는 RDF의 확장성을 ccREL에서도 이용할 수 있다는 것을 알게 될 것이다.
예를 들면, photoResolution 프로퍼티를 확장하고자 할 때 이미 사용중인 툴에 지장을 주지도 않고,
기존 프로퍼티에도 영향을 주지 않는다면 사진 커뮤니티 웹 개발자도 굳이 확장 프로퍼티 사용을 반대하지 않을 것이다.
프로퍼티 확장성을 활용할 수 있는 ccREL에 대한 구체적인 문법(RDFa)에 대해서는 다음 부분에서 보도록 하자.
다양한 곳에서 신규 프로퍼티를 만들 수는 있지만 http://creativecommons.org/ns#의 문서를 정의하는 것은 크리에이티브 커먼즈가 하고 있기 때문에,
cc:namespace에는 크리에이티브 커먼즈만이 신규요소를 포함시킬 수 있다.
RDF를 이용하면 이처럼 확장성을 제한하지 않으면서도 쉽게 관리를 할 수 있게 된다.
그러면 이제 라이선스를 표기하는 프로퍼티에 대해서 살펴보자. 크리에이티브 커먼즈는 웹 개발자가 ccREL의 라이선스 프로퍼티를 직접 수정하거나 사용하지는 않을 것이라 생각한다.
하지만, 크리에이티브 커먼즈의 첫 메타데이터 권고표준에서는 웹 개발자가 라이선스 작품과 라이선스 프로퍼티를
같이 제공하도록 권고했다.
이 방식은 좋지 않았는데, 왜냐면 웹 개발자가 작품에 적용한 라이선스를 한 번 표시하였는데,
거기에 추가로 라이선스 프로퍼티를 알려주는 것은 중복이기도 할뿐더러 실수할 가능성도 있기 때문이다.
ccREL은 이러한 중복을 제거하고자 라이선스 프로퍼티는 크리에이티브 커먼즈가 제공하는 것으로 남겨두고 있다.
그러나, 툴 개발자는 모든 크리에이티브 커먼즈 라이선스의 세부내역을 이해해야
하기 때문에 라이선스 프로퍼티를 다루어야 한다. 작품에 적용한 라이선스 프로퍼티는 보통 URL로 알아낸다.
작품을 검사하는 툴은 xhtml:license 프로퍼티를 찾아서, 거기에 지정된 라이선스를 가리키는 페이지를 따라간다.
크리에이티브 커먼즈가 관리하는 라이선스 상세서술 페이지-"크리에이티브 커먼즈 증서"-에는 CC가 권고하는
문법인 RDFa로 기술한 라이선스 프로퍼티가 들어있으며, 이것에 대해서는 7.2장에서 설명할 예정이다.
다음은 ccREL의 한 부분인 라이선스 프로퍼티이다:
- cc:permits - 작품에 대해 저작권법의 기본 허용 범위를 넘어서는 이용에 대한 예외적 허가.
- cc:prohibits - 작품 이용에 대한 예외적 금지, 특히 cc:permits 에서 제공된 허락 범위에 영향을 끼치는 경우 (저작권법이 부여한 권리를 제한하는 것은 아님).
- cc:requires - cc:permits 에서 제공된 허가를 이용하기 위해 이용자에게 요구되는 행위조건.
- cc:jurisdiction - 라이선스를 특정한 재판관할권에 귀속시킨다.
- cc:deprecatedOn - 지정된 날짜가 되면 무효가 되는 라이선스를 표시한다.
- cc:legalCode - 라이선스 법조문에 해당하는 주소를 표시한다.
중요한 점은 크리에이티브 커먼즈는 현재 크리에이티브 커먼즈 라이선스에 들어있는 프로퍼티를 제3자가 수정하도록 허용하지는 않는다는 것이다.
즉, 웹 개발자는 이러한 프로퍼티를 이용하여 자체적인 라이선스를 만들어서 자체 서버에 연결해 둘 수 있지만,
이것이 크리에이티브 커먼즈 라이선스를 나타내는 것은 아니라는 것이다.
cc:permitscc:permits 에 지정할 수 있는 값, 즉 CC 라이선스가 제공하는 이용 허락은 다음과 같다:
- cc:Reproduction - 다양한 형태로 작품을 복사하는 것.
- cc:Distribution - 작품을 재배포하는 것.
- cc:DerivativeWorks - 작품의 2차 저작물을 작성하는 것.
cc:prohibits에 지정할 수 있는 값, 즉 이용 금지에 지정될 수 있는 값(하지만, 공정이용처럼 저작권법이 이미 허락한 것을 금할 수는 없다)은 다음과 같다:
- cc:CommercialUse - 작품을 영리적으로 이용하는 것.
cc:requires에 지정할 수 있는 값은 :
- cc:Notice - 작품에 적용한 라이선스의 지시사항을 제공한다.
- cc:Attribution - 원작자를 표시한다.
- cc:ShareAlike - 2차 저작물을 재배포할 때, 동일조건 라이선스를 사용한다.
- cc:SourceCode - (이 항목은 소프트웨어에 해당하는데) 원본을 재배포할 때, 소스코드를 제공해야 한다.
예를 들면, 저작자표시 - 동일조건변경허락 v3.0 크리에이티브 커먼즈 라이선스는 다음과 같이 표시된다:주12
@prefix cc: http://creativecommons.org/ns# .
<http://creativecommons.org/licenses/by-sa/3.0/>
cc:permits cc:Reproduction ;
cc:permits cc:Distribution ;
cc:permits cc:DerivativeWorks ;
cc:requires cc:Attribution ;
cc:requires cc:ShareAlike ;
cc:requires cc:Notice .
향후 새로운 저작권 라이선스가 등장하게 되면 크리에이티브 커먼즈는 새로운 항목들을
허가사항, 요구사항, 금지사항 안에 추가할 것이다.
하지만, 크리에이티브 커먼즈가 허가사항, 요구사항, 금지사항 외에 새로운 라이선스 프로퍼티를 추가할 것 같지는 않다.
결과적으로 이들 세 개의 프로퍼티 타입을 인식하도록 만든 툴로도 새로운 라이선스를 해석하거나 최소한 라이선스의
허가사항, 요구사항, 금지사항을 목록으로 보여줄 수 있을 것이다.
또한 프로퍼티를 URL로 나타내는 RDF 프레임워크 덕분에
이러한 툴은 아직 정의되지 않은 프로퍼티 값에서 사람이 이해할 수 있는 부분을 찾아낼 수 있을 것이다.
앞서 ccREL을 설명하기 위해 RDF/XML과 N3 표기법을 사용하여 예를 들었지만,
ccREL은 RDF 트리플을 표현하고자 할 때 특정 문법에 얽매이지 않는다.
ccREL과 호환되는 결과물을 얻기 위해서, 웹 개발자가 해줄 것은 단지 툴 개발자가 탐색과정을 통해
각 ccREL 프로퍼티--작품 프로퍼티만 의미하며, 라이선스 프로퍼티는 크리에이티브 커먼즈만 제공--에
해당하는 RDF 트리플을 추출할 수 있도록 준비해 주기만 하면 된다.
각 웹 개발자는 각 유저들에게 제공하고자 하는 환경을 고려하여 선택한 문법(syntaxes)를 사용할 것이고,
상이한 방식으로 이를 수행할 것이라 예상된다.
그러나, 개개의 경우에 있어서 웹 페이지에 적절한 추출 메커니즘을 적용하고,
툴 개발자가 이를 알 수 있도록 설정하는 것은 웹 개발자의 역할이다.
또한 크리에이티브 커먼즈는 툴 개발자가 기본적으로 인식해야 하는 구체적인 ccREL 문법을 권고하여,
비록 추출 메커니즘과는 전혀 관련 없는 웹 개발자도 명확히 구현방법을 알 수 있게 하려고 한다.
이런 권고 문법--웹 페이지에는 RDFa를, 비정형 콘텐츠에는 XMP를 사용하는 것으로--은 다음 장에서 다룰 예정이다.
이번 장에서는 권고표준에 담긴 원칙을 설명한다.
웹 문서용 라이선스 정보는 HTML형태로 표현될 것이다. 어떤 프로퍼티가 크리에이티브 커먼즈 조건을 표시하는데 이상적인 HTML 문법이 될 수 있을까?
수 년에 걸쳐 용례들을 관찰해온 결과로 다음과 같은 필요조건들을 도출하였다:
- 독립성과 확장성 Independence and Extensibility:
우리는 어떤 새로운 종류의 데이터와 크리에이티브 커먼즈 라이선스를 적용한 데이터가 통합되고 싶은지를 미리 알 수 없다.
지금도 이미 크리에이티브 커먼즈 프로퍼티와 단순한 미디어 파일들(사운드, 이미지, 비디오)을 결합시킬 필요가 있으며,
복잡한 과학 데이터(바이오메디컬 기록, 실험 결과)를 위한 마크업을 제공하는 것에 대한 관심이 높아지고 있다.
따라서, HTML로 라이선스 정보를 표현하는 방식은 확장이 가능해야 한다.
즉, 크리에이티브 커먼즈나 다른 주체들에 의해서 기존 데이터 모델 재사용과 신규 프로퍼티 추가가 가능해야 한다.
신규 프로퍼티를 추가할 때 여러 커뮤니티간의 광범위한 조율 혹은 어느 중앙 권위체로부터의 승인이 필요하지 않아야 한다.
신규 프로퍼티가 추가되거나 기존 프로퍼티를 새로운 종류의 데이터 세트에 적용한다고 하여
현재 사용하는 툴이 쓸모 없게 되어서는 안 된다.
- 중복 사용 금지 DRY: 웹 페이지들 중에는 저작자의 이름과 크리에이티브 커먼즈 라이선스로 연결된 링크를
이미 가지고 있는 것들이 종종 있다.
이런 데이터를 컴퓨터가 인식하도록 하기 위해 다른 형태로 중복해서 가지고 있는 방식이어서는 안 된다.
특히, 사람이 보게 되는 라이선스 링크를 변경하면(예를 들면, v2.5 에서 v3.0으로),
컴퓨터도 이 변화를 자동적으로 알 수 있어야 한다.
즉, 사람이 보는 부분과 '맞추기 위해' HTML의 다른 부분을 고치거나 하지는 않아야 한다.
- 시각적 일치성 Visual Locality: 한 HTML 페이지에 각기 다른 라이선스를 가진 십여 개의 사진이 있는 경우처럼,
한 HTML 페이지에는 각각의 구조적 데이터를 가진 다수의 아이템이 있을 수 있다.
이런 경우 눈에 보이는 것과 그것이 가지고 있는 구조적 데이터를 툴이 쉽게 결합할 수 있어야 한다.
- 리믹스 편의성 Remix Friendliness: 한 문서에 있는 아이템의 구조적 데이터를 모두 유지한 채로 복사하여,
다른 문서로의 붙이기가 쉬워야 한다.
끊임없이 기존의 콘텐츠를 리믹스해서 새로운 콘텐츠를 만들어 내는 현재에는
복사와 붙이기, 위젯, 사이드바 같은 기능은 리믹스가 가능한 웹을 위한 중요한 요소이다.
가능한 한 ccREL에서는 라이선스 정보를 유지하면서 쉽게 복사와 붙이기가 되도록 해야 한다.
어떤 작품들은 HTML이 아니라, MP3나 MPEG, 또는 다른 형식의 미디어파일로 유통된다.
이런 종류의 파일에 라이선스 데이터를 넣기 위해서는 다음과 같은 설계 원칙들을 갖춰야 한다:
- 일관성 Consistency: 다양한 종류의 파일이 있을 수 있기 때문에,
라이선스 정보를 넣는 방식은 당연히 일반적이어야 한다.
그렇게 함으로써 하나의 툴이 모든 종류의 파일타입을 알아내지 않고도 라이선스 정보를 읽고 쓸 수 있어야 한다.
- 개발자의 신뢰성 Publisher Accountability: 파일이 P2P를 통해 배포되는 경우 한 곳에서 배포되는 것에 비해
라이선스 메타데이터에 대한 신뢰성(accountability) 확보가 어렵다.
메타데이터를 보여주는 방법이 적어도 소유자가 확실하고 잘 운영되고 있는 사이트의
웹 페이지가 주는 만큼의 신뢰성을 줄 수 있는 것이어야 한다.
- 간결함 Simplicity: 라이선스 정보를 추가하는 과정이 단순해야 하고, 프로그램 비용도 거의 들지 않아야 한다.
특별한 경우 전자서명이나 인증 같은 고수준의 배포자 신뢰성 검증 툴을 사용할 수는 있지만,
이런 것이 기본으로 요구되어서는 안 된다.
ccREL의 추상화 모델을 떠올려 보자. 여기에 N3로 표기한 레식 블로그의 트리플을 다시 적었다.주13
@prefix xhtml: <http://www.w3.org/1999/xhtml#> .
@prefix cc: <http://creativecommons.org/ns#> .
<http://lessig.org/blog/> xhtml:license <http://creativecommons.org/licenses/by/3.0/> .
<http://lessig.org/blog/> cc:attributionName "Lawrence Lessig" .
<http://lessig.org/blog/> cc:attributionURL <http://lessig.org/> .
여기에 적은 정보는 다음처럼 사람이 볼 수 있는 형태의 HTML 페이지로 중복되었을 가능성이 크다:
<div>
This page, by
<a href="http://lessig.org/">
Lawrence Lessig
</a>,
is licensed under a
<a href="http://creativecommons.org/licenses/by/3.0/">
Creative Commons Attribution License
</a>.
</div>
여기서 우리가 찾고자 한 것은 기존의 마크업과 링크정보를 사람과 컴퓨터가 모두 인식할 수 있도록 하는
중복방지(DRY) 원칙을 지키면서, RDF 트리플 추출이 가능한 구조를 갖도록
쉽고 빠르게 HTML을 확장할 수 있는 방법이다.
RDFa는 크리에이티브 커먼즈의 요청으로 W3C에서 설계했으며, 위에서 언급한 몇 가지 원칙들이 부분적으로 반영되었다.
RDFa는 기존의 HTML 프로퍼티에 새로운 것을 약간 추가함으로써 RDF 트리플을 표기할 수 있고,
어디서나 콘텐츠를 재사용할 수 있도록 하였다.
예들 들면, 위에 HTML 앵커(anchor)내에 몇 가지 속성을 추가함으로써 다음과 같이 확장할 수 있다:
<div about="" xmlns:cc="http://creativecommons.org/ns#">
This page, by
<a property="cc:attributionName"
rel="cc:attributionURL" href="http://lessig.org/">
Lawrence Lessig
</a>,
is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
Creative Commons Attribution License
</a>.
</div>
다음은 위의 마크업의 의미를 이해하기 위한 규칙이다:
- about에는 <div>안에 존재하는 모든 트리플의 주어(subject)를 정의한다.
about=""는 주어가 현재문서라는 것을 의미한다.
- xmlns:cc의 의미는 <div>안에 존재하는 모든 cc
접두사는 http://creativecommons.org/ns# 로 치환될 수 있다는 것으로,
N3 표기법의 @prefix와 같다.
- property는 술어가 cc:attributionName인 새 트리플을 생성한다.
오브젝트는 엘리먼트의 텍스트 내용인데, 위의 경우는 "Lawrence Lessig"이다.
- rel="cc:attributionURL"는 술어가 cc:attributionURL인 새 트리플을 생성한다.
오브젝트는 href에 있는 URL이다.
- rel="license"는 술어가 xhtml:license인 새 트리플을 생성한다.
license 처럼 xhtml은 예약된 XHTML을 가리키는 기본 접두사이다.
오브젝트는 href로 지정한다.
위 (div 안에 있는) HTML 부분은 완전히 독립적(self-contained)이다 (그래서 리믹스가 쉽다).
이 부분을 복사하여 다른 웹 페이지에 붙일 때도 그 의미가 계속 유지된다. 데이터가 데이터 구조를 포함하고 있다.
사람이 육안으로 페이지를 볼 때, 화면에 보이는 영역과 거기에 적용한 데이터 구조를 쉽게 알 수 있다.
게다가 다른 데이터를 입력하지 않아도 화면에 나타난 원저자 이름과 그 링크가 시맨틱적인 의미를 갖게 된다.
결론적으로, RDF를 사용함으로써 RDF 어휘가 갖는 프로퍼티의 확장성과 독립성이 자동적으로 상속된다.
결국, 누구나 신규 어휘를 만들고 기존의 어휘의 일부를 재사용할 수 있게된다.
그림 2: 현재 CC 작품 프로퍼티를 보여주는 RDFa 마크업 예제와
실제 웹 브라우저에 나타난 결과.
|
<div about="" typeof="cc:Work"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
align="center">
<img alt="Creative Commons License"
src="http://i.creativecommons.org/l/by/3.0/us/88x31.png" />
<br />
<span property="dc:title">The Lessig Blog</span>,
a
<span rel="dc:type" href="http://purl.org/dc/dcmitype/Text">
collection of texts
</span>
by
<a property="cc:attributionName"
rel="cc:attributionURL" href="http://lessig.org/">
Lawrence Lessig
</a>,<br />
is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
Creative Commons Attribution License
</a>.<br />
There are
<a rel="cc:morePermissions"
href="http://lessig.org/blog/other-license">
alternative licensing options
</a>.
</div>
|
물론 데이터를 화면에 표시하면서 동시에 구조도 유지하도록 추가할 수 있다.
그림 2는 크리에이티브 커먼즈가 지원하는 모든 작품 프로퍼티가
반영되어 좀 더 복잡하게 작성된 예제와 이 HTML+RDFa가 어떻게 화면에 그려지는 지를 나타낸다.
어떻게 크리에이티브 커먼즈 프로퍼티가 앵커(anchor) 뿐만 아니라 span에도 적용되는지,
또는 모든 HTML 엘리먼트에 적용되는지를 주목해봐야 한다. 자세한 것은 RDFa 스펙에 나타나 있다.
이번 장의 예제들은 어떻게 웹 개발자가 작품 프로퍼티를 구체적으로 적용할 수 있는지를 설명한다.
물론 라이선스 프로퍼티도 RDFa로 나타낼 수 있다.
이것은 크리에이티브 커먼즈 라이선스 설명 페이지에 이미 적용해 두었고,
이에 대해서는 7.2 장에서 설명한다.
마이크로포맷은 "컴퓨터보다는 사람을 우선하여 설계한" 간단한 개방형 데이터 포맷으로
HTML에 부가정보를 추가할 수 있도록 하는 특정 도메인 구문(domain-specific syntax)을 제공한다.
널리 사용되는 "복합(compound)" 마이크로포맷으로는 개인정보(hCard)와 일정(hCal)이 있으며,
"기본(elemental)" 마이크로포맷은 하나의 데이터 포인트에만 부가 정보를 넣을 수 있는데,
대표적인 것이 rel-tag로써 블로그에 적은 태그를 나타낼 때 사용한다.
또 다른 기본 마이크로포맷인 rel-license은 현재 페이지의 라이선스를 나타낼 때 사용하며,
편의상 RDFa:rel="license"와 문법적으로 중복해서 사용한다.
향후에는 이미지나 비디오, 멀티미디어 콘텐츠에도 라이선스를 표시할 수 있는 마이크로포맷이 생겨서
크리에이티브 커먼즈 라이선스를 통합할 수도 있을 것이다. 주14
마이크로포맷 설계자들은 간결함(simplicity)과 가독성(readability)에 비중을 두었다.
크리에이티브 커먼즈는 웹 개발자가 마이크로포맷을 만들 때 툴 개발자들로 하여금 ccREL 트리플을
추출하기 쉽도록 해줄 것을 장려했다.
하지만 마이크로포맷 구문의 간결함은 독립성과 확장성을 일부 희생한 결과이기 때문에,
크리에이티브 커먼즈가 볼 때 마이크로포맷의 사용은 한계가 있다고 생각한다.
예를 들면, 사진 대신 비디오로 내용이 바뀌는 경우와 같이 새로운 상황에서
새로운 크리에이티브 커먼즈 라이선스가 필요할 때마다
신규 마이크로포맷과 문법을 만들어야 하고
이를 처리하는 파서(parser)도 이런 변화를 알아내야 한다.
또한 한 마이크로포맷과 다른 것
주15사이에 문법이 다르거나 충돌이 나는 경우가 있을 텐데,
이 경우 어떻게 이들을 한 페이지에서 결합할 수 있는지도 불명확하다.
결론적으로, 과학연구 데이터처럼 프로퍼티를 계속 확장해야 하는 복잡한 데이터 집합을 표현해야 할 때,
마이크로포맷에서는 이를 적절하게 확장할 수가 없게된다.
이는 마이크로포맷이 워낙 어휘가 적은데다, 독립적으로 개발된 소스들로부터 나온 어휘를 혼합할 수 있는 기술이 없기 때문이다.
--RDF에서는 네임스페이스(namespace)를 이용하여 어휘를 혼합하는 것이 가능하다.
따라서 크리에이티브 커먼즈는 특정 마이크로포맷을 ccREL용으로 추천하기보다는 이를 가능하게 하는 방법을 추천한다.
즉, 웹 개발자가 마이크로포맷을 사용할 때 HTML문서의 헤더부분에 적절한 프로파일 URL을 넣으면
툴 개발자가 ccREL 프로퍼티를 추출할 수 있게 된다. 주16
프로파일 URL을 이용하면 마이크로포맷의 독립성과 확장성을 향상시킬 수 있는데,
이는 툴이 마이크로포맷의 모든 내용을 미리 알지 않고도,
거기서 ccREL을 추출하는데 필요한 파서 코드를 찾아낼 수 있도록 하기 때문이다.
한 가지 단점은 마이크로포맷의 정보가 헤더의 프로파일(profile) 선언부와 바디(body)에 데이터 표현부라는
두 부분으로 나뉘어짐으로써 리믹스 편의성(remix-friendly)이 떨어진다는 것이다.
그렇지만 프로파일 방식은 간단한 데이터에 적용할 때는 충분히 유용한 방식이다.
한가지 주목할만한 것은 프로파일 URL 방식이 이미 마이크로포맷 베스트 프랙티스의 하나로 권고되고 있다는 것인데,
안타깝게도 현재 채택된 어플리케이션 중에 이를 구현한 것은 거의 없다.
웹에서 사용되는 문서가 모두 HTML인 것은 아니다.
오히려 구조화된 데이터를 표현하는 대표적인 문법 중 하나는 XML이다.
하지만 XML은 컴퓨터가 인식할 수 있도록 만든 구문으로써
보통 표현된 데이터 형에 따르는 엄격한 스키마를 동반한다는 것을 고려하면,
이 경우 앞에서 열거한 원칙들이 모두 유용하지는 않을 것이다.
특히, 시각적 일치성 측면은 문서를 읽는 주체(Reader)가 사람이 아니라 기계인 경우 해당사항이 없으며,
리믹스 편의성 부분도 스키마 검증 시 XML 일부라도 아예 리믹스가 불가능한 경우라면 해당되지 않는다.
그러므로 여기서는 앞서 언급한 원칙 중 독립성과 확장성 그리고 DRY에 중점을 두고자 한다.
XML문서 내에 크리에이티브 커먼즈 라이선스 정보를 넣을 때는 XML에서 ccREL 추상화모델을 추출할 수 있는 메커니즘을 알려줄 것을 권장한다.
그렇게 하면 크리에이티브 커먼즈 툴이 XML의 모든 스키마를 미리 알 필요가 없기 때문이다.
W3C의 GRDDL 표준을 이용하면 웹 개발자가 XML에서 RDF/XML를 추출하는 XSL변환을 직접 지정
(각각에 문서에 대해서 지정하거나 또는 XML스키마에 넣어서 한 번에 지정)하는 방식으로 일을 처리할 수 있다.
주17예를 들면, 뉴스피드용 스키마를 생성하는 Atom XML 확장을 살펴보자:
주18
<entry>
<title>Lessig 2.0 - the site</title>
<link rel="alternate" type="text/html"
href="http://lessig.org/blog/2007/06/lessig_20_the_site.html" />
<id>tag:lessig.org,2007:/blog//1.3401</id>
<published>2007-06-25T19:44:48Z</published>
<link rel="license" type="text/html"
href="http://creativecommons.org/licenses/by/3.0/us/" />
</entry>
알맞은 XSL변환을 사용하면 위 데이터에서 라이선스를 표현하는 ccREL 프로퍼티를 쉽게 추출할 수 있다:
<rdf:RDF about="http://lessig.org/blog/2007/06/lessig_20_the_site.html"
xmlns:cc="http://creativecommons.org/ns#">
<cc:license resource="http://creativecommons.org/licenses/by/3.0/us/" />
</rdf:RDF>
유사하게, Open Archives Initiative는 도서관 리소스용으로 매우 복잡한 XML 스키마를 정의하고 있다.
주19 이들 리소스는 수 메가바이트의 데이터를 포함하고 있고,
가끔은 텍스트 전체에 포함된 리소스들을 모두 가지고 있기도 하다.
하지만, XSLT를 사용하면 위 예제와 동일한 ccREL 정보를 추출할 수 있다.
GRDDL을 사용함으로써 Open Archives Initiative는 XML 스키마 파일에 XSLT를 지정할 수 있고,
그 결과 OAI의 모든 문서들이 자동적으로 RDF/XML로 변환될 수 있으며 또한 여기서 ccREL 정보도 얻을 수 있다.
흥미로운 점은 RDF를 RDF/XML로도 표현할 수 있다는 것인데,
스키마를 잘 만들면 RDF/XML을 바로 XML문서에 넣어서 사용할 수도 있겠다고 생각할 수 있다.
실제로 SVG에서 이런 방식을 사용하는데, RDF/XML을 직접 삽입하는 방식으로 SVG주20그래픽에 라이선스 정보를 넣는 경우도 있다.
이런 방식을 이용하면 아주 쉽게 ccREL과 호환되도록 할 수 있다.
즉, XML 스키마 정의에 선언된 GRDDL 변환을 이용하여 RDF/XML을 추출하여 자체적으로 표현할 수 있다.
ccREL과의 호환을 위한 이러한 변환이 단순해 보이지만 꼭 필요하다는 것을 명심하자.
이 필요성이 ccREL 원리의 핵심이 될 수 있는 이유는 만약 XML 스키마 작성자가 변환정보를 주지 않는다면
툴이 RDF/XML을 포함하고 있는 다양한 XML에서의 모든 스키마들을 전부 알고 있어야만 하기 때문이다.
ccREL에서는 확장성과 향후 보완을 위해서 웹 개발자가 스키마를 만들 때 추출 메커니즘도 제공하도록 요구한다.
이는 명시적으로 추출메커니즘을 제공하는 것은 웹 개발자에게는 약간의 추가작업이지만,
툴 개발자에게 있어서는 처음보는 데이터라 하더라도 이를
처리하는 프로그램을 즉시 만들 수 있도록 해 주기 때문이다.
6 비정형 파일에 ccREL 정보추가
MP3나 워드문서, 그 외 비정형 파일들은 보통 이메일이나 개인간 네트워크를 통해 전달되는데, 여기서는 이러한 파일들에 ccREL 메타데이터를 추가하는 크리에이티브 커먼즈 권고표준에 대해서 살펴보고자 한다. 이 경우 명확히 해결해야 할 문제가 두 가지 있다:
- 표현방법 (Expression): 특정 문법과 임베딩을 사용하여 추상화 모델을 표현하는 것.
- 신뢰성 (Accountability): 표현된 ccREL 데이터에 대한 최소한의 신뢰성을 제공하는 것.
비정형 콘텐츠의 신뢰성을 확보하는 방법으로는 비정형 문서를 ccREL 정보를 넣어둔
웹 페이지와 연결하는 방법을 사용한다. 이런 식으로 비정형 콘텐츠 제작자도
웹 콘텐츠를 만든 웹 개발자만큼의 신뢰성을 얻을 수 있다. 웹 페이지와 이진파일이 제대로
연결된 것을 보증하기 위해서는 핑거프린트처럼 파일의 암호화 해쉬를 이용한다.
예를 들면, 로렌스 레식의 'Code v2' 의 PDF 파일은 http://codev2.cc/download+remix 를
참조하고 있는데, 여기에는 PDF파일의 SHA1 해쉬값도 포함되어 있다.
그렇기 때문에 http://codev2.cc/download+remix URL
소유자는 그 파일을 설명하고 있는 ccREL 문안에 대한 책임을 져야한다.
표현방법에 있어서는 XMP를 추천한다. XMP는 다양한 종류의 미디어 포맷에 적용할 수 있는 삽입형 메타데이터 포맷을
대부분 지원한다. (아마도 대부분을 지원하는 유일한 포맷일 것이다).
MP3에서와 같이 이미 삽입형 메타데이터 포맷을 사용하는 경우를 예외로 한다면
크리에이티브 커먼즈는 특별히 다음 두 분야에서 삽입형 메타데이터 표준으로 XMP 사용을 권고한다:
- 웹 레퍼런스(Web reference): xapRights:WebStatement의 값
- 라이선스(License): cc:license의 값
레식의 "가상공간의 코드와 법률들 (Code and Other Laws of Cyberspace)"을 가지고 공동체가 편집한 두 번째
버전으로 크리에이티브 커먼즈 라이선스가 적용된 "Code v2"의 예제를 보면,
이 책의 PDF는 http://pdf.codev2.cc/Lessig-Codev2.pdf에서 구할 수 있는데,
다음과 같은 XMP 메타데이터가 포함되어 있다:
<?xpacket begin="" id=""?>
<x:xmpmeta xmlns:x="adobe:ns:meta/">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="" xmlns:xapRights="http://ns.adobe.com/xap/1.0/rights/">
<xapRights:Marked>True</xapRights:Marked>
<xapRights:WebStatement rdf:resource="http://codev2.cc/download+remix/" />
</rdf:Description>
...
<rdf:Description rdf:about="" xmlns:cc="http://creativecommons.org/ns#">
<cc:license rdf:resource="http://creativecommons.org/licenses/by-sa/2.5/" />
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end="r"?>
이것은 http://codev2.cc/download+remix/라는 웹 페이지를 가리키는
xapRights:WebStatement 가 포함된 RDF/XML 이며, 웹 페이지에는 다음과 같은 RDFa 정보가 있다:
Any derivative must be licensed under a
<a about="urn:sha1:W4XGZGCD4D6TVXJSCIG3BJFLJNWFATTE"
rel="license"
href="http://creativecommons.org/licenses/by-sa/2.5/">
Creative Commons Attribution-ShareAlike 2.5 License
</a>
이 RDFa는 SHA1 해쉬(해당 PDF 파일에만 일치되는 보안지문)를 사용하는 PDF를 참조하면서,
그것이 크리에이티브 커먼즈 라이선스라는 것을 선언한다.
그 결과 "Code v2" PDF를 찾는 누구라도 거기에서 WebStatement 포인터를 찾아서,
URL을 알아내고, SHA1 해쉬로 파일을 검증하면, 웹 증서에 표시된 크리에이티브 커먼즈 라이선스를 확인할 수 있다.
이번 장은 몇 가지 예제들을 설명하는데, 우선은 크리에이티브 커먼즈 라이선스를 적용한 작품을 올리는
웹 개발자를 위한 것이고,
다음은 라이선스 정보를 사용하고자 하는 툴 개발자를 위한 것이다.
예제 중 일부는 실제로 사용되는 ccREL 구현 내용이고 일부는 미구현이지만 그래도 도움이 될만한 것들과 어플리케이션 소개이다.
웹 개발자는 ccREL과 다른 마크업을 자유롭게 섞어 쓸 수 있다.
ccREL의 독립성과 확장성 원칙 덕분에 한 웹 개발자는 ccREL 서술내역을 활용하여
다른 웹 개발자에게서 가져온 추가 속성(attribute)과 결합시키거나
또는 스스로 만든 속성과 결합시켜 사용할 수 있다.
ccREL의 DRY 원칙 덕분에
소규모 웹 개발자도 한 곳의 데이터만 수정하면 편리하게 사람이 보는 부분과
컴퓨터가 인식하는 부분을 자동으로 일치시킬 수 있다.
그림 3: 비트뭉크 송 마크업: 이것은 bitmunk.com 웹사이트에서 사용된 실제 HTML마크업에서 가져온 것으로 가독성을 위해 일부분을 생략하고, 들여쓰기 하였다.
|
<div class="mediaDetails haudio"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:commerce="http://example.org/rdf/commerce/elements/1.0/"
xmlns:hmedia="http://www.microformats.org/2007/12/hmedia/"
about="#album-6579151">
...
<a id="mediaImageLink" rel="hmedia:depiction"
href="http://www.bitmunk.com/view/image/6579151">
...
<h1 property="dc:title" class="mediaTitle album fn">Lifeseeker</h1>
...
<span property="dc:creator" class="fn">Lifeseeker</span>
...
<span property="dc:contributor" class="fn">(P) 2005 One In A Million Records</span>
...
<span property="dc:date" class="published" title="2007-11-18T11:23:07-05:00"
content="2007-11-18T11:23:07-05:00" datatype="xsd:date">
2002-07-23
</span>
...
<a href="/browse/genre/audio_album/59"
property="dc:type" class="category">Hip Hop and Rap</a>
<span class="detailLabel">Tracks:</span>
16 (<abbr property="hmedia:duration" class="duration"
title="PT1H13M37S" content="PT1H13M37S"
datatype="xsd:duration">1:13:37</span>)
...
<span class="detailLabel">Licenses:</span>
<img property="dc:license" class="licenseIcon"
src="http://www.w3.org/Submission/ccREL/themes/bm2/images/licenses/sc-sm.png"
alt="Standard Copyright" title="Standard Copyright"
content="Standard Copyright"/>
...
</div>
|
매쉬업이 자유로운 웹 환경에서 작업하는 웹 개발자가 종종 부딪히는 경우 중 하나는
다양한 라이선스가 적용된 콘텐츠를 혼합하여 사용하는 경우이다.
예를 들면, 레식 블로그에 비영리 사용조건이 붙은 다른 저자의 그림을 사용하고 있다고 하자.
레식 블로그는 영리적 이용도 가능한 라이선스라는 것을 고려한다고 할 때,
다음과 같이 간단하게 HTML 마크업을 작성할 수 있다:
<div about="" xmlns:cc="http://creativecommons.org/ns#">
This page, by
<a property="cc:attributionName" rel="cc:attributionURL"
href="http://lessig.org/">
Lawrence Lessig
</a>,
is licensed under a
<a rel="license"
href="http://creativecommons.org/licenses/by/3.0/">
Creative Commons Attribution License
</a>.
<div about="/photos/constitution.jpg">
The photo of the constitution used in this post was originally published by
<a rel="dc:source" href="http://example.org/">Joe Example</a>, and is licensed
under a
<a rel="license" href="http://creativecommons.org/licenses/by-nc/3.0/">
Creative Commons Attribution-NonCommercial License
</a>.
</div>
</div>
안쪽의 <div>의 about은 해당 사진을 가리킨다.
원래의 출처로 연결되는 링크는 dc:source 프로퍼티로 알려주고,
해당 사진에 대한 라이선스는 rel="license" 속성이 있는 앵커(anchor)로 알려준다.
비트뭉크는 저작권을 제대로 적용한 합법적인 콘텐츠 배포서비스로 예술가를 지원하는 서비스이다.
이 서비스에서는 노래와 앨범에 대한 구조적 데이터를 웹 페이지에 직접 삽입할 수 있는 기술이 필요했다.
그렇게 하면, 브라우저 애드온 같은 것들을 이용해서 여러 사이트에서 팔리는 노래의
가격비교를 하는 것 같은 부가적인 기능들을 이용할 수 있게 된다.
비트뭉크는 처음에 hAudio라는 마이크로포맷을 만들었다. 하지만 hVideo를 만들면서 필드를 중복 사용하려고 했는데,
이렇게 중복된 필드는 hAudio의 필드들과 호환이 안 된다는 것을 얼마 지나지 않아 깨달았다.
좀 더 시급한 문제는 hAudio의 기본필드(예, 제목) 조차도
다른 마이크로포맷의 "제목" 필드와 호환되지 않을 수 있다는 것이었다.
그래서, 비트뭉크는 hAudio RDFa 어휘를 만들었다.
어휘의 설계과정을 살펴보면 다음과 같이 논리적으로 분리되어 있음을 알 수 있는데, 예를 들면
제목(title)과 같은 기본 프로퍼티에는 더블린 코어, 라이선스 적용에는 크리에이티브 커먼즈,
재생시간(duration) 같은 미디어-전용 프로퍼티에는 새로 만든 "hMedia",
상품가격(price)처럼 상거래-전용 프로퍼티에는 새로 만든 "hCommerce"를 사용한다.
이처럼 비트뭉크는 이미 존재하는 두 개의 어휘를 재활용하고 일부는 새로 추가하였다.
또한 논리적 구성요소를 명확히 함으로써 다른 어휘 개발자들이 hCommerce같은 hAudio의
어휘 중 일부 구성요소를 쉽게 재활용할 수 있도록 만들어 주었다.
또한 크리에이티브 커먼즈 라이선스 정보도 변경 없이 모두 표현할 수 있게 되었다.
그림 3은 비트뭉크의 http://bitmunk.com/view/media/6579151에 있는 마크업(markup)의 일부분이다.
여기서 주목해야 할 점은 이 특정 샘플이 CC라이선스를 선택하지 않고 기존의 저작권을 채택한 샘플이라는 것이다.
CC라이선스를 단 음반도 이와 동일한 방식으로 다른 라이선스(license) 값을 가지고 마크업 될 수도 있다:
왜냐하면, 비트뭉크는 ccREL과는 별개로 자사의 어휘 개발을 했었지만,
이제라도 ccREL과 기존의 어휘를 합치고자 하면 단지 알맞은 속성만 추가하면 되기 때문이다.
그림 4: RDFa 정보가 있는 플리커 사진 페이지 :
어떻게 RDFa를 넣을 수 있는지 알려주고자 플리커 사진 페이지의 일부를 발췌한 것이다.
RDFa 프로퍼티가 추가되더라도 출력내용은 동일하다.
upcoming.org에 등록한 이벤트를 참조하고 있는 플리커 머신 태그 upcoming:event를 보자.
사실 이 머신 태그는 RDF 트리플인데 RDFa로 간단히 표현하여 기존 CC 라이선스 및 플리커 정보와 함께 보여줄 수 있다.
|
<div xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:flickr="http://flickr.com/ns#"
about="http://www.flickr.com/photos/laughingsquid/2034629532/">
...
<h1 property="dc:title">NewTeeVee Live Game Show</h1>
...
<img rel="flickr:defaultPhoto"
src="http://farm3.static.flickr.com/2320/2034629532_02085434dd.jpg?v=0" />
...
<div property="dc:description">
See the blog post for more info:
<a href="http://laughingsquid.com/a-few-random-newteevee-live-photos/">
A Few Random NewTeeVee Live Photos
</a>
</div>
...
This photo is licensed under a
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/2.0/">
Creative Commons license
</a>.
If you use this photo within the terms of the license or make
special arrangements to use the photo, please list the photo credit as
<span property="cc:attributionName">Scott Beale / Laughing Squid</span>
and link the credit to
<a rel="cc:attributionURL" href="http://laughingsquid.com">
laughingsquid.com
</a>.
...
Uploaded on
<span property="flickr:uploaded" content="2007-11-15">
November 15, 2007
</span>
...
<h4>Tags</h4>
<a rel="flickr:tag" href="/photos/laughingsquid/tags/newteevee/">NewTeeVee</a>
<a rel="flickr:tag" href="/photos/laughingsquid/tags/gigaom/">GigaOm</a>
...
<a rel="upcoming:event"
href="http://upcoming.org/event/286436">upcoming:event=286436</a>
...
</div>
|
플리커는 2007년 10월을 기준으로 CC-라이선스가 적용된 약 5천만 장의 이미지를 보유하고 있다.
현재 플리커는 각 이미지 페이지 라이선스를 rel="license"로 지정한 라이선스와 링크시켜서 표시하고 있다.
이런 방법은 마이크로포맷 쪽에서 요청한 임시방편이었는데 license가 이미 HTML 예약어라서 RDFa에서는 제외되어 버렸다.
그래서 안타깝게도 이 방법은 한 페이지에 한 개 이미지에만 적용된다.
이러한 접근방법은 한 페이지에 여러 개의 이미지가 있을 때나 사진작가의 이름과 같은 추가정보가 요구될 때는 사용할 수가 없게 된다.
만약 플리커가 ccREL의 권고표준을 사용한다면 지금처럼 단순한 라이선스 링크를 제공하는 것 외에도
다음과 같은 유익이 있을 것이다:
- 라이선스를 적용한 이미지를 종류별로 분류
- 저작자표시 상세
- 상업적 라이선스 중개인이 참고할 수 있는 cc:additionalPermissions (추가 이용 권한)과
원작을 알려주는 dc:source
- 이미지 자체에 대한 XMP 임베딩
게다가 플리커는 최근 사진작가들이 커스텀 프로퍼티(custom property)를 이용해서 본인 작품에
메타데이터를 추가할 수 있는 "머신 태그"를 채택했다.
사실 플리커의 머신 태그는 RDF의 한 부분으로 RDFa로 쉽게 표현될 수 있다.
그러므로 크리에이티브 커먼즈 라이선스는 플리커의 머신 태그와 충돌 없이 나란히 표기될 수도 있다.
그림 4는 http://www.flickr.com/photos/laughingsquid/2034629532/에 있는
CC라이선스가 붙은 사진에 ccREL을 적용한 마크업을 보여준다.
http://upcoming.org의 이벤트와 관계된 사진과 upcoming:event라는
머신 태그도 동시에 사용된다.
그림 5: RDFa가 기존 마크업에 자연스럽게 통합되는 것을 보여주고 있는
네이처 프리시딩 기사의 마크업 일부.
네이처가 정의한 태그를 사용한 콘텐츠라는 것을 알려주기 위해 nature:tag라는
프로퍼티를 사용했지만 어떤 어휘라도 이 자리에 대신 사용할 수 있다.
|
<div xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#"
xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"
xmlns:foaf="http://xmlns.com/foaf/0.1/" about="/documents/1290/version/1">
<h2 property="dc:title">An Olfactory Receptor Pseudogene whose Function emerged in
Humans</h2>
...
<span rel="dc:creator"><span property="foaf:name">Peter Lai</span></span>
<sup>1</sup>,
<a rel="dc:creator"
href="http://precedings.nature.com/users/bdaff59be022e709d8b7beab298ccfb8">
<span property="foaf:name">Gautam Bahl</span>
</a><sup>2</sup>,
...
<dt class="doctype">Document Type:</dt><dd
property="dc:type">Manuscript</dd>
Received <span property="dc:date">02 November 2007 21:20 UTC</span>;
Posted <span property="prism:publicationDate">05 November 2007</span>
...
<a rel="prism:category" href="http://precedings.nature.com/subjects/biotechnology">
Biotechnology
</a>,
...
<ul id="revision-1321-tags" class="taglist">
<li> <a rel="nature:tag"
href="http://precedings.nature.com/tags/olfactory+receptors">
olfactory receptors
</a>
</li>
...
</ul>
...
This document is licensed to the public under the
<a rel="license" href="http://creativecommons.org/licenses/by/2.5/">
Creative Commons Attribution 2.5 License
</a>
...
<!-- Citation -->
<dt class="abstract">How to cite this document:</dt>
<dd>
<p> <span property="cc:attributionName">
Lai, Peter, Bahl, Gautam, Gremigni, Maryse, Matarazzo, Valery ,
Clot-Faybesse, Olivier, Ronin, Catherine, and Crasto, Chiquito.
An Olfactory Receptor Pseudogene whose Function emerged in Humans.
</span>
Available from Nature Precedings <
<a rel="cc:attributionURL" href="http://dx.doi.org/10.1038/npre.2007.1290.1">
http://dx.doi.org/10.1038/npre.2007.1290.1
</a>> (2007)
</p>
</dd>
...
</div>
|
그림 6: RDFa로 마크업 페이지를 구성한 네이처 프리시딩 논문의 일부.
RDFa를 인식할 수 있는 브라우저(이 경우에는 일반 브라우저에 RDFa용 북마클릿을 사용)가
마크업을 발견하면 제목과 크리에이티브 커먼즈 라이선스 부분을 강조해서 보여주고
추가로 RDF 트리플도 알려준다.
|
|
세계 최고의 과학저널 중 하나인 네이처가 웹 서비스 "프리시딩"을 시작했다.
이 사이트를 통해 학자들은 본격적인 피어 리뷰(peer-review)에 앞서 미리 초기 연구 결과를 발표할 수 있다.
네이처 프리시딩에 게재되는 논문은 크리에이티브 커먼즈 라이선스로 배포된다.
플리커처럼 네이처 프리시딩도 CC의 이전 권고표준인 HTML 주석에 RDF/XML을 넣는 방식을 사용하고 있다.
만약 네이처가 ccREL을 채택하면 상당한 도움이 될 것이다.
ccREL은 좀 더 견고하고 확장 가능하고 가독성도 높이면서
크리에이티브 커먼즈 라이선스의 구조적 데이터를 배포할 수 있도록 하기 때문이다.
예를 들면, http://precedings.nature.com/documents/1290/version/1에 있는 네이처 프리시딩 문서를 살펴 보자.
그림 5는 더블린 코어, 크리에이티브 커먼즈, FOAF, 그리고 PRISM 출판용 어휘
주21를 이용해 RDFa 속성을 확장한 마크업을 보여준다.
주목해야 할 점은 제목을 위해 사용한 H1을 포함하여 모든 HTML 요소에 RDFa 속성을 적용할 수 있다는 것이다.
그림 6은 이 페이지가 RDFa를 인식할 수 있는 브라우저에서 어떻게 나타나는지를 보여준다.
인터넷으로 과학연구 자료를 공개 출판하는 것은 네이처 출판그룹이 최근 게놈연구자료(Genomic data set)를
크리에이티브 커먼즈 라이선스주22로 출간하기로 발표하면서부터
비로소 시작되었다.
이는 단순히 공개 라이선스를 사용한다는 의미를 넘어서 이러한 연구결과를 표시하기 위해 수천 개의 메타데이터 어휘와
프로퍼티가 새롭게 개발된다는 것을 의미한다. 이에 발맞춰 크리에이티브 커먼즈는 사이언스 커먼즈(Science Commons)
주23를 통해 적극 활동하고 있으며
과학연구의 협업과 공유를 가로막는 장벽을 제거하고자 노력 중이다.
사이언스 커먼즈는 특히 과학정보를 기술하는 RDF기반의 어휘 제작을 독려하고 있고,
RDF의 확장성과 상호호환성을 활용하는 툴을 제작하여 연구팀들간의 협업을 촉진하고 있다.
그림 7: 과학연구 데이터를 추가한 문헌목록 결과
 |
이 같은 어휘들이 널리 사용되면 새로운 과학연구용 태그를 표현할 수 있도록 문헌과 라이선스의 마크업을 확장하는데
ccREL과 RDFa를 활용하기가 쉬워진다.
또한, 추가적인 마크업을 활용하는 툴이 등장하여 과학적 개념을 상호참조할 수 있도록 하며, 이를 통해
여러 곳에서 역동적인 연구협력을 가능하게 할 것이다.
예를 들면, 바이오메드 센트럴 신경과학지(학술지)을 인용한 게놈연구에 대한 (가상의)웹 뉴스레터의
일부분을 발췌한다고 하면, 브라우저에서는 다음과 같이 나타날 것이다 (그림 7).
"쥐의 뇌에 대한 최근 연구"나 "CEBP-베타"라는 단어는 링크로 표시될 것이고, 이는 논문의 웹 페이지로 연결되며,
웹 페이지에는 유니프로 단백질 데이터베이스에 있는 CEBP-5#5 단백질에 대한 설명이 있는 식이다.
다음은 이 발췌 부분을 만들어 내는 RDFa의 한 가지 예이다.
<div
xmlns:OBO_REL="http://www.obofoundry.org/ro/ro.owl#"
A <a href="http://www.biomedcentral.com/1471-2202/6/69">
recent study on rat brains
</a>
by von Gertten <em>et. al.</em> reports that
<div about="http://purl.org/obo/owl/GO#GO_0050729">
<span property="rdfs:label">inflammatory stimuli</span>
upregulate expression of
<a rel="OBO_REL:precedes"
href="http://purl.uniprot.org/uniprot/P17676">
<span property="rdfs:label">CEPB-beta</span>
</a>
</div>
</div>
이 RDFa는 논문에 대한 링크를 보여줄 뿐만 아니라,
(Open Biomedical Ontology Initiative에서 정의한) 염증유발자극이
(유니프로 단백질 데이터베이스에서 자세하게 알 수 있는) CEPB 단백질의 발현을 촉진한다는 내용을
컴퓨터도 알 수 있도록 하는 정보를 제공한다.
이처럼 단백질에 대한 인터넷 주소(URI)가 화면에 보이기 때문에
트리플의 값도 확인하고, 동시에 클릭도 할 수 있게 된다.
CC 라이선스의 이용 허락은 일반대중에 주어지는데 반해, 다른 라이선스는 개인에게 주어진다.
"추가 이용 허락"이라는 링크는 이러한 이용가능성(availability)을 표시한다.
크리에이티브 커먼즈는 이것을 CC+ 라고 부른다.
또한 CC 라이선스는 배타적이지 않기 때문에 작품에 적용한 라이선스에 선택사항을 추가할 수 있다.
여기 http://magnatune.com의 예는
CC라이선스를 적용한 이미지와 마그나튠 로고에 RDFa를 어떻게 적용했는지를 보여준다:
<a href="http://creativecommons.org/licenses/by-nc-sa/1.0/" rel="license">
<img src="http://he3.magnatune.com/img/somerights2.gif">
</a>
<a href="https://magnatune.com/artists/license/?artist=Anup&album=Embrace&genre=World"
xmlns:cc="http://creativecommons.org/ns#" rel="cc:morePermissions">
<img border=0 src="http://he3.magnatune.com/img/button_license2.gif" />
</a>
위 마크업에는 두 가지 내용이 있는데, CC 라이선스로 공개된 이미지와 추가 이용 허락이 설정된 이미지이다.
이런 표현방식(코딩)에 익숙한 사용자들은 앞으로 특정 URL에서만 적용되는 추가 이용 허락을 회사별로, 미디어 별로 혹은 특정 장르별로 발행할 수 있다.
크리에이티브 커먼즈 라이선스를 인식하도록 설계된 툴이라면은 morePermissions 프로퍼티가 추가되었더라도
CC 라이선스를 찾아낼 수 있을 것이다.
좀 더 발전된 툴은 '추가 이용 허락'에 연결된 링크에서 추가정보를 얻을 수 있다는 사실도 알려줄 것이다.
그림 8: CC-저작자표시-변경금지(보여줄 목적으로 약간 단순화된)용 HTML 코드부분으로 ccREL 라이선스 프로퍼티 사용법을 보여주고 있다.
|
<h3>You are free:</h3>
<ul>
<li class="license share">
<strong>to Share</strong> --
to
<span rel="cc:permits"
href="http://creativecommons.org/ns#Distribution">copy</span>,
<span rel="cc:permits"
href="http://creativecommons.org/ns#Reproduction">distribute</span>,
display, and
perform the work
</li>
<div id="deed-conditions">
<h3>Under the following conditions:</h3>
<ul align="left" dir="">
<li rel="cc:requires"
href="http://creativecommons.org/ns#Attribution" class="license by">
<p><strong>Attribution</strong>.
<span id="attribution-container">
You must attribute the work in the manner specified by
the author or licensor (but not in any way that
suggests that they endorse you or your use of the work).
</span>
</li>
<li class="license nd">
<p><strong>No Derivative Works</strong>.
<span>You may not alter, transform, or build upon this work.
</span>
</li>
<li rel="cc:requires"
href="http://creativecommons.org/ns#Notice">
For any reuse or distribution, you must make clear to
others the license terms of this work. The best way to
do this is with a link to this web page.
</li>
</ul>
</div>
</ul>
|
7.2 라이선스 프로퍼티 발행하기
앞서 언급했듯이 크리에이티브 커먼즈는 콘텐츠 제작자가 라이선스 프로퍼티를 다룰 일은 없다고 생각하지만
그럼에도 ccREL 라이선스 프로퍼티를 이용해서 라이선스를 발행하고자 하는 사람이 있을 것이다.
이런 경우에도 역시 사람이 이해할 수 있는 라이선스를 만드는 프레임워크로 RDFa를 사용할 수 있고,
자동화된 툴을 사용하면 거기에서 필요한 프로퍼티도 추출할 수 있다.
이것을 보여주는 한 예가 바로 크리에이티브 커먼즈와 "커먼즈 증서(Commons Deeds)" 페이지이다.
그림 8은 미국 판 CC 저작자표시-변경금지 라이선스를 설명하는 http://creativecommons.org/licenses/by-nd/3.0/us/의 웹 페이지 HTML소스를 보여주고 있다.
이 소스가 보여주는 것처럼 LI뿐 아니라 모든 HTML 속성에 RDFa 속성을 사용할 수 있다.
클릭할 수 있는 링크를 만드는 데 사용하는 href 속성은 링크 사이의 구조적인 관계를 알려주는 목적으로도
사용할 수 있으며, href에 붙은 요소가 HTML 앵커(anchor)가 아닐 때에도 가능 한다.
이 마크업에서 "저작자표시-변경금지" 라이선스는 배포와 재생산은 허락하지만, 저작자 표시를 요구한다.
ccREL은 현재 저작권법에 더해서 추가적인 허용을 하는 것임을 상기해 보자.
그렇다면 "변경금지"라는 제한은 이미 저작권법에 기본적으로 명시되기 때문에 ccREL에서는 표시하지 않음을 알 수 있다.
반대로 변경을 허락하여 2차 저작물을 만들 수 있는 경우에는 추가적인 CC 이용 허락을 통해 명시한다.
이 페이지에서 RDF를 추출하고 싶은 툴 개발자는 W3C의 RDFa 디스틸러
주24같은 것을 이용하여 작업할 수 있다.
만약 http://creativecommons.org/licenses/by-nd/3.0/라는 CC 증서 URL이 있다면,
디스틸러는 이것을 동일한 구조적 데이터를 갖도록 RDF/XML 직렬화하여,
RDF/XML을 지원하는 다른 프로그래밍 언어에서 사용할 수 있도록 만들어준다:
<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://creativecommons.org/licenses/by-nd/3.0/">
<cc:requires rdf:resource="http://creativecommons.org/ns#Notice"/>
<cc:requires rdf:resource="http://creativecommons.org/ns#Attribution"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#Distribution"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#Reproduction"/>
</rdf:Description>
</rdf:RDF>
MozCC주25는 모질라(Mozilla)기반 브라우저에 설치하는 확장 툴로써
웹 페이지에 들어있는 메타데이터를 추출하거나 보여주는 기능을 한다.
이것은 이전에 사용하던 크리에이티브 커먼즈 메타데이터 권고표준의 미비점을 일부 보완하고자 2004년에 개발한 것이다.
그 당시의 MozCC 버전은 대부분의 다른 브라우저 파서들은 무시하던 HTML주석에 있는 크리에이티브 커먼즈 RDF를 찾아내는 역할을 하였다.
만약 메타데이터가 발견되면, 상태표시줄에 아이콘을 사용하여 크리에이티브 커먼즈 라이선스가 사용되었다고 알려준다.
게다가 MozCC는 작품 프로퍼티와 라이선스 프로퍼티를 보여주는 기능도 있다.
MozCC를 처음 개발할 때는 ccREL에 특화된 인터페이스를 제공하였으나
이후 모든 RDFa 메타데이터를 추출할 수 있는 범용적인 도구로 재작성되었다.
상태표시줄 아이콘과 메타데이터 상세정보표시 기능은 유지하면서 기능을 더했다.
MozCC가 RDFa 메타데이터가 있는 페이지를 만나면 화면에 바로 표시를 해주며,
그것이 크리에이티브 커먼즈 라이선스 메타데이터라면 해당하는 아이콘도 보여준다.
그림 9는 이런 동작을 보여준다.
그림 9: MozCC 모질라 애드온.
상태표시줄에 이 페이지에는 CC-라이선스가 있다고 알려주는 아이콘을 보여준다.
아이콘을 클릭하면 상세 메타데이터를 보여주는 창이 뜬다.
|
|
MozCC는 페이지가 로딩되면 작업을 시작하고 콘텐츠에 한 개나 그 이상의 메타데이터 추출자(extractor)를 호출한다.
메타데이터 추출자는 브라우저를 시작할 때 미리 등록해 둔 자바스크립트 클래스인데,
이것은 MozCC가 제공하거나, 다른 확장 툴이 제공할 수도 있다.
MozCC는 크리에이티브 커먼즈 메타데이터 기존 권고표준과 현재 권고표준인 ccREL을 모두 처리할 수 있는 추출자가 포함되어 제공된다.
등록된 추출자는 매번 페이지가 로딩될 때마다 호출된다.
이때 페이지 URL과 페이지가 마지막 작업 이후 변경되었는지 여부에 대한 정보가 전달되는데,
이를 통해 각 추출자는 페이지 재처리 여부를 결정하게 된다.
예를 들면, 콘텐츠가 변경되지 않았다면 RDFa 추출자는 작업을 시작하지 않는다.
반면 <link>태그를 사용한 외부파일에 메타데이터가 있다면
추출자는 일단 파일을 가져온 후 페이지 변경여부를 판단하게 된다.
각 추출된 결과는 로컬 메타데이터 저장소에 기록된다.
파이어폭스의 경우 사용자 프로파일의 일부로써 SQLite에 저장된다.
로컬 메타데이터 저장소는 추출자와 유저 인터페이스 코드 사이의 추상 레이어 역할을 한다.
내용은 페이지 정보를 통해 확인할 수 있다.
현재 소프트웨어는 정보를 상태표시줄 아이콘으로만 보여주고 있지만,
이후에는 MozCC나 다른 확장 툴을 통해 다른 방법으로 메타데이터를 확인할 수도 있을 것이다.
오퍼레이터
주26는 파이어폭스 브라우저 애드온으로써
사용자가 방문하는 웹 페이지에서 마이크로포맷과 RDFa를 찾아낸다.
또한 "액션스크립트"를 이용하여 웹 페이지에 특정 데이터가 발견될 경우 실행되도록 확장할 수 있다.
페이지에서 데이터가 있는 부분이 강조되어 표시되므로 사용자는 데이터에 대한 문맥정보를 시각적으로 확인할 수 있다.
웹 페이지에서 RDFa를 찾아내어 크리에이티브 커먼즈 라이선스가 적용된 콘텐츠임을 알아내는 액션스크립트는 비교적 쉽게 작성할 수 있다.
이것을 이용하여 웹에서 찾은 콘텐츠를 재사용할 때 필요한 권리와 책임범위를 명확히 파악할 수 있다.
지금은 알 수 없는 프로퍼티를 가진 항목을 포함해 어떤 항목이든 간단한 액션스크립트를 이용해 찾아내고,
그 항목의 이름과 권리정보를 보여줄 수 있기 때문이다.
일부 유틸리티 함수 정의 부분을 제외하면
라이선스 프로퍼티 액션 핸들러(an action handler for the license property)는 다음과 같이 선언된다:
주27
RDFa.DEFAULT_NS.cc = "http://creativecommons.org/ns#";
RDFa.ns.cc = function(name) { return RDFa.DEFAULT_NS.cc + name; };
var view_license = {
description: "View License",
shortDescription: "View",
scope: {
semantic: {
"RDF": {
property : RDFa.ns.cc("license"),
defaultNS : RDFa.ns.cc("")
}
}
},
doAction: function(semanticObject, semanticObjectType, propertyIndex) {
if (semanticObjectType == "RDF") {
return semanticObject.license;
}
}
};
SemanticActions.add("view_license", view_license);
일단 이 액션 스크립트가 동작되면,
웹 페이지에서 찾은 크리에이티브 커먼즈 라이선스가 붙은 "리소스"들이 오퍼레이터에 자동으로 표시된다.
예를 들면, 레식 블로그를 방문하면 CC 라이선스가 붙은 두 개의 리소스가 강조되어 오퍼레이터에 표시된다:
하나는 레식 블로그 자체에 대한 것이고, 다른 하나는 블로그 글 중에 포함된 CC 라이선스가 붙은 사진이다.
그림 10에서 결과를 볼 수 있다.
그림 10: CC 액션스크립트를 등록한 오퍼레이터로 방문한 레식 블로그. 각각 "라이선스 보기'라는 메뉴를 가진 두 개의 리소스가 있다.
|
|
크리에이티브 커먼즈는 예술가와 과학자가 다른 사람들의 창작물을 활용한 새로운 창작활동을 쉽게 할 수 있는 환경을 만들고자 한다. 그러기 위해서는 누구든지 자기 창작물을 재사용할 수 있도록 하는 라이선스를 붙이는 과정과 이러한 라이선스가 된 창작물을 찾는 과정이 쉬워야 한다. 본 연구는 이를 기술적인 측면에서 달성하고자, W3C의 RDF를 바탕으로 저작권리표현 추상화 모델로 ccREL을 정의하였으며, 또한 웹 기반 콘텐츠에는 RDFa 사용을, 비정형 콘텐츠에는 XMP 사용을 각각 권고했다. 크리에이티브 커먼즈가 지향하는 기술적 접근의 목표는 저작권리표현 데이터를 발행하고 추출하는 것을 쉽게 하도록 하는 것으로,
이는 현재뿐만 아니라 라이선스를 적용한 아이템과 데이터의 종류가 현재의 상상범위를 훨씬 벗어나는 미래에도 적용된다. 크리에이티브 커먼즈의 ccREL은 RDF를 이용하게 됨으로써 급성장하는 RDF 인프라와 상호운용이 가능하게 되었고, 많은 개발 툴을 활용할 수 있게 되었다. 즉, 다른 데이터세트도 ccREL과 통합될 수 있으며, "전자 서명된 데이터 출처파악기술" 같은 RDF 기술도 결국 ccREL에 유익이 될 것이다.
우리는 ccREL을 위해 선택한 기술이 인터넷의 특징인 강력하면서도 분산된 기술적 혁신을 가능하게 할 것이라 생각한다. 어떤 중앙기관의 승인 없이도 누구나 자체적인 목적으로 새로운 어휘를 만들 수 있고, 그것을 ccREL과 자유롭게 결합할 수 있다. CC라이선스의 법적 텍스트를 배포 및 확장하는 과정에서 그랬던 것처럼, 크리에이티브 커먼즈는 ccREL을 통해서도 협업과 창작이 원활 하도록 돕는 최소한의 기술적 인프라를 구축하는 것을 목표로 삼고 있다. 그러는 과정에서 이러한 인프라가 유기적이고 분산된 과정을 통해 활성화되기를 기원한다. ccREL이 생동감 넘치는 어플리케이션 생태계를 조성할 수 있는 기본단계의 기술을 제공할 것이라 믿으며, 모든 사람이 ccREL을 바탕으로 혁신적인 아이디어를 자유롭게 나눌 수 있기를 기대한다.
본 논문의 공동저자들은 전 크리에이티브 커먼즈 이사인 Neeru Paharia씨에게 "비정형" 콘텐츠의 신뢰성구조 부분에 대해 감사 드리고, 비트뭉크 대표인 Manu Sporny씨에게는 크리에이티브 커먼즈 오퍼레이터 코드에 대해, Aaron Swartz에게는 최초의 크리에이티브 커먼즈 RDF 데이터 모델과 메타데이터 전략 부분에 대해 감사 드리고 싶다. 좀 더 넓게는, W3C 워킹그룹에 속한 분들, 특히 RDF-in-HTML 태스크포스(Mark Birbeck, Jeremy Carroll, Michael Hausenblas, Shane McCarron, Steven Pemberton 그리고 Ellas Torres)의 모든 분들과, Guss Schreiber와 David Wood가 이끄는 Semantic Web Deployment 워킹그룹과, 쉼 없이 노력해준(이들이 없었다면 RDFa, GRDDL, RDF가 없었을 테고 그렇기에 ccREL에 불가능했을 것이기에) W3C 스태프인 Eric Miller, Ralph Swick, Ivan Herman, and Dan Connolly의 노고에 감사 드리고 싶다.
- 1
- 크리에이티브 커먼즈와 관련된 정보는 http://creativecommons.org에 있다. ccREL은 크리에이티브 커먼즈의 등록상표이다.자세한 내용은 http://creativecommons.org/policies에 있다.
- 2
- RDF는 웹에 있는 리소스 정보를 알려주는데 사용하는 언어이다. 이 문서에서도 기초적인 내용을 약간 다룬다. 또한 다음 W3C의 RDF 사이트에도 있다. http://www.w3.org/RDF/
- 3
- 여기서 "웹 개발자 publisher"란 CCL이 붙은 자료를 웹에 올리는 사람을 의미한다.
"툴 개발자 tool builders"란 라이선스 정보를 탐색 툴을 제작하는 개발자를 의미한다.
예를 들면, 라이선스 타입에 따라 결과를 분류하는 검색 프로그램이나 나름에 방식으로 라이선스 정보를 보여주는 유저인터페이스 프로그램일 수도 있다.
- 4
- RDFa는 RDF를 지원할 수 있도록 XHTML을 확장하는 프로세싱 룰과 속성집합이다. http://www.w3.org/TR/rdfa-syntax의 "RDFa in XHTML: Syntax and Processing"를 참조할 것. http://www.w3.org/TR/xhtml-rdfa-primer의 "RDFa Primer"를 참조할 것. RDF/XML은 XML문법으로 RDF를 표현하는 방법이다. http://www.w3.org/TR/rdf-syntax-grammar/의 "RDF/XML Syntax Specification (Revised)"를 참조할 것. XML(확장메타데이터플랫폼)은 어도비가 개발하였고 제한된 RDF/XML을 문서에 포함시켜 레이블을 하는 기술이다. http://www.adobe.com/products/xmp/를 참조할 것.
- 5
- 시맨틱 웹 액티비티는 W3C가 주도하는 대규모 공동연구로써,
웹이 인간과 프로그램 모두가 사용할 수 있는 보편적인 자료교환 매체가 되도록 확장하는 것을 목표로 하고 있다.
자세한 것은 http://www.w3.org/2001/sw/를 참조할 것.
- 6
- URI는 URL을 일반화한 용어이다. URL이 기본적으로 웹 상에 리소스를 참조하는 것이라면, URI는 이 계층적인 명명체계 안에 있다면 무엇이든지 참조할 수 있도록 고안된 것이다. ccREL에서는 다운로드 받은 미디어 파일 같은 아이템에 이런 특징(보편성)을 사용한다.
- 7
- 어휘 페이지인 http://www.w3.org/1999/xhtml/vocab#는 빈 페이지로 2008년 상반기에 W3C에서 갱신할 예정임.(역자주: 갱신되어 내용이 제공되고 있음. 2009년 8월 현재)
- 8
- 전체 이야기는 좀 더 복잡하다.
CC는 처음에 http://web.resource.org/cc/ 네임스페이스를 사용했으나,
사람이 어휘를 인식하는데 있어서 RDFa가 더 낫다는 사실이 명백해진 이후에는
http://creativecommons.org/ns# 로 네임스페이스를 변경하였다.
2005년 더블린 코어 메타데이터 이니셔티브는 "right"(http://dublincore.org/usage/decisions/2004/2004-01.Rights-terms.shtml 를 참조)
용어를 개선한 "license"를 승인했다.
만약 2002년에 http://purl.org/dc/terms/license 가 정의되었다면, CC는 굳이 http://web.resource.org/cc/license 를 정의하지는 않았을 것이다.
RDF 프로퍼티 확장성 덕분에, http://creativecommons.org/ns#license 에서는 이들 다른 프로퍼티와의 관계를 설명하고 있다.
- 9
- N3 (Notation 3)는 RDF/XML을 표시하는 간결하고 가독성있는 대체표현으로 개발되었다.
http://www.w3.org/DesignIssues/Notation3.html를 참조할 것.
- 10
- 더블린 코어 메타데이터 이니셔티브(DCMI)는 공동 이용할 수 있는 메타데이터 표준을 활성화하고, DCMI 메타데이터 어휘를 관리한다.
http://dublincore.org/를 참조할 것.
- 11
- 현재 모든 CC 라이선스에는 저작자표시가 필요하며, 웹 개발자가 선택적으로 저작자표시를 나타내는 URL을 지정할 수 있도록 한다.
기계적 인식이 가능한 형태로, cc:attributionURL 프로퍼티에다 이 URL을 제공하는 것을 권한다.
- 12
- 경고: 이들 프로퍼티에 대한 설명은 개략적(직설적)일 뿐이다. 프로퍼티에 대한 정확한 법적 해석은 민감하고, 사법관할권에 따라 다르다.
현실성 있는 법적 정의를 알려면 크리에이티브 커먼즈 라이선스 전체를 참조하라.
- 13
- cc스펙에서는 그 동안 xhtml:license 프로퍼티를 사용했었는데,
ccREL에서 cc:attributionName 과 cc:attributionURL 프로퍼티를 새로 도입한 사실을 주목해 보자.
HTTML에 ccREL을 삽입하기 위해 새로 도입한 방법은 독립성과 확장성에 근거하기 때문에,
기존의 xhtml:license만을 지원하는 툴에 문제를 일으키지 않고 이러한 확장이 가능하다.
- 14
- http://microformats.org/을 참조할 것.
- 15
- http://microformats.org/wiki/grouping-brainstorming
의 토론을 참조할 것.
- 16
- 프로파일(Profile) URL은 HTML 파일이 해석될 때 기준이 되는 프로파일을 알려준다.
예들 들면, "이 페이지에는 hCard 마이크로포맷 정보가 담겨있다"라고 알려주는 마이크로포맷 스펙에서 이러한 프로퍼티가 사용되기도 한다. 또한 이러한 이러한 프로퍼티는 일반 HTML을 RDF/XML로 변환하는데 이용되는 GRRDL에서도
이용된다. 참고로. HTML에서 RDF를 추출하는 방법이 본 논문이 주장하는 원칙과 100% 일치하는 않는다.
이는 GRDDL로 RDF를 추출했을 때 해당 페이지에 있는 그림 중 어떤 것이 CC라이선스를 적용한 것인지를
알아내기 힘들다는 것이 한가지 근거이다.
- 17
- Gleaning Resource Descriptions from
Dialects of Languages (GRDDL) (http://www.w3.org/TR/grddl/) 은
문서에서 RDF 데이터를 추출하는 알고리즘을 웹 문서에 적용할 수 있도록 하는 W3C 권고표준이다.
- 18
- 아톰 라이선스 확장. http://tools.ietf.org/html/rfc4946을 참조할 것.
- 19
- http://www.openarchives.org/
- 20
- 스케일러블 벡터 그래픽 Scalable Vector Graphics, http://www.w3.org/Graphics/SVG/, XML로 표현한 벡터 그래픽으로 W3C 권고표준이다.
- 21
- The Publishing Requirements for Industry
Standard Metadata (PRISM)은 도서, 잡지 또는 저널 등의 콘텐츠를 수집하거나, 발행하는데 필요한 어휘를 제공한다.
http://www.prismstandard.org/을 참조할 것.
- 22
- http://www.nature.com/authors/editorial_policies/license.html
을 참조할 것.
- 23
- http://sciencecommons.org을 참조할 것
- 24
- http://www.w3.org/2007/08/pyRdfa/
- 25
- http://wiki.creativecommons.org/MozCC
- 26
- https://addons.mozilla.org/en-US/firefox/addon/4106
- 27
- 오퍼레이터는 현재 rel="license"같은 HTML 예약키워드를 처리하지 못한다.
이 때문에 cc:license 프로퍼티를 위한 스크립트를 고려하고 있으며,
이와 관련된 예제를 제공한다. 이 결함은 2008년 상반기중 해결될 예정이다.
번역용어집
- accountability
- 신뢰성
- anchor
- 앵커
- attribute
- 속성
- description
- 서술내역
- Creative Commons
- 크리에이티브 커먼즈
- Creative Commons License
- 크리에이티브 커먼즈 라이선스
- element
- 요소
- extensibility
- 확장성
- free floating file
- 비정형파일
- Independence
- 독립성
- interoperability
- 상호호환성
- machine-readable
- 컴퓨터 인식이 가능한
- mechanism
- 메커니즘
- metadata
- 메타데이터
- property
- 프로퍼티
- publisher
- 웹 개발자, 제작자
- recommendation
- 권고표준('권고안'이라고 번역하는 것이 나을 수도 있으나, 권고를 하는 입장에서는 표준에 준하는 비중을 두고 있기 때문에, 사용자가 표준에 준하는 기준을 적용해 줄 것을 바라는 차원에서 권고표준이라고 사용하기로 함)
- remix
- 리믹스
- rights
- 권리
- scheme
- 스키마
- set
- 세트, 집합
- simplicity
- 간결함
- tool
- 툴
- tool builders
- 툴 개발자
- vocabulary
- 어휘
- works
- 작품
