추상 위키백과/업데이트/2023-03-15
| ◀ |  추상 위키백과 업데이트 
|
▶ |
|
쿼 바디스, 추상 위키백과?
추상 위키백과를 사용하면 더 많은 사람들이 자신의 언어로 된 인터페이스에서 작업하면서 지식의 기준선에 목소리를 낼 수 있습니다. 이렇게 공유된 지식 기준은 여러 언어로 제공될 것입니다. 이는 자연어와 독립적인 표기법으로 개별 문서별로 지식의 기준선을 생성, 저장 및 유지함으로써 달성됩니다. 이러한 표기법으로 작성된 콘텐츠를 "추상 콘텐츠"라고 합니다. 그런 다음 이 추상 콘텐츠는 위키함수의 함수 라이브러리의 도움을 받아 특정 자연 언어로 된 텍스트로 변환됩니다. 따라서 추상 위키백과는 모든 언어의 화자가 다양한 언어의 독자를 위해 콘텐츠를 제공할 수 있도록 합니다. 이렇게 하면 더 많은 사람들이 자신의 언어로 더 많은 콘텐츠를 읽을 수 있습니다.
예시
목성에 대한 새로운 위키백과 문서를 만들고 싶다고 가정하고 이 문서의 첫 번째 버전은 다음과 같아야 합니다(쉬운 영어 위키백과 문서의 처음 두 문장):
Jupiter is the largest planet in the Solar System. It is the fifth planet from the Sun.
이 자연 텍스트를 나타내는 추상 콘텐츠는 다음과 같습니다:
Article(
text: [
Superlative(
subject: Jupiter,
quality: large,
class: planet,
location constraint: Solar System),
Definition(
subject: Jupiter,
definition: Rank(
rank: Positive integer(
value: 5),
object: planet,
by: Relational noun(
noun: distance,
to: Sun)))],
categories: [Jupiter, planet, Solar System])
위키함수는 문서, 최상급, 정의, 순서, "등등"에 대한 유형을 가질 수 있으며 여기에서 이 두 문장의 내용에 대한 추상 표기법으로 사용됩니다. 이 추상 콘텐츠는 우리의 편의를 위해 여기에서 영어 레이블을 사용하여 표시되지만 실제로는 모두 ZID(위키함수에서) 및 QID(위키데이터에서)입니다. 추상 콘텐츠의 보기, 생성 및 편집을 제공하는 소프트웨어 구성 요소가 있습니다. 그런 다음 위키 함수는 이 객체를 인수로 사용하고 위와 같은 자연어 텍스트를 생성하는 함수도 제공합니다.
대답해야 할 한 가지 질문은 이러한 객체가 저장되는 위치와 위의 객체를 목성의 위키데이터 항목 Q319과 연결하는 방법입니다. 우리는 원래 위키함수를 출시하기 전에 이 대화와 결정을 할 계획이었지만, 시스템의 복잡성과 지금까지 유형이 거의 없기 때문에 상상하기가 매우 어렵다는 사실을 보고, 우리는 지금 이 질문을 논의하지 않기로 결정했습니다. 대신 생태계의 해당 부분이 어떻게 작동하는지 모두가 더 잘 이해할 수 있는 위키함수가 출시될 때까지 기다려야 합니다.
아래에서 추상 위키백과 팀과 위키미디어 독일의 위키데이터 팀 간의 토론에서 나온 몇 가지 옵션에 대해 설명합니다. 그것은 또한 리디아 핀처와 내가 오늘 공개된 위키무브 팟캐스트 에피소드에 대한 인터뷰에서 답변한 몇 가지 질문과 관련이 있으며 여러분을 초대합니다. 인터뷰에 응해주신 니콜 에버와 니키 제우너에게 감사드립니다!
우리는 최선의 대답에 대해 진정으로 결정하지 않았으며 옵션 및 잠재적으로 다른 옵션에 대한 더 광범위한 논의가 도움이 될 것입니다. 또한 질문을 하십시오. 이러한 질문은 종종 우리에게 모호한 점을 명확히 하고 빛을 비춰줄 수 있습니다. 현재 다음 다섯 가지 옵션에 초점을 맞추고 있습니다:
- 위키데이터의 항목에 대한 새 탭
- 위키데이터에서 객체에 대한 새 데이터 유형 생성
- 위키함수의 객체
- 새 위키백과 언어 버전의 객체
- 기존 프로젝트의 연결되지 않은 이름공간
아래에서 이 다섯 가지 옵션에 대해 논의해 보겠습니다.
옵션 1: 위키데이터 항목에 대한 새 탭
탭을 추가하여 추상 콘텐츠가 있는 새 콘텐츠 유형이 있는 위키데이터의 새 이름공간으로 이동할 수 있습니다. 이 이름공간은 위키데이터의 항목 이름공간에 연결됩니다. 이렇게 하면 모든 항목이 관련 추상 콘텐츠를 저장할 자연스러운 위치를 갖게 됩니다.
위키데이터에서 항목 토론 페이지를 거의 사용하지 않는다는 점을 감안할 때 추가 토론 페이지는 가치가 없을 수 있으므로 토론을 위해 사람들을 해당 항목의 기본 토론 페이지로 넘겨주기할 수 있습니다.
한 가지 중요한 질문은 동일한 항목에 대한 위키여행 및 기타 프로젝트의 콘텐츠를 저장할 위치입니다(예: 위키백과의 관점에서 Q90/Paris에 대해 작성하려는 추상 콘텐츠는 위키여행의 콘텐츠와 다를 수 있음). 또 다른 이름공간이 필요할까요? 새 관련 네이름공간을 추가하는 것은 기술적인 문제입니다. 여러 개를 추가하는 것은 복잡한 작업이 될 것이며 자주 발생하지 않기를 바랍니다.
옵션 2: 위키함수 객체에 대한 새 데이터 유형 만들기
위키함수 객체를 위해 위키데이터에 새로운 데이터 유형을 생성할 수 있습니다. 그런 다음 커뮤니티는 주어진 항목에 대한 추상 콘텐츠를 리터럴로 저장하는 속성을 위키데이터에 만들 수 있습니다. 이렇게 하면 커뮤니티가 특정 사용 사례를 위해 항목에 더 많은 추상 콘텐츠를 추가할 수 있는 유연성이 추가됩니다. 예를 들어 위키여행의 콘텐츠를 나타내거나 항목의 역사, 단어의 어원 등을 나타내기 위해.
추상 설명에 대한 계획된 지원을 고려할 때 이러한 데이터 유형과 그에 대한 UX가 필요합니다. 사실 이것은 추상적 설명을 지원하는 가장 간단한 방법일 수 있습니다.
그러나 위키데이터의 UX는 이에 쉽게 적합하지 않으며 항목 페이지의 제약 조건을 고려할 때 이 모델에 적응하는 것이 어려울 것입니다. 기존 속성은 종종 자동 완성 기능이 있는 하나 또는 소수의 단순하고 짧은 텍스트 상자로 편집됩니다. 대신 추상 콘텐츠는 도움말과 가능한 도구 모음, 미리 보기 컨트롤 등이 있는 더 큰 텍스트 영역이 됩니다. 한 가지 옵션은 원칙적으로 편집을 위한 모달 대화 상자일 수 있지만 고유한 UX 단점이 있으며 일반적으로 자체 전용 환경에서 동일한 기능을 구현하는 것보다 구현하기가 더 복잡합니다. 또한 이는 항목 페이지의 현재 디자인 패턴을 깨뜨리고 향후 계획된 패턴과 일치하지 않을 수 있습니다.
또한 추상 콘텐츠는 어느 정도 구조화되고 기계가 읽을 수 있지만 항목보다 적고(또는 다르게) 해당 구조는 SPARQL로 쿼리할 수 없습니다.
이 옵션에는 두 가지 추가 과제가 있습니다. 이미 최대 크기에 근접한 일부 위키데이터 항목은 더 커질 수 있으며 이를 허용하는 솔루션이 필요합니다. 둘째, 잠재적으로 매우 크고 복잡한 값의 시각화, 편집 및 diffing을 처리하는 방법입니다.
옵션 3: 위키함수의 객체
객체를 명령문의 값이나 추가 탭으로 위키데이터에 두는 대신 위키데이터는 단순히 객체에 대한 포인터를 위키함수에 저장할 수 있습니다. 여전히 새 데이터 유형을 생성하지만 해당 데이터 유형은 위키함수에 저장된 객체의 ZID일 뿐입니다.
이것은 이전 옵션의 모든 문제를 해결하고 많은 장점을 유지합니다.
여러 항목이 위키함수에서 동일한 객체를 참조할 수 있다는 추가 이점이 있습니다. 위키백과 문서의 추상적인 내용에는 거의 유용하지 않은 것처럼 들리지만 위키데이터 항목의 추상적인 설명과 어휘소의 추상적인 설명에는 매우 유용할 수 있습니다. 동일한 플랫폼에서 추상 콘텐츠, 유형 및 자연어 생성 기능을 생성하면 이러한 영역 중 하나에 집중하는 사람들 간의 협업이 보다 직접적일 것입니다.
이 옵션은 위키함수 커뮤니티에 도전이 될 수 있습니다. 범위는 기능뿐만 아니라 내용까지 포함하도록 확장됩니다. 이것은 소규모 커뮤니티를 어렵게 만들 수 있으며 위키데이터에서 이미 활동 중인 커뮤니티 점검자가 더 많이 필요합니다.
옵션 4: 새 위키백과 언어 버전의 객체
메인 이름공간이 추상 콘텐츠인 새로운 위키백과 언어 에디션을 출시할 수 있습니다. 이것은 예를 들어라고 할 수 있습니다. 다국어 위키백과(mul.wikipedia.org) 언어판 또는 추상적 위키백과 언어판(abstract.wikipedia.org). 다른 모든 언어 버전과 마찬가지로 페이지는 위키데이터의 사이트링크를 통해 항목에 연결됩니다.
위키여행에서 동일한 접근 방식을 사용하려면 설정을 복사하고 다국어 위키여행 에디션을 만들어야 합니다(또는 옵션 4B로 단일 공유 '추상' 콘텐츠 위키의 다른 이름공간일 수 있음).
이렇게 하면 위키백과 콘텐츠와 그렇지 않은 콘텐츠를 매우 명확하게 구분할 수 있으며 추상 콘텐츠에 뚜렷한 가시성이 부여됩니다. 그렇지 않으면 위키함수와 위키데이터 사이에 어느 정도 숨겨져 있을 것입니다. 다른 한편으로는 커뮤니티를 더욱 분열시키고 실제로는 위키백과가 아니지만 그렇게 레이블이 지정된 위키의 "새로운" 개념을 섞을 것입니다.
옵션 5: 기존 프로젝트에 첨부되지 않은 이름공간
위키백과의 추상 콘텐츠가 효과적으로 존재하는 기존 프로젝트에 새 이름공간을 도입할 수 있습니다. 가장 가능성이 높은 옵션은 다음과 같습니다:
- 위키데이터(항목에 첨부되지 않은 별도의 이름공간으로)
- 공용
- 메타
- 영어 위키백과(문서에 첨부되지 않음)
기술적으로 이러한 모든 옵션은 동일하지만 사회적 및 커뮤니티 관점에서는 매우 다릅니다. 더 가능성 있는 옵션이 되기 시작하지 않는 한 지금은 이러한 차이점에 대해 논의하지 않을 것입니다.
Rant: 하나의 위키미디어 운동입니까, 아니면 여러 프로젝트입니까?
콘웨이의 법칙에 따르면 소프트웨어는 조직을 반영합니다. 즉, 세 팀이 컴파일러 작업을 수행하면 3단계 컴파일러를 얻게 됩니다. 이전에 기욤 포미에가 관찰한 것처럼 그 반대도 마찬가지입니다: 소프트웨어 시스템은 시스템을 중심으로 진화하는 커뮤니티 구조를 결정합니다. 위키미디어 프로젝트 내에서 다양한 위키백과 언어 커뮤니티, 위키데이터 커뮤니티, 커먼즈 커뮤니티, 메타 등 간의 역학 관계에서 이러한 효과를 종종 볼 수 있습니다. 악용 방지 도구 또는 영어 위키백과의 짧은 설명으로 충분히 경고해야 합니다.
오늘 우리가 던지는 질문은 우리가 극복해야 할 진정한 기술적 과제가 있기 때문에 어려울 뿐만 아니라 절충해야 합니다. 또한 서로 다른 프로젝트 사이에 골절선이 있을 것으로 예상하고 이러한 골절선이 어떻게 형성될지 예상할 수 있기 때문에 훨씬 더 어렵습니다. 우리가 일반적으로 우리 자신을 하나의 공동 운동의 일부, 하나의 큰 공동체로 간주한다면 전체 이야기는 훨씬 더 쉬울 것입니다. 그러나 나는 우리가 위의 질문을 해결해야 하기 전에 이 궤적에서 많은 진전을 볼 수 있을지 의심스럽습니다.
그때까지 우리는 가능한 해결책과 그 효과에 대해서만 염두에 두고 있을 수 있으며, 우리가 원하는 세상이 아니라 있는 그대로의 세상과 앞으로 있을 가능성이 있는 세상을 위해 디자인하는 데 주의를 기울여야 합니다.
화요일 공개 NLG 워크스트림
3월 21일 화요일에 Jitsi에서 세 번째 공개 NLG 워크스트림 회의가 있습니다. 원하시면 사전에 저에게 연락해 프리젠테이션을 제안해 주세요. 우리는 이미 약간의 계획을 가지고 있지만 아직 공간이 있습니다. 회의 시간은 16:30-17:30 UTC로 미국 친구들에게는 1시간이 더 걸립니다.