추상 위키백과/과제

This page is a translated version of the page Abstract Wikipedia/Tasks and the translation is 100% complete.

이것은 추상 위키백과 개발 계획의 일부입니다.

추상 위키백과 요소에서 계속됩니다.

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

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

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

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

파트 P1: 위키함수

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

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

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

과제 P1.2: 초기 개발

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

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

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

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

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

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

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

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

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

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

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

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

add(x, y)

를 다음과 같이 하면

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

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

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

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

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

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

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

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

과제 P1.10: 테스트 유형

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

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

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

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

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

과제 P1.13: 접근 함수

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

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

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

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

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

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

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

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

과제 P1.17: REST 호출

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

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

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

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

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

파트 P2: 추상 위키백과

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

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

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

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

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

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

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

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

과제 P2.4: 모바일 UI

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

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

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

과제 P2.6: 규칙 활용

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

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

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

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

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

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

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

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

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

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

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

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

과제 P2.12: 추상적 주해

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

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

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

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

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

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

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

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

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

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

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

비 핵심 과제

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

과제 O1: 람다 대수

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

과제 O2: 터미널의 CLI

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

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

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

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

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

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

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

과제 O6: 파이썬 기반 구현

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

과제 O7: 다른 언어로 구현

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

과제 O8: 웹 기반 REPL

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

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

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

과제 O10: 토론 페이지 지원

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

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

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

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

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

과제 O13: NPM 라이브러리

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

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

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

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

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

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

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

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

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

과제 O18: 앱 기반 평가자

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

과제 O19: P2P 기반 평가자

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

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

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

과제 O21: 스트리밍 유형

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

과제 O22: 바이너리 유형

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

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

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

과제 O24: 머신 러닝과 통합

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

과제 O25: IDE에 통합

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

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

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

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

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

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

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

과제 O28: 활동 보기

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

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

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

과제 O29: 구현 컴파일

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

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

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

이것은 추상 위키백과 개발 계획의 일부입니다.