추상 위키백과/아이디어

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

구조화된 주석과 속성 및 데코레이터

구조화된 주석과 속성 및 데코레이터는 함수 메타데이터, 기능 검색 촉진 및 문서 자동 생성과 같은 기능을 제공하기 위해 위키함수에서 활용 될 수 있습니다. 구조화된 주석은 구문 패턴 또는 XML을 활용하여 주석의 내용을 기계적으로 처리 할 수있는 프로그래밍 언어 주석입니다.

속성은 C# 및 자바(Java)와 같은 프로그래밍 언어로 함수 및 해당 매개 변수에 첨부 될 수 있습니다.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/

데코레이터는 제안 된 자바스크립트 언어 기능입니다.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

버전 작성

구조화된 주석과 속성 또는 데코레이터를 활용하는 버전 관리 관련 메타 데이터는 진화하는 크라우드 소싱 리소스에 대한 버전 관리 시나리오를 단순화 할 수 있습니다.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/general#obsolete-attribute

— AdamSobieski (talk) 22:15, 15 July 2020 (UTC) [reply]

이름공간 및 모듈

이름 공간 및 모듈은 대규모 함수 모음을 구성 할 때 유용 할 수 있습니다. 이름 공간 및 모듈을 사용하면 여러 패러다임 또는 기능 에코 시스템이 크라우드 소싱 된 리소스에서 더 쉽게 공존 할 수 있습니다.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

자연어 생성을 위한 스크립팅 환경

V8과 같은 최신 스크립팅 엔진을 사용하면 스크립팅 환경을 만들고 제공하는 것이 비교적 쉽습니다.

웹 브라우저가 웹 시나리오를 위한 스크립팅 환경 및 API를 제공하는 방식과 유사하게 자연어 생성 시나리오를 위한 스크립팅 환경 및 API를 제공 할 수 있습니다.

렌더러를 위한 스크립팅 환경과 관련된 토론 주제는 다음과 같습니다: (1) 입력 위키데이터 데이터에 접근하고 작업하기 위한 API 및 객체 모델, (2) 렌더링 컨텍스트 접근 및 작업을 위한 API 및 객체 모델, (3) 중간 지식 표현에 접근하고 작업하기 위한 API 및 객체 모델, (4 ) 출력 자연어 콘텐츠를 생성하기 위한 API 및 객체 모델.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

출처

위키데이터는 출처 지식 기반이므로 API 및 객체 모델에는 중간 표현과 자연어의 일부에 소스를 주석 처리하는 수단이 포함되어야합니다. 자동으로 생성 된 문서에서 진술의 출처는 문서의 "참조" 섹션에서 참조 자료로 표시 될 수 있으며, 관련 콘텐츠 근처에 인라인으로 표시되는 인용 번호가 있습니다.

위키데이터에 자동화된 추론에 대한 지원이 포함되는 경우, 모든 추론과 논증, 파생 또는 진술을 뒷받침하는 증거가 관련 콘텐츠 근처에 인라인으로 표시되는 인용 번호가 있는 문서의 "주석" 섹션에 유사하게 나타날 수 있습니다. 독자는 하이퍼 링크를 클릭하여 하나 이상의 진술에 대한 추론, 논증, 파생 또는 증명을 뒷받침하는 자동 생성 문서를 탐색 할 수 있습니다.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

출력 스트림과 로깅, 진단 이벤트

추상 위키백과에서 사용하기 위한 위키함수 콘텐츠를 편집/개발할 때, 여러 스트림으로 출력하고, 기록하고, 입력된 이벤트를 발생시키는 것이 편리 할 것입니다. 이러한 기능은 함수에 제공되는 스크립팅 환경의 일부입니다.

구성 가능한 세분성 또는 자세한 수준으로 진단 출력을 집계, 구성 및 볼 수 있는 것도 유용합니다.

https://developer.mozilla.org/en-US/docs/Web/API/Console

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

편집자/개발자 경험

편집자/개발자는 추상 위키백과에서 "개발자 모드" 또는 "디버깅 모드"를 전환하는 방법을 사용할 수 있으므로 문서를 보는 동안 다음 중 하나를 수행 할 수 있습니다:

자연어 부분 위로 마우스를 가져 가서 호버 상자에서 계산 및 진단 메시지의 관련 추적을 확인합니다,
확장 된 데이터를 보기 위해 시각 표시기와 상호 작용할 수 있도록 여백에서 계산 및 진단 메시지의 추적에 대한 시각 표시기를 봅니다
그렇지 않으면 자연어 콘텐츠의 일부를 선택하거나 표시하여 관련 계산 및 진단 메시지 추적을 확인합니다.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

독자 경험

자동으로 생성된 자연어 콘텐츠의 특정 부분에 대한 의견, 좋아요, 찬성 또는 기타 피드백 제공과 같은 추상 위키백과 독자를 위한 피드백 메커니즘을 추가하는 것을 고려할 수 있습니다.

독자가 자동으로 생성 된 콘텐츠를 "사후 편집"할 수도 있습니다. 자동 생성 된 문서의 경우 문서의 미세 조정을 크라우드 소싱하기 위한 위키 버전의 문서가 있을 수 있습니다. 자동으로 생성 된 문서의 이러한 "위키 사후 편집" 버전은 탭 사용자 인터페이스 요소를 통해 탐색 할 수 있습니다. 자동 생성 된 문서 "위키 사후 편집"에 대한 크라우드 소싱 된 다양한 피드백의 데이터는 위키함수 편집자/개발자가 사용하기 위해 수집 및 집계 할 수 있습니다.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

자연어의 자동 평가

자동 에세이 채점, 문법 검사, 가독성 측정 또는 자연어 평가 범주의 소프트웨어 도구는 다양한 방법으로 문서를 자동으로 측정하는 데 사용할 수 있습니다. 예를 들어 코-매트릭스(Coh-Metrix) 3.0은 108개의 인덱스에서 자연어를 측정합니다.

아마도 봇은 업데이트되는 문서를 측정하고 플랫폼 API를 사용하여 편집자/개발자에게 데이터를 보고할 수 있습니다.

http://cohmetrix.com/

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

사용자 질문에 대한 문서 생성

질문 응답 시스템과 유사하게, 위키데이터 쿼리에 대해 또는 사용자가 웹 검색에서 문서를 탐색 한 후에 문서가 생성 될 수 있습니다. 관련 콘텐츠를 강조하는 것 외에도 이 컨텍스트 데이터를 활용하여 문서를 생성 할 수 있습니다. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

문서에 사용할 후속 질문 생성

하이퍼 텍스트 기반 대화 시스템과 유사하게 문서 하단 근처의 섹션에 독자의 관심을 끌 수 있는 후속 질문을 배치 할 수 있으며, 각각은 다른 문서에 대한 하이퍼 링크입니다. 아직 생성 및 캐시되지 않은 경우 동적으로 생성 될 수있는 문서에 대한 하이퍼 링크를 사용할 수 있습니다. — AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

음성 합성 및 하이퍼 텍스트

CSS 음성 모듈 W3C 후보 권장사항이 있습니다.

발음과 관련하여 하이퍼 텍스트 문서와 함께 발음 어휘를 활용할 수 있습니다. 또한 EPUB3과 유사하게 생성 된 하이퍼 텍스트 출력에 SSML 기반 속성을 활용하여 발음 데이터를 제공 할 수 있습니다.

— AdamSobieski (Discussion) 22:15, 15 July 2020 (UTC) [reply]

GPT-3 스타일 API 사용

GPT-3 스타일 API를 사용하여 일반 언어를 추상 위키백과의 구문으로 자동 번역합니다. — ChristianKl (Discussion) 16:15, 16 January 2021 (UTC) [reply]

함수 컨트렉트

위키함수는 이미 다른 프로그래밍 언어(Eiffel, Spark-Ada, JML 또는 다른 패키지를 가진 파이썬)에서 이미 제공 한 "함수 컨트렉트"를 지원해야 합니다.

선행조건: 이 함수를 호출하기 전에 인수에 필요한 조건을 나타내는 불리언 술어 목록이 있는 함수 인수 뒤의 새 섹션 (예를 들어, 리스트는 비워 둘 수 없거나 첫 번째 매개 변수가 두 번째 매개 변수보다 커야 함)
사후조건: 함수의 결과로 보장되는 조건을 나타내는 불리언 술어 목록이 있는 함수 인수 뒤의 새 섹션 (예를 들어, 결과가 0과 첫 번째 매개 변수 사이이거나 출력 목록의 길이가 입력 목록의 길이에 1을 더한 값입니다)
유형 불변량: 이 데이터 유형의 모든 값이 충족하는 조건을 나타내는 불리언 술어 목록이 있는 데이터 유형 페이지의 새 섹션(예를 들어, 값은 반드시 0보다 커야하거나 소수여야 함)

아마도 가장 간단한 접근 방식은 각 술어가 나머지 함수와 동일한 이름 공간에 있는 함수일뿐입니다. 프로그래밍 언어에서는 일반적으로 계약 조건자(예를 들어, "모든" 또는 "적어도 하나가 있습니다" 수량자)에서 추가 작업이 허용되지만 이는 선택 사항 일 수 있습니다. 선행조건에서는 함수 인수를 참조하기만 하면 되고 사후조건에서는 함수 결과를 참조하는 방법이 필요합니다. 인수를 수정할 수 없음을 이해하므로 함수 시작시 매개 변수의 원래 값을 사후조건에서 참조 할 필요가 없습니다. 목록의 모든 술어는 참(즉, 논리적이고 모든 술어)이어야하며, 선행조건은 필요에 따라 상세 할 수 있으며, 아마도 렌더러에도 유용 할 것입니다. 인수는 인간의 위키데이터 항목이어야하며 이미 죽었습니다.

구현자와 사용자를 위한 함수를 공식적으로 문서화하는 것 외에도 (예를 들어, 선행조건이 실패하면 사용자는 각 기능 구현 내에서 다른 오류를 처리 할 필요없이 통일되고 명확한 오류 메시지를 받게됩니다), 사후조건은 결과를 자동으로 확인하는 데 매우 유용합니다. 테스트 중에 결과가 입력 매개 변수 세트로 사후조건을 충족하지 못하는 경우 플랫폼이 각 구현에 대한 제약 조건 위반 보고서를 생성하는 것이 좋습니다 (따라서 구현 또는 사후조건을 수정할 수 있음). 유형 불변은 해당 유형의 인수를 가진 모든 함수의 암시적 함수 선행조건과 해당 데이터 유형의 결과를 가진 모든 함수의 암시적 사후조건입니다.

일반적으로 얻을 수 있는 다른 이점은 선행조건 덕분에 일부 방어 코드를 줄일 수 있고 지원되는 모든 언어간에 호환되는 방식으로 예외 상황을 처리 할 필요가 없기 때문에 구현을 단순화 할 수 있다는 것입니다. "견고성 테스트"도 제공되어야합니다. 즉, 함수의 현재 선행조건에서 일부 매개 변수가 허용되지 않는지 확인하는 함수에 대한 일부 특수 테스트가 제공되어야합니다.

이것이 디자인 과정에 도움이 되기를 바라며 이 멋진 프로젝트에 대해 다시 한번 감사드립니다. — surueña (Discussion) 06:59, 3 April 2021 (UTC)[reply]

여기를 참조하세요. — DVrandecic (WMF) (Discussion) 22:59, 19 April 2021 (UTC)[reply]

유용한 자료와 후원하는 번역가 팀으로 베타 테스트

서비스 매뉴얼은 어떤 것을 올바르게 사용하는 방법에 대한 지식입니다. 제조업체는 서비스 설명서의 다국어 번역으로 혜택을 볼 수 있고 소니, 스틸, 바이어스, 스즈키와 같은 대량 생산업체는 막대한 자원을 보유하고 있기 때문에 위키에서 제공하지만 비용을 지불하는 번역 팀을 후원할 여유가 있습니다. 번역가는 추상이 콘텐츠를 한 언어에서 다른 언어로 적절하게 가져왔는지 다시 확인합니다. 그리고 번역된 매뉴얼의 호스팅 비용은 팀을 여기로 끌어들이는 데 동의하는 대량 생산자가 전액 부담할 수 있습니다.

전기톱을 사용하는 방법이나 보케를 얻는 방법에 대한 다국어 서비스 매뉴얼 라이브러리가 있다는 것은 좋은 일이지만 내가 볼 때 이것은 목표가 아닙니다. 행복한 부수적 혜택일 뿐입니다.

주요 목표는 기계를 베타 테스트하는 것입니다. 번역가는 오류를 수정하지 않습니다. 그들은 기계가 실패한 이유를 이해할 수 있도록 우리를 위해 그것을 지적할 것입니다. 그리고 기계가 완벽하다면 번역된 팀이 그 신뢰성을 입증했을 것입니다.

번역팀에 대해서는 다양한 방식으로 모집할 수 있습니다. 정규 근무자 학교 교사 카톨릭 교회

저는 가톨릭 교회의 아이디어가 놀랍고 어울리지 않거나 독실한 움직임으로 보일 수 있다고 생각합니다. 그래서 여기에 그 이면에 있는 생각이 있습니다

먼저, 구름을 치워 봅시다: 가학적인 교사, 살인적인 경찰, 그리고 (어쩌면) 모든 조직에 나쁜 사람들이 많다고 해도 그들을 모두 나쁜 사람으로 정죄할 수는 없습니다. 그리고 저는 용서에 대해 말하는 것이 아닙니다. 전혀 아닙니다. 더 나은 부분, 거기에 있는 좋은 사람들과 협력하는 것에 대해 이야기하고 있습니다. 그들의 피치는 사랑과 나눔에 관한 것이며 어떤 믿음이나 기적을 믿을 필요가 없습니다. 위키는 세속적이며 초자연적인 활동이나 메시지 전파에 투자하지 않습니다. 그러나 (다시 말하지만, 이중 승리) 가톨릭 교회는 지구상의 어디에나 모든 언어로 존재하며 언어를 구사하는 학자들로 가득합니다. 예, 그들은 사랑에 대해 이야기하고 싶어하지만(불행하게도 때때로 그들의 사랑이 더 나은 이유에 대해) 지구상의 모든 언어로 성경을 번역하기를 원합니다. 예수께서 말씀하셨기 때문에 핵심적인 믿음입니다. 저는 프란치스코 교황과 친구들의 재정적 자원에 대해 최신 정보는 아니지만 그들이 현지 언어를 구사하거나 그 일을 하기에 정말 믿을만한 학자 네트워크가 있다는 것을 알고 있습니다. 그들은 나쁜 언론을 가지고 있었고 이제 교회가 어떤 자리를 가질 수 있는지, 우리의 말과 그들의 말씀을 전파하여 사람들을 도울 수 있는 방법에 대한 답을 찾고 있습니다. 그리고 믿음이 무엇이든 성경은 지난 2천년 동안 인류를 형성한 책입니다. 모든 크리올어로 번역하면 평화와 존경이 보일 것입니다. 그게 전부입니다. 그리고 다른 큰 종교는 어떻습니까? 그들을 타십시오! 범위가 명확하게 정의되어 있으므로 초대를 동시에 보낼 수 있습니다(따라서 위키는 세속적이며 모두가 편안합니다). 모든 교회는 문학의 읽기와 해석에 기초를 두고 있으며, 이것은 실제로 지식과 문헌학의 장소입니다. 그리고 그들의 계층 구조는 번역가의 신뢰성을 확인할 수 있습니다. 우리는 넬슨 만델라 추모식에서 버락 오바마의 연설을 통역하던 가짜 수화 통역사와 같은 사람을 원하지 않습니다. —앞의 서명되지 않은 주석은 프랑수아 주르댕에 의해 추가되었습니다 (talk) 04:35, 23 February 2022 (UTC)[reply]

아마도 흥미로운 아이디어일 것입니다. 후원 기부는 항상 철저하게 그리고 커뮤니티와 함께 고려해야 하지만 유기적 성장이 너무 정체된 경우 가능성이 있습니다. 봅시다! 그것은 우리가 1년 정도 후에 생각해야 하는 것입니다. --DVrandecic (WMF) (talk) 00:11, 5 March 2022 (UTC)[reply]