이번 주간 게시물에서는 함수 위키의 개체에서 구조화되지 않은 텍스트를 사용할 여러 위치에 대해 논의하고 싶습니다.
다음은 계획 및 의견 요청입니다. 레이블 외에는 아직 구현된 것이 없으므로 여러분의 의견에 감사드립니다.
레이블.
위키 함수의 모든 개체는 위키데이터의 항목을 식별하는 Q-ID와 유사하게 Z-ID로 식별됩니다. 그러나 Q-ID와 마찬가지로 Z-ID가 널리 표시되고 사용되기를 기대하지 않습니다. 대신 모든 개체에는 언어 당 하나씩 레이블이 있습니다.
그러나 위키데이터 항목과 달리 모든 개체는 특정 유형의 인스턴스가 됩니다. 예를 들어, 두 개의 정수를 더한 것을 나타내는 객체가 있을 수 있습니다. 따라서 이 개체의 영어 레이블은 “add”가 될 수 있습니다. 이 개체에 대한 다른 좋은 레이블은 “addition”, “sum” 또는 “plus”일 수 있습니다. 함수에 대한 부적절한 이름은 “multiplication”가 될 것입니다. 몹시 혼란스러울 것입니다.
독창성.
예를 들어 두 개의 부동 소수점 숫자, 두 개의 복소수 또는 두 개의 행렬을 더하는 것과 같이 더하기를 수행하는 함수를 나타내는 다른 객체도 있을 수 있습니다.
함수 위키에서 레이블은 전체적으로 고유할 필요는 없지만 각 유형에 대해 고유해야합니다. 따라서 두 개의 정수를 취하고 하나의 정수를 반환하는 "add"레이블이 있는 함수는 하나만 있을 수 있습니다. 또는 레이블이 "integer"인 유형이 하나뿐입니다. 유형별로 각 레이블은 고유해야합니다.
이제 모든 개체에 레이블이 필요합니까? 아니요. 레이블이 꼭 필요하지 않은 개체가 많이 있을 것입니다.
함수에 관한 모든 테스트에 레이블이 필요한 것은 아니며 함수의 모든 구현도 필요하지 않습니다. 레이블이 있을 수 있지만 필수는 아닙니다. 이것은 레이블이 없는 항목이 거의 항상 문제가 되는 위키데이터의 또 다른 차이점입니다.
레이블에 대한 또 하나의 참고 사항은 레이블이 여러 언어로 직접 번역될 필요는 없습니다.
따라서 한 언어에서 두 함수는 유형이 다른 경우 동일한 레이블을 가질 수 있지만 다른 언어에서는 두 함수도 다른 레이블을 가질 수 있습니다.
예를 들어, 영어에서 "length"는 목록의 요소 수를 반환하는 함수뿐만 아니라 강의 길이를 반환하는 함수 또는 영화의 길이를 반환하는 함수에 대한 적절한 레이블일 수 있습니다.
반면에 크로아티아어에서는 세 가지 모두 다른 이름을 가질 수 있습니다 ("broj elemenata", "duljina", "trajanje").
각 언어는 자신에게 가장 적합한 패턴을 결정할 수 있습니다. 명령형 동사(“add”) 또는 결과 설명 (“sum”) 또는 연산 이름 (“addition”)이 가장 잘 작동하는지 여부를 결정할 수 있습니다. 언어에서 언어로, 각 언어에 대한 독립적인 스타일 지침이 발전할 수 있습니다.
별칭.
레이블 외에도 모든 개체는 언어별로 추가 별칭을 가질 수 있습니다. 별칭은 개체를 검색 할 때 유용합니다.
영어로 "add"라는 레이블이 붙은 위의 함수는 위에 주어진 다른 모든 대체 이름 ("sum", "plus", "addition ")을 가질 수 있습니다. 다른 이름으로 하나의 함수를 검색 할 때 결과적으로 올바른 함수를 찾을 수 있도록 별칭을 사용합니다.
설명문.
모든 개체에는 각 언어로 된 설명서가 있을 수도 있습니다. 문서는 주어진 객체를 더 자세히 설명하는 위키 텍스트입니다. 많은 개체에는 문서가 전혀 없지만 많은 개체에는 일부가 있습니다.
만일 여러분이 "컴퓨터 프로그래밍의 예술"을 읽을 기회가 있다면, 함수에 대해 할 말이 많다는 것을 알게 될 것입니다!
그러나 이런 종류의 배경 이야기 외에도 주어진 구현을 설명하는 문서 또는 주어진 테스트가 왜 유용한 지에 대한 설명이있을 수 있습니다.
또한 이전에 있었던 오류를 설명하는 파브리케이터 작업과 연결될 수 있으며이 테스트는 오류가 다시 나타나기 전에 이를 포착하기 위해 이를 확인하고 있거나 알고리즘에 대한 교과서와 같은 다른 자료에 대한 링크를 확인할 수 있습니다.
키 및 인수.
최소한 유형과 함수에는 유형의 각 키와 함수의 각 인수에 대한 레이블이 있습니다. 이들은 값과 함수 호출을 표시하고 편집하는 사용자 인터페이스를 만드는 데 사용됩니다.
짧은 설명문.
우리가 가지고 있는 한 가지 구체적인 질문은 – 각 개체에 대한 선택적인 간단한 설명이 있어야 하는가?
많은 IDE에서, 때로는 프로그래밍 언어(파이썬에서 문서화를 생각해 보세요)에서 직접적으로도 함수의 이름과 인수 및 유형 외에도 함수에 대한 약간의 추가 정보를 제공하는 짧은 한 줄에 대한 지원이 있습니다.
우리는 강력한 유형 시스템을 갖게 될 것이며 문서화를 위한 충분한 공간을 갖게 될 것입니다.
그렇다면 짧은 설명을 위한 장소도 정말로 필요하나요? 그들의 사용 사례는 무엇입니까? UX에서 어떻게 사용됩니까?
웹 사이트에서 위키백과의 팝업 미리보기와 유사한 것이 전체 문서를 미리 보는 한 줄짜리 문서보다 훨씬 더 유용 해 보입니다.
원래는 기본적으로 위키데이터에서의 중요성과 유용성을 고려할 때 짧은 설명이 있을 것이라고 가정 했으므로 AbstractText 프로토 타입에도 포함되었습니다. 그러나 그들은 결코 유용하지 않았습니다.
또한 위에서 설명한대로 유형이 명확화의 역할을 대신했기 때문에 간단한 설명에 대한 기술적 필요가 없었습니다.
저는 현재 그것들이 없는쪽으로 기울고 있지만 더 많은 의견을 듣고 싶습니다.
좋은 점은 어떤 결정도 돌에 새겨지지 않을 것이라는 것입니다. 함수 위키의 데이터 모델은 위키데이터의 데이터 모델보다 훨씬 더 유연 할 것이며, 우리가 짧은 설명이 필요하다는 것을 알게되면 나중에 소개 할 수 있습니다.
그러나 거의 모든 것이 어떤 식으로든 사용되기 때문에 제거하기가 훨씬 더 어렵기 때문에 정당한 이유없이 기능을 도입하는 것이 더 조심스럽습니다.
도그푸딩.
한 가지 분명한 질문은 다국어 콘텐츠를 만들기 위해이 아키텍처를 개발하고 있다는 것입니다. 왜 이 모든 문서와 라벨이 실제 언어로 되어 있는가? 이 모든 것을 구축하기 위해 자체 함수를 사용하는 것은 어떨까요?
그리고 네, 동의했습니다. 단지 아직 거기에 있지 않으며 그때까지는 레이블과 문서, 별칭이 여전히 필요합니다.
그래서 결국 저는 함수 자체의 위키 객체를 설명하기 위해 추상적인 내용을 사용하기를 매우 고대할 것입니다.
또한 로컬 콘텐츠 중 일부를 롤백할 수 있는지, 그리고 그렇게 할 수 있는지 확인하는 것도 흥미로울 것입니다. 이것은 설명(그리고 어쩌면 레이블이나 의미 설명을 느끼는가?)에서부터 토막글 위키백과 문서에 이르기까지 다른 위키미디어 프로젝트에서 유사한 목표에 접근하는 방법에 대한 흥미로운 통찰력을 제공 할 것입니다.
프로젝트 전반에 걸친 콘텐츠를 보다 쉽게 유지 관리하고 언어 전반에 걸쳐 보다 균일한 기준 범위를 제공 할 수 있는 많은 잠재력이 있습니다.
추상 위키백과 업데이트 
