추상 위키백과/추상 콘텐츠의 위치

추상 위키백과를 통해 더 많은 사람들이 자신의 언어로 지식 기반에 목소리를 낼 수 있게 됩니다. 이 지식 기반은 여러 언어로 제공될 것입니다. 지식 기반은 위키데이터의 데이터를 사용하여 추상 콘텐츠로 생성, 저장 및 관리됩니다. 이 초록 콘텐츠는 위키함수의 함수와 위키데이터의 어휘소를 활용하여 특정 자연어로 된 텍스트로 변환됩니다. 이를 통해 더 많은 사람들이 자신의 언어로 콘텐츠를 읽을 수 있게 됩니다.

녹음된 강연과 문서 링크를 포함하여 추상 위키백과의 배경에 대한 자세한 내용은 추상 위키백과에서 확인할 수 있습니다.

저희는 결정 과정을 명확하게 하고 싶습니다. 아직 어떤 옵션을 사용할지 결정하지 못했기 때문에 여기서 협의를 진행하게 되었습니다. 위키미디어 커뮤니티의 주장을 참고하고, 다양한 커뮤니티와 협의하여 결정에 도움이 될 만한 주장을 듣고자 합니다. 재단은 협의 기간 이후에 결정을 내리고 이를 전달할 것입니다.

예시

목성에 대한 새로운 위키백과 문서를 만들고 싶다고 가정해 보겠습니다. 그리고 이 문서의 첫 번째 버전은 다음과 같습니다(이것은 간단한 영어 위키백과 문서의 처음 두 문장입니다):

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])

더 많은 예를 보려면 예제 페이지가 있습니다.

이것은 함수 호출 자체에 불과하며, 이 경우에는 Article 함수에 대한 호출입니다. Article 함수는 위키함수에서 정의됩니다. 편의를 위해 이 추상적인 콘텐츠는 영어 레이블을 사용하여 표시되며, 사용자는 이러한 레이블이 지정된 콘텐츠를 보기 좋은 UX로 볼 수 있습니다. 시스템에서는 이러한 모든 것이 ID이며, 다음과 같이 보일 수 있습니다. 하지만 이는 전적으로 내부적인 것이며 사용자에게 표시되는 방식이 아니라는 점을 기억하세요:

Z329391(
 Z329391K1: [
  Z239392(
   Z239392K1: Q319,
   Z239392K2: Z173772,
   Z239392K3: Q634,
   Z239392K4: Q544),
  Z202334(
   Z202334K1: Q319,
   Z202334K2: Z193935(
    Z193935K1: Z109882(
     Z109882K1: 5),
    Z193935K2: Q634,
    Z193935K3: Z183432(
     Z183432K1: Q126017,
     Z183432K2: Q525)))],
 Z329391K2: [Q319, Q634, Q544])

기술적 전문 지식이 없어도 모든 사람이 이 추상 콘텐츠를 보고, 유지하고, 만들고, 편집할 수 있는 UX 인터페이스가 있을 것입니다.

그러면 위키함수는 이 추상 콘텐츠를 가져와서 위와 같은 자연어 텍스트로 변환하는 함수를 제공합니다.

지금 우리가 답하고 싶은 질문은 다음과 같습니다. Article에 대한 해당 함수 호출을 어디에 저장하고, 그것을 목성의 위키데이터 항목인 Q319와 어떻게 연결할 것인가?

상담 과정

상담 기간은 4주입니다. 상담 기간 동안 관련 질문에 답변해 드리겠습니다. 누락되지 않도록 질문을 '표시'해 주세요.

첫째 주에는 우리의 관점 없이 커뮤니티의 의견을 수집할 것입니다. 이는 초기 의견에 편견이 생기는 것을 피하기 위한 것입니다.

일주일 후, 우리는 우리의 생각과 이미 나눴던 토론 내용을 게시하고, 기존 토론에 참여하기 시작할 것입니다.

저희는 메타에서 진행되는 협의에 적극적으로 참여할 것입니다. 다른 곳에서는 참여가 제한될 수 있습니다. 영어 외의 다른 언어로도 소통하기 위해 최선을 다하겠습니다.

협의 기간이 종료되면 모든 제출 내용을 검토하여 결정을 내릴 것입니다. 추후 적절한 시기에 결정을 내리고 공표하는 것을 목표로 합니다.

옵션

위키데이터에서 목성에 대한 항목은 Q319에서 찾을 수 있습니다. 이 맥락에서 아래 선택지가 제공됩니다.

옵션 1: 위키데이터 항목에 이름공간 첨부

항목에 새로운 이름공간을 도입할 예정입니다. 이 이름공간에는 항목에 대한 추상 콘텐츠가 포함됩니다. Q319에서 목성 항목에 대한 추상 콘텐츠를 찾을 수 있으며, 이는 목성 항목 없이 위키백과에서 사용될 것입니다.

고려사항

• 추상 콘텐츠를 만들고 유지하는 커뮤니티는 위키데이터 커뮤니티의 일부가 될 것입니다.
• 위키여행과 같은 다른 프로젝트의 추상 콘텐츠는 어떨까요? 자체 이름공간을 사용하면 다양한 요구 사항을 충족할 수 있을까요?
• 이로 인해 위키데이터에 얼마나 많은 추가 편집과 콘텐츠가 추가될까요?

옵션 2: 위키데이터의 추상 콘텐츠에 대한 새로운 데이터 유형 만들기

위키데이터에 추상적인 콘텐츠를 저장할 수 있는 새로운 데이터 유형을 만들 것입니다. 그러면 커뮤니티는 위키데이터에 추상적인 콘텐츠를 저장하는 하나 이상의 속성을 생성하고, 이러한 속성을 사용하여 해당 콘텐츠를 특정 항목과 연결할 수 있습니다.

목성의 경우 이는 기존 청구와 함께 Q319에 대한 새로운 청구를 의미합니다.

고려사항

• 커뮤니티는 두 개 이상의 속성을 만들고, 위키여행, 역사, 추상적 설명 등 더욱 세분화하여 사용할 수 있습니다.
• 추상적인 콘텐츠를 만들고 유지하는 커뮤니티는 위키데이터 커뮤니티의 일부가 될 것입니다.
• 이는 위키데이터에 상당히 무거운 값을 도입하게 되는데, 이는 현재 사용 모델에 적합하지 않습니다.

옵션 3: 위키함수의 객체

추상 콘텐츠는 위키함수에 저장되고, 위키데이터에는 추상 콘텐츠에 접근할 수 있도록 ZID로 연결되는 새로운 속성이 추가됩니다. 이는 여러 항목에 사용되는 함수와 같이 모델 콘텐츠에 대한 보다 자연스러운 표현 방식이기도 합니다.

고려사항

• 지금까지 개발 작업이 가장 적은 편입니다.
• 추상적인 콘텐츠를 만들고 유지하는 커뮤니티는 (대부분) 위키함수 커뮤니티에 속합니다.
• 위키함수 플랫폼은 상당히 기술적인데, 기술적인 부분과 비기술적인 부분을 가깝게 배치하면 구분이 모호해질 수 있습니다.
• 동일한 메커니즘이 위키여횅과 다른 프로젝트에도 적용될 수 있습니다.

옵션 4: 새로운 위키백과 언어 에디션 또는 위키 프로젝트의 객체

완전히 새로운 위키 프로젝트(예: abstract.wikipedia.org 또는 다른 이름(TBD))를 만들고, 이를 통해 추상 콘텐츠가 생성, 저장 및 관리됩니다. 위키데이터가 이러한 연결을 관리합니다.

고려사항

• 추상적인 콘텐츠의 제작과 유지 관리를 중심으로 새로운 커뮤니티가 성장해야 하지만, 보다 집중적이고 헌신적일 수 있습니다.
• 이로 인해 위키미디어 커뮤니티는 사람들이 사용해야 하는 또 다른 위키로 더욱 분열됩니다.
• 이를 통해 추상 위키백과의 콘텐츠에 대해 다른 저작권 라이선스를 사용하는 것이 더 쉬워졌습니다.

옵션 5: 기존 프로젝트의 새 이름공간에 있는 객체

기존 프로젝트에 추상 콘텐츠가 위치할 새 이름공간을 추가할 수 있습니다. 가장 가능성 있는 옵션은 다음과 같습니다:

1. Commons
2. Meta
3. 영어 위키백과, 문서에 첨부되지 않음

고려사항

• 이러한 각 옵션은 추상적인 내용을 다루는 커뮤니티에 매우 다른 사회적 의미를 갖습니다.
• 이 변경으로 호스트 위키에 얼마나 많은 추가 편집과 콘텐츠가 추가될까요? 커뮤니티 프로세스에 부담을 주거나, 기존 프로세스에 영향을 줄 수 있는 부분이 있다면 적용이 어려울까요?

내부 논의 요약

팀의 일반적인 질문

위키백과 외의 다른 프로젝트는 어떤가요?

옵션 1, 4, 5는 위키여행을 쉽게 확장할 수 없는 솔루션입니다. 옵션 2와 3은 다른 프로젝트에서 추상적인 콘텐츠를 사용할 수 있도록 간단한 확장을 허용합니다.

위키백과 외에 다른 사용 사례는 어떤가요?

이전에 논의했던 다른 사용 사례로는 추상적 설명과 추상적 설명이 있습니다. 옵션 2와 3이 이러한 기능을 가장 쉽게 지원할 수 있습니다.

다양한 콘텐츠에 대한 라이선스는 어떻게 되나요?

위키데이터는 일반적으로 CC0 라이선스를 사용하고, 위키함수는 콘텐츠에 CC0 라이선스를, Apache2 라이선스를 코드에 사용합니다. 위키백과 콘텐츠는 CC-BY-SA4 라이선스를 사용합니다. 옵션 1, 4, 5를 사용하면 추상 콘텐츠에 CC-BY-SA4 라이선스를 쉽게 적용할 수 있습니다. 옵션 2와 3은 추상 콘텐츠에 CC0 라이선스를 적용하면 더 쉬울 것입니다. 하지만 이는 (현재 위키백과 자체와 마찬가지로) 추상 위키백과의 추상 콘텐츠는 CC-BY-SA 라이선스를 적용한다고 명시한 이전 라이선스 결정과 상충됩니다.

특정 옵션에 대한 팀의 고려 사항

옵션 1: 위키데이터의 이름공간

이 솔루션은 추상 위키백과에만 국한되어 있으며, 추상 위키여행 등에는 확장 적용하기 어렵습니다.

"첨부된" 이름공간의 개념은 복잡하며, 이를 위한 고품질 미디어위키 지원을 제공하는 것은 어려울 것입니다.

위키데이터에는 이미 엄청난 양의 편집본과 콘텐츠가 있으며, 우리는 훨씬 더 많은 내용을 추가할 것입니다.

옵션 2: 위키데이터의 데이터 유형

기존 위키데이터 인터페이스의 맥락을 고려할 때, 추상 콘텐츠 데이터 유형에 적합한 UX를 구축하는 것은 특히 어려울 것입니다. 추상 콘텐츠는 장문 콘텐츠일 가능성이 높으며, 위키데이터 항목의 UI는 이에 적합하지 않습니다. 항목 페이지의 제약 조건을 고려할 때, 새롭고 훌륭한 UX 경험을 구축하려면 상당한 추가 노력이 필요할 것입니다. 원칙적으로 편집을 위한 모달을 사용할 수 있지만, 이러한 모달은 고유한 UX 단점을 가지고 있으며, 전용 환경에서 동일한 기능을 구현하는 것보다 일반적으로 구현이 더 복잡합니다. 또한, 항목 페이지의 현재 디자인 패턴을 깨뜨리고 향후 계획될 패턴과 일치하지 않을 수도 있습니다.

또한, 추상 콘텐츠는 어느 정도 구조화되어 있고 기계가 읽을 수 있지만, 항목보다 훨씬 덜 구조화되어 있고(또는 적어도 다르게) SPARQL로 구조를 쿼리할 수 없을 가능성이 높습니다.

또한, 항목에 직접 주요 사실의 중복이 발생할 수 있습니다. 이는 위키백과 문서의 중복보다 더 심각해 보입니다(추상적인 내용이든 아니든). 항목의 사실을 업데이트하는 편집자의 책임이 혼합되거나 확장되기 때문입니다. 이제 편집자는 같은 내용을 두 번이나 수정해야 하므로 매우 답답할 것입니다. 만약 추상적인 내용이 별도의 영역에 존재한다면, 기존 위키백과처럼 유지 관리 책임도 명확하게 분리될 것입니다.

여기에는 두 가지 추가적인 과제가 있습니다. 첫째, 위키데이터 항목의 크기가 증가할 것이므로 이를 해결할 수 있는 솔루션이 필요합니다. 미디어위키는 엄격한 제한을 적용하는데, 일부 위키데이터 항목은 이미 이 제한에 도달했습니다. 둘째, 다양한 사용 사례에 잘 작동하는 기존 시스템에서 매우 크고 복잡한 값의 시각화, 편집 및 비교를 어떻게 처리할지 결정해야 합니다. 다른 옵션에서는 이러한 모든 문제가 발생하지 않습니다.

위키데이터 항목 내에 추상 콘텐츠를 저장하는 기능은 쿼리가 불가능한 다른 비정형 장문 텍스트(예: 시)를 저장하는 기능에 대한 요청을 다시 불러올 수 있습니다. 지금까지 위키데이터 팀은 이러한 요청이 위키데이터에 적합하지 않다는 이유로 항상 거부해 왔습니다.

위키데이터에는 이미 엄청난 양의 편집본과 콘텐츠가 있으며, 우리는 훨씬 더 많은 내용을 추가할 것입니다.

새로운 데이터 유형은 지금까지 위키데이터에서 다루어 온 어떤 데이터 유형보다 훨씬 더 클 것이며, 이와 관련하여 다양한 문제가 있을 것입니다.

옵션 3: 위키함수의 객체

이렇게 하면 옵션 2(위키데이터 데이터 유형)의 많은 문제점을 해결하고 유연성의 이점을 유지할 수 있습니다. 하지만 해당 항목에서 콘텐츠를 삭제해야 합니다.

위키함수에서 동일한 객체를 참조하는 여러 항목을 지원할 수 있다는 추가적인 이점이 있습니다. 위키백과 문서의 추상적인 내용에는 거의 유용하지 않을 것처럼 보이지만, 위키데이터 항목의 추상적인 설명이나 어휘소의 추상적인 주석에는 매우 유용할 수 있습니다. 추상적인 내용과 기능을 동일한 플랫폼에서 모두 생성할 수 있으므로, 이러한 영역 중 하나에 집중하는 사람들과 다른 분야에 집중하는 사람들 간의 협업이 더욱 직접적으로 이루어질 것입니다.

위키함수 커뮤니티는 콘텐츠와 변화 속도가 크게 증가할 것이므로 관리에 어려움을 겪을 수 있습니다. 위키의 범위는 콘텐츠뿐만 아니라 커뮤니티를 지원하는 '구조적' 요소까지 포괄하도록 확장되어야 합니다. 커뮤니티가 "콘텐츠"(추상적인 인터링구아든 아니든)와 "기능"을 중심으로 모일 가능성이 높다고 가정하면, 위키백과의 객체는 두 개의 이질적인 커뮤니티를 결합할 것입니다. 반면 커뮤니티가 "추상적인 언어 표현"을 중심으로 분열된다고 가정하면, 두 개의 유사한 하위 커뮤니티를 결합할 것입니다.

검색 시스템과 메인 페이지의 내용은 더욱 복잡해지고, 다양한 기본 사용 사례(코드 함수, 언어 함수, 백과사전 주제 페이지)가 생겨날 것입니다.

옵션 4: 새 프로젝트

이를 통해 위키백과 콘텐츠와 그렇지 않은 콘텐츠가 명확하게 구분되고, 위키펑션과 위키데이터 사이에 가려져 있던 추상적인 콘텐츠가 뚜렷하게 보이게 됩니다. 하지만 반대로, 위키미디어 커뮤니티는 더욱 분열될 것입니다.

옵션 5: 기존 프로젝트의 이름공간

이는 제휴되지 않은 프로젝트의 범위에 있어서 상당한 변화가 될 것입니다.

영어 위키백과를 사용하는 것은 특히 좋지 않은 생각으로 보입니다. 위키미디어 운동에서 영어의 우위를 더욱 공고히 하는 결과를 낳기 때문입니다. 또한 위키백과 범위를 벗어난 콘텐츠, 예를 들어 위키낱말사전의 어휘 관련 콘텐츠나 위키여행의 위치 관련 콘텐츠에 대한 향후 지원을 정당화하기 어렵게 만들 것입니다.

팀의 일반적인 요점

사용자 경험

UX 관점에서 볼 때, 옵션 1(위키데이터에 항목 첨부), 4(새로운 프로젝트), 5(위키데이터에 없는 이름공간 첨부), 그리고 어떤 측면에서는 옵션 3(위키함수 객체)은 많은 기능을 공유합니다. 각 옵션에는 추상적인 콘텐츠 전용 페이지가 하나씩 있습니다(해당 페이지는 서로 다른 위치에 있고 생태계의 나머지 부분과 다른 방식으로 연결되어 있음에도 불구하고). 이러한 모든 기능은 추상적인 콘텐츠를 표시하고, 유지하고, 해당 페이지의 히스토리를 보여주는 전체 페이지 경험을 제공하며, 이는 추상적인 콘텐츠에만 전념하고 다른 콘텐츠와 섞이지 않음을 의미합니다.

독자의 UX 관점에서 볼 때, 옵션 2(위키데이터 데이터 유형)와 옵션 3(위키함수 객체)은 위키데이터 항목을 기본적으로 동일한 방식으로 변경하기 때문에 여러 측면에서 공통점이 있습니다. 독자의 경우, 함수 호출의 렌더링(즉, 독자의 언어로 렌더링된 추상 콘텐츠)을 인라인으로 표시하고, 전체 페이지 경험을 방해하지 않도록 잘라낼 수 있습니다. 하지만 콘텐츠 편집 및 유지 관리 측면에서는 두 옵션이 상당히 다릅니다. 추상 콘텐츠를 편집하면 위키데이터 항목에 인라인으로 표시되거나 위키함수의 해당 페이지로 이동하게 됩니다.

개발

옵션 1(항목 첨부)과 옵션 2(위키데이터 데이터 유형) 모두 위키데이터 팀과 위키함수 팀이 긴밀하게 협력해야 합니다. 다른 옵션들은 두 팀이 협력할 필요성을 줄여줍니다. 옵션 1은 미디어위키 플랫폼에 가장 복잡한 요구 사항을 가지고 있으며, 옵션 2의 위키데이터 객체 증가 문제 또한 미디어위키 그룹과 협력하여 해결해야 합니다.

커뮤니티

가장 흥미로운 질문 중 하나는 새로운 추상 콘텐츠 기여자 커뮤니티는 어디에 위치하게 될 것인가입니다. 옵션 1(항목 첨부)과 옵션 2(위키데이터 데이터 유형)에서는 위키데이터 커뮤니티의 하위 커뮤니티가 됩니다. 위키데이터 커뮤니티는 이미 잘 구축되어 있고, 다국어를 사용하며, 친절하고 기술적으로 능숙합니다. 또한, 저명성과 관련된 워크플로우와 콘텐츠 분쟁 해결을 위한 부분적인 워크플로우를 이미 갖추고 있습니다. 편집자들이 위키데이터에서 관심 목록을 필터링할 수 있도록 추가적인 환경 설정/UI가 필요할 것입니다.

옵션 3(위키함수 객체)에서는 위키함수 커뮤니티의 하위 커뮤니티가 됩니다. 이는 언어와 코드에 관심 있는 사람들로 구성된 기존 커뮤니티의 성격을 크게 변화시킬 것입니다. 언어와 코드에 관심 있는 사람들뿐 아니라 특정 백과사전 주제에 대한 세부 정보에 관심 있는 사람들도 함께 참여하는 커뮤니티로 말이죠. 하지만 "추상 문장을 만들고 그 새 문장을 추상 콘텐츠 페이지에 사용하는" 작업 흐름이 기술적, 정신적으로 모두 간소화될 수 있을 것입니다. 두 가지 모두 동일한 위키에서 검색 가능하게 만들 수 있기 때문입니다.

옵션 4(새로운 프로젝트)의 경우, 그들은 모든 사회적 비용을 감수하면서 그들만의 커뮤니티를 형성해야 합니다.

옵션 5(연결되지 않은 이름공간)에서는 해당 위키의 하위 커뮤니티가 되고, 호스트 위키 커뮤니티의 초점은 새 콘텐츠와 기존 작업으로 나뉩니다.

이는 중요한 질문입니다. 어떤 관리자가 어떤 유형의 관리자인지를 결정하기 때문입니다.

유연성

중요한 고려 사항 중 하나는 제공된 솔루션이 커뮤니티에 얼마나 많은 유연성을 제공하는가입니다. 옵션 1(항목 첨부), 4(새 프로젝트), 5(이름공간 미첨부)는 각각 예상치 못한 창의적인 개발 기회를 매우 제한적으로 제공합니다. 실제로 솔루션이 매우 제한적이어서 향후 위키여행을 지원하려면 전담 리소스를 제공해야 하며, 그렇지 않으면 지원이 불가능할 것입니다. 이러한 설정으로 이점을 얻을 수 있는 다른 프로젝트의 경우 더욱 그렇습니다. 이로 인해 위키여행을 비롯한 다른 프로젝트에 대한 지원이 전혀 이루어지지 않을 위험이 있습니다.

옵션 2(위키데이터 데이터 유형)와 그보다 더 중요한 옵션 3(위키함수 객체)은 훨씬 더 큰 유연성을 제공하며, 앞으로 이러한 유연성이 오늘날 우리가 매우 놀랄 만큼 창의적이고 참신한 방식으로 적용될 것으로 예상됩니다. 이 옵션들은 커뮤니티에 가장 큰 권한을 부여하지만, 동시에 가장 복잡한 기능을 제공하기도 합니다.

콤보 및 기타 아이디어에 대한 팀의 생각

옵션 4(새로운 프로젝트)는 추상 위키백과뿐만 아니라 추상 콘텐츠 전반에 적용될 수 있으며, 따라서 추상 위키여행 및 잠재적으로 다른 프로젝트들을 지원할 수 있습니다. 또한 문서 콘텐츠를 현재보다 더 세분화된 방식으로 분할할 수 있습니다. 그러면 위키데이터가 각 항목에 대한 메타데이터를 지정하고 제공할 수 있습니다.

옵션 3(위키함수 객체)과 4(새로운 프로젝트)를 결합하면 유연성을 어느 정도 유지할 수 있습니다(예: 위키함수에서 짧고 공유되는 추상적인 설명과 주석에는 옵션 3을 사용). 또한, 자체 위키에서 전체 장문 콘텐츠를 개발할 적절한 장소를 확보할 수 있습니다(옵션 4).

Questions

• The Wikipedias already have a kind of "function" that can create content: templates. Wikidata has some very useful standard templates that pull things in from statements on an item or property - d:Template:Item documentation and d:Template:Property documentation (there are probably others). I would consider these to already be a form of "abstract content"; it has also been proposed that Wikidata description fields be auto-filled with a similar sort of template where needed (right now there are several bots that fill those in automatically for some item types). Can we add a namespace similar to the Template namespace (in any wiki but particularly Wikidata) with fully multilingual capability using the new Wikifunctions? That seems like a logical way to start here. ArthurPSmith (talk) 16:44, 22 May 2025 (UTC)

  @ArthurPSmith Thanks for the suggestion, but I am not sure I fully understand it. All Wikifunctions functions are immediately available to all wikis where access has rolled out to. It is a global space, available to all wikis. Why would we want a per-wiki namespace in addition to that? --DVrandecic (WMF) (talk) 10:29, 23 May 2025 (UTC)

  Ah, I hadn't been following that. Which wikis are using it now then? ArthurPSmith (talk) 14:11, 23 May 2025 (UTC)

  So far, Dagbani Wikipedia and Wikifunctions. More wikis are planned soon. --DVrandecic (WMF) (talk) 14:30, 23 May 2025 (UTC)

• What about generic abstract content? For example, we don't need a abstract content for each city in a country, we can have one generic abstract content for all cities in a specific country, and that would generate generic information about each city based in the properties each Wikidata item have. Are that been considered? Danilo.mac talk 19:33, 22 May 2025 (UTC)

  Absolutely! We call these two different types of articles manually written articles and model articles. Both of these should be possible with any of the options we discuss here, although some of the options make some solutions a bit easier than others. --DVrandecic (WMF) (talk) 10:35, 23 May 2025 (UTC)

  I guess this relates to my question above then - I think the templates I mentioned work somewhat like "model articles" - so where should those live? I don't see them as single functions, but maybe they could be. ArthurPSmith (talk) 14:18, 23 May 2025 (UTC)

  That's a great question, and I don't have a great answer. If the answer to our question here only allows for exactly one abstract article per item (e.g. Option 1), then it would need to live as a function on Wikifunctions. If we allow for more flexibility than that, where several items can share the same function (e.g. Option 3), then we could decide whether to put these functions in Wikifunctions or in a new space (e.g. Option 4). So, the desire to use model articles and also put them under a CC-BY-SA license might be a bit at odds given some of the options. Hmm, that's a very good point indeed. --DVrandecic (WMF) (talk) 14:30, 23 May 2025 (UTC)

• Will all Wikipedias be forced to display the content based in abstract content when that specific Wikipedia does not have an article and Abstract Wikipedia have? Will the communities of each Wikipedia have the control to display or not the content from abstract Wikipedia? That is an important question because there are editors that don't like templates that automatically pull content from Wikidata, for different reasons like quality of the Wikidata content and difficulty to modify and watch modifications, and they can just not use them, or choose to use only in some cases. How will the Wikipedia editors communities can choose what can be pulled from Abstract Wikipedia and what can not? Danilo.mac talk 19:33, 22 May 2025 (UTC)

  @Danilo.mac Thank you! Those are really important questions, and not all answers are there yet. The plan is to certainly allow the local communities a lot of control. Sometimes, there are intentionally omitted articles (e.g. when a community decides to split up the topics of an article differently than another, e.g. Bonny and Clyde. It would indeed not make for a great experience if in these cases the community couldn't suppress the creation of the article from Abstract Content.

  But all these questions will be true no matter what the result of the current consultation, I assume, and that the answer to these questions wouldn't really have import for the current discussion, or am I missing something?

  Thanks for raising these important questions! --DVrandecic (WMF) (talk) 10:54, 23 May 2025 (UTC)

• Will we be able to import only a section of the abstract content to an article? For example, when comparing the article in my home wiki and the article from abstract content I find that in general the article in my home wiki is better, but one or two sections are better in the abstract version, could I import just those sections? I it not be possible, editors could in the future copy the abstract part that is better to the Wikipedias wiki-code and not indicate in the summary that they are coping, generating a license issue. So, I think that it is better to allow sections import since the beginning of the project. And that would be hard to implement if we choose options #1 or #2. Danilo.mac talk 00:25, 23 May 2025 (UTC)

  @Danilo.mac in both cases I would expect that we can still write a function that takes the abstract content, and just chooses a part of it. I think that this should be possible with any of the options discussed here (although it might be a bit easier if we chose Option 3 and then already break apart the content along these lines, but I am not expecting this to be the usual process? I think rather a function such as "fetch the section on history and render it here" used in the local Wikipedia is more likely. --DVrandecic (WMF) (talk) 10:57, 23 May 2025 (UTC)

• I got a message on my wiki's discussion board, alerting us of this discussion. The message contained the text "Since some of the hypothesis involve your project, we wanted to hear your thoughts too." I don't see how this "involves our project". Only option 5 seems that it might be hosted on a Wikipedia project. Is that the only way that this would affect a Wikipedia project directly? - Rooiratel (talk) 07:54, 23 May 2025 (UTC)

  @Rooiratel If I read your User page correctly, your main projects you contribute to are Afrikaans Wikipedia and Wikidata. Both projects would potentially be affected:

  1. Afrikaans Wikipedia would get potentially a lot of articles from Abstract Wikipedia, to fill in knowledge gaps on that wiki. In that case we still would want the community to be able to edit those articles, and therefore it makes a difference for contributors as to where and how they can contribute to those articles. The laid out options answer that question.
  2. Wikidata would potentially change in community dynamics and technical requirements depending on the option selected. Some of the options have a more direct impact on these questions than others.

  I hope that clarifies why we invited you and your project to participate in this consultation, and how your projects would be affected. Thanks for asking! --DVrandecic (WMF) (talk) 11:02, 23 May 2025 (UTC)

• It is still not clear to me the relation between an Abstract Wikipedia item, and a normal human language Wikipedia. Is the point of Abstract Wikipedia to display basic text in any human language that can then be used to create a stub article for that language? What happens when the abstract wikipedia content for a specific changes over time? How is that meant to affect the human language wiki, that already has made use of an earlier version of the text from abstract wikipedia? - Rooiratel (talk) 07:54, 23 May 2025 (UTC)

  @Rooiratel no, in general the output from Abstract Wikipedia is not meant to be a stub to start your own article from (although that is indeed a possible workflow). It is rather thought to generate the articles that don't have a version in your wiki. For example, the island my family is from, Brač, currently has no article on Afrikaans Wikipedia, your home wiki. If so configured, the article would be generated from Abstract Wikipedia in Afrikaans and displayed.

  Now if someone wants to write that article in Afrikaans, they can do so at any time. They can also use the existing generated text as a starting point. But from that point on, the local version in Afrikaans would overwrite the version from Abstract Wikipedia.

  Alternatively, they might also choose to contribute to the Abstract Wikipedia version directly, through the Afrikaans interface of Abstract Wikipedia. In that case, any improvement to the Abstract Wikipedia article would immediately go out to all other Wikipedia language editions that don't have a local Wikipedia article, e.g. to Hindi Wikipedia, which currently also doesn't have an article on Brač.

  I hope that makes sense! Happy to answer further questions. --DVrandecic (WMF) (talk) 11:09, 23 May 2025 (UTC)

• Is this going to be under CC0 like Wikidata or CC-BY-SA like Wikipedia? I'm rather keen on attribution and especially on share alike, and I'm concerned if this becomes the future of Wikipedia, but like Wikidata free for tech companies to turn into something we can't even tell is a copy of Wikipedia. This isn't just an ethical concern, we need to know whether sources are mirrors or independent before we cite them on Wikipedia. WereSpielChequers (talk) 09:04, 23 May 2025 (UTC)

  We should let others answer officially. but for the Wikipedia-like original encyclopedic content you ask about, the answer is very clearly CC-BY-SA. See Abstract Wikipedia/Updates/2021-12-21 re: "Abstract Content for Abstract Wikipedia", and the earlier Abstract Wikipedia/Licensing discussion - noting that these cite CC-BY-SA 3.0 but Wikimedia projects have since transitioned to the up-to-date (and broadly compatible) CC-BY-SA 4.0, and Abstract Wikipedia will likely do the same.
  (CC0 remains a useful possibility for factual claims with negligible creative input: similar in principle to the existing Wikidata statements, but benefiting from the more expressive model of Abstract Content.) Hupaleju (talk) 09:33, 23 May 2025 (UTC)

  @WereSpielChequers as @Hupaleju already answered correctly, in our previous community consultation the decision was that the content of Abstract Wikipedia should be CC-BY-SA (with a likely update to 4.0, pending input from legal). The question of how easy it is to apply the license is indeed a major consideration when weighing the options. --DVrandecic (WMF) (talk) 11:17, 23 May 2025 (UTC)

• I'm here because of a message suggesting that this project involves enWS. I'm intrigued to know in what way the Abstract concept will affect/involve Wikisource. Beeswaxcandle (talk) 09:10, 23 May 2025 (UTC)

  @Beeswaxcandle thanks for the question! Obviously the question goes back to the Wikisource communities: how much do the Wikisource communities want to build shared, multilingual content? If not for content, maybe for community process, overview pages about authors and works, or even -- dare I say? -- translations? With multilingual Wikisource, Wikisource already has an approach towards handling some of these questions. But yes, it might be less directly relevant to the core work of Wikisource than it is for e.g. Wikipedia. Nevertheless, since some of the options would make certain workflows harder or easier for projects such as Wikisource, I thought it fair to invite you to this consultation too. I hope that makes sense! --DVrandecic (WMF) (talk) 11:24, 23 May 2025 (UTC)

  wikisource.org hosts texts in multiple languages that currently do not have their subdomain, but I don't know about specific multilingual features in Wikisource.

  I guess Wikisource could use Wikifunctions in non-content pages (e.g. pages about an author), but abstract content seems less relevant (assuming "abstract content" means "whole sentences"). And I'm afraid this will make wikicode even more frightening to non-geek users, since the wikicode will incorporate not only template calls and occasionally Lua calls, but also Wikifunction calls (unless I understood nothing about Wikifunctions and abstract content, which is possible). Seudo (talk) 13:20, 23 May 2025 (UTC)

  There would be very little applications on most Wikisources for Author pages. The purpose of the Author pages is to list hostable works by that author that were written in or translated into the language of the particular Wikisource. So a suitable translation must exist, and that translation must also be in the public domain. No amount of Wikifunction calls would be able to determine those things automatically. And even if a French edition of a Spanish work exists, none of the data concerning the Spanish work would necessarily be relevant for the French translation. The translator's name would not be part of the original, nor the date of publication, nor the publisher. Nor can titles be auto-translated, because what matters is the new title chosen by the publisher, not a literal translation. Even data like number of pages cannot be used for the new translation, because that too is subject to change when a translation is made and published.

  So, I'm at a loss to see any use at all that this proposal can be for any Wikisource project. --EncycloPetey (talk) 20:34, 26 May 2025 (UTC)

  OK, understood. I thought there might have been places in Wikisource where abstract content might have been useful, but it seems I have been wrong. Apology for the message. I hope that it will turn out that there are interesting applications also in Wikisource, but for now I will defer to your expertise and not consider Wikisource as a place where the concept of Abstract Content might be useful, unless someone else finds a use. --DVrandecic (WMF) (talk) 15:53, 27 May 2025 (UTC)

• Warum gab es eine Nachricht in der deWP, wenn das hier gar nicht uns betrifft? Das hier ist nicht übersetzbar, also sind andere Sprachen offensichtlich unerwünscht. Es kann also kein Projekt außerhalb des englischen Spüracxhraums betreffen, da diese hier gar nicht gefragt werden. Grüße vom Sänger ♫^(Reden) 13:24, 23 May 2025 (UTC)
• How much abstract content will be shared between projects (e.g. Wikipedia and Wikivoyage and Wiktionary) in practice? The divide between lexemes and entities on Wikidata come to mind. If the level of isolation is high, that would make less reason for a Wikimedia-wide centralized shared repository. whym (talk) 11:46, 24 May 2025 (UTC)

  That's a great question, and I really don't know the answer. In theory, I could imagine that a short, three sentence description of a city could be useful for Wikipedia, Wikivoyage, Wikiquotes, etc., but whether the different projects really want to share that kind of content? I find that terribly difficult to predict. --DVrandecic (WMF) (talk) 10:41, 26 May 2025 (UTC)

Discussion

• For #4, wouldn't w:zxx:Q96807071 be the tertiary domain most analogous to Abstract Wikipedia's role among the other language editions? For comparison, wikisource:mul:WS:LANG hosts human-readable source content in multiple languages, whereas AbsWP would use a non-human-linguistic exchange format for its (non-source in the evidentiary sense, but still a translation source) content. — Arlo Barnes (talk) 06:15, 19 May 2025 (UTC)
  • Hi @Arlo Barnes, thank you for your comment. Would you like to elaborate a bit further on what you wrote, please? Are you suggesting something similar to mul.wikisource or...? Sannita (WMF) (talk) 15:12, 19 May 2025 (UTC)
    • Well, I think the location that makes sense in the near term is to use the wikifunctions.org domain (option 3); but presuming that Abstract Wikipedia grows into its envisioned role, in the middle and long terms it should probably be a coequal Wikipedia, using a wikipedia.org subdomain. Since most of the Wikimedia language codes match to the w:ISO 639 codes, making an appropriate selection from one of the special codes in that standard (mis, mul, und, zxx, etc.) seems useful. There was some mention of Abstract Wikivoyage and so on for the other language-specific projects, so depending on whether Wikimedians generally think all the abstract content should be in one place or whether there should be content repositories for each project area, the selected locations might be different. — Arlo Barnes (talk) 18:32, 19 May 2025 (UTC)
• In my opinion, it's quite possible that different kinds of Abstract Content, relating most closely to different existing projects, should be hosted in different places. My view is that Wikidata itself should always be reserved for CC0-licensed content, thus this MUST NOT include the remarkably complex and creative "structure, sequence and organization" of encyclopedic content (which would be licensed under CC-BY-SA much like Wikipedia itself, per previous discussions), but arguably SHOULD include the already proposed Abstract Labels, Descriptions and Senses/Glosses and also, more generally, any other sort of broadly factual claims which simply cannot be expressed by the existing Wikidata model (due to its lack of generality and 'compositionality'), as well as supporting content relating to, e.g. basic semantic constructs (the role of 'Superlative', 'Definition' and 'Rank' in the mock-up above - though these might also end up on Wikifunctions). This means that Abstract Content for Abstract Wikipedia SHOULD be allowed to reference and transclude Abstract Content from Wikidata, much like custom Wikibases today are able to reference Wikidata items and properties.
  Please note that under this proposed model, Wikidata MAY also end up hosting large volumes of Abstract Content, such as the literal, close "translation" into Abstract Content of an existing public domain text. The distinction would be driven by feasible licensing and usage conditions, not volume of data. (Most of all, we should avoid making Wikidata licensing legally uncertain which would threaten to destroy much of its current usefulness to outside reusers!)
  We SHOULD also be mindful of the needs of other projects, like Wikibooks (there is no reason why we might not want to make textbooks and tutorial information also available in a language-independent version at some point), Wikivoyage (which includes travel-guide information that is intentionally somewhat subjective and thus would be out of place both on Wikidata and on Abstract Wikipedia), Wikiquote (which quotes a lot of "fair use" content that it would be inappropriate to include on Wikidata) etc. etc. These would then merit their own Abstract Content spaces, much like Wikipedia itself. --Hupaleju (talk) 11:36, 19 May 2025 (UTC)

  @Hupaleju: thanks for these thoughts! I agree that license considerations should play an important role. And having literal values in Wikidata on properties with a different license would be a complexity which we probably want to avoid. The same should probably true with regards to the Wikifunctions main namespace, we probably don't want to make the license more complex there.

  So one major consideration should indeed be how to apply relevant licenses and separate things accordingly to make that more or less straighforward. Again, thanks for raising this important point! --DVrandecic (WMF) (talk) 10:28, 20 May 2025 (UTC)

  @Hupaleju I also find the suggestion to do a mix of the proposals interesting: Option 4 for Abstract Content for Wikipedia, and in addition Option 3 or 4 for other uses of Wikifunctions in Wikidata, such as glosses, abstract descriptions, etc. --DVrandecic (WMF) (talk) 10:34, 20 May 2025 (UTC)

• I'd say the best is either option 3 or 4. This is a project which has a radically different way of creation and working compared to Wikidata, or others for it to be integrated into another project and therefore deserves its own place to be built. Having it on Wikifunctions has the additional benefit of having both the people who created the functions for translations, and the people who create the content using this model in the same place, which I think will be better in terms of easy debugging and faster development. Having this on a completely new domain is also a good option to consider. ~/Bunnypranav:<ping> 12:14, 19 May 2025 (UTC)
  • What domain name are you considering? https://abstract.org or the like would be nifty but might not be available depending on the current owners. — Arlo Barnes (talk) 18:38, 19 May 2025 (UTC)

    For the domain, I'd lean towards what you said above. Another option is just abstract.wikipeda.org or likewise for other projects. ~/Bunnypranav:<ping> 04:25, 20 May 2025 (UTC)

    We can think of the name of the project and the domain at a separate point, once we have decided whether we want a new project. I am not a fan of calling it Abstract Wikipedia, to be honest, but again, we can get to that decision if we take that path. --DVrandecic (WMF) (talk) 10:30, 20 May 2025 (UTC)

• The fourth option is more adequate. "Content" about an entity can be of many textual genres. If we're building an abstract encyclopedia, that's one project. If it's an abstract travel guide, that's another project. Attaching the content into an existing project will limit ourselves into just one genre and not allow the full diversity of genres we have in Wikimedia. Arcstur (talk) 14:11, 19 May 2025 (UTC)
  • On the other hand, keeping the 'genres' distinct allows the unique editor styles each has cultivated to persist. — Arlo Barnes (talk) 18:43, 19 May 2025 (UTC)
• I like the idea of having abstract content in different places. From my point of view abstract content should be available after community consensus in every Wiki. The decision if it should be activated is one of the local community of the specific Wiki. I wish it is possible to write it down in Wikitext. One solution from my point of view is, abstract content should be a feature integrated in the Wikitextparsers like Parsoid. There is a simple kind of generation of abstract content available in Wikitext within Mediawiki with the substitute function.--Hogü-456 (talk) 20:23, 20 May 2025 (UTC)

  Given that we will have function calls enabled everywhere, it is expected that you can have such calls everywhere. I am not sure it's always a good idea: I don't see the benefit on, say, writing in Abstract content on the Croatian Wikipedia? There are many functions which will make sense, but I am having a bit of trouble to find many use cases for abstract content in a specific-language Wikipedia. --DVrandecic (WMF) (talk) 11:18, 21 May 2025 (UTC)

  @Hogü-456, you'd never write Abstract content on a single wiki. Why would you bother with that? If it's just going to be used on a single wiki, just write the plain old sentence in the local language.

  I see this question as being similar to mw:Global templates: Should we have a single place for certain templates, which local editors can choose to use, or not use? Imagine that {{cite web}} and {{citation needed}} were available globally. You wouldn't want to think, "Oh, I need to call the French Wikipedia's cite web template and the Spanish Wikipedia's citation needed tag and the English Wikipedia's template for..." You would want them all to be in the same place. And you'd never create a template that was going to say "Jupiter is the largest planet in the Solar System", because you don't need that sentence to appear in lots of articles and lots of Wikipedias. WhatamIdoing (talk) 16:18, 22 May 2025 (UTC)

  There are for example sections in articles who represent data about demography. For example this section about the population in the English Wikipedia article of Windsor in Conneticut. It is a long list of facts written down in sentences. If there is enough data in a structured format available for it, it is possible to generate such a text using abstract content and it can be used in many articles. As I like facts I enjoy reading such sections and I think abstract content can help generating it and it could be also interesting for other language versions of Wikipedia. Regarding the multilingual aspect of abstract content I am not sure how soon it will work and how far it will become real to support small language versions with it. So I see a use case of abstract content in a framework for creating boilerplate templates working for a specific language. From my point of view it is necessary to check a text having a person who understands the language well before publishing it. It is possible to use a template for generating the text too and so I am not sure if abstract content is the best choice for such examples. Hogü-456 (talk) 19:49, 22 May 2025 (UTC)

• I worry about the added load on Wikidata, particularly on the query service. Wikidata just split the query service because of concerns that it would be unable to keep up as Wikidata grew. Any solution needs to keep these concerns at the forefront. My view is that the best place for this information is a separate project, as the data is different from other projects - not text and not factual statements. Peter F. Patel-Schneider (talk) 13:49, 21 May 2025 (UTC)
  • Comment: We should keep in mind that the WDQS is quite distinct from Wikidata itself, i.e. the main site. We're still quite far from having a real data model for Abstract Content comparable to the existing data model for Wikidata entities, properties, statements etc. but while it may of course be seen as desirable in a general sense that some Abstract Content be made available as queryable RDF (or even quite possibly as RDF* which seems to better address 'compositionality' concerns, thus arguably narrowing the gap with the already-proposed "frame" models) via the Query Service, this is a decision that it will clearly be possible to make separately within the Wikidata project, similar to how the decision was reached to split off the scholarly citations data.
    There are also third-party services that work much like the the Query Service but using other backends (e.g. QLever) that do not seem to be showing the same scalability concerns; such services may find it quite beneficial to have some sorts of Abstract Content available within Wikidata itself (of course, as far as can allowed by the above-mentioned licensing concerns; i.e. in my view, basically sticking to factual claims and excluding the unambiguously original and "creative" content that arguably makes up the bulk of what's currently hosted in Wikipedia and other non-Wikidata projects). --Hupaleju (talk) 15:14, 21 May 2025 (UTC)

  Yes, I think those are really important points, which we are certainly taking into consideration. We definitely don't want to increase the risk of Wikidata having technical problems in the future. --~~~~ DVrandecic (WMF) (talk) 11:33, 23 May 2025 (UTC)

• I would agree in general with the comments suggesting that abstract content reside in a separate project (option 4). If instead it were possible to store abstract representations of facts not representable as Wikidata statements individually--that is, each fact has its own entity ID (like "F12345") or subentity ID (much as statements on items have UUIDs, like "Q123-4567-...-89abcdef0123") with its own separate references--and then have abstract content consist of arrangements of those facts--so that the abstract article for Q123 would consist of rendering three statements and three fact sub-entities from that item--then I could see those fact subentities stored in a separate slot of Wikidata items. Mahir256 (talk) 22:47, 21 May 2025 (UTC)

  The way I understand it, these "abstract representations of facts" stored in Wikidata would themselves be Abstract Content, though not of the same character as the Content that may be involved in a "full" Abstract Wikipedia article.
  Also, while in many cases it may be quite practical to reference individual "facts" by subentities of some existing Wikidata item, there are also potential facts that are not so unambiguously linked to a single Wikidata item, hence where filing them as subentities of one would ultimately be somewhat artificial. This may end up being a harder problem than the one we face now of where each individual Wikidata statement should be stored, since that can be decided based on the property type and the required "subject" item for the statement. Much of the projected power of Abstract Content arguably comes precisely from not having such tight restrictions, and indeed from allowing "content" to be built somewhat arbitrarily in some sort of vaguely tree-like structure, starting from elementary "building blocks" involving some sort of well understood semantics. Hupaleju (talk) 23:37, 21 May 2025 (UTC)

  @Hupaleju yes, agreed with your points, but I think that for some cases it might still be interesting to consider extending Wikidata the way Mahir is suggesting. --DVrandecic (WMF) (talk) 11:38, 23 May 2025 (UTC)

  @Mahir256 thanks, that's a great consideration. I'll think about it. --DVrandecic (WMF) (talk) 11:37, 23 May 2025 (UTC)

• I believe that language-neutral content should reside in its own project. I don’t find the “article as function” argument especially compelling. It is up to the contributing community, of course, but I imagine that language-neutral encyclopaedia Articles will require the same editorial structures as any Wikipedia edition: categories, transclusions, redirects, infoboxes, sortable tables, captioned images etc. I further suppose that there will be content templates that we can default to, according to how the article’s subject is categorised.
  However, I also believe that there is an equivalence between Wikidata statements or claims and their language-neutral representations. Arguably, this is a non-trivial correspondence, but I would support the view that any copyright in such content should be explicitly disclaimed (CC0). We previously discussed such representations using the term “infoText”, without considering copyright. I have no settled view on where any contribution that simply maps or filters Wikidata content should reside, but I suspect it will be simpler to have a single CC0-specific location within the language-neutral domain. GrounderUK (talk) 09:53, 22 May 2025 (UTC)

  Thanks for explicating the arguments re the community processes and their influences on the decision. Those are strong arguments. --DVrandecic (WMF) (talk) 11:41, 23 May 2025 (UTC)

• I dislike Option 5.3, to put it at the English Wikipedia. Language-neutral content should not reside in a language-specific project. Also, people might be blocked at enwiki, and thus unable to contribute to something that will mostly benefit non-enwiki wikis. WhatamIdoing (talk) 16:22, 22 May 2025 (UTC)
• Given the peculiarities of the various projects, both stylistic (for example Wikipedia or Wikivoyage) and linguistic, and the possible technical problems to be faced, I would initially consider it appropriate not to separate the wiki functions from the abstract Wikipedia, so I would choose option 3, and I would postpone the final choice on the placement of the abstract contents to a later time. I believe that the objection according to which the proximity of the technical and non-technical parts could obscure the separation, at first glance does not represent a big problem, but rather an advantage in making developers understand the needs of the users. However, if this would lead to big problems in the relocation of the abstracts, and therefore it were appropriate to think about a definitive placement, I would choose option 2 (after evaluating the load on the wiki data), or even option 5 (after evaluating the compatibility of the licenses with those of Commons).--Ciaurlec (talk) 21:24, 22 May 2025 (UTC)

  @Ciaurlec oh, thanks! I haven't thought about a temporary answer involving a later move. That's an interesting contribution. Thanks! --DVrandecic (WMF) (talk) 11:42, 23 May 2025 (UTC)

• I don't think option 5 is a good one (leaving aside option 1 for the moment, which is technically a variant of option 5). In essence, this project is writing articles using a language that looks like nested function calls and is intended to be easy to translate to actual languages in use, instead of using some other language as a base for translation. Accordingly it will need to develop its own community of writers fluent in the abstract language and establish its own community norms. I think it will be overly challenging to try to build this community alongside an existing community, with too much potential for the goals of the two to clash. Options 1 and 2 might work as a storage location, but I still think there needs to be a suitable home for the abstract language community. isaacl (talk) 22:11, 22 May 2025 (UTC)
• I think the option 4 is better, actually I thought that was the plan since the beginning, and the main reason is because the evolution of the project over time. We can have in the future many improvements that can be hard to implement if the abstract content is in some existing wiki that was not originally created to store abstract content. With a dedicated wiki we can develop more easily new tools and features specific to deal with abstract content. And I also think that we should create the "abstract" as a wiki language, and not only one wiki. So initially we would have abstract.wikipedia.org, after some time we can create abstract.wikivoyage.org, and so on. Abstract content is a new way to structure knowledge and ideas, that is exactly what a language is about. Danilo.mac talk 00:59, 23 May 2025 (UTC)

• Man sieht wie wichtig "Euch" das Feedback der verschiedenen Communities ist! Daher habt ihr es sicherheitshalber nur auf englisch veröffentlicht und nichtmal wenigstens als Feigenblatt es zur Übersetzung markiert. Danke für Euer Interesse an einem breiten Feeback für dieses very delicate issue. 🤣 SCNR. Keine Antwort an mich nötig, ich wollte es nur mal wieder herausstellen. Nicht zuletzt weil ja direkt im 1. Satz etwas steht von " contribute their voices in their language ". Herrlich ...Sicherlich ^Post 06:30, 23 May 2025 (UTC) es jetzt zu übersetzen ist auch nutzlos. Die Announcments waren nur auf englisch. Wer kein Englisch kann wird sich nicht aus versehen hierher verlaufen. Die Chance ist vertan

  @Sicherlich Es tut uns leid, dass wir die Nachricht auf Englisch geschickt haben, aber wir hatten keine Zeit, sie in andere Sprachen zu übersetzen. Das nächste Mal werden wir es besser machen. Sannita (WMF) (talk) 11:26, 23 May 2025 (UTC)

  Funny thing; I get responses like that from WMF since years (decades?). So; no you wont. There is no concept of any kind about languages in WMF. Sometimes it is translated, usually its not. If it is, than the languages are randomly chosen. Makes no sense ...Sicherlich ^Post 11:46, 23 May 2025 (UTC) and its not about me personaly, nor is it about German.

  @Sicherlich in this case, where we addressed all communities at once, it wasn't just possible to address each single community with a translated message, this is why we used English. But you can express your ideas in German, as I already said at the Kurier. Sannita (WMF) (talk) 13:49, 23 May 2025 (UTC)

  It was not even possible to translate this page to any other language? That's a clear show of complete lack of respect for the communities.

  Without at least 10-20 complete translations this RfC is not worth anything at all, as it excludes 90% of the communities. Grüße vom Sänger ♫^(Reden) 13:54, 23 May 2025 (UTC)

  You didn't even manage to translate it in Italian yourself, although you are paid as a communications specialist by us, the community, who generates the money for the WMF. Grüße vom Sänger ♫^(Reden) 14:09, 23 May 2025 (UTC)

  Its not about adressing it in all languages. Its about at least trying to do it for the major ones. And even as I pointed it out you still don't understand. Its NOT about me and its NOT about German. You (aka WMF) did not even put the smallest effort into it. and the response one gets from you (WMF) is always like you did now. So its either (1) you just pretend you care, but really aren't, (2) your internal communication is pretty poor or (3) the learning curve is f(x)=1. I assume its (1) but maybe you offer a different explanation. (oh usually the excuse of WMF is (4): we don't have the funds. Don't try this: the figures are public ...Sicherlich ^Post 15:56, 23 May 2025 (UTC)

  Die Diskussion hier genau wie die Fragensektion sollte nicht auf einer übersetzbaren Seite sein. Wofür gibt es denn Talk pages? Ich kenne einen Workaround, siehe Translations:Abstract_Wikipedia/Location_of_Abstract_Content/69/de, bin aber nicht sicher, ob das jeder schnallt. Zum Thema: unbedingt eigenes Projekt! Jerusalem-Artikel aus nur einer Quelle Wikidata? Oder solche zu prähistorischen Gruppen, die jedes Land für sich beansprucht und benamst? Unvorstellbar. Euer Vorschlag, astronomisches Objekt Jupiter, ist zweifelsfrei als unkritisch erwählt, wiewohl nach einem Gott benannt. Beim Mond sieht das aber ganz anders aus, ist doch en:Allah der Mondgott, was wiederum von Gläubigen bestritten wird, JHWH der Sturmgott. Beide waren vor der Monotheisierung familiär eingebunden, was wiederum zu wissen und wiederzugeben mancherorts als steinigungswürdige Häresie gilt. usw. Sargoth (talk) 00:04, 24 May 2025 (UTC)

  Abstract Wikipedia ist ja nicht dafür da, die Inhalte der Wikipedien zu ersetzen, sondern diese, wo sie fehlen, zu ergänzen. Die Artikel, die einer bestimmten Sprachversion besonders wichtig sind, sind ja auch diejenigen, die am wahrscheinlichsten in dieser Sprachversion zur Verfügung stehen werden, und entsprechend nicht von Abstract Wikipedia stammen werden. Und selbst wenn es nur bei unkritischen Artikeln hilft, ist ja schon viel geholfen. --DVrandecic (WMF) (talk) 10:38, 26 May 2025 (UTC)

• Options 1, 2, & 5 are problematic from a couple of perspectives. 1) Cultural. These existing projects have cultures that would need to either change to accomodate these new concepts or accept that there is a subset that has a different culture and ethos to the way everything else is done. 2) Administrative. This ties in with the cultural aspects. There would likely need to be specialist administrators to oversee the "AbstractWiki" parts, including the development of policies and managing vandalism. At the same time, those administrators would be expected to be aware of and implement the wider policies and procedures of the project. I have seen such expectations build into resentment, cabals and warfare, both on and off Wiki.

  Option 4 has the advantage of being specifically about the Abstract concept, but is disadvantaged by being focused on the Wikipedias. If the concept that the other projects are to be involved at some point, then there would be the need to develop an AbstractWiki for each project and thus dilute the knowledge and experience gained from the first. If Option 3 were chosen, then each project could be a subdomain/namespace. However, given the size of each of these there is the potential to outgrow its space. Beeswaxcandle (talk) 09:02, 23 May 2025 (UTC)

• Option 4 provided it is under CC-BY-SA. I get that an abstract version is going to be difficult to achieve where concepts are different. This is going to be at least as difficult as getting a mutually agreed definition of football, pants, or Cambridge that works on both sides of the Atlantic, but the exercise should be interesting. Hopefully it will also help identify factual differences between Wikipedias, much as before Wikidata, the death anomalies project used to identify people who were dead on one language version of Wikipedia and alive on another. WereSpielChequers (talk) 09:24, 23 May 2025 (UTC)

  Cambridge had to work in English both sides of the Atlantic already! :)

  Regarding the license, yes, agreed, that's the outcome of the previous licensing consultation. Abstract Content for Wikipedia should be under CC-BY-SA. --DVrandecic (WMF) (talk) 11:46, 23 May 2025 (UTC)

  This content is not reaching any treshold of originality and therefore cannot be licensed by CC-BY-SA. However Option 4 does make the most sense at it won't interfere with other projects and would not relay harm in form of bad publicity if the abstract content creates rubbish. --Matthiasb (talk) 00:50, 24 May 2025 (UTC)

  This content is not reaching any treshold of originality and therefore cannot be licensed by CC-BY-SA. --Says who? First of all, many Wikipedia articles are absolutely original today and would be just as original in a language-independent version, because the "structure, sequence and organization" of a complex text or even of a computer program can very clearly be protected by copyright. Besides, even if you argued that some Abstract Wikipedia articles are not sufficiently original, all that would mean is that folks might be able to ignore the licensing conditions. The license itself would still be valid as far as ordinary users are concerned. Hupaleju (talk) 05:50, 24 May 2025 (UTC)

• I think option 4 is the only one viable : to be dependant of another project will probably hamper the evolution on long term and might create tension. Wikidata has managed to build a community on its own space, despite being fairly technical, so I don’t see why Abstract couldn’t do it.

Now I address the subject from the Wikipedia in French perspective, it’s not totally in the current scope but worth to be mentioned I think. Considering the still high tensions around the Wikidata theme, the idea of direct inclusion of content from Abstract in WP:fr will probably be widely rejected. So I think the best way to link the content will be through the language menu, with an entry « international Wikipedia ». The problem is that on such a big Wikipedia, the content from Abstract will be interesting mostly for subjects that doesn’t have an article yet. However, it’s not possible currently to link the page of a non existing article to Wikidata. The placeholder extension is a bypass but it’s not activated on WP:fr because it imports content from outside the project, something the community is hostile to. I think the way Abstract will be reused on other projects is already central, because most people will come to Abstract from another project, hence if Abstract is rejected on other projects, people will not know about it or not see the point to spend time with it. --Runi Gerardsen (talk) 11:22, 23 May 2025 (UTC)

• i would  Support (prefer) option 4 abstarct.wikipedia.org, as it is in fact writing an wikipedia article, using functions instead of templates or text.
  

Option 3 in wikifunctions could also work (  Support), as abtract content and wikifunctiosn content rely heavily upon each other and both will be quite complex to write.

I absolutely are  Strong oppose to option 2 (new wikidata data type) as then it will be very hard to find for users where to update the abstact content and very hard to see the history of just the abtract content. HenkvD (talk) 12:40, 23 May 2025 (UTC)

• Warum ist das hier und nicht in der enWP, wo es doch augenscheinlich allein um Englisch geht? Ohne eine Übersetzung in mindestens 10-20 Sprachen ist das Ganze hier komplett wertlosw für alle Projekte, in dxenen Englisch nicht die Muttersprache ist. Ich weigere mich, dieses arrogante Ansinnen der monolingualen Anglophonen hier inhaltlich zu bewerten, sie wollen offensichtlich nicht, dass Nicht-Englischsprachige hier mitmachen. Grüße vom Sänger ♫^(Reden) 13:04, 23 May 2025 (UTC)

  @Sänger Was meinst Du mit "nicht übersetzbar"? Oder meintest Du "nicht übersetzt"? --DVrandecic (WMF) (talk) 13:30, 23 May 2025 (UTC)

  Nicht übersetzbar. Diese Seite hier ist gegen das Übersetzen geschützt, also geht es hier nur iúm die monolingualen Anglophonen. Grüße vom Sänger ♫^(Reden) 13:32, 23 May 2025 (UTC)

  Gereade gesehen, es gibbt doch Teile, die übersetzt werden könnten, aber mal wieder nicht wurden. Also interessieren die internationalen Projekte mal wieder niemanden in der WMF, wie üblich. Grüße vom Sänger ♫^(Reden) 13:34, 23 May 2025 (UTC)

  Ein RfC kann erst dann gültig gestartet werden, wenn der Text in mindestens einem Dutzend Sprachen vorliegt, vorher ist es vollkommen wertloses Gelaber in einer beliebigen Sprache. Grüße vom Sänger ♫^(Reden) 13:36, 23 May 2025 (UTC)

  Hmm, laut Requests for comment/Policy kann ich nichts finden, dass das bestätigt. Fände das aber keine schlechte Idee: willst Du das als Regel vorschlagen? Bin auch offen dazu, dass wir die Konsultationszeit verlängern, sollte es Übersetzungen geben. --DVrandecic (WMF) (talk) 14:38, 23 May 2025 (UTC)

  Il est vrai que traduire la page projet et ses sous-pages en français serait une bonne idée pour qu'on essaie d'y comprendre quelque chose. Croquemort Nestor (talk) 16:10, 23 May 2025 (UTC)

  @DVrandecic (WMF): Das ergibt sich ohne explizite Regel aus Respekt. Von Anfang an die große Mehrheit der nicht-anglophonen WikimedianerInnen auszuschließen, indem gar nicht erst der Versuch unternommen wird, sie angemessen anzusprechen, delegitimiert ein solches Projekt von Anfang an.

  Dieser vollkommene Mangel an Respekt, der hier mal wieder mehr als deutlich wird, ist es, der die WMF so unbeliebt macht bei allen, die nicht aus der enWP-Blase kommen. Grüße vom Sänger ♫^(Reden) 08:21, 25 May 2025 (UTC)

• The question of how "long-form" content might be edited on Wikidata is interesting in its own right. Ultimately, we may want to enforce a workflow similar to the one currently used on Wikifunctions, where a Function implementation must first be written and then its linkage to the Function definition has to be confirmed by a trusted user: similarly, Wikidata long-form content might have some sort of provisional status at first and live in some sort of sandbox or talk page, with it only being added to the item after some sort of check by the community. The existing limits per Wikidata item might in principle be addressed by allowing claims about a single Wikidata item (i.e. Q-number or L-number) to be moved to different MediaWiki subpages, but still pertain to the same entity.
  I agree with the concern that editing Abstract Content inline with the Wikidata item might be difficult in many cases, hence something closer to the default Wikitext editing experience would work better. --Hupaleju (talk) 13:08, 23 May 2025 (UTC)

• I think the options as stated are unhelpfully mingling the technical and social aspects (or, the backend and frontend) of the future project. When an editor creates abstract content, which domain they're on should be orthogonal to which database the content ends up in. There's a note about Wikidata's interface being unsuitable for viewing and editing long-form content—so don't use that? But that shouldn't proclude the project from living on a subdomain of wikidata.org. YoshiRulz (talk) 22:18, 23 May 2025 (UTC)

  @YoshiRulz Thank you for your thoughts! Could you elaborate a little bit further? Where the project is located has major effects on the editor experience, particularly since the community of the project hosting Abstract Wikipedia can put editing restrictions on contributors, rules on the content, etc. As far as I understand it, assuming that we can put an editing interface that interfaces to a completely different project can be possible in some cases -- as the Wikidata Sitelinks and the Wikidata Bridge demonstrate -- but is always difficult, particular when the content starts to become more substantial in size. But maybe I misunderstand the suggestion. --DVrandecic (WMF) (talk) 10:29, 26 May 2025 (UTC)

  My point is exactly that "Who should be responsible for moderation and style?" is the key part of this consultation. Not the domain name, nor other things like the exact project name or visual identity, which I'm sure will be bikeshedded later. Being clear about technical limitations is good, I just felt it was overemphasised—and I should say that came mostly from reading the #Summary of internal discussions section, so maybe it was my expectations which were at fault.

  On the subdomain point: I don't know anything about the WMF server infrastructure, but I know that dividing subdomains between servers is easy compared to splitting by path/directory. YoshiRulz (talk) 15:54, 26 May 2025 (UTC)

  @YoshiRulz gotcha, thanks! The technical considerations are relevant too, but I agree, that the social implications play a more fundamental role, as these are much harder to be changed later, if at all. Thanks for emphasizing the issue! --DVrandecic (WMF) (talk) 15:44, 27 May 2025 (UTC)

• IMHO the most appropriate option is a new project (option 4) — though not exclusively for abstract encyclopedic articles, but for generic abstract textual content. I can see this project working in a similar way as Wikimedia Commons does today for media and raw data, but for language-independent prose instead.
  Some of the reasons I feel a separate wiki is a good idea:
  • Writing Abstract content is going to require a specific kind of expertise and writing style. Anyone who has worked with content that needs to be translated into very diverse languages knows how challenging that can be. This is not something that can be an afterthought or secondary focus of the community working on the project.
    For example, I'd expect the experience of Simple English Wikipedia, authors of translatable pages (e.g. Tech News) and translatable software in translatewiki.net to be a useful model for part of what this community needs to develop; but it still will need to chart new ground.
    Put simply, the editing community for abstract content will need to develop and constantly refine its own style guide and best practices, which IMO is a much more crucial success factor than any technical considerations. Having its own wiki, growing gradually and scaling its processes accordingly, seems like the best social structure to support this work.
  • A new project can easily be made to support generic kinds of language-independent content, thus providing material that could be used by Wikipedias, WikiVoyage, etc.
  • I can see the same format of abstract content existing in smaller parcels within existing projects (for example, as Wikidata item descriptions, Commons category descriptions, etc.), the same way that even though Commons exists, wikis can still host local images if they prefer.
  • I think it's reasonable to be cautious about starting new communities that may not take off as we'd hoped, given past examples in the movement (e.g. Wikiversity, Wikinews, etc.); but given the success of Wikidata and WikiFunctions, and the careful deliberation that the WikiFunctions/Abstract Wikipedia project has been characterized by so far (this discussion as a case in point), I would argue that some cautious optimism is warranted.
  • The challenge of creating and editing this new content format will require a quite unique interface; a separate wiki makes it easier to provide and evolve this new interface, via MediaWiki extensions, gadgets, stylesheets, etc. (think e.g. how editing translateiki.net or Wikisource involves a quite specialized UX) and dpoing this on a separate wiki would not interfere with (or add additional complexity to) the UX of existing wikis.
  --Waldyrious (talk) 22:55, 23 May 2025 (UTC)

  @Waldyrious: thank you for your thoughts, I really enjoyed reading your well-reasoned considerations. That's super helpful, and your points have indeed causes some change in my thinking.

  A further thought: what about the Abstract Content not being on an entirely new project, but hosted within a new namespace on Wikifunctions? Since one of Wikifunctions' main goals is to provide the functions needed to build Abstract Content, having those two together on the same project would have certain advantages. What do you think with regards to that compared to a completely new project? --DVrandecic (WMF) (talk) 10:33, 26 May 2025 (UTC)

  I can definitely see how the natural language functions existing in the same wiki as the abstract content may be helpful, just like it's easier for templates to live in the same wiki where they're used (in the case of templates there's a case to be made for central hosting, but that's a separate issue 😄). I can even agree that that benefit may take precedence over the factors I listed above. However, I wonder if mixing the two in the same wiki might not muddle the waters between what is Abstract Wikipedia and what is Wikifunctions even more, preventing either to evolve to its full potential.
  If the initial implementation is done in the same wiki, I would at least expect the path for an eventual split to be considered in advance and well prepared, so that such a transition, should the communities decide it's warranted, would be as painless and lossless as possible. Waldyrious (talk) 18:50, 26 May 2025 (UTC)

  Great points again, thank you! I found that extremely helpful, thanks! --DVrandecic (WMF) (talk) 15:45, 27 May 2025 (UTC)

• It is great idea, I am agree with it completely.July 2806

12:52, 24 May 2025 (UTC)

• Option 5 mit der englischsprachigen Wikipedia klingt nicht so dolle. Muss mir das alles hier nochmal im Detail durchlesen, aber aus dem Stehgreif sehe ich ein direktes Verknüpfen mit enwiki kritisch. Nyamo Kurosawa (talk) 18:18, 24 May 2025 (UTC)

  Na ja, solange es dann auch bei denen bleibt und ander Projekte nicht kontaminiert werden von irgendwelchem Maschinenschrott, kann das gerne so bleiben. Wichtig ist, dass dieser Unsinn in keinster Weise irgendwie echten Enzyklopädieprojekten übergebügelt wird, wenn diese das nicht explizit mit großer Mehrheit so wünschen. Grüße vom Sänger ♫^(Reden) 08:18, 25 May 2025 (UTC)

  @Nyamo Kurosawa: dem stimme ich zu. Ich wollte es nur als eine potentielle Möglichkeit ins Spiel bringen. --DVrandecic (WMF) (talk) 10:42, 26 May 2025 (UTC)

  For largely undocumented minoritized languages like the Tyap language, I think at the moment, we have so many definite articles to worry about. German learners think things are hard with 'der, die, das'; well, Tyap has 'hu, ji, ka, wu, ba, na' to worry about. Not funny at all. Machine contents would be great but we will have to fix some basics first to employ machine translations in the Tyap Wikipedia and Wiktionary later in the future. We have some catching ups to do, manually. Warm regards, Kambai Akau (talk) 12:23, 26 May 2025 (UTC)

  @Kambai Akau: Thank you! Yes, the whole point is that we do not use machine translation, but rather allow the community to write language functions and lexicographic content for Tyap themselves. I can see that there are 47 Lexemes about Tyap in Wikidata currently. I would hope that Tyap nouns are marked with the right noun class so that the correct article can be chosen, but I know virtually nothing about Tyap. --DVrandecic (WMF) (talk) 15:09, 26 May 2025 (UTC)

  @DVrandecic (WMF), thanks for giving more details about this. I am yet to grasp the entire concept really strongly. All the while I have thought of it like a machine translation concept. Our community is made up largely of people who are illiterate in Tyap or have insufficient knowledge in Tyap, thus making the work more on a very limited number of volunteers who may not entirely be devoted. Splitting that little number across projects like Wikipedia, Wiktionary, and Wikidata (lexeme translation) thus gets really slow. However, when we are really ready to up our game, giving more attention to the Wikidata lexemes (which I think we should), I will come to ask for someone from the Foundation to take my community through the basics of Wikidata lexeme editing (it could be you, if you are chanced). Hopefully by October 2025. We will definitely need it. Warm regards, Kambai Akau (talk) 20:26, 26 May 2025 (UTC)

  @Kambai Akau there are several options for this kind of training sessions! I'd be happy if you reach out to me or @Sannita (WMF) when the time comes, and we can point you to the right resources. Thanks! --DVrandecic (WMF) (talk) 15:46, 27 May 2025 (UTC)

  Thanks, @DVrandecic (WMF)! I will contact either of you on it as the time draws nigh. Warm regards, Kambai Akau (talk) 19:11, 27 May 2025 (UTC)

• Have you considered putting it in a different namespace on Wikifunctions? Compared to option 3 as written, I think that would be much cleaner than intermingled ZIDs, and would mitigate some of the clash-of-communities issues. For example, the new namespace could be CC-BY-SA licenced, user rights could be targeted at the correct namespace, and the UX could be quite distinct. --99of9 (talk) 05:33, 27 May 2025 (UTC)

  This is a good option. As some stated above, a seperate namespace on Wikifunctions will also allow for easier splitting to a completely new project if deemed necessary in the future (like option 5). I think this mostly aligns with option 5, but with the existing project being Wikifunctions (not listed above). ~/Bunnypranav:<ping> 06:32, 27 May 2025 (UTC)

  Yes, agreed. Given this consultation, this is starting to become one of my two favorite options, and I haven't really considered it before. --DVrandecic (WMF) (talk) 16:00, 27 May 2025 (UTC)

Mapping items and content, how to find content, entry points

I note from the discussions above that one problem is that there is an issue that be open after all : how to map the topics and the "abstract articles". Is it a one/one mapping between Wikidata items and abstract articles (one/at-most one actually, there might not have any abstract content for an item, a "one item/many abstract contents" ?

Mapping topics has technical issues that have social implications with the contributors. Qids are the natural identifier for topics, only them can be actually used when there is no article in a topic on a Wikipedia, and they are the most stable. It has the problem that a community might be reluctant to use them in the core of an article, especially when editing from the wikicode (it might be less of a problem with visual editor because it can map the id and the label and select the item automatically, potentially, if there is a item selection mechanism). So to reuse some abstract content in a Wikipedia (or wikidata content on an item whatsoever), on frwiki, you can use the identifier indirectly in an infobox call for example. In turn this can be used, in wikis in which it is activated, with the "Article placeholder" extension which could be used to use abstract articles on local wiki. But a community might not want to do that at all for various reason, so we can't really assume the content can be findable from a wiki.

One entry point for the whole thing might be the wikipedia.org domain which currently lets you select a topic and a project you are interested in, the topic could be any wikidata item(?), abstract content could be provided here if community and foundation are OK with this, to make the landing page a bit more like a search engine landing space who redirects you to where you want to go. Not sure of how this page is popular.

Wikidata on the other hand has a natural mapping between a space for abstract content and items. The "create a new item" button is present here. You could have several type of abstract contents associated to an item (provided it's supported by community), a "autodescription" content for example, which is natural to have, and if it uses information from the item data the editing interface for the item is also present at the same place. This is also relevant from an "article" abstract content : when writing / testing abstract content you might want to edit the item data in parallel for convenience … (you might also want to edit the lexical data but it's another line of story, the mapping is way harder). I'd be inclined these points are positive points for storing the abstract datas in Wikidata close to their item pages.

Not well structured a comment and on definitive answer but I don't think all this point have been raised yet. TomT0m (talk) 08:50, 27 May 2025 (UTC)

• In principle you could use Wikidata's Q-items as "topic identifiers" while still editing the article-form Abstract content on a separate project. It is already the case that each article on any one Wikipedia language edition is supposed to be linked to a single Wikidata item (though that Wikidata item may be one that simply identifies a "Wikipedia article with multiple topics) and Abstract Wikipedia needs not be any different.
  It has the problem that a community might be reluctant to use [Q-items] in the core of an article, especially when editing from the wikicode (it might be less of a problem with visual editor because it can map the id and the label and select the item automatically, potentially, if there is a item selection mechanism). - The Wikidata Query Service (WDQS) text-entry UI solves this issue by displaying a "hint" about the labeling of a Q-item when you hover the mouse pointer over it, and allowing one to "search" for Q items via a keyboard shortcut. These solutions could be imported to the Wikitext editing interface. Hupaleju (talk) 11:22, 27 May 2025 (UTC)

  Sure, it could be, but this would either require a new syntax, which is quite rare in the wiki world, or a special treatments of links such as d:Q42. But template currently usually use the "Q42" raw string for Wikidata identifier. A new templatedata parameter datatype could help of course. But it's not done and a global thinking about how all this interacts with the project goals and the communities and what they want could be useful to motivate. It's obvious to me from the start that identifiers from Wikidata could get a better handling in wikis, I felt quite alone in this so the traction might not be easy to get and utility might not be so easy to motivate to communities. TomT0m (talk) 17:56, 29 May 2025 (UTC)

I am going to start with my least preferred option:

• I do not like Option 5 because it would put our abstract content on a wiki where it does not really belong. Commons is a media repository, Meta is not a content project and the English Wikipedia is probably the Wikipedia that has the least benefits from abstract content. Furthermore there are lots of specific rules on enwiki that we might not want to have for the abstract content.
• My main concern with Option 1 and Option 2 is that it would be another burden for the Wikidata infrastructure. Wikidata is already the project with the most content pages and we have only ~70 admins for taking care of maintenance tasks. We already have two very different content types on Wikidata: items and lexemes. Not everyone in the community in familiar with these two content types and another one might make things even more difficult. The CC0 license on Wikidata might also be a problem for the license of the Abstract Wikipedia.
• Option 3 would be fine for me. Wikifunctions is a new project and since there will be strong relations between the abstract content and the functions it might make sense to have these contents on the same wiki.
• Option 4 would be fine for me as well. Having a seperate project for the content could make it easier to distinguish between the (technical) work on functions and the (encyclopedia related) work on abstract content.

--Ameisenigel (talk) 08:07, 4 June 2025 (UTC)

Abstract articles and norms in individual projects

It seems abstract articles are meant to be fetched as such, rendered in the local language. The abstract articles would be different between e.g. Wikipedia, Wikivoyage and Wikisource, but I wonder how differences between language versions of the projects will be accommodated. E.g., Wikipedias may have different standard structures of biographies or sports articles. There may also be different views on what kinds of external links to have, and what references are seen as good.

For the abstract articles to conform to the expectations in the projects, one would need to enable local tweaking. E.g., in Wikipedia in Swedish, infoboxes censor data fetched from Wikidata that seems not to be reliably sourced or otherwise problematic. On that Wikipedia, there is a community of editors that know Wikidata well and can tweak templates according to wishes of the larger community. I think such tweaks of Abstract Wikipedia would be best accommodated in a separate namespace in that specific project, while most of the Abstract Wikipedia would be its own project, like Wikidata now.

Have such local tweaks been considered?

–LPfi (talk) 07:21, 28 May 2025 (UTC)

• Oczekuję opcji 6 - całkowite odrzucenie jako marnowanie czasu i zasobów. Przede wszystkim ludzkich, na poprawianie tłumaczeń. Mamy już wystarczająco pracy z fatalnymi narzędziami, nie potrzebujemy więcej śmieci w wikiprzestrzeni. Lukasz Lukomski (talk) 07:45, 28 May 2025 (UTC)

  Pełna zgoda! Helemaal mee eens! Grüße vom Sänger ♫^(Reden) 11:31, 28 May 2025 (UTC)

@LPfi Yes, such local tweaks have been considered. There are two approached on how:

1. Local articles always override articles created from Abstract Content. If a topic is important enough for a community, I would always expect it to have a local article, just written in the language of the project.
2. For some local tweaks, particularly if they are as predictable as you say, it would be possible to write a function that either checks if the local requirements are given, or even modifies the abstract content to make them fit local rules.

I am curious about how feasible Option 2 will be. I also expect that most projects but the largest ones actually have such rules that would require accommodation. --DVrandecic (WMF) (talk) 10:54, 3 June 2025 (UTC)

If systematic local tweaks (rules) are wanted in more than a few projects, I think they need to be accommodated separately from the global functions, to avoid the tweaks accidentally affecting other projects. They could be hosted in the local project (in a local function namespace) or as localization functions in the Abstract Wikipedia project, invoked when a page is to be constructed for a project that wants tweaks. If it isn't clear where to place hooks in the affected functions, perhaps the localization function could be the one primarily called; it could do a few checks and just call the global function if no tweaking is needed, otherwise calling the individual global functions as it sees fit (e.g. constructing its own infobox but calling the global function for the article content). –LPfi (talk) 08:38, 11 June 2025 (UTC)

Further discussion

• My vote is for Option 4. I was going to write more about it, but it looks like Waldyrious already wrote most of what I wanted to say! Including the comparison of this "abstract text repository" to Commons - it could become a general resource, with a scope quite a bit broader than not just Wikipedia, but Wikimedia in general. The only thing I'll add is that a strong argument in favor of giving this its own project - rather than a namespace on Wikifunctions/Wikidata/Commons - is not technical but social: the massive difference in nature between generating functions/data/images, and developing encyclopedic text - at least for the text that would end up on Wikipedia. I have no idea how contentious the "abstract Wikipedia" parts would be, but there's the possibility that they could become just as contentious as the most warred-over topics on Wikipedia. This does not make a good fit with any of the other current "repository" sites: imagine being banned from editing Wikifunctions, for example, because you have an unpopular view on, say, the sovereignty of Crimea. Yaron Koren (talk) 19:16, 28 May 2025 (UTC)

  Presumably the 'abstract' content would be subject to the founding principles, most relevantly to geopolitics the principles one and four. An encyclopedia could discuss views on the status of a territory, but not forward one without sourcing. Arlo Barnes (talk) 05:08, 30 May 2025 (UTC)

The founding principles are great, but of course their interpretation is in the eye of the beholder - one man's impassioned defense of an alternate viewpoint in the interest of neutrality is another's disruptive editing. Yaron Koren (talk) 15:37, 2 June 2025 (UTC)

@Yaron Koren Thank you, these are great points. I, too, expect those points to be rather contentious. And the point of keeping editing rights for content and editing rights for functions separate is indeed a good one (and directly contradicting with my favorite current idea, so there's that :D ). Thanks! --DVrandecic (WMF) (talk) 11:07, 3 June 2025 (UTC)

• The location question can't be answered without first knowing how the content is going to be licensed. Is it going to be CC-0? CC-BY-SA? Nosferattus (talk) 22:40, 30 May 2025 (UTC)

  @Nosferattus agreed. That's why we had the licensing discussion before that. The result has been published: Abstract Content is going to be under CC-BY-SA. I hope this helps with the next steps. --DVrandecic (WMF) (talk) 12:05, 3 June 2025 (UTC)

• Options 2 and 3 would recommend CC0 for Abstract Content. WHY is this mentioned, when it has supposedly been decided that CC-BY-SA applies? I, and many others in the editing community, would be more than happy to fund a lawsuit against the Foundation if it attempted to apply CC0. (edit sorry for the strong kneejerk reaction) While "Jupiter is the fith planet" may be defended as uncopyrightable fact, any court on earth would laugh at anyone trying to translate the complex free-form expressive content in Donald Trump's biography into "abstract" language. The courts are universally clear that translations are bound by the original copyright license. Alsee (talk) 05:11, 1 June 2025 (UTC)

  I am not a big fan of threatening legal actions.

  Nevertheless, it is correct that we have already decided on the licensing rules for Abstract Wikipedia in a previous decision, and the goal of this discussion is not to put this into question. I fixed the text. --DVrandecic (WMF) (talk) 12:35, 2 June 2025 (UTC)

  Strictly speaking the licensing discussion's outcome was only about "Abstract Content for Abstract Wikipedia": nothing was said about "Abstract Content in general" (note that this point was explicitly raised, and agreed upon, when that discussion happened). So this exactly agrees with Alsee's expectation that the "complex free-form expressive content" that's inherently found in mostly any non-trivial encyclopedic text should keep its CC-BY-SA license!

  But it's entirely possible that there will be other sorts of data that will technically be in the form of Abstract Content (such as declarations of basic linguistic or semantic constructs, which might be relied upon by Abstract Wikipedia and other Wikimedia projects but also make it easier to create Abstract Content for other purposes; or strictly factual claims not unlike those found in Wikidata today, but going beyond the expressiveness of our current Wikidata model) for which a CC0 license would quite probably be a lot more appropriate. These two distinct potential settings should not be conflated, and Wikidata is probably a very fitting venue for the latter sorts of data. Hupaleju (talk) 14:02, 3 June 2025 (UTC)

  @DVrandecic (WMF) thank you for your clarification and edit. I apologize for my kneejerk reaction, perhaps hyper-vigilant of any potential or perceived threat to the project (and it's license). I have struck the text. Alsee (talk) 20:11, 7 June 2025 (UTC)

• Recently a new Status update has been posted for Wikifunctions, which includes a summary of Denny's current thinking about where to host the Abstract Content. Please read it, and I think Denny might want to clarify if there are any doubts, but it looks like his current proposal involves a combination of what we are calling Option 4 with a new project or namespace for the long-form encyclopedic Abstract Content for which a CC-BY-SA license has already been agreed upon, and Option 3 with Wikifunctions as a host for more baseline Abstract Content that can be directly referenced in Wikidata statements and would most easily be licensed under CC0. AIUI, compared to hosting such content directly in Wikidata, this involves less development work and more elegantly resolves the issue of how "complex" content might be edited in the current Wikidata UI, so I am quite okay with it.

Also, although we know very little yet about what Abstract Content will look like, I do have to stress that there will probably be a lot of "infrastructural" underlying data about constructs in language and semantics that has the role of simply making it feasible to write expressively about complex topics in the first place. I expect that this sort of basic infrastructure (which has no real equivalents in current projects, aside from what's in Wikidata itself) would then also be hosted on Wikifunctions and made available under a CC0 license, which might help establish the structure of Abstract Content as a quasi-standard for multi-language communication even outside the Wikimedia movement proper, much like Wikidata's current role as a "hub" of the semantic web. (While human-editable semantic interlinguas for automated machine translation have certainly been developed in the past, they have so far been either wholly proprietary or mere academic proofs of concept; we are very much lacking a usable open standard in this domain!) I think that's a really exciting prospect that should be explicitly considered when making these decisions. Thanks for your attention. --Hupaleju (talk) 15:29, 7 June 2025 (UTC)

 Support for Option 4, in particular storing Abstract Content at wikipedia.org. I concur with@TomT0m about using this domain, as it is a major entry point to the encyclopaedia (thus better coverage and visibility of Abstract Wikipedia), and virtually all Wikipedia content is stored on language edition subdomains (from what I understand). Additionally, this approach could be scaled to other projects (e.g. Wikivoyage at wikivoyage.org); the home domain would be separate enough from language editions, whilst sharing their focus. As for the Abstract Content, wouldn't it be feasible to link an Abstract article (e.g. stored at wikipedia.org/wiki/Q42) to Wikidata via interwiki links (i.e. an mul or abstract link at wikidata.org/wiki/Q42), thus enabling Wikipedias to access Abstract Content to render said Abstract article? Cheers! --Red Sneak (talk) 21:43, 12 June 2025 (UTC)

I thin I understand the scheme. If the article is the QID, an explicit mapping to Wikidata via sitelinks wouldn't be needed, since the QID is the QID anyway :) --DVrandecic (WMF) (talk) 11:43, 13 June 2025 (UTC)

• Option 4 for sure. Option 1, 2 and 3 do not allow future extension to abstract Wikiquote, abstract Wikivoyage, abstract Wikibooks, abstract Wikiversity, abstract Wikinews and so on. Option 5 is very English Wikipedia centric and do not allow future extension to a language without its own Wikiquote, Wikivoyage, Wikibooks, Wikiversity, Wikinews and so on. Midleading (talk) 12:24, 18 June 2025 (UTC)