콘텐츠 파트너십 허브/메타베이스/처음부터 위키베이스 설정하기
 |
처음부터 위키베이스 설정하기
이 사례 연구에서 우리는 메타베이스의 비전과 목표에 동의한 후 위키베이스 클라우드 인스턴스를 시작하는 것부터 기본 온톨로지를 구축하는 것까지 메타베이스와 함께 수행한 첫 번째 단계를 설명합니다.
초기 설정
이니셔티브를 시작했을 당시(2022년 10월), 위키베이스 클라우드는 폐쇄형 베타 상태여서 조기 액세스를 신청해야 했습니다. 이 단계는 더 이상 필요하지 않습니다. 플랫폼이 모든 사람에게 개방되었기 때문입니다.
초기 설정은 간단했습니다. 우리는 비슷한 프로젝트를 시작하는 다른 사람들에게 가치 있을 수 있는 몇 가지 관찰을 했습니다:
- 위키의 이름과 첫 번째 사용자의 사용자 이름은 첫 번째 단계에서 제공해야 하며, 나중에 쉽게 변경할 수 없습니다.
- 첫 번째 단계에서는 위키를 모든 사람이 사용자 계정을 만들 수 있도록 공개할지 여부를 선택할 수 있습니다. 관심 있는 커뮤니티 구성원이 일찍 합류할 수 있도록 공개 상태로 유지하기로 결정했습니다.
- 어휘에 대한 지원을 활성화할 수 있습니다.
- 속성과 항목을 위키데이터에 매핑할지 여부를 선택할 수 있습니다. 우리는 그렇게 하지 않기로 했습니다. 그 단계에서는 어느 정도 필요한지 여전히 확신이 서지 않았기 때문입니다. 이 단계는 나중에 수행할 수도 있는데, 결국 몇 가지 속성과 항목으로 테스트했지만 어떤 종류의 이점을 제공하는지는 불분명합니다.
법적 고려 사항
위키베이스 클라우드가 독일의 서버에 호스팅된다는 사실에서 비롯된 몇 가지 법적 고려 사항이 있습니다. 독일에서 호스팅되는 모든 웹사이트와 마찬가지로 위키베이스 클라우드 인스턴스는 법적으로 임프린트가 있어야 하며, 누가 소유하고 관리하는지 명시해야 하므로 메타베이스에서 임프린트를 만들었습니다.
무엇 그리고 어떻게
위키베이스가 가동되고 나서, 데이터로 채우기 시작할 때가 되었습니다. 지식베이스가 완전히 비어 있었기 때문에 어떻게 시작하고 싶은지에 대한 완전한 유연성을 얻을 수 있었습니다. 반면에, 그것은 또한 우리가 온톨로지 전체를 처음부터 고안해야 한다는 것을 의미했습니다. 우리는 루트 항목과 첫 번째 속성이 무엇인지 결정해야 했는데, 이는 위키데이터를 사용할 때 일반적으로 생각하지 않는 것입니다.
저희의 목표는 모든 사람이 쉽게 이해할 수 있고 유연하면서도 위키데이터와 가능한 한 호환되는 데이터 모델을 만드는 것이었습니다. 배경 섹션에서는 메타베이스와 위키데이터의 관계에 대해 자세히 설명합니다. 물론 저희 플랫폼에는 몇 가지 특정 요구 사항이 있지만, 사용자 친화성과 데이터 호환성(연방 SPARQL 쿼리, 가능한 데이터 내보내기/가져오기)을 염두에 두고 위키데이터와 "완전히" 다르게 만들고 싶지 않습니다.
메타베이스의 목표는 세계 지식의 아주 작은 일부만을 포함하는 것이므로, 우리의 온톨로지는 위키데이터의 온톨로지만큼 미묘할 필요가 없었습니다. 연방의 마법 덕분에 SPARQL을 작성할 때, 우리는 항상 위키데이터로 돌아가서 거기에서 수집된 모든 지식을 사용할 수 있습니다. 우리의 지침 원칙은 다음과 같습니다:
- "콘텐츠 항목"과 "지원 항목"을 구분합니다.
- 콘텐츠 항목은 메타베이스가 초점을 맞추는 실제 개체로, 문서, 슬라이드 데크, 모임 등이 있습니다.
- 지원 항목은 이를 모델링하는 데 필요한 모든 것이며, 지리적 위치, 주제, 이벤트 유형 및 문서 등과 같이 위키데이터에 존재합니다.
- 콘텐츠 항목은 위키데이터에 존재하든 존재하지 않든 메타베이스의 일류 시민입니다.
- 지원 항목에는 가능한 한 적은 정보가 포함되어야 하며, 이상적으로는 위키데이터에 대한 링크만 포함되어야 합니다. 스톡홀름의 지리적 좌표나 "컨퍼런스" 개념을 설명하는 모든 백과사전에 대한 링크는 필요하지도 원하지도 않습니다.
속성
최초로 생성된 속성은 다음과 같습니다:
이러한 기본적 속성은 구조적 필요성을 충족시키고 콘텐츠 생성을 위한 기본 프레임워크를 만듭니다.
위키데이터에 동등한 내용이 있는 속성은 위키데이터 문장에서 sameAs를 갖습니다.
위키데이터에 대응하는 속성이 없는 속성은 메타베이스 내부 속성의 "instance of"입니다.
메타베이스 내부 속성
다음 속성(메타베이스 내부 속성)은 메타베이스에 특화되어 있으며, (1대1) 위키데이터와 동등한 것이 없습니다. 이러한 속성은 우리의 필요를 충족하는 데 필요하다고 판단하여 신중하게 고려한 후 생성되었습니다.
- 위키미디어-페이지에 설명되어 있음 - 위키베이스 클라우드는 사이트 링크를 지원하지 않으므로 위키미디어 플랫폼의 페이지에 링크하는 방법을 제공합니다. 예를 들어, ":es:Wikipedia:Encuentros/IV Jornadas de Wikimedia España"는 스페인어로 된 위키백과의 페이지에 링크합니다. 특히 이를 통해 위키데이터의 사이트 링크를 통해 지원되는 것 외에도 위키미디어 위키의 페이지에 링크할 수 있습니다. 예를 들어 가맹단체 위키는 다음과 같습니다. ":wmse:Projekt:Wikipedia_för_hela_Sverige"는 WMSE 위키로 이동합니다.
- 영향을 받는 위키미디어 플랫폼 – 예를 들어 스페인어 위키백과 편집에 초점을 맞춘 에디터톤이라고 할 수 있습니다.
- WMSE 프로젝트 ID – 위키미디어 스웨덴이 수행한 프로젝트의 고유 내부 식별자입니다.
- 프로그래밍 영역별로 정렬됨 – 위키미디어 스웨덴에서 내부적으로 사용되며, 우리가 진행하는 모든 프로젝트는 4개의 프로그램/주제 영역 중 하나에 속합니다. "지부 데이터를 위한 메타베이스" 또한 참조.
항목
메타베이스 온톨로지의 맨 위에는 바로 하위 항목인 위키데이터와 동등한 메타베이스 루트 항목이 있는 메타베이스 루트 항목이 있습니다. 다음 SPARQL 쿼리는 우리가 만든 루트 항목을 보여줍니다. 우리는 우리가 구상한 데이터를 모델링하는 데 가장 중요한 항목 유형이 중요하다고 결정했습니다:
운동이 하는 모든 일과 우리가 메타베이스에 포함시키고자 하는 모든 것은 어떤 종류의 '활동'(에디터톤, 컨퍼런스, 프레젠테이션, 프로젝트 등)이거나 게시된 '문서'(튜토리얼, 보고서, 블로그 게시물, 비디오, 슬라이드 데크 등)입니다. 다른 모든 것은 우리가 그 개체를 설명할 수 있도록 하는 것입니다. 누가 조직하거나 작성했는지, 어디에서 일어났는지 또는 무엇에 관한 것인지.
일부 특정 모델링 고려 사항
하향식, 반복적 개발
온톨로지 작업을 시작하기 전에 우리는 적합한 워크플로를 결정해야 했습니다. 우리가:
- 필요하다고 생각한 모든 속성을 만든 다음 콘텐츠 만들기를 시작하거나
- 콘텐츠 만들기를 시작하고 동시에 속성과 데이터 모델을 만드는 것?
우리는 두 번째 대안인 콘텐츠 중심 모델링 워크플로를 선택했습니다. 처음에는 매우 간단한 사례에 대한 이론적 논의가 있었습니다. 사람, 조직, 주제 등에 대한 모델이 필요할 것입니다. 하지만 우리는 그런 논의가 우리의 뇌를 즐겁게 하긴 하지만 순전히 학문적이라는 것을 매우 빨리 깨달았습니다. 실제로 필요할 때까지는 무엇이 필요한지 "정확히" 알 수 없었습니다. 그래서 우리는 메타베이스에서 답을 찾는 데 도움이 되는 질문에 집중하고 거기에서 다시 돌아가 데이터를 어떻게 구성해야 하는지 알아내기로 했습니다. 메타베이스를 콘텐츠로 채우면 어떤 데이터 구조가 필요한지에 대한 논의가 시작되었고, 그 반대는 아니었습니다. 결국 메타베이스는 운동의 다른 구성원이 실제로 사용하기 전까지는 목적을 달성하지 못할 것입니다. 그들이 배우는 가장 좋은 방법은 우리가 만든 예를 보는 것입니다.
사람
메타베이스의 초점은 개인이 아니라 그들이 생산하는 것에 있습니다. 이러한 이유로 우리는 사람들에 대한 정보를 그들의 작업과 그 제품에 연결하는 데 필요한 것으로 제한하기로 결정했습니다. 그렇게 하기 위해 우리는 그들의 성별, 생년월일 또는 교육적 배경을 알 필요가 없습니다. 데이터 프라이버시도 고려 사항이었습니다. 위키미디어 운동의 모든 활동적인 구성원이 위키데이터 항목이나 그들의 삶과 작업에 대한 다른 공개 정보를 가지고 있는 것은 아닙니다. 개인 정보를 존중하는 것은 인간의 품위 문제일 뿐만 아니라 EU 국가에 기반을 둔 조직인 위키미디어 스웨덴이 법적으로 따라야 할 일반 데이터 보호 규정의 문제이기도 합니다.
저희는 저자/연사/이벤트 또는 프로젝트 책임을 설명하는 데 필요한 경우에만 사람에 대한 항목을 만듭니다. 그리고 저희는 이 정보가 이미 공개적으로 사용 가능한 경우에만 그렇게 합니다. 모든 가맹단체도 공개적으로 전달되어야 합니다. 주요 가맹단체가 항상 적용되는 것은 아니므로 항목별로 한정자로 대체될 수 있습니다.
일부 위키미디어인은 운동 활동에 참여하며 사용자 이름으로만 널리 알려져 있습니다. 우리는 문서에서 이를 존중해야 하며 기여자는 실제 이름을 알고 있는 경우 실제 이름을 게시해서는 안 된다는 점을 명확히 밝혔습니다. 또한 일부 위키미디어인은 가맹단체 직원과 자원봉사자로서의 참여를 위해 별도의 사용자 계정을 유지한다는 점도 확인했습니다. 예를 들어 한 사람이 컨퍼런스에서 가맹단체 직원으로서 한 번, 자원봉사자로서 한 번 두 번의 프레젠테이션을 하는 경우가 있습니다. 출처 자료에서 구분이 명확한 경우(예: 컨퍼런스 프로그램에서 한 프레젠테이션은 "스벤 스벤손 (WMSE)"이 하고 다른 프레젠테이션은 "Sven123456"이 한다고 명시되어 있는 경우) 일부 사람이 자원봉사자 계정의 소유자를 알고 있더라도 두 사람 항목을 만들어야 한다고 주장합니다.
이런 식으로 사람에 대한 정보를 제한함으로써 우리는 원하는 저자나 이벤트 리더십에 대한 데이터를 저장하면서도 주제의 개인 정보를 존중할 수 있기를 바랍니다.
색인 용어
우리는 메타베이스 사용자가 다른 것에 대한 것, 예를 들어 젠더 갭에 대한 프레젠테이션이나 미술관 작업과 같은 것을 찾을 수 있기를 바랍니다. 이를 위해 메타베이스는 위키데이터에 분명히 존재하는 "젠더 갭"과 "미술관"이라는 항목을 포함해야 합니다. 그러나 미술관의 모든 콘텐츠를 복제하는 것은 메타베이스에 전혀 필요하지 않습니다.
그래서 우리는 색인 용어에 대한 단순화된 개념을 생각해냈습니다.
색인 용어는 예를 들어 문서의 주제나 프로젝트의 주요 분야를 설명하는 데 사용하는 키워드입니다(주제 속성 사용).
메타베이스의 범위 내에서 레이블은 충분합니다. 예를 들어 색인 용어 간의 관계를 표현하는 것에는 관심이 없습니다. 이러한 용어는 위키데이터에 있으며 필요한 경우 연합 쿼리를 사용하여 쿼리할 수 있습니다.
따라서 우리가 색인 용어에 대해 제공하는 유일한 데이터는 다음과 같습니다:
- instance of → "색인 용어"
- "위키데이터의 sameAs → 위키데이터 Q ID
때로는 다른 것인 항목을 색인 용어로 사용해야 할 필요가 있습니다. 이 경우 항목에는 여러 개의 "instance of" 문장이 있을 수 있습니다. 예를 들어:
- 예테보리 시는 장소(어떤 컨퍼런스가 열린 곳)이자 색인 용어(에디터톤의 주제였기 때문)입니다.
- 스웨덴어 위키백과는 위키미디어 콘텐츠 프로젝트(영향을 받은 위키미디어 플랫폼을 사용하여 편집된 에디터톤을 설명할 수 있기 때문)이자 색인 용어(프레젠테이션이나 튜토리얼의 주제였기 때문)입니다.
위키미디어 플랫폼
저희의 목표 중 하나는 메타베이스를 사용하여 위키미디어 플랫폼의 활동(예: 에디터톤 및 업로드)에 대한 정보를 저장하는 것입니다. 이 플랫폼은 계층적 구조를 가지고 있습니다. 다른 언어로 된 위키백과는 형제 프로젝트이며 개념적 "위키백과"(존재하지 않더라도)의 자식입니다. 사용자 관점에서 볼 때, 저희는 이 계층적 관계를 복제하고자 합니다. 때로는 위키백과에 초점을 맞춘 모든 에디터톤을 찾는 데 관심이 있을 수 있고, 때로는 특정 언어 버전으로만 제한될 수 있습니다. 위키백과 외에도 위키데이터 및 위키미디어 공용과 같이 저희 데이터와 관련된 다른 여러 프로젝트가 있습니다.
메타베이스의 위키미디어 플랫폼 구조는 다음과 같습니다:
- 위키미디어 프로젝트의 가족은 루트 항목입니다.
- 위키미디어 콘텐츠 프로젝트는 루트 항목입니다.
- 위키백과는 다양한 언어 버전을 포함하고 있기 때문에 "위키미디어 프로젝트 가족"입니다.
- 스웨덴어, 영어, 독일어 등. 위키백과는 위키미디어 콘텐츠 프로젝트이자 위키백과"의 일부"입니다.
- 위키미디어 공용과 위키백과의 다른 형제 프로젝트는 위키미디어 콘텐츠 프로젝트입니다.
위키데이터에서 온 경험
숙련된 위키데이터 편집자로서 위키베이스 클라우드 인스턴스에 기여하는 것은 매우 쉬울 것입니다. 적어도 우리는 그렇게 생각했습니다. 그 과정에서 위키베이스 클라우드 인스턴스와 위키데이터 사이에 주요에서 약간 성가신 것까지 여러 가지 기술적 차이점을 발견했습니다. 그것들이 우리의 진행을 막지는 않았지만, 처음에는 속도를 늦췄습니다.
- 소도구와 사용자 스크립트에 대한 지원 부족. 많은 숙련된 위키데이터 편집자는 사용자 지정 환경에 큰 자부심을 가지고 있으며, 누드 위키베이스 인터페이스가 어떤 것인지조차 알지 못할 수도 있습니다. 작성자는 특히 "Merge", "LabelLister", "DuplicateReferences" 및 "MoveClaim"을 갈망했습니다. 인터페이스를 사용자 지정하기 위해 자체 자바스크립트 또는 CSS 파일을 배포하는 것도 불가능합니다.
- 제한된 수의 확장 기능. 위키데이터와 비교했을 때 위키베이스 클라우드에는 위키미디어인들에게 익숙한 여러 확장 기능이 없습니다. 항목 이름공간에서 속성 제안자가 없는 것이 가장 눈에 띄는데, 위키데이터에서 얼마나 많은 시간과 정신적 노력을 절약하는지 깨닫지 못했습니다! 항목 이름공간 외부에서 번역과 시각적 편집기가 특히 필요합니다. 이를 사용할 수 없으면 모델링 지침과 같은 문서 페이지를 편집하는 효율성이 저하됩니다. 결국 시각적 편집기에서 표를 만드는 데는 우리 모두가 철저히 버릇없어졌잖아요! 번역 확장 기능 없이는 향후 사용자가 선호하는 언어로 버전을 쉽게 만들 수 없게 되어 글로벌 커뮤니티에 메타베이스를 소개하고 옹호하는 능력에 큰 부정적인 영향을 미칠 것입니다.
- 위키미디어 공용의 이미지는 표시되지 않습니다. 이는 모델링을 설명할 때 사소하지만 고통스러운 장애물이 되었습니다. 때로는 그림이 천 단어보다 더 많은 것을 말해주기도 합니다(그리고 이것이 여러분이 메타베이스에서 이 논문을 읽지 않는 실제 이유입니다).
- Cradle 도구가 제대로 작동하지 않고 대신 위키데이터에서 항목을 검색합니다. 이 문제는 파브리케이터에서 발견되었는데, Cradle을 사용하고 싶어하는 다른 위키베이스 클라우드 사용자가 있기 때문입니다.
- 속성 제약 조건, 즉 속성을 어떻게 사용해야 하는지 지정하는 속성 규칙이 없습니다. 위키데이터 편집자로서, 규칙에 익숙하지 않거나 단순히 실수로 속성에 오류가 있을 수 있는 값을 설정할 때 즉시 알림을 받는 것은 매우 편리합니다. 메타베이스에서 우리는 일반적인 오류와 불일치를 감지하기 위해 SPARQL 쿼리 세트를 작성하여 이를 우회하려고 시도했지만, 자동 제약 조건 경고만큼 효과적이거나 사용자 친화적이지 않습니다.
- 위키미디어 프로젝트에 대한 인터위키 지원 부족. 위키미디어 페이지에 설명된 속성의 생성은 이에 의해 동기가 부여되었습니다.
- SPARQL 쿼리를 작성할 때 접두사 선언이 필요합니다. 예:
PREFIX wb: <https://metabase.wikibase.cloud/entity/> PREFIX wbt: <https://metabase.wikibase.cloud/prop/direct/>
결론
요약하자면, 위키베이스 클라우드 인스턴스를 설정하는 것은 기술적으로 간단합니다. 우리는 자체 호스팅 위키베이스 인스턴스로 작업하려고 시도하지 않았으므로 합리적인 비교를 할 수 없습니다. 실제 어려움은 기본 온톨로지를 고안하고 구현할 때 개념적 수준에서 시작됩니다. 물론 이러한 어려움은 클라우드에서 작업하든 자체 서버에서 작업하든 동일합니다. 누구나 소프트웨어를 구성할 수 있지만 온톨로지를 설계하려면 높은 수준의 추상적 사고가 필요하며, 우리는 이에 대한 전문가가 아닙니다.
위키베이스 클라우드 인스턴스를 직접 만드는 것을 고려하고 계신가요? 메타베이스를 설정하고 데이터 입력을 위해 준비하면서 배운 몇 가지 사항은 다음과 같습니다:
- 어떻게 할 것인가가 아니라 무엇을 달성하고 싶은지 결정하세요. 어떤 질의를 실행할 수 있기를 원하시나요? 그런 다음 거기에서 거꾸로 작업하여 온톨로지를 설계하세요.
- 처음부터 온톨로지를 설계하는 것은 생각보다 어렵다는 사실에 대비하세요. 위키데이터에 익숙해지면 도움이 될 수 있지만 방해가 될 수도 있습니다.인간의 뇌는 익숙한 것을 좋아하지만, 우리는 위키데이터만큼 자세할 필요는 없고 원치도 않습니다.
- 위키데이터와의 호환성 수준이 어느 정도인지 일찍 결정하세요.
- 대상 그룹, 즉 데이터 사용자와 기여자에 대해 생각해보세요. 그들은 모두 주제에 대해 잘 알고 있을까요? 아니면 외부 사용자와 적극적으로 교류할 계획인가요? 이는 온톨로지와 그 복잡성에 대한 생각에 영향을 미칠 것입니다.