콘텐츠 파트너십 허브/메타베이스/지부 데이터용 메타베이스

This page is a translated version of the page Content Partnerships Hub/Metabase/Metabase for chapter data and the translation is 100% complete.

콘텐츠 파트너쉽 허브

콘텐츠 파트너와의 위키미디어 운동 개선

지부 데이터용 메타베이스

메타베이스에 대한 백서
소개 처음부터 위키베이스 설정하기 지부 데이터용 메타베이스 글로벌 운동을 위한 메타베이스

초기 설정이 완료되고 메타베이스가 가동되면서 콘텐츠를 채울 준비가 되었습니다. 우리는 익숙한 것, 즉 위키미디어 스웨덴의 내부 지식 기반부터 시작하기로 했습니다. 이 연구에서는 메타베이스를 이러한 목적으로 사용하는 것을 고려하는 다른 가맹단체가 무엇을 기대해야 할지 알 수 있도록 프로세스에 초점을 맞춰 진행 방법을 설명합니다.

배경

자체 데이터로 시작하는 것은 당연한 일이었습니다. 우리는 그 구조를 잘 이해하고 있었기 때문입니다. 모든 것이 있는 지부 위키는 우리의 중앙 정보 저장소입니다. 우리는 그것을 사용하여 우리의 운영과 관련된 모든 것을 문서화합니다. 일괄 업로드 및 활동과 같은 프로젝트와 그 구성 요소, WMF 및 파트너에게 보고하는 지표, 보조금 신청서 및 프로젝트 보고서, 연간 계획 및 보고서, 이사회 회의록, 정책 및 직원 지침. 수년에 걸쳐 수집된 정보 덕분에 다른 사람들이 우리의 작업에 대해 알 수 있습니다(결국 우리는 위키미디어 세계에서 투명성을 중시합니다. 특히 우리가 비영리 협회이고 회원과 일반 대중의 지원에 크게 의존한다는 점을 고려할 때 더욱 그렇습니다). 그러나 동시에 그것은 우리 자신을 위한 참고 자료이기도 합니다. 우리는 범주와 템플릿을 사용하여 정보를 구조화하지만, 특히 데이터를 집계하거나 여러 프로젝트에서 검색하려는 경우, 우리에게도 항상 찾고 있는 것을 빠르게 찾는 것이 쉽지 않다는 것은 비밀이 아닙니다. 그래서 일부 정보를 링크된 데이터로 전환하는 것이 매력적인 실험이었습니다.

저희 직원들은 매일 위키에 기여하고 위키를 읽으며, 각자의 역할에 따라 다양한 방식으로 위키를 사용합니다.이를 염두에 두고, 저희는 실제 직원을 기반으로 일련의 페르소나를 편집하여 지식 기반을 개발하는 작업을 안내하는 것으로 시작했습니다.저희는 메타베이스 프로젝트에 참여하는 소수의 개인이 동료들과 동일한 기술과 요구 사항을 가지고 있지 않다는 것을 빨리 깨달았고, 그들이 메타베이스가 무엇이고 무엇이 아닌지, 그리고 업무에 어떻게 사용할 수 있는지 최대한 쉽게 이해할 수 있도록 해야 했습니다.프로젝트 내내 저희는 그들에게 저희의 작업, 그 목적 및 주요 이정표에 대해 계속 업데이트했습니다.또한 모든 사람이 자신의 전문 분야와 관련된 데이터를 제공할 수 있는 몇 가지 세션도 있었습니다.작성한 보고서나 조직한 에디터톤을 위해 두 사람을 위한 항목을 만들었습니다.이런 식으로 저희는 조직으로서 메타베이스 구축에 리소스를 투자하는 이유를 잘 이해하도록 했습니다. 동시에 동료들의 작업을 관찰하고 그들의 피드백을 경청하면서 우리는 다양한 사용자들의 요구 사항에 대해 (약간!) 더 나은 아이디어를 얻었습니다.

방법

"처음부터 위키베이스 설정"에서 언급했듯이, 메타베이스를 설정하는 초기 작업은 기본 온톨로지를 구축하는 것으로 마무리되었습니다. 위키데이터의 sameAs와 같은 여러 가지 일반적인 용도 속성이 생성되었습니다. 또한 데이터 중복 및 위키데이터와 개인 정보와의 호환성과 같은 문제를 해결하는 방법에 대한 기본 지침을 논의하고 결정했습니다. 이는 출처나 주제에 관계없이 메타베이스의 모든 데이터에 적용됩니다. 다음 단계로 들어가 실제로 콘텐츠에 대해 생각하기 시작하면서 빈 데이터베이스의 공포를 다루는 가장 좋은 방법은 모델링을 콘텐츠와 함께 성장시키는 것이라고 결정했습니다. 즉, "무엇"을 입력하고 싶은지 생각하기 시작한 다음 가장 합리적인 속성과 모델링 지침을 만들었습니다.

실제적으로, 우리는 데이터 입력을 전담하는 직원 한 명과 메타베이스의 기본 구조를 설정한 다른 두 명을 두고 지원을 제공하고 의견 교환의 장을 마련했습니다. 그들은 모두 정기적으로 만나 최근 개발 사항을 살펴보고 과제를 논의했습니다. 특히, 작업 초기 단계에서 우리는 세 사람이 필요성과 사용 방법에 대한 합의에 도달할 때까지 새로운 속성을 만들지 않기로 결정했습니다. 우리는 모델링을 가능한 한 단순하게 유지하고 너무 구체적인 목적을 가진 불필요한 속성을 만드는 것을 피하고 싶었습니다. 콘텐츠가 늘어나는 것과 동시에 우리는 공유 내부 문서에 결정을 기록했고, 그 후 정리하여 메타베이스의 위키 기반모델링 가이드라인을 만들었습니다.

반복적인 프로세스는 계획과 실제 작업 사이에 많은 차이가 있음을 보여주었습니다. 우리는 미리 알지 못했습니다. 실제로 상상조차 할 수 없었습니다. 얼마나 많은 시간이 걸릴지, 어떤 문제가 생길지 말입니다. 작업 중에 많은 질문이 생겨서 논의해야 했는데, 특히 복사할 구조의 위키데이터 예가 없는 분야에서는 더욱 그렇습니다.

WMSE 데이터

모든 가맹단체는 각자의 업무를 관리하고 운영하는 고유한 방식을 가지고 있습니다. 위키미디어 스웨덴에서는 다음과 같은 구조를 사용합니다:

주제 영역. 지난 몇 년 동안은 다음 네 가지였습니다. 활성화, 접근, 커뮤니티, 사용.
프로젝트. 모든 프로젝트는 네 가지 주제 영역 중 하나에 속합니다. 모든 프로젝트에는 시간 틀, 관리자 및 자금 조달 출처가 있습니다.
- 위키미디어 재단의 운영 보조금(WCF)으로 자금이 지원되는 프로젝트. 프로젝트에 대한 전체 자금은 연초에 수령됩니다. 프로젝트는 달력 연도 기준으로 실행되므로 연도가 프로젝트 이름에 포함됩니다.
- 외부 자금 지원 프로젝트. 형식, 예산 및 시간 측면에서 기금 제공자에게 제출된 특정 신청서와 관련된 광범위한 프로젝트 범주입니다. 프로젝트는 종종 달력 연도에 걸쳐 있으므로 연도는 프로젝트 이름에 포함되지 않습니다.
- 시간 기반 프로젝트. 이들은 일반적으로 특정 수의 작업 시간을 제공하기로 약속함으로써 다른 당사자가 위임합니다. 작업은 위임 당사자를 위해 직접 수행되거나 프로젝트 신청에서 하청업체로 수행될 수 있습니다.
활동. 일괄 업로드, 에디터톤 또는 컨퍼런스에서 제공하는 프레젠테이션과 같은 모든 활동은 자금을 지원하는 특정 프로젝트에 속하며, 활동은 프로젝트 목표를 달성하는 데 기여합니다.

결과

프로젝트

프로젝트는 우리 업무의 중심에 있습니다. 우리가 하는 모든 일은 프로젝트의 일부입니다. 그래서 이 개념으로 시작하는 것이 합리적이었습니다. 우리의 Q1은 콘텐츠 파트너십 지원 프로젝트였습니다. 프로젝트를 만든 후, 우리는 그것에 대해 무엇을 말하고 싶은지 생각하기 시작했고, 필요한 속성을 만들었습니다.

그 중 일부는 명확했고, 위키데이터에 "instance of", "start time", "end time" 등과 같은 동등한 단어가 있었습니다. 하지만 우리는 또한 우리의 작업이 실제로 어떻게 구성되어 있는지 반영하고 싶었습니다. 이를 달성하기 위해 다음과 같은 속성과 구조가 필요했습니다.

WMSE 속성

프로그래밍 영역 아래에 정렬됨 – 프로젝트가 우리 작업의 네 가지 주요 주제 중 어느 것에 속하는지 보여줍니다.
WMSE 프로젝트 ID – 모든 프로젝트에 할당하는 고유한 관리 ID입니다.

WMSE 작업 구조

일부 프로젝트는 에디터톤을 조직하거나 위키미디어 공용에 파일을 업로드하는 것과 같이 위키미디어 플랫폼에 콘텐츠를 편집하거나 추가하는 것을 목표로 합니다. 이는 프로젝트 항목에서 영향을 받는 위키미디어 플랫폼 속성을 사용하여 표시할 수 있습니다.

모든 프로젝트는 WMSE 위키의 "프로젝트" 이름공간에 전용 페이지가 있습니다(예: 프로젝트: 콘텐츠 파트너십 지원). 위키미디어-페이지에 설명된 속성을 사용하여 링크합니다.

우리가 하는 모든 활동은 프로젝트의 일부이므로, "has part(s)" / "part of" 속성을 사용하여 이들을 연결합니다.

자금 조달 - 해결되지 않은 문제

우리 지부의 작업에서 우리가 모델링하고 싶은 한 측면은 예산과 작업의 자금 조달 방식입니다. 여기에는 다음과 같은 정보가 포함됩니다:

보조금 신청 - 기금 제공자, 보조금, 요청 금액, 공동 자금 조달, 신청자; 성공 및 실패한 신청 모두 포함.
자금 조달 프로젝트 및 이벤트 - 최종 비용 및 자금 출처를 포함한 이것의 재정적 측면.
우리의 전체 연간 재정 - 예산 규모, 최종 비용/수입/결과, 기부금.

우리는 이 주제에 가장 잘 접근하는 방법에 대한 여러 내부 논의를 했습니다. 이상적으로는 기존의 모든 위키데이터 구조와 모범 사례를 재사용하고 싶습니다. 위키데이터는 연구 보조금을 중심으로 일부 모델링을 하지만, 주로 보조금과 자금 지원 프로젝트에 초점을 맞추고 있으며, WMSE의 작업 방식에 핵심적인 애플리케이션 자체는 아닙니다. 우리는 관심을 가질 만한 몇 가지 위키데이터 속성을 파악했습니다.

이 모든 연구를 한 후, 우리는 메타베이스에서 경제나 금융과 관련된 어떤 것도 모델링하지 않기로 했습니다. 그 이유는 우연히 우리의 필요에는 완벽하지만 다른 제휴사에게는 유용하지 않은 구조를 구축하고 싶지 않기 때문입니다. 다른 모든 것과 마찬가지로, 우리는 온톨로지가 유연하고 다른 제휴사에서 사용하기 쉽기를 바랍니다. 이를 달성하기 위해서는 그들이 현재 어떻게 일하고 무엇이 필요한지에 대한 의견과 피드백을 얻는 것이 중요합니다. 우리는 2023년 가을에 열린 위키데이터 모델링 데이에서 이 주제를 제기했고(유튜브 녹화본, 슬라이드), 2024년 위키마니아에서 다시 한 번 이를 실시하여 다른 가맹단체들이 참여하여 필요한 구조를 함께 논의할 수 있는 기회를 제공할 것입니다.

콘텐츠 업로드

콘텐츠 업로드(미디어 파일을 위키미디어 공용에 업로드하거나 데이터를 위키데이터에 업로드)는 저희와 다른 많은 가맹단체의 콘텐츠 파트너십 작업에서 가장 중요한 부분 중 하나입니다. 동시에 위키데이터에서 이를 모델링할 필요가 없었고, 따라서 배울 모범 사례도 없었습니다. 저희는 처음부터 모델링해야 했습니다. 이 때문에 여기에서는 특별히 주의를 기울여야 합니다. 2021년 뢰스카 박물관에서 업로드한 2021년 이미지 항목을 예로 들어보겠습니다.

우리는 콘텐츠 업로드에 관해 다음 사항을 표현하고자 했습니다:

언제 완료되었는지.
WMSE의 어떤 프로젝트에 속했는지 - 프로젝트별 정보를 검색하거나 각 프로젝트에 대한 지표를 컴파일할 수 있도록 합니다.
어떤 위키미디어 플랫폼에서 수행되었는지.
어떤 유형의 리소스가 업로드되었는지. 이는 특히 미디어 업로드와 관련이 있습니다. 위키미디어 공용은 이미지, 오디오 파일, 비디오, PDF 파일 등을 보관할 수 있기 때문입니다. 위키데이터에서 항목이나 어휘를 사용할 수 있으므로 이러한 항목을 따로 보관할 수도 있어야 합니다.
업로드된 개체 수. 위키데이터의 항목이나 어휘 또는 위키미디어 공용의 파일입니다.
업로드된 리소스의 출처. 특정 박물관이 기여한 파일 수를 알려드리고 싶습니다.
커먼즈 범주. 업로드된 파일을 쉽게 찾을 수 있도록!
WMSE 위키의 관련 페이지에 대한 링크. 저희 위키는 모든 업로드에 대한 지표를 보고하는 곳입니다.

몇 가지 논의와 시행착오 끝에 우리는 다음과 같은 속성과 구조를 결정했습니다:

영향을 받은 콘텐츠 페이지 수 – 얼마나 많은 콘텐츠 페이지가 생성되거나 개선되었는지. 세부 사항은 한정사와 함께 설명됩니다.
- 이름공간 – 어떤 이름공간이 영향을 받았는가.
- 영향을 받는 위키미디어 플랫폼 – 위키미디어 프로젝트의 일부입니다.
- 리소스 유형 – 어떤 유형의 리소스와 함께. 리소스 유형은 위키미디어 공용의 경우 오디오, 비디오 또는 이미지 파일과 같은 미디어 유형입니다.

"이름공간"과 "리소스 유형"을 모두 사용하는 이유는 위키미디어 공용의 파일 이름공간이 오디오 녹음, 사진, 비디오 등 다양한 유형의 파일을 호스팅할 수 있기 때문입니다. 위키데이터에서 항목과 어휘는 모두 연결된 데이터임에도 불구하고 다른 이름공간에 속합니다. 때로는 세부 정보를 아는 것이 유용합니다. 얼마나 많은 개체가 업로드되었는지 뿐만 아니라 어떤 종류인지도 알아야 합니다.

이 모델링은 여러 위키미디어 플랫폼에 영향을 미치는 업로드를 수용할 수 있습니다. 예를 들어, 여러 디지털화된 그림을 위키미디어 공용에 업로드하고 동시에 위키데이터 항목을 만드는 프로젝트를 수행했습니다. 동시에 또는 적어도 동일한 개념적 공간 내에서 이를 수행하므로(별도의 프로젝트로 생각하지 않습니다. 그림에는 위키데이터 항목이 있어야 한다는 것은 분명합니다) 이를 분리하는 것은 의미가 없습니다. 여러 위키미디어 프로젝트와 리소스 유형을 포함하는 콘텐츠 업로드의 예로 WiR 업로드, 스웨덴 공연 예술 기관을 참조하세요.

문서

위키미디어 스웨덴은 다른 조직과 마찬가지로 내부 및 외부 사용을 위해 많은 문서를 생산합니다. 앞서 언급했듯이 메타베이스를 가능한 한 위키데이터와 동기화하고 싶습니다. 여기에는 문서 유형도 포함됩니다. 간단할 것이라고 생각했지만 모든 문서에 대한 위키데이터 대응 항목을 찾는 것은 쉽지 않았습니다. 예를 들어, 우리는 종종 remissvar를 작성하거나 기여합니다. remissvar는 의회에 보내어 그들이 만들고자 하는 새로운 법률에 대한 피드백을 제공하는 문서입니다. 위키데이터에는 협의 항목이 있는데, 이는 의회가 제안된 법률에 대한 피드백을 요청하지만 문서 자체에 대한 피드백은 요청하지 않는 프로세스입니다. 협의 답변?

다른 가맹단체들이 작업하는 문서 유형을 위키데이터에 매핑할 때 비슷한 문제에 직면하게 되더라도 놀랍지 않을 것입니다. 문서 유형이 정의되는 방식에는 지역적 차이가 있을 것입니다. 명백한 해결책은 위키데이터의 데이터를 수정하거나 개발하는 것이며, 이는 메타베이스 사용자뿐만 아니라 모든 사람에게 이롭습니다. 우리는 실험적 작업의 일환으로 이를 하지 않기로 결정했습니다. 시간과 도메인 지식이 모두 필요하기 때문입니다(모든 위키데이터 편집자가 알다시피, 처음에 무엇을 했는지 잊어버릴 때까지 한 가지를 더 편집하는 토끼굴에 빠지기 쉽습니다). 게다가 메타베이스에 더 나은 서비스를 제공하기 위해 위키데이터의 데이터를 편집하지 않으면 이러한 문제가 발생할 수 있음을 분명히 합니다. 시간에 제약을 받지 않는 메타베이스 편집자는 전문성에 따라 위키데이터의 데이터를 개선하거나 적어도 관련 편집자 커뮤니티에서 문제를 제기할 동기를 가질 수 있을 것으로 생각합니다.

결론

메타베이스는 현재 구조를 보완하는 것인가, 아니면 대체하는 것인가?

답이 나오지 않은 큰 질문 중 하나는 메타베이스가 현재 구조를 어느 정도 대체하거나 보완할 수 있는가입니다. 우리는 스스로만 답할 수 있지만 다른 가맹단체도 비슷한 고려를 할 것입니다. 모든 가맹단체의 요구 사항은 다릅니다.

WMSE의 경우, 저희 위키는 저희 워크플로의 핵심 부분입니다. 저희는 이를 사용하여 기금 제공자에게 보고하는 저희 활동에 대한 지표와 같이 쉽게 링크된 오픈 데이터가 될 수 있는 정보뿐만 아니라 쉽게 액세스하고 탐색할 수 있어야 하는 정책 및 지침과 같은 많은 수의 문서를 저장합니다. 이 정보는 직원이 오고 가는 동안 위키가 보관소의 기능을 수행하면서 수년 전으로 거슬러 올라갑니다. 이를 메타베이스의 데이터가 아닌 이름공간과 같이 다른 플랫폼으로 옮기려면 많은 작업이 필요하므로, 그저 그렇게 하려는 것은 아닙니다. 이점이 번거로움보다 더 커야 합니다. 이렇게 오랜 역사가 있기 때문에 저희 위키를 없애고 다른 플랫폼으로 대체하는 것은 현실적이지 않습니다. 수년 동안 성공적으로 사용해 온 워크플로를 고수하는 것은 역사적 관점에서 이점이 있으며, 향후 사용자가 저희 지식 저장소에서 방향을 잡기가 더 쉬워집니다.

우리는 어떤 종류의 분할이 가능할 것이라고 생각합니다. 연결된 데이터로 저장"될 수 있는" 데이터는 메타베이스에 있고 WMSE 위키에 표시됩니다("표시됨"은 여기서 많은 작업을 수행하며, 잠시 후에 설명하겠습니다). 지금은 실험 중이므로 직원이 메타베이스에서 활동을 보고할 의무는 없습니다. WMSE 위키는 여전히 제자리에 있습니다. 앞으로는 어떻게 해야 할까요?

메타베이스가 데이터의 "유일한" 장소가 되어야 하는지에 대한 의문을 제기하지 않고는 내부 데이터에 대한 메타베이스의 미래 적용에 대해 생각하는 것은 불가능합니다. 여전히 WMSE 위키에서도 보고해야 하며, 작업량이 두 배가 되고 불일치 위험이 증가해야 할까요? 많은 위키 페이지가 매우 구조화되어 있다는 사실을 고려하면 - 우리는 템플릿과 미리 정의된 페이지 레이아웃을 사용하여 작업에서 메트릭을 보고하고, 누가 입력하든 항상 동일하게 보이도록 합니다 - 위키에서 메타베이스로의 데이터 흐름을 자동화하는 가능한 방법에 대해 생각하는 것이 합리적입니다. 봇은 데이터를 전송하고, 위키에서 수정이 이루어지면 데이터를 업데이트하고, 메타베이스에서 수동 편집으로 인해 발생한 불일치 사항을 알려줄 수 있습니다. 물론, 이는 메트릭 보고 인프라의 엄격한 구조 덕분에 가능합니다. 모든 가맹단체는 고유한 과제와 고려 사항이 있을 것입니다.

하지만 지금은 단지 사고 실험일 뿐입니다. 위키베이스 클라우드 위키의 내용을 위키미디어 위키에 표시하는 간단한 방법은 없습니다. 위키데이터에 적합한 솔루션이 있는데, 여기서는 틀:인물 정보 상자/위키데이터와 같은 틀과 지역화된 동등물 또는 리스테리아를 사용하여 다른 위키미디어 위키에 데이터를 삽입할 수 있습니다. 특히 리스테리아는 위키베이스 클라우드 사용자와 관리자의 관점에서 매우 흥미로운 도구입니다. 위키미디어 플랫폼 전반에 걸쳐 널리 사용되므로 위키베이스 클라우드에서 데이터를 수집하도록 조정하면 사용자가 사용하기 시작하는 임계값이 낮아질 것입니다. 위키베이스 클라우드 인스턴스에서 위키미디어 위키로의 데이터 흐름을 용이하게 하는 열쇠가 되어 플랫폼을 새로운 사용자에게 더욱 유용하고 관련성 있게 만들 수 있습니다.

우리는 적절한 교육을 받지 않은 직원에게 메타베이스를 사용하도록 요청할 수 없다는 것을 알고 있습니다. 대부분이 최소한 기본적인 위키데이터 기술을 가지고 있지만, 경험이 풍부한 위키데이터와는 거리가 멀어 메타베이스를 이해하고 사용하기 위한 문턱이 상당히 낮아집니다. 전체 직원에게 프로젝트에 대한 기본적인 소개를 제공했지만(그들은 플랫폼이 개발되는 이유를 알고 있으며 편집을 시도하도록 격려받았습니다) 새로운 디지털 도구의 경우와 마찬가지로 일상 생활의 일부로 사용하는 데 편안함을 느끼려면 시간과 노력이 필요하다는 것을 알고 있습니다.

조직으로 시작하기

위키미디어 스웨덴의 데이터를 바탕으로 우리는 가맹단체가 비슷한 여정을 시작할 때 직면할 수 있는 과제에 대해 몇 가지 일반화를 내릴 수 있습니다.

우선, 사용 가능한 데이터를 검토하는 것부터 시작해야 합니다. 어떤 종류의 정보가 처음에 기록되었으며, 얼마나 멀리까지 갈 수 있습니까? 이를 통해 메타베이스에서 무엇을 달성할 수 있는지가 결정됩니다. 이미 메타베이스에 있는 프레젠테이션이나 이벤트와 같은 유사한 항목이 어떻게 모델링되는지 살펴보고 이러한 구조 중 얼마나 재사용할 수 있는지 고려하는 것이 도움이 될 것입니다. WMSE에 WMSE 프로젝트 ID와 주제 영역이 필요했던 것처럼 가맹단체별 속성과 구조가 필요할 수 있습니다. 위키데이터와 비교했을 때 메타베이스의 강점은 외부 사용자에게 관심이 없더라도 필요한 속성을 실험하고 쉽게 만들 수 있다는 것입니다.

그런 다음 실제 데이터 입력 단계에 대한 워크플로를 개발해야 합니다. 누가 해야 하며, 어떤 리소스를 사용할 수 있습니까? 이미 위키데이터에 익숙하다면 작업의 어려움이 크게 줄어듭니다. QuickStatements를 사용할 수 있다면 더욱 그렇습니다. 메타베이스에서 작동합니다! 소스 데이터를 구문 분석하는 방법(예: 가맹단체 위키의 위키 텍스트에서 정보를 추출하는 방법)을 알고 있다면 더욱 그렇습니다. 전담 데이터 입력 담당자가 있더라도 소스 자료에 명시적으로 언급되지 않은 조직 지식을 활용하기 위해 다른 직원의 지원이 필요할 수 있다는 점을 명심하세요.

사실, 지부의 위키에서 데이터를 복사할 때 마주친 한 가지 어려움은 정보가 항상 명확하지 않다는 것이었습니다. 이벤트나 활동에 대한 메모는 혼란스럽고 이벤트에 직접 참여하지 않은 사람들에게는 이해하기 어려울 수 있으며, 프레젠테이션 주제와 같은 중요한 정보는 찾기 어려울 수 있습니다. 우리 모두 알다시피, 직접 조직한 이벤트를 문서화할 때, 본인에게는 명백한 내용을 생략할 수 있지만 5년 후에 메모를 살펴보면 동료(또는 본인...)에게는 명백하지 않을 수 있습니다! 어떤 경우에는 이벤트를 조직한 직원에게 설명을 요청할 수 있었지만, 항상 그럴 것이라고 가정할 수는 없습니다. 이런 식으로 메타베이스 실험은 추가적인 교훈을 제공했습니다. 위키에 글을 쓸 때는 더 주의를 기울여야 나중에 이해할 수 있습니다.

문서화는 필수적입니다. 우리의 경우 모델링 선택을 문서화하는 데는 두 가지 목적이 있었습니다. 우선, 물론 미래의 메타베이스 기여자가 모델링을 이해하고 이를 사용하거나(또는 논의하고 변경!) 할 수 있도록 하고 싶었습니다. 하지만 우리는 문서화가 우리 자신에게도 똑같이 중요하다는 것을 금세 깨달았습니다. 인간의 기억은 신뢰할 수 없고, 우리가 스스로 고안한 모델링 가이드라인에서 실수로 벗어나는 데는 시간이 많이 걸리지 않습니다.

조직의 워크플로에서 메타베이스의 위치

이를 염두에 두고, 일상 업무에 메타베이스를 포함하려는 가맹단체는 전제 조건과 결과를 신중하게 고려해야 합니다. 누가 플랫폼에 데이터를 기여해야 하고, 얼마나 자주 기여해야 하며, 메타베이스는 조직 수준에서 어떤 역할을 해야 합니까?

조직의 모든 사람이 메타베이스가 무엇이고 어떻게 사용할 수 있는지 이해하는 것이 유익할 수 있지만, 모든 사람이 메타베이스에 기여해야 할 필요는 없습니다. 결국, 조직의 모든 사람은 에티터톤을 운영하거나 재무 계획을 개발하는 것과 같은 역할과 책임이 있으며, 또 다른 보고 도구를 배울 필요 없이 최대한의 생산성으로 핵심 작업에 집중할 수 있어야 합니다. 사람마다 다릅니다. 어떤 사람은 링크드 데이터로 작업하는 것을 가장 편안하게 여기고, 어떤 사람은 위키에 기여하거나 텍스트 문서를 작성하는 것을 더 쉽게 여깁니다. 게다가 링크드 데이터에 익숙하지 않은 사람이 데이터 수집에 기여하면 데이터 품질이 크게 달라질 수 있습니다. 즉, 데이터 정리 및 검증에 더 많은 시간과 리소스를 투자해야 하며, 이는 비효율적이고 비용이 많이 듭니다.

데이터 입력을 전담하는 직원을 두는 것이 이 문제에 대한 해결책이 될 수 있습니다. 메타베이스에 카탈로그화해야 하는 많은 데이터와 지식 자료를 생성하는 대규모 지부는 이 작업을 위해 누군가를 고용할 수 있지만 생활비가 높은 지역에서는 재정적으로 현실적이지 않을 수 있습니다. 또는 직원이나 자원봉사자가 주제별 또는 지역 허브를 대신하여 여러 가맹단체에 메타베이스 기술을 서비스로 제공할 수 있습니다. 정기적으로 메타베이스에서 작업하면 구조와 모델링에 대한 좋은 개요를 얻을 수 있고 소스 간에 데이터 품질이 일관되도록 할 수 있습니다. 이는 가끔 기여하고 특정 전문 지식과 관련된 데이터만 사용하는 사람에게는 어려운 일입니다. 이러한 중앙 집중화된 구조와 책임을 통해 귀중한 데이터(예: 자원봉사자가 운영하는 이벤트에 대한 정보 또는 가맹단체 직원이 생성하지 않은 역량 강화 자료)가 간과될 위험이 줄어듭니다. 더욱이 이 사람은 메타베이스 사용자에게 SPARQL 쿼리를 개발하여 특정 데이터를 추출하고 분석하는 등 지침과 지원을 제공할 수 있으며, 교육 자료를 개발하고 컨퍼런스 및 기타 이벤트에서 플랫폼에 대한 지식을 전파할 수도 있습니다.

지속 가능성에 대한 문제도 있습니다. 과거 데이터를 입력하는 것은 일회성 프로젝트일 수 있지만, 일단 완료되면 얼마나 자주 업데이트해야 하는지 결정해야 합니다. WMSE에서는 협회 회원들에게 최신 정보를 제공하고 WMF, 파트너 및 기타 스폰서에게 결과를 보고할 때 아무것도 잊지 않도록 하기 위해 가능한 한 빨리 위키에 지표를 추가하는 것을 목표로 합니다. 하지만 동시에 메타베이스를 업데이트하면 어떤 이점이 있을까요? 물론 이는 플랫폼이 작업에서 어떤 역할을 하기를 원하는지에 따라 달라집니다. 일상적인 운영의 중요한 부분이 아니라 검색 가능한 지식 저장소에 불과하다면 주기적으로만 업데이트하는 것이 합리적일 수 있습니다. 모든 사람이 아닌 플랫폼에 익숙한 전담 직원이 해당 데이터 입력을 수행할 수 있습니다. 이렇게 하면 동료들의 정신적 업무 부담이 줄어들고 또 다른 보고 플랫폼을 배우도록 강요받지 않아도 됩니다.

결론적으로, 메타베이스를 적극적으로 사용하고 기여하고자 하는 제휴사는 시간과 리소스에 대한 필요한 투자에 대해 우려할 수 있지만, 단일 조직의 요구 사항을 줄일 수 있는 방법이 있습니다. 모든 직원은 메타베이스가 무엇인지에 대한 교육을 받고 관심이 생기면 기여하도록 권장받을 수 있지만, 대규모 투자가 필요하지 않은 데이터 입력에 대한 대안 솔루션이 있습니다. 메타베이스가 운동의 지식 허브가 되기를 원한다면, 가맹단체와 자원봉사자가 의존할 수 있는 데이터 입력 및 유지 관리를 위한 중앙 집중식 서비스를 구축하는 것이 합리적일 것입니다. 리소스가 부족한 소외 계층의 가맹단체로부터 투자를 요구하지 않고 말입니다.