Wikimedia Meta-Wiki

추상 위키백과/계획

< Abstract Wikipedia
This page is a translated version of the page Abstract Wikipedia/Plan and the translation is 100% complete.
Other languages:

이것은 제외되는 개별 섹션의 한 페이지 버전입니다. 제목을 클릭하면 개별 페이지로 이동합니다.

요약

추상 위키백과에서 "추상 콘텐츠"는 공동체에서 직접 편집할 수 있는 언어 독립적 형식으로 표시됩니다. 로컬 위키백과는 "추상 콘텐츠"(추상 위키백과에서)를 사용하여 로컬에서 제어되는 자체 콘텐츠에 접근하고 강화할 수 있습니다. 이러한 방식으로 위키백과의 현지화된 버전은 독자들에게 훨씬 적은 노력으로 훨씬 더 많은 콘텐츠를 제공할 수 있으며, 대부분의 지역 위키백과가 제공할 수 있는 것보다 더 포괄적이고 최신이며 더 많은 검토를 거친 콘텐츠를 제공할 수 있습니다.

자연어 생성 분야의 연구 결과와 프로토 타입을 감안할 때, 언어 독립적인 "추상 콘텐츠"에서 자연어를 생성하려면 "튜링 완전"체계가 필요하다는 것은 안타깝게도 사실입니다. 그러나 위키백과가 다루어야하는 언어의 수를 다루기 위해서는 이 시스템이 크라우드 소싱되어야 합니다. 따라서 우리는 가능한 사용 사례가 많은 "함수"의 개방형 라이브러리(또는 저장소)를 생성하고 분류 및 유지 관리하는 프로젝트인 Wikifunctions을 소개합니다.

Wikifunctions의 주요 동기는 위키데이터(또는 위키낱말사전 또는 위키생물종과 같은 다른 위키미디어 프로젝트의 데이터를 포함하여 다른 적절한 공개 데이터 출처의 지식)에서 사용할 수 있는 언어 및 존재론적 지식을 사용하여 언어 독립적인 "추상 콘텐츠"를 자연어로 전환하는 "렌더러"(예를 들어, Wikifunctions에서 호스팅되거나 참조되는 일부 함수)를 개발하는 것입니다.

이 프로젝트는 Wikifunctions 프로젝트를 생성하는 것으로 시작하여 추상 위키백과를 생성하기 위해 이를 사용합니다. Wikifunctions는 첫해에 출시될 예정이며, 우리는 두 번째 해에 추상 위키백과의 개발을 추가할 것입니다. 2년 후, 우리는 언어 독립적인 "추상 콘텐츠"의 생성 및 유지 관리와 이 콘텐츠를 위키백과 내에서 통합할 수있는 생태계를 만들 것이며, 많은 개별 위키백과의 적용 범위와 통용성 및 정확성을 크게 증가시킬 것입니다. 이를 통해 모든 사람이 모든 지식을 공유할 수 있는 세상에 극적으로 가까워질 것입니다.


이름

모든 이름 - 추상 위키백과 및 위키람다 - 은 예비적이며 주로 이 제안서를 작성하고 논의하기위한 것입니다.

현재 이름은 다음 아이디어를 기반으로 합니다:

  • 추상 위키백과: 추상 위키백과의 내용은 구체적인 언어에서 추상화되었습니다.
  • 또한 "Wλ"는 의도했던 대중을 만나지 못하고 전문가에 의해서만 편견으로 관리되는 것으로 인식될 위험이 있는 일종의 기술 애호가("괴짜")처럼 보이며, 이미 자신의 문화에서 사용할 수 있는 가장 큰 지식에 대한 접근으로의 이점을 얻었습니다.

사실, "추상 위키백과"라는 이름은 붙지 않을 것입니다. 프로젝트가 완료되면 추상 위키백과는 위키데이터의 일부일 뿐입니다. 이것은 개발 작업의 이름일 뿐이므로 이름 지정은 그다지 중요하지 않습니다. 반면에 위키람다는 새로운 위키미디어 프로젝트가 될 것이므로 이름은 다소 높은 가시성을 가질 것입니다. 그것에 대한 좋은 이름을 생각해내는 것이 좋을 것입니다.

목적

지금까지 위키람다라는 이름에 반대하는 세 가지 이유가 있습니다:

  • 많은 사람들에게 철자를 쓰는 것은 정말 어렵습니다(Effeietsanders가 말함).
  • 어떤 사람들은 그것을 계속해서 위키람바다(Wikilambada)로 잘못 읽습니다(Jean-Frédéric가 말함).
  • 또한 WikiIambda / Wikiiambda (즉, l / L 대신 또 다른 i / I 사용)로 쉽게 잘못 읽히므로 적어도 대문자 L이 있는 위키람다(WikiLambda)여야 합니다(Fuzheado가 제안함).

제안된 대안

고려되거나 제안된 대체 이름:

이것은 아카이브입니다. 위키 기능 명명 콘테스트에서 새로운 이름을 제안해야합니다.

다른 제안도 환영합니다.

실제로 프로젝트의 첫 번째 작업 P1.1은 공동체와 함께 이름과 로고를 결정하는 것입니다. 이것은 이전 프로젝트(위키데이터의 로고, 위키여행의 이름)보다 우선했습니다.


목표

이 프로젝트에는 1차 및 2차의 야심찬 목표가 있습니다.

1차 목표

  • 더 많은 사람들이 자신이 선택한 언어로 더 많은 콘텐츠를 읽을 수 있도록 합니다.
  • 더 많은 사람들이 더 많은 독자를 위해 콘텐츠를 제공 할 수 있도록하여 잘 알려지지 않은 기여자의 도달 범위를 확대합니다.

2차 목표

2차 목표에는 다음이 포함되지만 이에 국한되지는 않습니다:

  • 재사용 가능하고 잘 테스트 된 자연어 생성.
  • 다른 위키미디어 공동체 및 외부 당사자가 더 많은 언어로 콘텐츠를 만들 수 있습니다.
  • 위키백과 프로젝트를 넘어서 커뮤니케이션 및 지식 접근성을 향상시킵니다.
  • 지식 표현에 대한 새롭고 훨씬 더 포괄적인 접근 방식 개발.
  • 자연어 이해의 결과를 나타내는 새로운 접근 방식을 개발합니다.
  • 함수 라이브러리.
  • 영어를 먼저 배우도록 요구하는 대신 사용자의 모국어로 기능을 개발하고 공유 할 수 있습니다.
  • 모든 사람 이 기능/함수를 공유하고 실행할 수 있습니다.
  • 관리 할 위키미디어 프로젝트를 위한 새로운 형태의 지식 자산을 소개합니다.
  • 대화형 기능을 허용하는 위키백과 및 기타 위키미디어 프로젝트에 새로운 구성 요소를 소개합니다.
  • 위키데이터의 지식 기반에서 작동하는 함수를 생성하여 추론을 추가하여 위키데이터 데이터의 범위를 상당히 늘립니다.
  • 코딩 인터페이스를 대중화하는 연구 및 개발을 촉진합니다.
  • 과학자와 분석가가 공동으로 모델을 공유하고 작업 할 수 있습니다.
  • 함수에 대한 사양 및 테스트를 공유합니다.
  • 잘 정의된 식별자를 통해 함수의 의미를 참조 할 수 있는 가능성.
  • 새로운 전용 위키에서 기능의 더 넓은 표준 라이브러리 (또는 저장소)에 접근하여 새로운 프로그래밍 언어를 더 빠르게 개발합니다.
  • 표준 및 기술 설명에 대한 알고리즘 및 접근 방식을 정의합니다.
  • 새로운 기계 학습 시스템에 통합되는 강력한 기능에 대한 접근을 제공합니다.

이 목록은 완전하지 않습니다.


조직

단일 호스팅 조직에 고용 된 핵심 팀이 위키함수 및 추상 위키백과에서만 독점적으로 작동한다고 가정합니다. 인적 자원과 법률 등과 같은 호스팅 조직의 다른 부서에서 지원합니다.

팀은 공개적으로 공개되고 코드베이스에 대한 외부 기여를 환영하도록 명시적으로 구축됩니다. 이들은 자원 봉사자이거나 유료 일 수 있습니다(예를 들어 운동 단체 또는 다른 조직 또는 회사에 대한 보조금을 통해). 우리는 그러한 야심적인 프로젝트에 필요한 건강한 자원 봉사자 커뮤니티를 만들 기회를 높이기 위해 자원 봉사자들에게 선호되는 치료를 제공하는 것을 목표로합니다.

프로젝트는 공개적으로 개발될 것입니다. 팀의 커뮤니케이션 채널은 가능한 한 공개됩니다. 커뮤니케이션 지침은 공개됩니다. 이것은 공개적으로 소통하고 코드베이스에 외부 기여를 통합할 수 있는 개발팀을 만드는 데 도움이 될 것입니다


요구 사항

다음의 강력한 요구 사항은 위키미디어 운동의 원칙과 관행을 기반으로합니다.

  1. 추상 위키백과와 위키함수는 위키미디어 프로젝트이고 위키미디어 재단에서 유지하고 운영합니다. 이것은 추상 위키백과와 위키함수가 위키미디어운동의 설립 원칙 및 지침을 따를 것을 요구합니다.
  2. 추상 위키백과와 위키함수를 실행하는 소프트웨어는 오픈 소스 라이선스에 따라 개발되며 오픈 소스 소프트웨어에만 의존합니다.
  3. 추상 위키백과와 위키함수에 대한 설정은 가능한 한 쉽게 현재 위키미디어 인프라에 통합되어야합니다. 이는 가능한 한 동일한 배포, 유지 관리 및 운영 인프라에 적합해야 함을 의미합니다.
  4. 추상 위키백과와 위키함수의 모든 콘텐츠는 무료 라이선스하에 제공됩니다.
  5. 추상 위키백과와 위키함수의 성공 여부는 건강한 커뮤니티의 생성과 이전에는 이 지식에 접근 할 수 없었던 언어로 얼마나 많은 지식을 사용할 수 있는지에 의해 측정됩니다.
  6. 추상 위키백과는 많은 개별 위키백과에서 정의한 원칙을 따릅니다: 특히 중립적 관점과 검증 가능성, 주목할만한 원본 연구 없음(공동체 역량 개발 및 각 로컬 위키의 커뮤니티에서 추가로 개발).
  7. 추상 위키백과와 위키함수는 완전히 국제화되고 위키미디어 프로젝트의 모든 언어로 사용 가능하고 편집 할 수 있습니다. 완전히 현지화되었는지 여부는 커뮤니티에 따라 다릅니다.
  8. 주요 목표는 로컬 위키백과와 위키데이터 및 기타 위키미디어 프로젝트를이 순서대로 지원하는 것입니다. 두 번째 목표는 우리 자신의 커뮤니티를 성장시키는 것입니다. 3차 목표는 나머지 세계를 지원하는 것입니다.
  9. 로컬 위키백과 커뮤니티는 추상 위키백과가 그들에게 영향을 미치는 정도를 통제해야합니다. 영향을 받고 싶지 않은 경우 완전히 무시할 수 있으며 변경 사항은 없습니다.

추상 위키백과의 개발자는 미디어위키의 개발자가 위키백과의 내용을 결정하지 않는 것처럼 추상 위키백과의 내용을 결정하지 않습니다. 다른 위키미디어 프로젝트와 달리 개발자는 초기 유형과 함수 집합을 설정하고 시작하며 추상 위키백과용 위키함수에서 필요한 기능을 만들고 언어 렌더러 커뮤니티 시작을 돕는 데 적극적으로 참여할 것입니다. 다른 프로젝트와 달리 추상 위키백과의 개발 팀과 위키함수는 원래 프로젝트에 더 많이 관여 할 것이지만 모든 것을 조만간 커뮤니티에 넘기는 것을 목표로 합니다.

다음 요구 사항은 추상 위키백과의 설계 및 개발에 적용되는 강력한 지침으로 사용됩니다:

  1. 추상 위키백과와 위키함수는 사회적 기술 시스템입니다. 지나치게 지능적이기보다는 위키미디어 커뮤니티에 의존합니다.
  2. 추상 위키백과와 위키함수의 첫 번째 목표는 위키백과에서 실제 사용 사례를 제공하는 것이지, 지식 표현에서 가상의 완벽 함을 가능하게하거나 모든 인간 언어를 표현하는 것이 아닙니다.
  3. 추상 위키백과와 위키함수는 사용의 용이성과 표현력의 균형을 유지해야합니다. 사용자 인터페이스는 몇 가지 예외적 인 경우를 다루기 위해 복잡해져서는 안됩니다.
  4. 예외적인 경우와 그렇지 않은 경우는 위키백과에 나타나는 빈도로 정의됩니다. 일화적인 증거 나 가상의 예 대신 위키백과를 분석하여 특정 사례가 얼마나 자주 발생하는지 살펴볼 것입니다.
  5. 실용적이 됩시다. 배포 된 것이 완벽한 것보다 낫습니다.
  6. 추상 위키백과와 위키함수는 외부 연구와 개발 및 사용 사례를 지원할 수 있는 많은 새로운 데이터를 제공합니다. 우리는 쉽게 사용할 수 있도록 하고 싶습니다.
  7. 위키함수는 정의 된 함수를 호출하기위한 API 인터페이스를 제공합니다. 그러나 제공할 계산 비용에는 제한이 있습니다.
  8. 추상 위키백과와 위키함수는 인간과 봇 모두가 편집 할 수 있습니다. 그러나 봇을 실행하는 사람들은 커뮤니티를 압도하지 않아야한다는 책임감을 인식해야합니다.


설계

프로젝트의 주요 구성 요소는 다음 세 가지입니다:

  1. 생성자 – 생성자의 정의 및 해당 슬롯, 의미와 슬롯 유형 및 생성자의 반환 유형에 대한 제한 포함(예를 들어, 항목과 항목 유형, 숫자로 된 순위, 순위 지정 및 로컬 제약을 받는 생성자 순위(rank)를 정의합니다.)
  2. 콘텐츠 – 슬롯에 대한 필러를 포함하여 생성자에 대한 추상 호출(예를 들어 rank(SanFrancisco, city, 4, population, California))
  3. 렌더러 – 콘텐츠와 언어를 가져와 텍스트를 반환하는 함수로 콘텐츠의 의미를 나타내는 자연어가 됩니다.(예를 들어, 주어진 예시에서 "San Francisco is the fourth largest city by population in California."를 반환합니다)

 

세 가지 주요 구성 요소를 구현할 수 있는 네 가지 주요 가능성이 있습니다:

  1. 생성자와 콘텐츠 및 렌더러는 모두 위키데이터에서 구현됩니다.
  2. 생성자와 렌더러는 해당 항목 옆에 있는 위키함수 및 위키데이터의 콘텐츠에서 구현됩니다.
  3. 생성자와 콘텐츠 및 렌더러는 모두 위키함수로 구현됩니다.
  4. 생성자와 콘텐츠는 위키데이터에서 구현되고 렌더러는 위키백과 로컬 버전에서 구현됩니다.

해결안 4는 많은 함수를 서로 다른 언어간에 공유할 수 있다는 단점이 있으며 렌더러와 기능을 로컬 위키백과로 이동하면 그 가능성을 상실합니다. 또한 렌더러를 로컬 위키백과로 강등함으로써 독립적인 함수 카탈로그가 달성할 수 있는 잠재력을 놓칩니다.

렌더러를 포함한 새로운 형태의 지식 자산과 함수를 위해 새로운 프로젝트인 위키함수를 도입하는 것이 의사 소통과 공동체 구축에 유리하다고 생각합니다. 이것은 해결안 2와 3을 말합니다.

해결안 3에서는 함수 위키에서 가능한 모든 위키백과 문서에 대해 새로운 위치를 만들어야합니다. 이에 대한 자연스러운 장소가 이미 위키데이터의 항목과 함께 존재한다는 점을 감안할 때, 이를 사용하고 위키데이터의 항목과 함께 콘텐츠를 저장하는 것이 더 편리할 것입니다.

이러한 이유 때문에 우리는 해결안 2를 선호하고 나머지 제안에 대해 이를 가정합니다. 다른 것으로 전환하면 프로젝트 계획을 쉽게 수용할 수 있습니다 (대부분의 재작성이 필요한 해결안 4의 경우 제외). 해결안 2를 진행하려면 위키데이터 공동체의 동의가 필요합니다. 동의하지 않는 경우 해결안 3이 다음으로 가장 가까운 선택 사항일 수 있습니다.

다국어 위키백과를 위해 제안된 아키텍처는 다음과 같습니다. 위키백과는 항목 옆에 있는 위키데이터에 저장된 콘텐츠를 호출합니다. 이 확장을 위키데이터 추상 위키백과라고 합니다. 이것은 단지 개발 프로젝트의 이름일 뿐이며, 이 이름이 주변에 남아있을 것으로 예상되지는 않습니다. 그 이름으로 새로운 위키프로젝트는 없을 것입니다. 위키함수에서 렌더러를 호출하면 콘텐츠가 자연어 텍스트로 번역됩니다. 렌더러는 위키함수의 다른 함수와 유형 및 생성자에 의존합니다. 위키함수는 또한 콘텐츠를 텍스트로 번역하는 데 사용하기 위해 위키데이터의 어휘소에 있는 사전식 지식을 호출할 수 있습니다. 위키함수는 위키공용과 위키데이터 또는 위키문헌과 동등한 새로운 위키미디어 프로젝트가 될 것입니다.

 

(기울임 체로 명명된 구성 요소는 이 제안에 의해 추가될 예정이며 굵게 표시된 구성 요소는 이미 존재합니다. 최상위의 상자는 위키미디어 프로젝트이고 내부 상자는 주어진 위키미디어 프로젝트의 일부입니다.) ("위키람다"(Wikilambda)는 현재 "위키함수"(Wikifunctions)로 알려진 작업 이름이었습니다.)


구성품

위키미디어 프로젝트를 세 곳으로 확장해야합니다:

  1. 제공되는 새로운 기능을 사용하는 위키백과 및 기타 클라이언트 프로젝트의 로컬 판에서
  2. 위키데이터에서 콘텐츠 생성(추상 위키백과), 그리고
  3. 새로운 프로젝트 위키함수에서는 함수 라이브러리를 만드는 것을 목표로 했습니다.

로컬 위키백과에 대한 확장

각 로컬 위키백과는 지역 공동체에 따라 다음 세 가지 선택 사항 중 하나를 선택할 수 있습니다:

  1. 추상 위키백과와의 내재적 통합;
  2. 추상 위키백과와의 명시적 통합;
  3. 추상 위키백과와 통합되지 않습니다.

로컬 위키백과의 확장에는 다음과 같은 기능이 있습니다: 하나의 새 특수 페이지, 두 개의 새 기능 및 세 개의 새로운 마법 단어입니다.

F1: 새로운 특수 페이지: Abstract

Q-ID 또는 로컬 문서 이름 및 선택적 언어(기본값은 로컬 위키백과의 언어)와 함께 사용되는 각 로컬 위키백과에서 새로운 특수 페이지를 사용할 수 있습니다. 특수 페이지 URL의 예는 다음과 같습니다:

https://en.wikipedia.org/wiki/Special:Abstract/Q62
https://en.wikipedia.org/wiki/Special:Abstract/Q62/de
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco/de

매개 변수없이 특수 페이지를 호출하면 Q-ID 및 언어(현지 언어로 미리 채워져 있음)를 선택할 수있는 양식이 표시됩니다.

특수 페이지에는 선택한 Q-ID 또는 선택한 언어로 렌더링된 각 문서에 사이트 링크된 Q-ID의 콘텐츠가 표시됩니다.

F2: 명시적인 문서 생성

로컬 위키백과가 명시적인 문서 생성을 통해 추상 위키백과와 통합하는 선택 사항을 선택한다면, 이것이 그들이 하는 방법입니다.

기여자는 아직 대상 로컬 위키백과에 사이트 링크가 없는 위키데이터의 항목으로 이동합니다. 아직 존재하지 않는 페이지에 사이트 링크를 추가합니다. 이런 식으로 문서의 이름을 지정합니다. 예를 들어 영어로 된 Q62에 아직 기사가 없어 사이트 링크도 없는 경우 en.wikipedia에 대한 사이트 링크 San_Francisco를 추가 할 수 있습니다.

로컬 위키백과에서 이것은 주요 이름공간에 가상 문서를 생성합니다. 해당 문서는 위에서 설명한 특별 페이지와 동일한 내용을 가지고 있지만 에를 들어 일반적인 URL에서 찾을 수 있습니다.

https://en.wikipedia.org/wiki/San_Francisco

새로 지정된 이름을 사용하는 해당 문서에 대한 링크는 다른 링크와 유사합니다. 즉, [[San Francisco]]에 대한 링크는 가상 문서, 파란색 등을 가리킵니다. 이러한 문서는 주어진 위키백과의 검색 및 외부 검색을 위해 색인화됩니다.

사용자가 문서 편집을 클릭하면 위키데이터로 이동하여 추상 콘텐츠(선호)를 편집하거나 처음부터 현지 언어로 새 문서를 시작하거나 현재 번역을 텍스트로 구체화하고 로컬에서 편집을 시작할 수 있습니다. .

사이트 링크가 있는 기존 로컬 문서가 삭제되면 가상 문서가 자동으로 생성됩니다(이름을 알고 링크를 유지할 수 있기 때문에).

가상 문서를 삭제하려면 위키데이터의 사이트 링크를 삭제해야합니다.

로컬 위키백과에 대한 모든 변경은 명시적으로 수행되어야하므로 이를 명시적 문서 생성 선택 사항이라고 합니다. 무조건적인 문서 생성 또는 통합 없음을 선택하지 않는 한 로컬 위키백과의 기본 옵션으로 설정합니다.

여기에서 통합에 대한 토론을 참조하세요.

F3: 무조건적인 문서 생성

로컬 위키백과가 위키데이터에서 무조건적인 문서 생성을 선택하면 주어진 위키데이터에 대한 사이트 링크가 없지만 주어진 언어로 콘텐츠를 렌더링하는 모든 위키데이터 항목에서 추상 특수 페이지를 호출 한 결과는 다음과 같이 인덱싱됩니다. 주요 이름 공간에 있었고 주요 이름 공간에 있는 것처럼 검색에서 사용할 수있게 되었습니다

일반 문서에서 가상 문서로 연결하는 새로운 매직 워드가 도입되었습니다. F6 LINK_TO_Q을 참조하세요. 이것은 시각 편집기에 보이지 않게 통합 될 수 있습니다.

이것은 공동체가 많은 문서를 얻는 데 최소한의 작업이며 소규모 공동체에 좋은 선택 사항이 될 수 있습니다.

F4: 링크 또는 탭

위키데이터 항목에 연결된 로컬 위키백과의 모든 문서는 상단의 탭 또는 사이드 바의 링크로 새 링크를 받습니다. 해당 링크는 로컬 언어로 렌더링되어 연결된 위키데이터 항목에 대한 콘텐츠를 표시합니다. 가상 문서에는 이 탭이 없지만 편집 버튼은 추상 위키백과의 콘텐츠 편집으로 직접 연결됩니다.

F5: 새로운 매직 워드: ABSTRACT_WIKIPEDIA

매직 워드는 사이트 링크를 통해 이 페이지에 연결된 위키데이터 항목의 콘텐츠를 렌더링한 결과 위키 텍스트로 대체됩니다

매직 워드는 두 개의 선택적 매개 변수와 함께 사용할 수 있습니다. 하나는 Q-ID이고 다른 하나는 언어입니다. Q-ID가 제공되지 않으면 Q-ID는 기본적으로 이 페이지가 사이트 링크별로 연결된 항목으로 설정됩니다. 언어가 제공되지 않으면 해당 언어는 기본적으로 주어진 위키의 언어로 설정됩니다

예제 호출:

{{ABSTRACT_WIKIPEDIA}}
{{ABSTRACT_WIKIPEDIA:Q62}}
{{ABSTRACT_WIKIPEDIA:Q62/de}}

기본적으로 Q-ID가 제공되거나 선택되지 않으면 오류 메시지가 나타납니다.

나중에 콘텐츠에서 명명된 섹션을 선택할 수 있습니다.

추상 위키백과에 통합하지 않기로 선택한 위키백과는 여전히 이 새로운 매직 워드를 사용할 수 있습니다.

새로운 매직 워드의 도입은 예비적인 계획입니다. 작업 2.3이 그렇게하지 않고도 기능을 달성 할 수 있는지 조사 할 것입니다.

F6: 새 매직 워드: LINK_TO_Q

이 매직 워드는 주어진 Q-ID에 사이트 링크 된 로컬 문서에 대한 링크 또는 존재하지 않는 경우 주어진 Q-ID가 있는 추상 특수 페이지에 대한 링크로 바뀝니다. 이를 통해 가상 문서에 대한 링크가 있는 문서를 작성할 수 있으며, 로컬 콘텐츠가 생성되면 자동으로 대체됩니다.

예제 호출:

{{LINK_TO_Q:Q62}}

결과적으로

[[San Francisco]]

문서가 존재하면

[[Special:Abstract/Q62|San Francisco]]

새로운 매직 워드의 도입은 예비적인 계획입니다. 작업 2.3이 그렇게하지 않고도 기능을 달성 할 수 있는지 조사 할 것입니다.

F7: 새 매직 워드: LAMBDA

이는 매개 변수와 함께 위키데이터에 지정된 함수를 호출하고 페이지에 출력을 렌더링합니다.

예를 들어, 다음 호출:

{{LAMBDA:capitalize("san francisco")}}

그러면 페이지에 "San Francisco"가 출력됩니다(로컬 키가 있고 예상되는 정의와 구현이 있는 함수가 있다고 가정). 호출을 구문 분석하기 위해 로컬 위키의 언어를 사용합니다.

다운스트림 중단을 줄이기 위해 특정 버전의 함수를 호출하는 옵션도 고려하세요.

새로운 매직 워드의 도입은 예비적인 계획입니다. 작업 2.3이 그렇게하지 않고도 기능을 달성 할 수 있는지 조사 할 것입니다.

위키데이터 확장

위키데이터의 주요 이름공간에 새로운 보조 이름공간을 추가합니다. 즉 www.wikidata.org/wiki/Q62 양식의 모든 항목 페이지에는 www.wikidata.org/wiki/Content:Q62 콘텐츠 페이지도 함께 제공됩니다. 이 페이지에는 언어독립적인 추상 콘텐츠가 포함되어 있으며 편집과 유지 관리가 가능합니다.

추가 특수 페이지가 필요할 수 있습니다. 이것은 프로젝트의 두 번째 부분에서 확장될 것입니다. 프로젝트가 추상 콘텐츠를 저장하는 데 사용될 것이라는 위키데이터 공동체의 동의가 필요하며 동의하지 않을 경우 다른 프로젝트가 선택됩니다.

F8: 새 이름공간: Content

복잡한 대화형 편집 기능이 많은 새로운 이름공간. 콘텐츠를 생성하고 유지하기 위한 사용자 경험(UX)와 콘텐츠를 평가하는 기능(예를 들어, 언어별로 표시되는 콘텐츠의 양 표시 등)을 제공합니다. 이것은 대부분 F11 Function 이름공간 기능의 하위 집합입니다.

F9: 새 데이터 유형: Content

(짧은) 콘텐츠를 포함하는 새 데이터 유형입니다. 주요 사용 사례는 항목 설명과 어휘소 의미의 용어에 대한 것입니다.

F10: 항목의 색인 및 사용, 의미의 용어

항목과 의미에 대한 주석에 관한 설명 필드의 선형화를 인덱싱하고 표면화하며 항목의 설명 필드에 중복 된 레이블/설명 짝이 없는지 확인합니다. 수동 편집으로 이 두 가지를 모두 덮어 쓸 수 있습니다.

다른 위키미디어 프로젝트에 대한 확장

다른 위키미디어 프로젝트도 F7 LAMBDA과 F5 ABSTRACT_WIKIPEDIA 매직 워드를 받지만 다른 기능은 제공되지 않습니다. 특별히 유용하지 않은 것 같습니다. 이는 해당 공동체의 요청에 따라 변경 될 수 있습니다.

새로운 함수 위키를 위한 확장

위키함수는 새 도메인에서 새로운 위키미디어 프로젝트가 될 것입니다. 위키함수의 주요 이름공간은 새로운 Function 이름공간이 될 것입니다. 나머지 위키 기능은 전통적인 위키미디어 위키가 될 것입니다.

F11: 새 이름공간: Function

함수와 유형, 인터페이스, 값, 테스트 등의 저장을 허용합니다. 상수(유형 또는 단일 값과 같은), 함수 인터페이스, 함수 구현 및 생성자와 렌더러를 포함하는 단일 이름공간이 있습니다. 이 이름공간의 개체는 위키데이터 항목의 Q-ID와 비슷하게 Z-ID로 이름이 지정되지만 Z로 시작하고 뒤에 숫자가 옵니다.

Z 이름공간에는 다양한 유형의 개체가 있습니다. 여기에는 유형 및 기타 상수(기본적으로 0의 함수)뿐만 아니라 양수인 고전 함수도 포함됩니다.

기여자는 Function 이름공간 안에서 새로운 유형의 함수를 만든 다음 이를 사용할 수 있습니다.

함수는 인수를 가질 수 있습니다. 인수가 주어진 함수는 실행될 수 있으며 함수 정의에 의해 유형이 지정된 값이 됩니다.

Function 이름공간은 복잡하고 함수 유형에 따라 아주 다른 뷰를 갖습니다. 즉, 인터페이스와 구현, 테스트, 유형, 값 등에 대해 내부적으로는 모두 다른 UX가 있습니다. Z-객체로 저장됩니다. 결국 다른 뷰는 모두 위키함수에서 함수에 의해 생성됩니다.

Function 이름공간에서 개체를 고정 및 해제 할 수 있습니다. 이것은 보호된 페이지와 유사하지만 레이블과 설명 등이 아닌 개체 값 부분의 편집만 제한합니다.

F12: 새 특수 페이지 및 API 모듈

새로운 Function 이름공간을 지원하기 위해 새로운 특수 페이지 및 API 모듈이 생성됩니다. 여기에는 특히 지정된 함수 매개 변수로 함수를 평가할 수있는 특수 페이지와 API 모듈이 포함됩니다. 그 외에도 콘텐츠의 유지 관리를 지원하는 수많은 특수 페이지 및 API(예를 들어, 매개 변수의 수와 유형, 통계가 있는 페이지, 특정 구현이 호출되는 빈도, 테스트 페이지 등의 검색과 같은)가 포함됩니다. 목표는 이러한 내부 위키함수를 가능한 한 많이 구현하는 것입니다.


과제

개발은 두 가지 주요 부분으로 이루어집니다. 파트 P1은 위키 기능을 시작하고 실행하는 것에 관한 것이며 파트 P2에 필요한 콘텐츠 생성을 지원할 수 있도록 충분히 개발되었습니다. 파트 P2는 위키데이터 내에서 콘텐츠 생성을 설정하고 위키백과가 해당 콘텐츠에 접근하도록 허용하는 것입니다. 그 후 위키함수와 추상 위키백과를 모두 개선하기 위한 지속적인 개발이 있을 것입니다. 이 지속적인 개발은 이 계획에 포함되지 않습니다. 모든 타이밍은 우리가 실제로 작업하는 인원 수에 따라 다릅니다.

첫해에는 파트 P1에서만 작업 할 것입니다. 파트 P2는 두 번째 해부터 시작하여 프로젝트에 추가 인원을 추가합니다. 파트 P1과 P2는 향후 18개월 동안 병렬로 개발됩니다. 프로젝트의 결과와 성공 여부에 따라 추가 개발 인력은 약 24개월에 결정되고 이후 정기적으로 재평가되어야합니다.

이 계획은 개발 초기 30개월에 적용됩니다. 그 이후의 주요 결과물은 다음과 같습니다:

  1. 새로운 WMF 프로젝트 겸 위키인 위키함수는 자체의 공동체 그리고 자체 사명과 함께 함수 카탈로그를 제공하고, 모든 사람이 해당 카탈로그에서 공유 할 수 있도록하여 컴퓨팅 지식에 대한 접근을 민주화함으로써 사람들에게 권한을 부여하는 것을 목표로합니다.
  2. WMF 프로젝트 사이에 틀과 모듈을 공유하기위한 교차 위키 저장소. 이는 공동체의 오랜 소망입니다. 이것은 위키함수의 일부가 될 것입니다.
  3. 추상 위키백과는 자연어와 독립적으로 위키데이터의 콘텐츠를 정의할 수 있는 교차 위키 프로젝트로, 여러 지역 위키백과 에 통합되어 현재 서비스가 부족한 언어의 지식 사용자가 공유 할 수 있는 양을 상당히 늘립니다.

<span id="_Part_P1:_Wikifunctions">

파트 P1: 위키함수

<span id="_Task_P1.1:_Project_initialization">

과제 P1.1: 프로젝트 초기화

우리는 메타와 버그 구성 요소, 메일링 리스트, 채팅방, 자문 게시판 및 더 넓은 커뮤니티와의 기타 관련 토론 수단에 위키페이지를 구축할 것입니다. 토론을 시작하고 위키함수 및 추상 위키백과의 이름을 결정하고 로고 콘테스트를 개최하고 행동 강령 생성과 건강한 커뮤니티에 필요한 단계를 구성합니다.

또한 프로젝트의 다른 부분에 대한 라이선스 선택을 정의하는 공동체 절차를 시작해야합니다: 위키데이터의 추상 콘텐츠와 위키함수의 함수 및 기타 개체, 위키백과에 표시될 생성된 텍스트의 법적 상태. 이것은 과제 P1.9 이전에 완료되어야합니다. 이 결정은 법률 고문의 의견이 필요합니다.

<span id="_Task_P1.2:_Initial_development">

과제 P1.2: 초기 개발

첫 번째 개발 단계는 Z-객체의 저장 및 편집을 허용하는 함수 이름공간을 사용하여 위키함수 위키를 만드는 것입니다(더 제한된 JSON 객체 - 실제로 기존 JSON 확장으로 시작하여 빌드할 수 있음). 초기 이정표의 목표는 다음과 같습니다:

  • 초기 유형: 유니코드 문자열, N까지의 양의 정수, 불리언, 목록, 쌍, 언어, 단일어 텍스트, 다국어 텍스트, 유형, 함수, 내장 구현 및 오류.
  • 유형에 대한 초기 상수 집합입니다.
  • 초기 함수 집합: if, head, tail, is_zero, successor, predecessor, abstract, reify, equal_string, nand, 생성자, 아마도 몇 가지 더 많은 함수, 각각 내장 구현이 있습니다.

이를 통해 함수 호출을 위한 프런트 엔드 UX 개발을 시작하고 다양한 유형의 Z객체뿐만 아니라 제너릭 Z객체도 표시하는 첫 번째 도구 및 인터페이스 세트를 만들 수 있습니다. 여기에는 위키미디어 서버에서 실행되는 첫 번째 평가자가 포함됩니다.

뷰, 편집 인터페이스 및 유효성 검사기의 초기 구현은 모두 내부화되면 P1.12 이후 점차적으로 폐기될 가능성이 있습니다. 일부 코드를 내부화한다는 것은 코어에서 멀어지고 사용자 영역으로 이동하는 것을 의미합니다. 즉, 위키함수에서 코드를 다시 구현하고 거기에서 호출하는 것입니다.

<span id="_Task_P1.3:_Set_up_testing_infrastructure">

과제 P1.3: 테스트 인프라 설정

위키함수에는 여러 테스트 시스템이 필요합니다. 하나는 코어를 테스트하기위한 것이고, 하나는 웹 UI를 테스트하기위한 것이고, 다른 하나는 위키함수 콘텐츠 자체를 테스트하기위한 것입니다. 이것은 지속적인 작업이며 버전 제어와 통합되어야합니다.

<span id="_Task_P1.4:_Launch_public_test_system">

과제 P1.4: 공개 테스트 시스템 시작

우리는 코드의 최첨단을 실행하는 공개적으로 표시되고 편집 가능한 테스트 시스템을 설정할 것입니다 (영업일당 최소 1회 배포). 우리는 공동체가 들어 와서 물건을 부수도록 초대 할 것입니다. 지속적인 통합 테스트에도 이 시스템을 사용할 수 있습니다

<span id="_Task_P1.5:_Server-based_evaluator">

과제 P1.5: 서버 기반 평가자

초기 개발에서는 내장된 기능으로 만 작동하는 간단한 평가자를 만들었으므로 매우 예측 가능한 동작을 가지고 있지만 다가오는 P1.6 함수 구성 작업에서는 평가자를 다시 생각해야합니다. 첫 번째 평가자는 위키미디어 인프라에서 실행되며 모니터링 및 조절 기능이 필요하며 로그인 여부에 따라 사용자에게 다른 양의 컴퓨팅 리소스를 할당 할 수있는 가능성도 필요합니다.

<span id="_Task_P1.6:_Function_composition">

과제 P1.6: 함수 컴포지션

함수 호출로 구성된 새로운 함수 인터페이스와 새로운 유형의 구현을 만들 수 있습니다. 예를 들어, 그것은 구현할 수 있습니다

add(x, y)

를 다음과 같이 하면

if(is_zero(y), x, add(successor(x), predecessor(y))

시스템은 이것을 실행할 수 있습니다. 또한 여러 구현이 가능합니다.

<span id="_Task_P1.7:_Freeze_and_thaw_entities">

과제 P1.7: 개체 고정 및 해동

개체의 메타 데이터(이름, 설명 등)를 편집할 수 있지만 실제 값은 편집 할 수 없는 보호 수준입니다. 이 기능은 위키데이터에도 유용할 수 있습니다. 여기에서 보다 정교한 버전 관리 제안이 제안됩니다.

<span id="_Task_P1.8:_Launch_beta_Wikifunctions">

과제 P1.8: 베타 위키함수 출시

베타 시스템은 테스트 목적으로 다음 배포 주기와 함께 위키함수로 이동할 코드의 다음 반복을 실행합니다.

<span id="_Task_P1.9:_Launch_Wikifunctions">

과제 P1.9: 위키함수 출시

보안 검토를 통과하세요. 새 위키미디어 프로젝트를 구축하세요. 일부 위키 페이지를 메타에서 위키함수로 이동합니다.

<span id="_Task_P1.10:_Test_type">

과제 P1.10: 테스트 유형

함수 테스트 작성을 위한 새로운 유형을 소개합니다. 이것은 입력 값과 출력을 확인하는 함수를 지정하여 수행됩니다. 테스트 유형을 도입하는 것 외에도 기능 및 구현은 테스트를 사용하고 구현 개발 및 인터페이스 보기에 통합해야 합니다.

<span id="_Task_P1.11:_Special_page_to_write_function_calls">

과제 P1.11: 함수 호출을 작성하는 특수 페이지

기본 구문 검사, 자동 완성, 문서 등을 사용하여 함수 호출 작성을 허용하고 지원하는 새로운 특수 페이지가 필요합니다.이 기능의 하위 집합은 개별 함수 및 구현 페이지에 통합되어 더 복잡한 값으로 실행됩니다. 이 특별 페이지는 초기 간단한 API를 사용하여 함수 호출을 평가합니다.

<span id="_Task_P1.12:_JavaScript-based_implementations">

과제 P1.12: 자바 스크립트 기반 구현

우리는 자바 스크립트로 작성된 구현인 새로운 유형의 구현을 허용합니다. 이를 위해서는 값을 자바 스크립트로 변환하고 다시 Z-객체로 변환해야합니다. 또한 처음에는 수동 검토 및 P1.7 동결로 강화된 코드 분석 및 샌드 박싱을 통해 보안에 대해 생각해야합니다. O1 람다 미적분이 아직 성공하지 못했거나 건너 뛴 경우이 작업을 통해 위키함수에 대한 자체 호스팅에 도달 할 수도 있습니다. 이렇게 하면 대부분의 코드를 내부화 할 수 있습니다.

<span id="_Task_P1.13:_Access_functions">

과제 P1.13: 접근 함수

위키 함수에 대한 함수 호출을 인코딩하고 주어진 위키미디어 프로젝트의 출력에 결과를 통합 할 수 있는 위키미디어 프로젝트에 F7 람다 매직 워드를 추가합니다. 사실 이것은 사람들이 위키함수에서 틀을 다시 구현한 다음 로컬 위키에서 호출 할 수 있다는 것을 사람들이 인식함에 따라 중앙 집중식 틀 시스템을 만들 것입니다. 이는 TemplateData 및 루아 호출과 같은 기존 솔루션에 대한 분석이 선행됩니다.

이것은 공동체부터 미디어위키 틀 언어와 루아(P1.15 참조)를 위키함수 내에서 프로그래밍 언어로 사용하도록 요청하는 것으로 이어질 수 있습니다. 이것은 위키데이터가 한 것과 유사한 개선된 위치리스트 솔루션에 대한 요청과 미디어위키 틀 기반 구현 및 공동체의 기타 요청으로 이어질 것입니다. 이러한 작업을 수행하기 위해 추가 사람이 공동체의 요청에 응답하는 데 도움이 될 수 있습니다. 그렇지 않으면 P2가 최대 1/4 후에 시작될 수 있습니다. 이 사람은 이미 위의 개발 팀에 등록되어 있습니다.

<span id="_Task_P1.14:_Create_new_types">

과제 P1.14: 새로운 유형 생성

우리는 새로운 유형의 생성을 허용합니다. 이것은 우리가 새로운 유형 정의를 편집하고 생성 할 수 있어야하며, 모든 코드를 내부화하여 위키함수 내에서 유형의 값을 처리 할 수 있어야 함을 의미합니다. 즉 값의 유효성을 검사하고, 구성하고, 여러 환경에서 시각화하는 등의 코드가 필요합니다. 또한 모든 기존 유형에 대해 이러한 값을 내부화해야합니다.

<span id="_Task_P1.15:_Lua-based_implementations">

과제 P1.15: 루아 기반 구현

구현을 위해 지원되는 프로그래밍 언어로 루아를 추가합니다. 루아의 중요성은 미디어위키 프로젝트에서 광범위하게 사용되기 때문입니다. 또한 아직 발생하지 않은 경우 위키함수에서 프로그래밍 언어로의 값 변환이 이 시점에서 내부화되어야합니다(그리고 이 시점에서 내장 기능을 사용할 가능성이 있는 자바 스크립트 구현에 대해서도 수행됨).

<span id="_Task_P1.16:_Non-functional_interfaces">

과제 P1.16: 비 함수 인터페이스

위키함수는 순전히 기능적인 구현을 기반으로 구축되는 반면, 난수와 현재 시간, 자동 증가 또는 많은 REST 호출과 같이 단순하게 작동하지 않는 인터페이스가 있습니다. 이를 위키함수와 통합하는 방법을 알아볼 것입니다.

<span id="_Task_P1.17:_REST_calls">

과제 P1.17: REST 호출

웹에서 REST 인터페이스를 호출하고 결과를 수집하는 내장 기능을 제공합니다. 이것은 바람직하게는 P1.16에 의존합니다. 임의의 REST 인터페이스를 호출하면 보안 문제가 있습니다. 적절한 설계에서 이를 고려해야 합니다.

<span id="_Task_P1.18:_Accessing_Wikidata_and_other_WMF_projects">

과제 P1.18: 위키데이터 및 기타 WMF 프로젝트에 접근

우리는 위키데이터 항목 및 어휘소, 위키미디어 프로젝트의 기타 콘텐츠에 접근하는 함수를 제공합니다. 이것은 P1.17에 의존하는 것이 바람직하지만 아직 성공하지 못한 경우 내장 기능이 이 기능을 차단 해제합니다.

<span id="_Task_P1.19:_Monolingual_generation">

과제 P1.19: 단일언어 생성

이러한 함수의 개발은 전적으로 위키에서 이루어집니다. 여기에는 명사와 동사, 명사구 등과 같은 문법적 개체를 나타내는 테이블 및 레코드와 함께 작동하는 함수가 포함됩니다. 여기에는 필요에 따라 조응을 생성할 수 있도록 컨텍스트 구현이 포함됩니다. 이것은 즉 아직 추상이 아닌 자연어의 구체적인 생성이 가능하게합니다.

<span id="_Part_P2:_Abstract_Wikipedia">

파트 P2: 추상 위키백과

이 파트의 과제는 개발 1년 후에 시작됩니다. 파트 P1의 모든 작업이 파트 P2가 시작되기 전에 완료 될 것으로 예상되는 것은 아닙니다. 실제로 파트 P1과 P2는 계속해서 병렬로 개발 될 것입니다. P2를 시작하려면 P1 파트의 일부 작업만 필요합니다.

<span id="_Task_P2.1:_Constructors_and_Renderers">

과제 P2.1: 생성자 및 렌더러

여기서는 P1.19에서 개발된 구체적인 생성자에 대한 추상 인터페이스를 소개합니다. 이것은 생성자 및 렌더 함수의 초기 개발로 이어집니다. 이 작업 후에 공동체는 새 생성자를 만들고 렌더러를 확장하여 지원할 수 있어야합니다.

  • 생성자는 추상 콘텐츠의 표기에 사용됩니다. 생성자는 언어에 독립적이며 조건부 논리를 포함해서는 안됩니다.
  • 렌더러는 실제 조건 논리(생성자의 정보에 적용됨)를 보유해야합니다. 렌더러는 언어별로 있을 수 있지만 여러 언어로 공유 할 수도 있습니다.
  • 둘 사이의 분리는 문법적 프레임 워크와 같은 다른 NLG 시스템의 분리와 유사합니다.

<span id="_Task_P2.2:_Conditional_rendering">

과제 P2.2: 조건부 렌더링

렌더러가 콘텐츠를 완전히 렌더링할 수있는 경우는 거의 없습니다. 단계적인 저하를 지원해야합니다. 일부 콘텐츠는 렌더링에 실패했지만 다른 콘텐츠는 여전히 렌더링되는 경우 렌더링된 해당 부분을 표시해야합니다. 그러나 때로는 다른 콘텐츠가 확실히 렌더링될 경우에만 특정 콘텐츠를 렌더링해야하는 경우가 있습니다. 이 작업에서는 이러한 조건부 렌더링에 대한 지원을 구현하여 소규모 공동체가 위키백과를 안전하게 성장시킬 수 있도록 합니다.

<span id="_Task_P2.3:_Abstract_Wikipedia">

과제 P2.3: 추상 위키백과

위키데이터에서 새 이름공간을 생성하고 콘텐츠가 생성되고 유지 될 수 있도록 합니다. UI 요소를 재사용하고 콘텐츠 생성에 맞게 조정합니다. UI 작업은 파트 P2 출시 이전에 시작할 수 있는 디자인 연구 작업이 선행됩니다. 이 디자인에 대한 몇 가지 중요한 생각이 여기에 있습니다. 이 작업은 또한 새로운 매직 워드(F5, F6 및 F7)가 필요한지 또는 도입을 피할 수 있는지 여부를 결정합니다.

<span id="_Task_P2.4:_Mobile_UI">

과제 P2.4: 모바일 UI

콘텐츠의 생성 및 편집은 다국어 위키백과 생성에서 가장 빈번한 작업입니다. 따라서 우리는 이 작업이 즐겁고 접근 가능한 사용자 경험을 갖기를 원합니다. 모바일 인터페이스에서 콘텐츠 생성 및 유지 관리를 지원하기 위해 명시적인 작업을 할애하고자합니다. 위키 텍스트를 편집하는 것보다 더 나은 경험을 제공하는 인터페이스를 만들 수 있다고 가정합니다.

<span id="_Task_P2.5:_Integrate_content_into_the_Wikipedias">

과제 P2.5: 콘텐츠를 위키백과에 통합

추상 위키백과 매직 워드를 활성화합니다. 그런 다음 명시적인 문서 생성을 허용하고 마지막으로 묵시적인 문서 생성을 허용합니다(F1, F2, F3, F4, F5, F6).

<span id="_Task_P2.6:_Regular_inflection">

과제 P2.6: 규칙 활용

위키데이터의 어휘소에는 변형된 형태의 어휘소가 포함되어 있습니다. 이러한 양식은 종종 규칙적입니다. 우리는 위키함수를 통해 규칙 활용을 생성하는 솔루션을 만들고 이를 기존 어휘소와 통합하는 방법을 공동체와 논의할 것입니다.

<span id="_Task_P2.7:_Basic_Renderer_for_English">

과제 P2.7: 영어용 기본 렌더러

렌더러의 초기 생성이 어려울 것이라고 가정합니다. 영어가 공동체에서 널리 사용되는 언어라는 점을 감안할 때 영어를 첫 번째 언어로 사용하여 렌더러 생성을 시연하고 이를 잘 문서화 할 것입니다. 우리는 공동체의 도움을 통합할 것입니다. 여기에는 참조를 표시하는 기능도 포함됩니다.

<span id="_Task_P2.8:_Basic_Renderer_for_a_second_language">

과제 P2.8: 제2 언어용 기본 렌더러

공동체 피드백과 관심사 및 팀에서 작업하는 언어 전문가의 전문 지식을 기반으로 공동체와 함께 기본 렌더러를 만들 두 번째 큰 언어를 선택합니다. 지역 위키백과의 공동체가 이미 추상 위키백과 통합에 대한 관심을 확인한 언어를 선택하는 것은 흥미로울 것입니다.

<span id="_Task_P2.9:_Renderer_for_a_language_from_another_family">

과제 P2.9: 다른 어족 언어에 대한 렌더러

P2.8의 언어는 인도유럽어족일 가능성이 높으므로 다른 언어 계열의 언어에 대한 공동체와 함께 기본 렌더러를 만들 것입니다. 이 언어의 선택은 팀에서 사용할 수있는 전문 지식과 공동체의 관심사에 따라 이루어집니다. 지역 위키백과의 공동체가 이미 추상 위키백과 통합에 대한 관심을 확인한 언어를 선택하는 것은 흥미로울 것입니다

<span id="_Task_P2.10:_Renderer_for_an_underserved_language">

과제 P2.10: 서비스가 부족한 언어를 위한 렌더러

P2.8 및 P2.9의 언어는 이미 활발하고 대규모 위키백과 공동체에서 잘 제공되는 언어일 가능성이 높으므로 현재 잠재 독자가 많은 언어인 서비스가 부족한 언어도 선택할 것입니다. 작은 공동체와 콘텐츠가 거의 없습니다. 이 언어의 선택은 팀에서 사용할 수있는 전문 지식과 공동체의 관심사에 따라 이루어집니다. 여기에서 지역 위키백과 공동체가 이미 추상 위키백과를 통합하기 위해 지원을 약속한 언어를 선택하는 것이 중요합니다.

<span id="_Task_P2.11:_Abstract_Wikidata_Descriptions">

과제 P2.11: 추상 위키데이터 설명

위키데이터 설명은 특히 위키함수를 통해 만들어지기 쉬운 것 같습니다. 그들은 종종 짧은 명사구입니다. 이 작업에서는 위키데이터에서 추상적인 설명의 저장 및 유지 관리와 위키데이터 생성을 지원합니다. 또한 이 결과가 레이블과 설명의 고유한 조합으로 이어지도록 해야합니다.

자세한 내용과 토론은 추상 위키백과/업데이트/2021-07-29를 참조하십시오.

<span id="_Task_P2.12:_Abstract_Glosses">

과제 P2.12: 추상적 주해

위키데이터 어휘소에는 의미가 있습니다. 의미는 주해로 포착됩니다. 주해는 언어별로 제공되므로 일반적으로 몇 가지 언어로만 제공됩니다. 진정한 다국어 사전을 지원하기 위해 추상적 주해를 만들 것을 제안합니다. 이것이 본격적인 위키백과 문서를 만드는 것보다 훨씬 쉬울 것 같지만 주해의 특성으로 인해 이것이 훨씬 더 어려운 작업일 수 있다고 생각합니다.

<span id="_Task_P2.13:_Support_more_natural_languages">

과제 P2.13: 더 많은 자연어 지원

렌더러 생성시 다른 언어 공동체를 지원하고 서비스가 부족한 언어에 중점을 둡니다.

<span id="_Task_P2.14:_Template-generated_content">

과제 P2.14: 틀 생성 콘텐츠

일부 위키백과에는 현재 많은 틀 생성 콘텐츠가 포함되어 있습니다. 이 콘텐츠를 식별하고 위키함수에 기반한 솔루션으로 대체할지 여부를 로컬 위키백과와 논의하세요. 여기서 틀은 위키함수에 있고 콘텐츠는 로컬 위키백과 또는 추상 위키백과에 있습니다. 이는 한 명의 기여자에게 의존할 필요가 없는 보다 지속 가능하고 유지 가능한 솔루션으로 이어질 것입니다. 다국어일 필요는 없으며 전체 추상화를 수행하는 것보다 훨씬 간단 할 수 있습니다.

<span id="_Task_P2.15:_Casual_comments">

과제 P2.15: 격식이 없는 의견

일반 기여자가 렌더링된 텍스트에 주석을 달고 해당 주석을 캡처하는 메커니즘을 만들고 이를 콘텐츠 또는 렌더러로 보낼 수있는 분류 메커니즘으로 다시 보낼 수 있도록 합니다. 평범한 기여자의 댓글을 잃지 않는 것이 중요합니다. 이상적으로는 렌더링된 출력의 일부를 명시적으로 덮어 쓰고 이를 변경 요청으로 간주 할 수 있도록 허용한 다음, 일반 기여자의 의도를 시스템의 해당 변경 사항으로 변환하는 작업에 더 관여하는 기여자가 참여하게 됩니다.

<span id="_Task_P2.16:_Quick_article_name_generation">

과제 P2.16: 빠른 문서명 생성

일반 대중은 대부분 자신의 언어로 찾고 있는 항목의 이름을 일반 검색 엔진에 입력하여 위키백과를 찾습니다. 즉, 묵시적인 문서 생성을 사용하려면 위키데이터 항목이 언어로 번역된 레이블이 필요합니다. 이것은 아마도 수백만 개의 위키데이터 레이블을 번역하여 달성 할 수 있습니다. 때로는 봇이나 AI에 의해 수행 될 수 있지만 이는 완전히 신뢰할 수 있고 확장 가능하지 않으므로 사람이 참여해야합니다.

위키데이터 레이블의 대규모 크라우드 소싱 번역을 위한 현재 도구는 작업에 적합하지 않습니다. 이를 수행하는 두 가지 주요 방법이 있습니다. 위키데이터 자체에서 레이블을 편집하는 것은 아마도 수십 개의 레이블을 추가하는 것은 좋지만 금방 피곤 해지는 것입니다. 그리고 태버내클(Tabernacle)을 사용하는 것은 대량 일괄 번역을 지향하는 것처럼 보이지만 너무 복잡합니다. 실제로 대부분의 사람들에게 사용합니다.

이 작업은 많은 사람들이 사용할 수있는 쉽고 현대적인 프런트 엔드를 사용하여 대규모 통합 레이블 번역 도구를 개발하는 것입니다.

<span id="_Non-core_tasks">

비 핵심 과제

추가 선택적 작업의 전체 집합이 있습니다. 이상적으로는 외부 공동체에서 선택하여 초기 개발 팀 외부에서 오픈 소스로 개발할 수 있지만 일부는 킥스타트해야하고 핵심 팀에서 완전히 개발해야 할 수도 있습니다.

<span id="_Task_O1:_Lambda_calculus">

과제 O1: 람다 대수

위키함수에서 람다 대수를 구현하여 다른 프로그래밍 언어의 내장 또는 구현에 의존하지 않고 위키함수를 완전히 자체 호스팅할 수 있습니다(이름 제안이 유래 된 곳입니다). 이는 언어 지원없이 평가를 허용하고 평가자의 개발을 더 쉽게 시작할 수 있도록 하는 데 도움이 될 수 있습니다.

<span id="_Task_O2:_CLI_in_a_terminal">

과제 O2: 터미널의 CLI

많은 개발자가 명령 라인 인터페이스를 사용하여 위키함수와 같은 시스템에 접근하는 것을 즐깁니다. 자동 완성과 히스토리, 셸 통합 등과 같은 일반적인 기능을 제공해야합니다.

<span id="_Task_O3:_UIs_for_creating,_debugging_and_tracing_functions">

과제 O3: 함수 생성과 디버깅 및 추적을 위한 UI

위키함수의 목표는 위키함수에서 함수를 빠르게 이해하고 개발할 수 있도록 하는 것입니다. 기능적 접근 방식을 감안할 때 함수 호출의 부분 평가, 전개, 디버깅 및 추적을 허용하는 사용자 경험을 생성할 수 있어야합니다.

<span id="_Task_O4:_Improve_evaluator_efficiency">

과제 O4: 평가자 효율성 향상

평가자의 효율성을 개선하여 리소스 사용, 특히 캐싱 또는 평가 전략의 적절한 선택을 줄이는 방법에는 여러 가지가 있습니다. 일반적으로 평가자를 위해 그렇게하는 데 시간을 할애하고 결과를 기록하여 다른 평가자가 이 지식을 사용할 수 있도록해야 하지만 핵심 팀에서 유지 관리하는 평가자가 대부분의 모범 사례를 사용하도록해야합니다.

<span id="_Task_O5:_Web_of_Trust_for_implementations">

과제 O5: 구현을 위한 트러스트 웹(Web of Trust)

프로그래밍 언어의 구현 조건을 완화하기 위해 기여자가 기존 구현을 검토하고 승인을 명시적으로 표시하고 다른 기여자를 신뢰할 수있는 것으로 표시 할 수있는 트러스트 웹 기반 솔루션을 도입할 수 있습니다. 그런 다음 평가 전략을 선택하거나 준비 할 때 이러한 승인을 고려할 수 있습니다.

<span id="_Task_O6:_Python-based_implementations">

과제 O6: 파이썬 기반 구현

파이썬은 특히 학습자 및 기계 학습과 같은 일부 도메인에서 널리 사용되는 프로그래밍 언어입니다. 파이썬을 지원하면 위키함수에 풍부한 생태계를 열 수 있습니다.

<span id="_Task_O7:_Implementations_in_other_languages">

과제 O7: 다른 언어로 구현

우리는 다른 프로그래밍 언어 공동체를 호출하여 위키함수에 통합하고 지원하기 위해 노력할 것입니다. 구현 후보는 웹 어셈블리(Web Assembler), PHP, Rust, C/C++, R, Swift, Go 등이지만 이러한 인터페이스를 만들고 지원하는 것은 핵심 팀과 외부 공동체의 관심에 달려 있습니다.

<span id="_Task_O8:_Web-based_REPL">

과제 O8: 웹 기반 REPL

웹 기반 REPL은 때때로 불가능한 로컬 환경에 CLI를 설치할 필요없이 O2 명령 라인 인터페이스의 이점을 웹으로 가져올 수 있습니다.

<span id="_Task_O9:_Extend_API_with_Parser_and_Linearizer">

과제 O9: 파서 및 선형화기로 API 확장

위키함수를 사용하는 다른 파서와 선형화기가 있을 수 있습니다. 호출자가 수동으로 래핑하는 대신 명시적으로 선택할 수있는 경우 위키함수 API를 사용하기가 더 쉬울 수 있습니다. 이렇게 하면 표면적인 방언이 다른 위키함수를 사용할 수 있습니다.

<span id="_Task_O10:_Support_talk_pages">

과제 O10: 토론 페이지 지원

위키함수의 토론 페이지에 대한 토론을 지원하기 위해 (초기에) 간단한 토론을 허용하는 메커니즘을 개발하고 통합하고 공동체의 필요에 따라 복잡성을 천천히 증가시킵니다.

<span id="_Task_O11:_Legal_text_creation">

과제 O11: 법률적 텍스트 생성

위키함수의 흥미로운 응용 프로그램은 다른 크리에이티브 커먼즈 라이선스에 대한 설명 수준이 다르듯이 모듈 방식과 다른 수준 (법률적이거나 사람이 읽을 수있는 수준)으로 법적 텍스트를 생성하는 것입니다.

<span id="_Task_O12:_Health_related_text_creation">

과제 O12: 건강 관련 텍스트 작성

위키함수의 흥미로운 응용 프로그램은 다양한 읽기 수준에 대한 건강 관련 텍스트를 만드는 것입니다. 이것은 위키함수와의 협력을 통해 더 많은 사람들에게 도달할 수 있는 위키 프로젝트 의료와 그들의 성공적인 작업에 의해 주도되어야합니다.

<span id="_Task_O13:_NPM_library">

과제 O13: NPM 라이브러리

자바 스크립트 프로그램에서 위키함수의 함수를 간단하게 사용할 수있는 NPM용 위키데이터 라이브러리를 만들 것입니다. 위키함수의 자바 스크립트 구현이 다른 위키함수에 접근할 수 있도록 동일한 구문을 사용해야합니다. 위키함수 평가자를 호출하거나 필요한 함수를 주어진 코드베이스로 컴파일하여 수행할 수 있습니다.

<span id="_Task_O14:_Python_library">

과제 O14: 파이썬 라이브러리

파이썬 스크립트에서 위키함수의 함수를 간단하게 사용할 수있는 파이썬 라이브러리를 만들 것입니다. 위키함수의 파이썬 구현이 다른 위키함수 함수에 접근할 수 있도록 동일한 구문을 사용해야합니다. 위키함수 평가자를 호출하거나 필요한 함수를 주어진 코드베이스로 컴파일하여 수행할 수 있습니다.

<span id="_Task_O15:_Libraries_for_other_programming_languages">

과제 O15: 다른 프로그래밍 언어용 라이브러리

우리는 그들의 언어로 된 프로그램에서 위키함수 함수를 간단하게 호출 할 수있는 라이브러리를 만드는 데 도움을 주기 위해 여러 프로그래밍 언어의 공동체를 호출 할 것입니다. 위키함수 평가자를 호출하거나 필요한 함수를 주어진 코드베이스로 컴파일하여 수행할 수 있습니다.

<span id="_Task_O16:_Browser-based_evaluator">

과제 O16: 브라우저 기반 평가자

위키데이터의 장점 중 하나는 함수 호출의 실제 평가가 다른 평가자에서 발생할 수 있다는 것입니다. 추상 위키백과의 주 평가자는 서버 기반이며 위키미디어 재단에서 실행하지만 컴퓨팅 부하를 줄이기 위해 사용자의 클라이언트(아마도 작업자 스레드에서)에서 실행되는 평가자를 제공해야합니다.

<span id="_Task_O17:_Jupyter-_and/or_PAWS-based_evaluator">

과제 O17: 주피터 또는 PAWS-기반 평가자

한 가지 흥미로운 평가자는 주피터(Jupyter) 또는 PAWS 노트북을 사용하여 이러한 노트북의 일반적인 이점을 허용하지만 위키함수의 이점도 통합합니다.

<span id="_Task_O18:_App-based_evaluator">

과제 O18: 앱 기반 평가자

평가자는 안드로이드 또는 iOS 장치에서 기본적으로 실행되어야하며 따라서 사용자가 상당한 컴퓨팅 성능을 손에 사용할 수 있도록해야합니다.

<span id="_Task_O19:_P2P-based_evaluator">

과제 O19: P2P 기반 평가자

많은 평가자가 서로 연결되어 네트워크에서 휴면 컴퓨팅 리소스를 사용하도록 허용 할 수 있습니다. 이것은 개별 컴퓨팅의 프라이버시를 보장하는 참여 노드 사이에 보호막이 필요할 수도 있고 필요하지 않을 수도 있습니다.

<span id="_Task_O20:_Cloud-based_evaluator">

과제 O20: 클라우드 기반 평가자

컴퓨팅 리소스를 얻을 수 있는 한 가지 분명한 곳은 클라우드 공급자를 사용하는 것입니다. 클라우드 기반 인프라에서 서버 기반 평가자를 간단하게 실행할 수있는 반면, 클라우드 제공 업체는 보다 맞춤화 된 평가자에게 더 얇은 인터페이스를 제공하는 것이 유리할 것입니다.

<span id="_Task_O21:_Stream_type">

과제 O21: 스트리밍 유형

입력 및 출력 모두 스트리밍 데이터 유형에 대한 지원을 추가합니다. 스트림 유형은 예를 들어 위키미디어 위키의 최근 변경 사항 스트리밍을 의미합니다.

<span id="_Task_O22:_Binary_type">

과제 O22: 바이너리 유형

입력 및 출력 모두에 대해 바이너리 파일에 대한 지원을 추가합니다.

<span id="_Task_O23:_Integration_with_Commons_media_files">

과제 O23: 공용 미디어 파일과 통합

공용의 파일에 직접 접근할 수 있습니다. 현재 필요한 것보다 적은 배포 기계가 필요한 공용으로 워크 플로를 활성화합니다. O22가 필요합니다.

<span id="_Task_O24:_Integrate_with_Machine_Learning">

과제 O24: 머신 러닝과 통합

머신 러닝 솔루션과의 몇 가지 통합 예제를 개발하세요. NLP 작업 또는 이미지 또는 비디오 작업. 예를 들어, 분류자를 사용하여. 이를 위해서는 모델을 저장하는 방법과 위치, 가능하면 모델을 교육하는 방법 및 모델에 접근하는 방법이 필요합니다.

<span id="_Task_O25:_Integrate_into_IDEs">

과제 O25: IDE에 통합

IDE를 개발하는 커뮤니티에 연락하여 유형 힌트와 문서화, 완성 및 최신 IDE의 기타 편리하고 중요한 기능을 사용하여 위키함수와 통합할 수 있도록 지원합니다.

<span id="_Task_O26:_Create_simple_apps_or_Websites">

과제 O26: 간단한 앱 또는 웹사이트 만들기

위키함수에 의존하는 앱 또는 웹사이트를 쉽게 만들고 배포 할 수 있는 시스템을 개발합니다.

<span id="_Task_O27:_Display_open_tasks_for_contributors">

과제 O27: 기여자를 위한 미결 작업 표시

추상 위키백과는 모든 언어의 모든 생성자에 대해 하나의 렌더러가 필요합니다. 기여자가 렌더러가 다음에 구현할 지침을 얻을 수 있다면 도움이 될 것입니다. 이는 종종 사소하게 보이지 않기 때문입니다. 생성자가 얼마나 자주 나타나는지 계산하는 것이 첫 번째 근사치가 될 수 있지만 일부 생성자가 리드 또는 다른 텍스트가 나타나지 않도록 차단하는 텍스트의 일부 또는 다른 텍스트보다 더 많이 읽는 문서에서 더 자주 사용되는 경우 이 근사치 꺼져 있을 수 있습니다. 이 작업에서는 사용자가 언어 (스포츠, 지리, 역사 등과 같은 도메인 및 예상되는 렌더러의 복잡성에 대한 필터)를 선택할 수 있는 대시 보드 형식을 만든 다음 구현이 미칠 영향에 따라 순위가 매겨진 렌더링되지 않은 생성자 목록이 있습니다.

또한 기여자가 대시 보드에 필요한 동일한 프레임 워크를 기반으로 자신이 얼마나 많은 영향을 받았는지(보기 및 생성된 콘텐츠 측면에서) 알려주는 정기적인 메시지에 등록 할 수 있습니다.

이는 TranslateWiki.Net에서 다른 프로젝트의 번역 상태(선택 가능한 언어) 또는 주석 속에서 주제와 조직 또는 저자에 대한 견해를 보는 것과 비슷합니다. 각 프로젝트에 대해 번역된 문자열의 %와 업데이트가 필요한 %를 표시하며 자원 봉사 번역자가 선택할 수 있습니다: 98%에서 100%까지, 40%에서 60%까지, 0%에서 10%까지 등을 얻을 수 있습니다.

<span id="_Task_O28:_Active_view">

과제 O28: 활동 보기

렌더된 콘텐츠의 기본 보기는 정적 텍스트와 매우 비슷하지만 렌더러 누락으로 인해 렌더링에 실패한 기존 콘텐츠를 기반으로 기여를 초대하는보다 활성적인 보기도 있어야합니다. 가장 간단한 경우는 위키데이터에서 어휘소를 만들고 올바른 어휘소에 연결하는 것입니다. 렌더러를 작성하거나 예제 문장을 텍스트로 제공 할 수 있는 보다 복잡한 경우에는 P2.15에 설명된 격식이 없는 기여 경로를 사용할 수 있습니다. 이는 더 많은 독자를 기여자로 전환할 수있는 흥미로운 창구를 제공합니다.

활성 보기를 사용하는 방법과 위치, 기본 보기인지 여부 또는 초대 후에만 켜야하는지 여부 등에 대한 제품 및 디자인 결정이 있습니다. 기여자가 문서에서 이동할 수 있는 모드도 있을 수 있습니다. O27의 추상적인 방식과 유사하게 누락된 부분을 문서화하고 작성합니다.

모바일 장치에서도 작동하도록 유도하는 적극적인 방법과 기여 경로를 확인하는 것이 정말 유용 할 것입니다.

<span id="_Task_O29:_Implementation_compilation">

과제 O29: 구현 컴파일

구현에 사용되는 함수 구성은 다양한 대상 프로그래밍 언어, 특히 웹 어셈블러 및 자바 스크립트에서 다소 높은 수준의 함수에 대한 고성능 컴파일을 생성 할 수 있어야합니다. 이렇게하면 평가 속도가 몇 배 빨라집니다.

<span id="_Task_O30:_Integrate_with_Code_examples_on_Wikipedia,_Wikibooks,_etc.">

과제 O30: 위키백과와 위키책 등의 코드 예제와 통합합니다.

위키백과, 위키책 및 기타 프로젝트가 코드 예제를 함수위키와 직접 통합하여 라이브로 실행할 수 있도록합니다.


구현 단계

추상 위키백과의 개발은 각각 많은 수의 과제로 구성된 두 가지 주요 부분으로 진행됩니다. 파트 P1은 함수위키 개발에 관한 것이고 파트 P2는 추상적인 내용과 자연어 생성에 관한 것입니다. 이 페이지에서는 파트 P1의 작업을 각각 주어진 작업의 일부 작업을 다루는 단계로 세분화합니다. 아래에는 작업과 단계가 더욱 세분화 된 파브리케이터에 대한 링크가 포함되어 있습니다.

이 위키 페이지는 오래되었을 수 있습니다. 작업에 대한 정보의 표준 위치는 파브리케이터입니다. 파브리케이터에서 현재 상태를 찾으세요.

함수 위키를 시작하기 전에 약 10단계가 걸릴 것으로 예상됩니다.

아래의 모든 단계는 달리 표시되지 않는 한, 과제 P1.2: 초기 개발에 따른 작업을 다룹니다.


파트 P1: 함수의 위키

Main article: 추상 위키백과/과제 — § 파트 P1: 위키함수

알파(α) 단계: 저장 및 표시, 헤더 편집 —   완료 2020-08-25

  1. 복제 가능한 개발 환경 구축합니다. — 작업 T258893
    •   완료 확장을 시작하세요. — 작업 T258893
    •   완료 구성이 작동하고 부트 스트랩 콘텐츠를 업로드합니다.
    •   완료 기존 JSON ContentHandler를 재사용합니다. — 작업 T258893
    •   완료 원시 편집 인터페이스를 통해 JSON 객체를 입력할 수 있습니다. — 작업 T258893
  2.   완료 JSON 객체의 검사기를 확장하고 하드 코딩하여 Z객체의 형식이 올바른지 확인합니다. 제대로 구성되지 않은 것은 더 이상 처리되거나 저장되지 않습니다. 올바른 형식은 아마도 PHP와 JS 코드에서 확인되어야합니다 (어쨌든 작성하기 쉬울 것입니다).
    •   완료 PHP에서. — 작업 T258894
    • 잘 만들어진 형식: 키 구문과 허용되는 키, 값은 문자열 또는 프로토 객체 또는 값 목록입니다. — 작업 T258894
  3.   완료 저장된 모든 최상위 Z객체는 Z2/영구 객체여야합니다. — 작업 T258897
  4.   완료 하나의 키를 제공하는 Z1/객체 생성. Z1K1/유형.
  5.   완료 Z1K1/유형을 확인하는 하드 코딩된 검증자 확장.
  6.   완료 Z2/영구 객체 생성. — 작업 T258897
  7.   완료 Z2/영구 객체에는 Z2K1/ID 및 Z2K2/값 키와 Z2K3/프로토-레이블 키가 있으며 후자는 언어 정보가 없는 단일 문자열입니다. — 작업 T258897
  8.   완료 지금까지 Z2/영구 객체에 대한 하드 코딩된 검증자를 확장합니다. — 작업 T258897
  9.   완료 Z2/영구 객체(즉, 헤더)에 대해 하드 코딩된 디스플레이를 제공합니다(아주 큰 과제). — 작업 T258898
  10.   완료 Z2K2/값 객체에 대한 일반 보기를 제공합니다. — 작업 T258898
  11.   완료 Z2K3/프로토-레이블을 다국어 텍스트에 적합한 Z2K3/레이블로 전환합니다.
  12.   완료 다국어 텍스트로 Z2K3/레이블 보기를 확장합니다.

단계 완료 조건: [미디어위키 확장이 설치된 사이트의] 사용자로서 새로운 Z객체로 문자열을 생성하고 저장할 수 있습니다. "e.g." "Hello world!".

베타(β) 단계: 유형 및 인스턴스 생성 —   완료 2021-02-04

  1.   완료 Z4/프로토-유형 및 Z3/프로토 키에 대한 하드 코드된 검증자. — 작업 T258900
    • Z4에는 Z3의 json 리스트가 있는 Z4K2/키가 있습니다.
    • 프로토-키에는 Z3K1/ID 및 Z3K2/유형, Z3K3/레이블이 있습니다(Z2K3용 레이블 개발을 반영하시겠습니까?).
  2.   완료 Z4/유형 및 Z3/키(과제 P1.14)를 만듭니다.
  3.   완료 레이블로 Z객체를 검색합니다. — 작업 T260750
  4.   이 단계에서 완료 객체의 유효성을 검사하기 위해 Z4 유형 데이터 및 키 선언을 사용합니다. — 작업 T260861
  5.   완료 객체의 일반보기에 Z4 유형 데이터 및 키 선언을 사용합니다. — 작업 T258901
  6.   완료 객체 편집 및 생성에 Z4 유형 데이터 및 키 선언을 사용합니다. — 작업 T258903 & 작업 T258904
  7.   완료 Z12 유형에 대한 하드 코딩 된 디스플레이 및 편집 인터페이스를 제공합니다. — 작업 T258900

단계 완료 조건: 사용자는 위키에서 정의된 모든 유형(예를 들어, 양의 정수)을 구현하는 객체를 만들고 저장할 수 있습니다.

감마(γ) 단계: 함수, 구현, 오류 —   완료 2021-04-02

  1.   완료 간단한 오류 객체를 소개합니다. — 작업 T261464
  2.   완료 간단한 함수를 소개합니다. — 작업 T258957
  3.   완료 지금은 내장 기능만 있는 간단한 구현을 소개합니다. — 작업 T258958
  4.   완료 몇 가지 함수와 내장 함수를 만듭니다. — 작업 T261474
  5.   완료 간단한 함수 호출 유형을 소개합니다. — 작업 T261467
  6.   완료 테스터 유형 (과제 P1.10). — 작업 T261465

단계 완료 조건: 사용자로서 함수 호출과 함수 및 테스터(객체 만, 아직 실제 평가 없음)를 저장할 수 있습니다. 예를 들어, if(true, false, true) ("참이면 거짓, 그렇지 않으면 참"으로 읽으면, "즉" 부정)

델타(δ) 단계: 내장 기능 —   완료 2021-05-11

  1.   완료 빌트인 평가 시스템. — 작업 T260321
  2.   완료 웹 사용자가 API 모듈(과제 P1.5)를 통해 평가를 호출 할 수 있습니다. — 작업 T261475
  3.   완료 평가 호출을 위한 특별 페이지입니다(과제 P1.11). — 작업 T261471

단계 완료 조건: 사용자는 특수 페이지를 사용하여 제공된 입력이 있는 내장 함수를 평가할 수 있습니다. 예를 들어, 빈 목록이 비어 있는지 확인합니다.

엡실론(ε) 단계: 네이티브 함수 호출 —   완료 2021-06-30

  1.   완료 자바 스크립트 구현 (과제 P1.12). — 작업 T275944
  2.   완료 파이썬 구현 (과제 O6). — 작업 T273517
  3.   완료 평가를 위해 양식을 포함 할 수 있습니다. — 작업 T261472

단계 완료 조건: 사용자는 특수 페이지를 사용하여 지원되는 언어 중 하나로 사용자가 작성한 함수를 평가할 수 있습니다. "예를 들어" 파이썬에서 사용자 작성 함수를 호출하여 두 숫자를 더할 수 있습니다.

제타(ζ) 단계: 컴포지션 —   완료 2021-08-27

  1.   완료 컴포지션 구현 허용 (과제 P1.6). — 작업 T261468

단계 완료 조건:

  • 사용자는 직접 작성하는 것이 아니라 다른 함수를 조합하여 함수를 구현할 수 있습니다. 예를 들어, negate(Boolean → Boolean). —   완료
  • (스트레치 조건) 사용자는 해당 기능 구현 페이지에서 테스터의 결과를 볼 수 있습니다. [이 시점에서 모든 요구 사항이 충족되지 않을 수 있으므로 이후 단계로 이동해야 할 수도 있습니다. 요타(ι) 단계에 의해 수행되어야합니다] —   완료

에타(η) 단계: 제너릭 유형 —   완료 2022-04-08

  1.   완료 특히 Z10/리스트 및 Z8/함수에 대한 제너릭 유형을 허용하고 Z10/리스트 및 Z8/함수를 대체합니다. ― 작업 T275941
  2.   완료 오류는 Z객체처럼 처리될 수 있습니다.
  3.   완료 사용자 정의 유형은 유효성 검사기와 함께 작동합니다.

단계 완료 조건:

  • curry를 위키에서 컴포지션으로 구현할 수 있지만 엄격한 정적 분석이 필요하지 않음 —   완료
  • 위키에서 다음 세 가지 '사용자 정의' 유형 생성 가능: positive integer, sign 그리고 integer —   완료
  • 위키에서 작성을 통해 일반 감싸기(래퍼) 유형을 만들 수 있음 —   완료

해당 단계에 대한 이 업데이트도 참조하세요.

세타(θ) 단계: 해동 및 동결 —   완료 2023-06-19

  1.   완료 콘텐츠 동결 및 해동 (과제 P1.7). ― 작업 T275942
  2.   완료 과제 P1.9: 보안 검토를 통과. — 작업 T274682, …
  3.   완료 공개 테스트 시스템 시작 (과제 P1.4). — 작업 T261469

단계 완료 조건:

  • 시스템 관리자로서 사용자가 작성한 모든 객체를 동결 및 동결 해제할 수 있습니다(미디어위키의 보호 시스템과 유사하거나 동일할 수도 있음). 모든 시스템 제공 객체는 영구적으로 동결됩니다.
  • 동결된 페이지를 편집하는 사용자는 레이블을 변경할 수 있지만 구현은 변경할 수 없지만 동결해제된 페이지에서는 둘 다 가능합니다.
  • Z객체는 유형이 지정된 목록에 대한 새로운 표준 형식을 사용하여 저장되며 모든 부분은 여전히 작동합니다.
  • 보기 및 편집 기능이 구현되고 성공적으로 테스트되었습니다.
  • 여러 구현을 사용할 수 있는 경우 "최상"이 선택됩니다. (체력 판정은 추후 변경될 수 있습니다.)
  • 각 함수의 실행 시간과 메모리 사용량을 측정하여 실행 결과 및 구현/테스트 테이블에 표시합니다.
  • 시스템 정의 Z객체에 대한 편집은 올바른 권한을 가진 사용자로 제한됩니다. 이해할 수 있는 diff가 생성됩니다. 결과가 캐시됩니다.
  • 대체, 참조, 문자열, 목록이 있는 텍스트가 성공적으로 구현 및 테스트되었습니다.
  • 팀이 위키함수에 기여하는 방법과 그 이유에 대해 커뮤니티와 공유된 이해가 문서화되어 있습니다.
  • 모바일 및 데스크탑에서 다국어 문서를 보고 편집할 수 있는 디자인이 승인되었습니다. UX가 계측되고 데이터가 수집됩니다.

요타(ι) 단계: 객체 문서화

  1. 이것은 예비 과제이며 문서화 작업을 여기로 이동합니다.
  2. 헤더에 대한 편집을 제공합니다(완전한 원시 편집에 추가로)(이것은 매우 큰 작업입니다) — 실제로는 레이블만 참조합니다.
  3. 다국어 텍스트로 Z2K3/레이블 편집을 확장합니다.
  4. Z2K4/문사화로 헤더를 확장하세요. — 작업 T260954 & 작업 T260956
  5. Z2K4/문서를 다루기 위해 편집을 확장합니다. — 작업 T260955

단계 완료 조건: 사용자는 위키 텍스트를 사용하여 지원되는 모든 언어로 Z객체를 문서화 할 수 있습니다.

카파(κ) 단계: 뒤처리

  1. 모든 사전 실행 작업을 닫기 위해 작업을 강화하고 정리합니다.

단계 완료 조건: 추상 위키백과 팀으로서 우리는 모든 관련 동료의 승인을 포함하여 출시 준비가 되었다고 생각합니다.

람다(λ) 단계: 출시

  1. 람다(λ) 단계는 출시를 의미합니다. 이를 방지하는 사전 출시 작업이 있다면 당연히 그렇게 하세요.
  2. 새로운 위키미디어 프로젝트를 구축합니다.
  3. 프로젝트에 대한 일부 위키 페이지를 메타에서 위키함수로 이동하세요.

단계 완료 조건: 웹에 있는 사람으로서 저는 Wikifunctions.org를 방문하여 사이트에서 직접 기능을 작성하고 실행할 수 있습니다.

단계화되지 않은 과제

수행해야 하지만 아직 단계적으로 진행되지 않은 사전 출시 작업:

파트 1의 출시 후 작업

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Abstract_Wikipedia/Plan/ko&oldid=21266378"