추상 위키백과/구조
- 이것은 함수 위키 개발 계획의 일부입니다.
- 함수 위키에 대한 요구 사항에서 계속됩니다.
프로젝트의 주요 구성 요소는 다음 세 가지입니다:
- 생성자 – 생성자의 정의 및 해당 슬롯, 의미와 슬롯 유형 및 생성자의 반환 유형에 대한 제한 포함(예를 들어, 항목과 항목 유형, 숫자로 된 순위, 순위 지정 및 로컬 제약을 받는 생성자 순위(
rank)를 정의합니다.) - 콘텐츠 – 슬롯에 대한 필러를 포함하여 생성자에 대한 추상 호출(예를 들어
rank(SanFrancisco, city, 4, population, California)) - 렌더러 – 콘텐츠와 언어를 가져와 텍스트를 반환하는 함수로 콘텐츠의 의미를 나타내는 자연어가 됩니다.(예를 들어, 주어진 예시에서 "San Francisco is the fourth largest city by population in California."를 반환합니다)
세 가지 주요 구성 요소를 구현할 수 있는 네 가지 주요 가능성이 있습니다:
- 생성자와 콘텐츠 및 렌더러는 모두 위키데이터에서 구현됩니다.
- 생성자와 렌더러는 해당 항목 옆에 있는 위키함수 및 위키데이터의 콘텐츠에서 구현됩니다.
- 생성자와 콘텐츠 및 렌더러는 모두 위키함수로 구현됩니다.
- 생성자와 콘텐츠는 위키데이터에서 구현되고 렌더러는 위키백과 로컬 버전에서 구현됩니다.
해결안 4는 많은 함수를 서로 다른 언어간에 공유할 수 있다는 단점이 있으며 렌더러와 기능을 로컬 위키백과로 이동하면 그 가능성을 상실합니다. 또한 렌더러를 로컬 위키백과로 강등함으로써 독립적인 함수 카탈로그가 달성할 수 있는 잠재력을 놓칩니다.
렌더러를 포함한 새로운 형태의 지식 자산과 함수를 위해 새로운 프로젝트인 위키함수를 도입하는 것이 의사 소통과 공동체 구축에 유리하다고 생각합니다. 이것은 해결안 2와 3을 말합니다.
해결안 3에서는 함수 위키에서 가능한 모든 위키백과 문서에 대해 새로운 위치를 만들어야합니다. 이에 대한 자연스러운 장소가 이미 위키데이터의 항목과 함께 존재한다는 점을 감안할 때, 이를 사용하고 위키데이터의 항목과 함께 콘텐츠를 저장하는 것이 더 편리할 것입니다.
이러한 이유 때문에 우리는 해결안 2를 선호하고 나머지 제안에 대해 이를 가정합니다. 다른 것으로 전환하면 프로젝트 계획을 쉽게 수용할 수 있습니다 (대부분의 재작성이 필요한 해결안 4의 경우 제외). 해결안 2를 진행하려면 위키데이터 공동체의 동의가 필요합니다. 동의하지 않는 경우 해결안 3이 다음으로 가장 가까운 선택 사항일 수 있습니다.
다국어 위키백과를 위해 제안된 아키텍처는 다음과 같습니다. 위키백과는 항목 옆에 있는 위키데이터에 저장된 콘텐츠를 호출합니다. 이 확장을 위키데이터 추상 위키백과라고 합니다. 이것은 단지 개발 프로젝트의 이름일 뿐이며, 이 이름이 주변에 남아있을 것으로 예상되지는 않습니다. 그 이름으로 새로운 위키프로젝트는 없을 것입니다. 위키함수에서 렌더러를 호출하면 콘텐츠가 자연어 텍스트로 번역됩니다. 렌더러는 위키함수의 다른 함수와 유형 및 생성자에 의존합니다. 위키함수는 또한 콘텐츠를 텍스트로 번역하는 데 사용하기 위해 위키데이터의 어휘소에 있는 사전식 지식을 호출할 수 있습니다. 위키함수는 위키공용과 위키데이터 또는 위키문헌과 동등한 새로운 위키미디어 프로젝트가 될 것입니다.
(기울임 체로 명명된 구성 요소는 이 제안에 의해 추가될 예정이며 굵게 표시된 구성 요소는 이미 존재합니다. 최상위의 상자는 위키미디어 프로젝트이고 내부 상자는 주어진 위키미디어 프로젝트의 일부입니다.) ("위키람다"(Wikilambda)는 현재 "위키함수"(Wikifunctions)로 알려진 작업 이름이었습니다.)
- 함수 위키의 구성 요소에서 계속됩니다.