Cześć.
Na konferencji w Białowieży prowadziłem razem z Jakubem Kacprzakiem prezentację (http://www.netsprint.pl/publikacje/wikimedia2007/) o tym, w jaki sposób NetSprint wykorzystuje dane z Wikipedii. Padł wtedy ze strony kilku osób pomysł, aby NetSprint zaproponował konkretne rozwiązania w Wikipedii, które mogłyby się przyczynić do ułatwienia przetwarzania jej zawartości przez programy komputerowe. Chciałbym więc przedstawić pierwszą taką propozycję.
Propozycja dotyczy wprowadzenia szablonu o roboczej nazwie disambig-item, który pozwalałby uporządkować nieco strony ujednoznaczniające. W chwili obecnej, strona ujednoznaczniająca jest po prostu fragmentem tekstu. Bez jego zrozumienia, nie da się łatwo określić, które linki prowadzą do stron opisujących konkretne znaczenia ujednoznacznianego hasła, a które spełniają inną rolę. Dzięki użyciu specjalnego szablonu, stałoby się możliwe określenie, które odnośniki są istotne, a które nie. Miałoby to kilka zalet: * Możliwość łatwego automatycznego przetwarzania takich stron przez programy komputerowe. Np. boty wiedząc, jakie jest znaczenie poszczególnych linków mogłyby być bardziej "inteligentne". W przypadku wspomnianego w prezentacji Miksera, poprawiłaby się jakość wyszukiwania, bo rozpoznawane byłyby synonimy różnych haseł (obecnie działa to dla przekierowań ale nie dla stron ujednoznaczniających). * Możliwość tworzenia różnego rodzaju statystyk dotyczących zawartości stron ujednoznaczniających (jest to szczególny przypadek poprzedniego punktu). * Możliwość zmiany w łatwy sposób layoutu stron ujednoznaczniających - np. drukowania ujednoznacznień jako pozycji w tabeli zamiast w liście nieuporządkowanej, gdyby zaszła taka potrzeba.
Tutaj: http://pl.wikipedia.org/wiki/Wikipedysta:Mkosmul/brudnopis/disambig umieściłem krótki opis problemu oraz link do testowego szablonu, który mógłby spełnić rolę opisaną wyżej. Są tam także przykłady użycia.
W skrócie - zamiast pisać np.:
{{Disambig}} *[[Lepton (mechanika kwantowa)]] - grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]]. *[[Lepton (moneta)]] - [[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].
proponuję pisać:
{{Disambig}} {{disambig-item|Lepton (mechanika kwantowa)|Leptony w mechanice kwantowej|grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].}} {{disambig-item|Lepton (moneta)|Lepton|[[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].}}
Szablon ma kilka trybów wywołania (opisane na w.w. stronie) tak aby obsługiwać różne przypadki - zarówno takie, gdy linkujemy do artykułu jak i takie, gdy definicja hasła mieści się w tekście strony ujednoznaczniającej.
Proszę o komentarze i uwagi.
Pozdrawiam, Michał
Proszę o komentarze i uwagi.
Ja nie widze sensu. Wystarczy ustalić, ze pozycja w disambigu powinna rozpoczynać się gwiazdką, po której bezpośrednio nastąpi link do danego hasła, oraz ze jeśli występują linie nie będące pozycją, to nie zaczynają się od gwiazdki. Tak już zresztą wygląda prawie każdy disambig. Skąd według tego szablonu bot miałby wiedzieć jakie jest znaczenie?
A tak marginesie, to na jakiej zasadzie uznaje się które przekierowanie prowadzi do synonimu danego słowa?
Ja nie widze sensu. Wystarczy ustalić, ze pozycja w disambigu powinna rozpoczynać się gwiazdką, po której bezpośrednio nastąpi link do danego hasła, oraz ze jeśli występują linie nie będące pozycją, to nie zaczynają się od gwiazdki. Tak już zresztą wygląda prawie każdy disambig. Skąd według tego szablonu bot miałby wiedzieć jakie jest znaczenie?
Nie chodzi o to. Chodzi o przystosowanie Wikipedii dla programistów wyszukiwarki NetSprint. Dzięki takiemu użyciu wszystko byłoby łatwiej znaleźć. Mamy te:
{{disambig-item|Lepton (mechanika kwantowa)|Leptony w mechanice kwantowej|grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].}} {{disambig-item|Lepton (moneta)|Lepton|[[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].}}
To szukają w tekście źródłowym Wikipedii wg schematu: "{{[Dd]isambig-item|(.*?)|(.*?)|.*?}}" i już mają odpowiedź dla wyszukiwarki.
08-05-07, Holek holek.n@gmail.com napisał(a):
Ja nie widze sensu. Wystarczy ustalić, ze pozycja w disambigu powinna rozpoczynać się gwiazdką, po której bezpośrednio nastąpi link do danego hasła, oraz ze jeśli występują linie nie będące pozycją, to nie zaczynają się od gwiazdki. Tak już zresztą wygląda prawie każdy disambig. Skąd według tego szablonu bot miałby wiedzieć jakie jest znaczenie?
Nie chodzi o to. Chodzi o przystosowanie Wikipedii dla programistów wyszukiwarki NetSprint. Dzięki takiemu użyciu wszystko byłoby łatwiej znaleźć. Mamy te:
Jak dla mnie dostosowywanie się do konkretnej wyszukiwarki to nie za dobry pomysł.
{{disambig-item|Lepton (mechanika kwantowa)|Leptony w mechanice kwantowej|grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].}} {{disambig-item|Lepton (moneta)|Lepton|[[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].}}
To szukają w tekście źródłowym Wikipedii wg schematu: "{{[Dd]isambig-item|(.*?)|(.*?)|.*?}}" i już mają odpowiedź dla wyszukiwarki.
A nie moga szukać według schematu: ^*[[(.*)|(.*)]] ?- ?(.*)$ Tak wygląda niemal każda pozycja w disambigu.
08-05-07, Holek holek.n@gmail.com napisał(a):
Ja nie widze sensu. Wystarczy ustalić, ze pozycja w disambigu powinna rozpoczynać się gwiazdką, po której bezpośrednio nastąpi link do danego hasła, oraz ze jeśli występują linie nie będące pozycją, to nie zaczynają się od gwiazdki. Tak już zresztą wygląda prawie każdy disambig. Skąd według tego szablonu bot miałby wiedzieć jakie jest znaczenie?
Nie chodzi o to. Chodzi o przystosowanie Wikipedii dla programistów wyszukiwarki NetSprint. Dzięki takiemu użyciu wszystko byłoby łatwiej znaleźć. Mamy te:
{{disambig-item|Lepton (mechanika kwantowa)|Leptony w mechanice kwantowej|grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].}} {{disambig-item|Lepton (moneta)|Lepton|[[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].}}
To szukają w tekście źródłowym Wikipedii wg schematu: "{{[Dd]isambig-item|(.*?)|(.*?)|.*?}}" i już mają odpowiedź dla wyszukiwarki.
Pod warunkiem, że użytkownikowi się nie pomyli i nie wstawi tych parametrów na odwrót, co wielu będzie czyniło o ile w ogóle będzie się im chciał stosować taki skomplikowany mechanizm do pisania prostej rzeczy.
Idąc dalej tym tropem można by wymusić od użytkowników, żeby np: każdy akapit artykułu pisali za pomocą szablonu: Np:
{{pargagraf-item|Tekst paragrafu|słowo kluczowe dla bota|przypis literaturowy}}
na pewno by to ułatwiło botowi wyszukiwawczemu zadanie - np: można by odnajdywać paragrafy w artykułach, które mają to samo słowo kluczowe.
Potem można wprowadzić podobny szablon do wstawiania grafiki np:
{{grafika|nazwa_pliku|opis|słowa kluczowe dla bota}}
tylko, że to jednak chyba nie tędy droga...
On Tue, 8 May 2007, Tomasz Ganicz wrote:
Potem można wprowadzić podobny szablon do wstawiania grafiki np: {{grafika|nazwa_pliku|opis|słowa kluczowe dla bota}}
"A może Curie-Skłodowska też?" ;)
tak mi się skojarzyło... i mean, przecież grafikę to akurat się faktycznie mniej więcej tak wstawia ;)
On Tue, 8 May 2007, Holek wrote:
Nie chodzi o to. Chodzi o przystosowanie Wikipedii dla programistów wyszukiwarki NetSprint. Dzięki takiemu użyciu wszystko byłoby łatwiej znaleźć. Mamy te:
no tak, ale wikipedia jest przede wszystkim dla ludzi, a nie dla botów, czy wyszukiwarek... i jeśli coś może służyć przede wszystkim ludziom, a przy okazji botom/wyszukiwarkom/whatever, to ok, ale jeśli coś ma być dużym utrudnieniem dla ludzi, a zyskiem jakimśtam dla botów, to imho już problem...
problem imho jest przede wszystkim w tym, że disambigi to nie jakaś jedna strona jak SDU, GnM, AnM, czy coś w ten deseń, gdzie korzystający są w miarę obyci technicznie i chcący uczestniczyć w życiu społeczności bardziej, a zwykła strona wikipedii, którą może chcieć zedytować ktokolwiek - nawet ktoś z nikłą wiedzą o mediawiki...
dlatego uważam, zgodnie z polimerkiem, że to jest kiepski pomysł...
pozdrowienia, blue.
Ja nie widze sensu. Wystarczy ustalić, ze pozycja w disambigu powinna rozpoczynać się gwiazdką, po której bezpośrednio nastąpi link do danego hasła, oraz ze jeśli występują linie nie będące pozycją, to nie zaczynają się od gwiazdki. Tak już zresztą wygląda prawie każdy disambig. Skąd według tego szablonu bot miałby wiedzieć jakie jest znaczenie?
A tak marginesie, to na jakiej zasadzie uznaje się które przekierowanie prowadzi do synonimu danego słowa?
Chodzi o to, że obecnie wiersz na stronie ujednoznaczniającej może mieć dowolny format, może wyglądać np. tak (ze strony Troglodyta): * We [[Francja|Francji]] określa się tym mianem ludzi mieszkających w domach wykutych wewnątrz skał.
Jeśli na tej podstawie wyciągnemy wniosek, że słowo "troglodyta" jest synonimem słowa "Francja", to nie będzie to wniosek poprawny.
Szablon wymusza wyróżnienie pewnego linku - jego wywołanie wygląda np. tak (przerobiona linijka z artykułu Troglodyta): {{disambig-item|Strzyżyk|Strzyżyk|gatunek ptaka z rodziny strzyżykowatych (Troglodytidae).}}
Widać, że "Strzyżyk", który poajwia się jako osobny parametr szablonu, jest wyróżniony. Moglibyśmy dodać inne linki w opisie: {{disambig-item|Strzyżyk|Strzyżyk|gatunek [[ptaki|ptaka]] z rodziny strzyżykowatych (Troglodytidae).}} Tutaj słowo "ptaka" też jest linkiem, ale wyraźnie widać, że słowo "troglodyta" jest inną nazwą słowa "strzyżyk", ale nie słowa "ptak".
Gdybyśmy napisali tak jak się pisze obecnie: * [[Strzyżyk]] - gatunek [[ptak|ptaka]] z rodziny strzyżykowatych (Troglodytidae). to nie byłoby widać, który link prowadzi do konkretnego znaczenia ujednoznacznianego słowa, a który w ogóle nie ma związku z tytułem strony ujednoznaczniającej.
Pozdrawiam, Michał
08-05-07, Michal Kosmulski michal.kosmulski@netsprint.pl napisał(a):
Ja nie widze sensu. Wystarczy ustalić, ze pozycja w disambigu powinna rozpoczynać się gwiazdką, po której bezpośrednio nastąpi link do danego hasła, oraz ze jeśli występują linie nie będące pozycją, to nie zaczynają się od gwiazdki. Tak już zresztą wygląda prawie każdy disambig. Skąd według tego szablonu bot miałby wiedzieć jakie jest znaczenie?
A tak marginesie, to na jakiej zasadzie uznaje się które przekierowanie prowadzi do synonimu danego słowa?
Chodzi o to, że obecnie wiersz na stronie ujednoznaczniającej może mieć dowolny format, może wyglądać np. tak (ze strony Troglodyta):
- We [[Francja|Francji]] określa się tym mianem ludzi mieszkających w
domach wykutych wewnątrz skał.
Jeśli na tej podstawie wyciągnemy wniosek, że słowo "troglodyta" jest synonimem słowa "Francja", to nie będzie to wniosek poprawny.
Szablon wymusza wyróżnienie pewnego linku - jego wywołanie wygląda np. tak (przerobiona linijka z artykułu Troglodyta): {{disambig-item|Strzyżyk|Strzyżyk|gatunek ptaka z rodziny strzyżykowatych (Troglodytidae).}}
Widać, że "Strzyżyk", który poajwia się jako osobny parametr szablonu, jest wyróżniony. Moglibyśmy dodać inne linki w opisie: {{disambig-item|Strzyżyk|Strzyżyk|gatunek [[ptaki|ptaka]] z rodziny strzyżykowatych (Troglodytidae).}} Tutaj słowo "ptaka" też jest linkiem, ale wyraźnie widać, że słowo "troglodyta" jest inną nazwą słowa "strzyżyk", ale nie słowa "ptak".
Gdybyśmy napisali tak jak się pisze obecnie:
- [[Strzyżyk]] - gatunek [[ptak|ptaka]] z rodziny strzyżykowatych
(Troglodytidae). to nie byłoby widać, który link prowadzi do konkretnego znaczenia ujednoznacznianego słowa, a który w ogóle nie ma związku z tytułem strony ujednoznaczniającej.
Samo ujednolicenie formatu wpisu z zalążku popieram, ale użycie do tego szablonu to moim zdaniem nie za dobry pomysł. Jeśli chcemy wyłapywać te wypełnione nieprawidłowo, to już lepiej zaprzęgnąć do tego bota, który dodawał by do takich odpowiednią kategorię. Jeśli komuś będzie się chciało to poprawiać, to bedzie miał dużo mniej roboty, a bot wyszukiwarki odróżnił by strony wypełnione nie według tego formatu na podstawie kategorii.
08-05-07, Michal Kosmulski michal.kosmulski@netsprint.pl napisał(a):
Cześć.
Propozycja dotyczy wprowadzenia szablonu o roboczej nazwie disambig-item, który pozwalałby uporządkować nieco strony ujednoznaczniające. W chwili obecnej, strona ujednoznaczniająca jest po prostu fragmentem tekstu. Bez jego zrozumienia, nie da się łatwo określić, które linki prowadzą do stron opisujących konkretne znaczenia ujednoznacznianego hasła, a które spełniają inną rolę. Dzięki użyciu specjalnego szablonu, stałoby się możliwe określenie, które odnośniki są istotne, a które nie. Miałoby to kilka zalet:
- Możliwość łatwego automatycznego przetwarzania takich stron przez
programy komputerowe. Np. boty wiedząc, jakie jest znaczenie poszczególnych linków mogłyby być bardziej "inteligentne". W przypadku wspomnianego w prezentacji Miksera, poprawiłaby się jakość wyszukiwania, bo rozpoznawane byłyby synonimy różnych haseł (obecnie działa to dla przekierowań ale nie dla stron ujednoznaczniających).
- Możliwość tworzenia różnego rodzaju statystyk dotyczących zawartości
stron ujednoznaczniających (jest to szczególny przypadek poprzedniego punktu).
- Możliwość zmiany w łatwy sposób layoutu stron ujednoznaczniających -
np. drukowania ujednoznacznień jako pozycji w tabeli zamiast w liście nieuporządkowanej, gdyby zaszła taka potrzeba.
Tutaj: http://pl.wikipedia.org/wiki/Wikipedysta:Mkosmul/brudnopis/disambig umieściłem krótki opis problemu oraz link do testowego szablonu, który mógłby spełnić rolę opisaną wyżej. Są tam także przykłady użycia.
W skrócie - zamiast pisać np.:
{{Disambig}} *[[Lepton (mechanika kwantowa)]] - grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]]. *[[Lepton (moneta)]] - [[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].
proponuję pisać:
{{Disambig}} {{disambig-item|Lepton (mechanika kwantowa)|Leptony w mechanice kwantowej|grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].}} {{disambig-item|Lepton (moneta)|Lepton|[[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].}}
Szablon ma kilka trybów wywołania (opisane na w.w. stronie) tak aby obsługiwać różne przypadki - zarówno takie, gdy linkujemy do artykułu jak i takie, gdy definicja hasła mieści się w tekście strony ujednoznaczniającej.
Proszę o komentarze i uwagi.
IMHO główny problem z tym będzie taki - że użycie tych szablonów w stosunku do normalnego tworzenia disambigów jest znacznie bardziej kłopotliwe. Trzeba pamiętać nazwę kolejnego szablonu i kolejność dodawania do niego dwóch parametrów, w różnych jego trybach, a efekt finalny jest niemal identyczny z tym jakby się po prostu wpisało tekst. Rzecz jasna można to zaproponować - ale są IMHO małe szanse, żeby ludzie to zaczęli masowo stosować, a jak nie będą stosowali to i tak sytuacja się nie zmieni.
Wystarczy porównać wpis:
{Disambig}} {{disambig-item|Lepton (mechanika kwantowa)|Leptony w mechanice kwantowej|grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].}} {{disambig-item|Lepton (moneta)|Lepton|[[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].}}
Z:
{{Disambig}}
*[[Lepton (mechanika kwantowa)|Leptony]] w mechanice kwantowej - grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].
*[[Lepton (moneta)|Lepton]] - [[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].
żeby zrozumieć, którą wersję kodu łatwiej i bardziej intuicyjnie jest wpisać. Szczególnie mało intucyjna jest konieczność wpisywania linku do disambigowanej strony bez kwadratowych nawiasów - natomiast wszystkich pozostałych linków z nawiasami.
W zasadzie zamiast tego skomplikowanego systemu wystarczyłoby przyjąć zalecenie, że poszczególne wpisy w disambigu rozpoczynamy zawsze od linku do disambigowanej strony. Szansa na przestrzeganie tego prostego zalecenia będzie większa niż na to, że przyjmie się złożony mechanizm tworzenia dismabigów przy pomocy dwóch szablonów, z których jeden jest wariantowy i wymaga dwóch parametrów.
IMHO główny problem z tym będzie taki - że użycie tych szablonów w stosunku do normalnego tworzenia disambigów jest znacznie bardziej kłopotliwe. Trzeba pamiętać nazwę kolejnego szablonu i kolejność
Zgadzam się, ale myślę, że zwykle i tak bardziej złożone strony buduje się korzystając z przykładów czy też kopiując fragmenty wikitekstu z innych stron. Gdyby zacząć stosować taki mechanizm, to prawdopodobnie stopniowo propagowałby sie on na nowe strony. Nie chodzi przecież o to, aby w krótkim czasie wszystkie strony ujednoznaczniające korzystały z tego mechanizmu. Większość stron ujednoznczniających to np. listy osób noszących to samo nazwisko - to można sobie w programie wygenerować na podstawie tytułów artykułów. Dla mnie ważniejsze byłoby użycie takich szablonów nawet w stosunkowo nielicznej grupie artykułów "złośliwych", dla których alternatywne nazwy nie dają się odnaleźć na podstawie nazwy artykułu.
żeby zrozumieć, którą wersję kodu łatwiej i bardziej intuicyjnie jest wpisać. Szczególnie mało intucyjna jest konieczność wpisywania linku do disambigowanej strony bez kwadratowych nawiasów - natomiast wszystkich pozostałych linków z nawiasami.
To mogę w szablonie łatwo zmienić (nie używanie nawiasów wymsuza trochę ściślejszą składnię, ale można z tego zrezygnować).
W zasadzie zamiast tego skomplikowanego systemu wystarczyłoby przyjąć zalecenie, że poszczególne wpisy w disambigu rozpoczynamy zawsze od linku do disambigowanej strony. Szansa na przestrzeganie tego prostego zalecenia będzie większa niż na to, że przyjmie się złożony mechanizm tworzenia dismabigów przy pomocy dwóch szablonów, z których jeden jest wariantowy i wymaga dwóch parametrów.
Tak, ale warunkiem byłoby bezwzględne stosowanie się do tego zalecenia, co jest nie do zrobienia. Ponadto jeśli część stron stosuje się do konwencji a część nie, to nie da się odróżnić, które się do niej stosują, a które nie (ktoś mógłby umieścić na początku link ale nie do disambigowanej strony). Szablon wymusza stosowanie się do konwencji, bo jeśli poda się niewłaściwe parametry, to nie zadziała. Od razu też widać, czy wiersz jest w "starym stylu" czy w "nowym stylu": jeśli jest szablon, to wiem, że mogę z neigo wyciągnąć pewne informacje; Jeśli nie ma szablonu, to ignoruję dany wiersz i idę dalej. Nawet jeśli 99% stron jest w starym stylu, to mi one nie przeszkadzają, natomiast 1%, który jest w nowym stylu, dostarcza już bardzo cennych informacji.
Pozdrawiam, Michał
08-05-07, Michal Kosmulski michal.kosmulski@netsprint.pl napisał(a): [...]
W zasadzie zamiast tego skomplikowanego systemu wystarczyłoby przyjąć zalecenie, że poszczególne wpisy w disambigu rozpoczynamy zawsze od linku do disambigowanej strony. Szansa na przestrzeganie tego prostego zalecenia będzie większa niż na to, że przyjmie się złożony mechanizm tworzenia dismabigów przy pomocy dwóch szablonów, z których jeden jest wariantowy i wymaga dwóch parametrów.
Tak, ale warunkiem byłoby bezwzględne stosowanie się do tego zalecenia, co jest nie do zrobienia. Ponadto jeśli część stron stosuje się do konwencji a część nie, to nie da się odróżnić, które się do niej stosują, a które nie (ktoś mógłby umieścić na początku link ale nie do disambigowanej strony).
Jeśli po linku występuje myślnik, to raczej nie widze szans na to, aby nie prowadził on do ujednoznacznianej strony. Już większe prawdopodobieństwo, że ktoś poda źle parametry w szablonie i nie zauważy, że wyświetla się źle.
Dodam jeszcze od siebie:
1. http://pl.wikipedia.org/wiki/Wiki#Zasadnicze_cechy_serwis.C3.B3w_opartych_na... 3 pierwsze punkty chyba kłucą się z używaniem tego szablonu w disambigach.
2. http://pl.wikipedia.org/wiki/WP:CWNJ punkt 2. W moim jego rozumieniu Wikipedia nie jest słownikiem, także słownikiem synonimów itp dla bota. Jeśli coś takiego uda się wygenerować na jej podstawie to bardzo dobrze, jeśli ułatwienie tego nie przeszkadza w jej tworzeniu (np. infoboxy) to również dobrze, ale nie powinno się zmuszać tworzących encyklopedie do angażowania się w tworzeniw bazy danych dla bota.
Oczywiście to tylko moja opinia.
Michał!
1. błąd - na tej liście żadko rodzi się coś konstruktywnego (sorry chłopaki, ale po dwóch latach obecności mam swoje zdanie)
2. Zrób listę disambigów, które nie-pasują do potrzebnego ci schematu formatowania, a my spróbujemy je ręcznie poprawić.
Punkt 2 jest o tyle istotny, że na bank wyłapie masę lewych disambigów, które i tak musimy poprawić ;)
Pozdrawiam AJF/WarX
On Tue, 8 May 2007, Artur Fijałkowski wrote:
Michał!
- błąd - na tej liście żadko rodzi się coś konstruktywnego (sorry
chłopaki, ale po dwóch latach obecności mam swoje zdanie)
tak, ale bez tej listy i innych konsultacji powstają pomysły w stylu Tawbota i jednynego słusznego sposobu organizowania opisów na Commons... :p
- Zrób listę disambigów, które nie-pasują do potrzebnego ci schematu
formatowania, a my spróbujemy je ręcznie poprawić.
ale problem mu pozostanie - bo i tak nie bedzie mógł tego odróżnić od tych nieprawidłowych - zwłaszcza, jeśli ktoś to później zedytuje...
a ponadto - jeśli będzie w stanie je wymienić, to pewnie sobie je sam może na sztywno shardcode'owac ;)...
Punkt 2 jest o tyle istotny, że na bank wyłapie masę lewych disambigów, które i tak musimy poprawić ;)
tylko please, WarX bez wprowadzania w życie pomysłów w stylu właśnie omawianego...
imho, jak to rozwiązanie jest faktycznie niezbędne, to niech chętni to robią OBOK właściwego wikitekstu a NIE ZAMIAST...
09-05-07, Przemyslaw 'BlueShade' Idzkiewicz blue@wave460.net napisał(a):
On Tue, 8 May 2007, Artur Fijałkowski wrote:
[...]
imho, jak to rozwiązanie jest faktycznie niezbędne, to niech chętni to robią OBOK właściwego wikitekstu a NIE ZAMIAST...
Niech to lepiej robią obok Wikipedii, bo w niej należy tworzyć WYŁĄCZNIE ENCYKLOPEDIE!!!
Tworzenie obok mogło by być nawet prostsze, bo mediawiki nie jest oprogramowaniem stworzonym z myślą o takich rzeczach.
A tak na marginesie, to jest jakikolwiek powód ku temu, aby robić to na wiki inny niż to, że wikipedyści zrobią to za darmo, a za sprawdzanie prywatnej listy na zewnątrz trzeba by komuś zapłacić?
On Tue, 8 May 2007, Michal Kosmulski wrote:
IMHO główny problem z tym będzie taki - że użycie tych szablonów w stosunku do normalnego tworzenia disambigów jest znacznie bardziej kłopotliwe. Trzeba pamiętać nazwę kolejnego szablonu i kolejność
Zgadzam się, ale myślę, że zwykle i tak bardziej złożone strony buduje się korzystając z przykładów czy też kopiując fragmenty wikitekstu z
tak, ale zwykły disambig to nie jest "bardziej złożona strona" i moim zdaniem jest złym pomysłem, komplikowanie jej tworzenia... wykluczymy w ten sposób z partycypacji w tworzeniu i uzupełnianiu disambigów osoby z mniejszą wiedzą na temat mediawiki...
Tak, ale warunkiem byłoby bezwzględne stosowanie się do tego zalecenia, co jest nie do zrobienia. Ponadto jeśli część stron stosuje się do konwencji a część nie, to nie da się odróżnić, które się do niej stosują, a które nie (ktoś mógłby umieścić na początku link ale nie do disambigowanej strony). Szablon wymusza stosowanie się do konwencji, bo jeśli poda się niewłaściwe parametry, to nie zadziała.
to może po prostu niech ten szablon będzie pusty i niech będzie "obok" normalnego wikitekstu - wtedy i netsprint będzie syty i user cały...
W zasadzie zamiast tego skomplikowanego systemu wystarczyłoby przyjąć zalecenie, że poszczególne wpisy w disambigu rozpoczynamy zawsze od linku do disambigowanej strony. Szansa na przestrzeganie tego prostego zalecenia będzie większa niż na to, że przyjmie się złożony mechanizm tworzenia dismabigów przy pomocy dwóch szablonów, z których jeden jest wariantowy i wymaga dwóch parametrów.
Zgadza się
przykłady podane przez Michała są jednak ciekawe - w przypadku torglodyty jest mnóstwo okresleń słownikowych - w Arizonie jest hasło, które nie brzmi dokładnie Arizona (coś tam).
Jak ja to widzę jako nie techniczny :)
W disambigu jest istotne to, co jest napisane w nawiasie danego homonimu:
*[[Lepton (mechanika kwantowa)]] *[[Lepton (moneta)]]
a więc mechanika kwantowa i moneta
W przypadku troglodyty nie mamy ani jednego linku do ency hasła (btw - określenie technofoba informatycznego jako torglodyty to OR)
W takim przypadku można dać inne rozwiązanie, które nie myliłoby wyszukiwarki. Po * nie ma linku, więc się nie uwzględnia hasła po *, albo lepiej dajemy link z prefiksem [[wikt:Troglodyta|Troglodyta]]. Na fr wiki jest chyba nawet tak, ze jak hasło jest słownikowe, to nie pojawia się pusta strona w Wikipedii, tylko informacja o tym, że jest takie hasło w wikisłowniku (nie sprawdź, tylko jest) - chyba nie jest indeksowane, jak u nas {{nieart}}. Przypadek troglodyty jest bardzo specyficzny. Wyszukiwarka w takim przypadku wykorzystywałaby dodatkowo zasoby Wikisłownika - da się tak?
* [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]] * [[Okręt]] [[USS Arizona]]
Tu mamy wąż, stan w USA i film dokumentalny. Co do okrętu trzeba się zdecydować - albo [[Arizona (okręt)]] i redirect albo przenosimy w disambigu do zobacz też, gdzie umieszczamy linki bez (określeń w nawiasach) - albo jakoś inaczej oddzielamy. Hmmm, brakuje mi tu [[Arizona (wino)]] ;) Do obgadania.
Czy o to chodzi, czy problem pogrzebany jest gdzie indziej?
przykuta
08-05-07, Przykuta przykuta@o2.pl napisał(a):
W zasadzie zamiast tego skomplikowanego systemu wystarczyłoby przyjąć zalecenie, że poszczególne wpisy w disambigu rozpoczynamy zawsze od linku do disambigowanej strony. Szansa na przestrzeganie tego prostego zalecenia będzie większa niż na to, że przyjmie się złożony mechanizm tworzenia dismabigów przy pomocy dwóch szablonów, z których jeden jest wariantowy i wymaga dwóch parametrów.
Zgadza się
przykłady podane przez Michała są jednak ciekawe - w przypadku torglodyty jest mnóstwo okresleń słownikowych - w Arizonie jest hasło, które nie brzmi dokładnie Arizona (coś tam).
Jak ja to widzę jako nie techniczny :)
W disambigu jest istotne to, co jest napisane w nawiasie danego homonimu:
*[[Lepton (mechanika kwantowa)]] *[[Lepton (moneta)]]
a więc mechanika kwantowa i moneta
Tylko to chyba trudno było by do czegokolwiek praktycznego wykorzystać. Opis był by akurat napewno lepszy, bo o ile lepton to moneta, to lepton to nie mechanika kwantowa.
[...]
- [[Arizona (wąż)]]
- [[Arizona (stan w USA)]]
- [[Arizona (film dokumentalny)]]
- [[Okręt]] [[USS Arizona]]
Tu mamy wąż, stan w USA i film dokumentalny. Co do okrętu trzeba się zdecydować - albo [[Arizona (okręt)]] i redirect albo przenosimy w disambigu do zobacz też, gdzie umieszczamy linki bez (określeń w nawiasach) - albo jakoś inaczej oddzielamy. Hmmm, brakuje mi tu [[Arizona (wino)]] ;) Do obgadania.
Problem w tym, że bot uzna, że arizona i okręt to synonimy. Mógł by szukać słowa Arizona w linku, lub treści linku ([[tytuł|tu miałby szuakć]]), lecz wtedy nie znajdzie synonimów. Może za to szukać czego innego:)
Czy o to chodzi, czy problem pogrzebany jest gdzie indziej?
Zależy co dokładnie ten bot miałby robić. Nie moge jakoś pobrać tej prezentacjii w formacie pdf, a innych nie jestem teraz w stanie otworzyć (jak ktoś byłby tak uprzejmu odpiszcie, czy też macie z tym problem), a interesuje mnie jak tworzyć beze synonimów na podstawie redirectów, kiedy nie jest zasadą, że przekierowanie prowadzi do synonimu.
P.S. Jeśli wikipedysci z dobrej woli przystosują disambigi do wykrywania synonimów (czy czegokolwiek innego) przez bota netsprintu, to moga liczyć na opublikowanie zebranych przez niego informacji na wolnej licencji?
W disambigu jest istotne to, co jest napisane w nawiasie danego homonimu:
*[[Lepton (mechanika kwantowa)]] *[[Lepton (moneta)]]
a więc mechanika kwantowa i moneta
Tylko to chyba trudno było by do czegokolwiek praktycznego wykorzystać. Opis był by akurat napewno lepszy, bo o ile lepton to moneta, to lepton to nie mechanika kwantowa.
Opis oczywiście powinien być - wyciąłem dla czytelności. Co do leptonu - to jest raczej problem z tytułem - raczej powinno być [[Lepton (cząstka elementarna)]] - od razu wiadomo o co chodzi.
[...]
- [[Arizona (wąż)]]
- [[Arizona (stan w USA)]]
- [[Arizona (film dokumentalny)]]
- [[Okręt]] [[USS Arizona]]
Tu mamy wąż, stan w USA i film dokumentalny. Co do okrętu trzeba się zdecydować - albo [[Arizona (okręt)]] i redirect albo przenosimy w disambigu do zobacz też, gdzie umieszczamy linki bez (określeń w nawiasach) - albo jakoś inaczej oddzielamy. Hmmm, brakuje mi tu [[Arizona (wino)]] ;) Do obgadania.
Problem w tym, że bot uzna, że arizona i okręt to synonimy. Mógł by szukać słowa Arizona w linku, lub treści linku ([[tytuł|tu miałby szuakć]]), lecz wtedy nie znajdzie synonimów. Może za to szukać czego innego:)
No, tu też jest źle, ale gdy będzie
* [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]] * [[Arizona (okręt)]]
lub
* [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]] * [[USS Arizona]] - [[okręt]] ...
to bot sobie poradzi - IMHO powinien ignorować wszystkie linki, których treść jest różna od tytułu disambigu - w linku [[okręt]] nie ma "Arizona", więc bot ignoruje...
A gdyby zrobić jeszcze * [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]]
== Zobacz też == * [[USS Arizona]] - [[okręt]] ...
I bot ignoruje wszystko co jest poniżej == Zobacz też ==
tyle powiedział teoretyk :D
Tak czy siak IMHO lepiej się pomęczyć nad botem raz niż zmuszać Bogu ducha winnych wikipedystów by stosowali skomplikowane formuły w disambigach ;)
Oczywiście w każdym przypadku powinien być opis i ukryty nawias * [[hasło (coś w nawiasie)|]] - to jest [[to]] i [[owo]]
Zaraz zrobię oftopa: <OT>Z | rzadko się korzysta i niepotrzebnie się pisze np. [[Wikipedia:Jakieś dłuższe hasło|Jakieś dłuższe hasło]] zamiast [[Wikipedia:Jakieś dłuższe hasło|]] - mniej czasu się traci na takie ceregiele</OT>
to pisałem ja przykuta
08-05-07, Przykuta przykuta@o2.pl napisał(a):
W disambigu jest istotne to, co jest napisane w nawiasie danego homonimu:
*[[Lepton (mechanika kwantowa)]] *[[Lepton (moneta)]]
a więc mechanika kwantowa i moneta
Tylko to chyba trudno było by do czegokolwiek praktycznego wykorzystać. Opis był by akurat napewno lepszy, bo o ile lepton to moneta, to lepton to nie mechanika kwantowa.
Opis oczywiście powinien być - wyciąłem dla czytelności. Co do leptonu - to jest raczej problem z tytułem - raczej powinno być [[Lepton (cząstka elementarna)]] - od razu wiadomo o co chodzi.
Czyli wiadomo co poprawiać:) Warto było by wypracować zalecenia na temat tego co wpisywać w nawiasie w tytule artykułu.
[...]
- [[Arizona (wąż)]]
- [[Arizona (stan w USA)]]
- [[Arizona (film dokumentalny)]]
- [[Okręt]] [[USS Arizona]]
Tu mamy wąż, stan w USA i film dokumentalny. Co do okrętu trzeba się zdecydować - albo [[Arizona (okręt)]] i redirect albo przenosimy w disambigu do zobacz też, gdzie umieszczamy linki bez (określeń w nawiasach) - albo jakoś inaczej oddzielamy. Hmmm, brakuje mi tu [[Arizona (wino)]] ;) Do obgadania.
Problem w tym, że bot uzna, że arizona i okręt to synonimy. Mógł by szukać słowa Arizona w linku, lub treści linku ([[tytuł|tu miałby szuakć]]), lecz wtedy nie znajdzie synonimów. Może za to szukać czego innego:)
No, tu też jest źle, ale gdy będzie
- [[Arizona (wąż)]]
- [[Arizona (stan w USA)]]
- [[Arizona (film dokumentalny)]]
- [[Arizona (okręt)]]
lub
- [[Arizona (wąż)]]
- [[Arizona (stan w USA)]]
- [[Arizona (film dokumentalny)]]
- [[USS Arizona]] - [[okręt]] ...
to bot sobie poradzi - IMHO powinien ignorować wszystkie linki, których treść jest różna od tytułu disambigu - w linku [[okręt]] nie ma "Arizona", więc bot ignoruje...
Ale jeśli ma wyłapywać synonimy, to pewnie interesować go będą jedynie te linki, które nie zawierają w sobie tytułu disambiga, chyba że ktoś mądrzejszy odemnie wymyślił jakąś lepszą metodę.
A gdyby zrobić jeszcze
- [[Arizona (wąż)]]
- [[Arizona (stan w USA)]]
- [[Arizona (film dokumentalny)]]
== Zobacz też ==
- [[USS Arizona]] - [[okręt]] ...
I bot ignoruje wszystko co jest poniżej == Zobacz też ==
To patrz wyżej. To nadaje się co najwyżej do wyłapywania wieloznacznych słów (nie wiem jak się to fachowo nazywa).
Pomijając wyszukiwarkę netsprint pomysł uważam za dobry.
tyle powiedział teoretyk :D
Tak czy siak IMHO lepiej się pomęczyć nad botem raz niż zmuszać Bogu ducha winnych wikipedystów by stosowali skomplikowane formuły w disambigach ;)
Zwłaszcza, że te dane nie są potrzebne wikipedii, a firmie która pewnie nawet nie opublikuje tego co uda się jej z tego wydobyć.
Jeśli mamy robić coś w tym kierunku, lepiej sami wydobędźmy z tego takie dane i opublikujmy je na licencji LGPL. Może by założyć jakiś wikiprojekt wydobywający tego typu dane? Jeśli netsprint byłby skłonny nam w tym pomóc, to było by jeszcze lepiej, tak czy tak mógłby z tego korzystać.
Oczywiście w każdym przypadku powinien być opis i ukryty nawias
- [[hasło (coś w nawiasie)|]] - to jest [[to]] i [[owo]]
Przydało by się spisać następne zalecenia, co do tworzenia disambigów. teraz komuś może się wydawać, że ten jego zagmatfany jest fajniejszy.
Zaraz zrobię oftopa: <OT>Z | rzadko się korzysta i niepotrzebnie się pisze np. [[Wikipedia:Jakieś dłuższe hasło|Jakieś dłuższe hasło]] zamiast [[Wikipedia:Jakieś dłuższe hasło|]] - mniej czasu się traci na takie ceregiele</OT>
Skąd wiesz, skoro po zapisaniu w kodzie jest i tak [[Wikipedia:Jakieś dłuższe hasło|Jakieś dłuższe hasło]]?
Zwłaszcza, że te dane nie są potrzebne wikipedii, a firmie która pewnie nawet nie opublikuje tego co uda się jej z tego wydobyć.
Eh, zakładaj dobra wolę :) Mi się prezentacja podobała i liczę na kolejne. W szczególności, że mobilizuje nas to do robienia porządków. (Ta firma była sponsorem konferencji :)
Przydało by się spisać następne zalecenia, co do tworzenia disambigów. teraz komuś może się wydawać, że ten jego zagmatfany jest fajniejszy.
No, mamy coś takiego:
http://pl.wikipedia.org/wiki/Wikipedia:Strony_ujednoznaczniaj%C4%85ce
Nawet niedawno rozbudowałem o przypadki z disambigiem R :)
Możemy się przenieść na stronę dyskusji? Te zapiski zginą zasypane lawiną innych postów.
przykuta
08-05-07, Przykuta przykuta@o2.pl napisał(a):
Zwłaszcza, że te dane nie są potrzebne wikipedii, a firmie która pewnie nawet nie opublikuje tego co uda się jej z tego wydobyć.
Eh, zakładaj dobra wolę :) Mi się prezentacja podobała i liczę na kolejne. W szczególności, że mobilizuje nas to do robienia porządków. (Ta firma była sponsorem konferencji :)
Przydało by się spisać następne zalecenia, co do tworzenia disambigów. teraz komuś może się wydawać, że ten jego zagmatfany jest fajniejszy.
No, mamy coś takiego:
http://pl.wikipedia.org/wiki/Wikipedia:Strony_ujednoznaczniaj%C4%85ce
Nie podoba mi się tam linia *[[Terefere (miasto)|]] - [[miasto]] - strona ujednoznaczniająca Dobrze jesli daną rzecz da się odnaleść odwiedzając maks 3 strony, tutaj mamy "Strona główna", "Terefere", "Terefere (miasto)", "Terefere (miasto gdzieśtam)" Lepiej podzielić disambiga na sekcje. Pozatym najwazniejsza jest sekcja "Zasady ujednoznaczniania", a w niej prawie nic nie ma.
[...] Możemy się przenieść na stronę dyskusji? Te zapiski zginą zasypane lawiną innych postów.
Nie mam nic przeciw, ale trzeba by streścić to co już zostało napisane, może lepiej spisujmy wyciągnięte wnioski, a dyskutujmy tutaj? Przy okazji zwiększyło by to szanse, że nie skończy się na bezowocnej dyskusji.
Spisałem coś krótko w brudnopisie (http://tinyurl.com/23unao). Jak komuś się chce to zapraszam do przejrzenia i poprawek/poszerzenia.
08-05-07, Witek1988 witekthc@witekkrypczyk.info napisał(a):
Zwłaszcza, że te dane nie są potrzebne wikipedii, a firmie która pewnie nawet nie opublikuje tego co uda się jej z tego wydobyć.
Jeśli mamy robić coś w tym kierunku, lepiej sami wydobędźmy z tego takie dane i opublikujmy je na licencji LGPL. Może by założyć jakiś wikiprojekt wydobywający tego typu dane? Jeśli netsprint byłby skłonny nam w tym pomóc, to było by jeszcze lepiej, tak czy tak mógłby z tego korzystać.
Taki projekt już jest - istnieje program o nazwie Synarcher - który tworzy listy synonimów i mapy powiązań między artykułami w dowolnym wiki bez konieczności stosowania jakichś ekstra szablonów.
http://synarcher.sourceforge.net/
Ludzie z synarcher planują zrobić słownik wyrazów bliskoznacznych na bazie powiązań między artykułami w Wikipedii-en.
Czesc, dziekuje wszystkim za komentarze, zwlaszcza te krytyczne. Po przemysleniu sprawy, doszedlem do wniosku, ze zaproponowane przeze mnie poczatkowo podejscie faktycznie byloby zrodlem trudnosci przy edycji stron. Wpadlem jednak na pomysl, jak mozna osiagnac [prawie] ten sam efekt bez potrzeby az tak silnej ingerencji w wyglad stron ujednoznaczniajacych. Oczywiscie tak samo jak pierwotna koncepcja, tutaj tez stosowanie tej techniki lub jej nie stosowanie nie byloby w zaden sposob wymuszone.
Zatem: zarzucam stara propozycje, a zamiast niej proponuje: 1. Tworzymy szablon o nazwie, dajmy na to, {{link-1-ujednoznacznia}}. 2. Szablon ten jest pusty, tzn. nie wstawia zadnego tekstu w tresc strony. Sluzy on jedynie za marker, tzn. sama jego obecnosc jest pewna informacja. 3. W tresci strony ujednoznaczniajacej wstawiamy ten szablon na koncu linijki, o ktorej wiemy, ze sie trzyma wlasciwego formatu, tzn. ze pierwszy link wewnetrzny prowadzi do hasla opisujacego konkretne znaczenie ujednoznacznianego slowa. 4. Przyklad (znowu lepton):
{{Disambig}} *[[Lepton (mechanika kwantowa)]] - grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].{{link-1-ujednoznacznia}} *[[Lepton (moneta)]] - [[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].{{link-1-ujednoznacznia}} *Slowo lepton bywa takze stosowane jako [[obelga]], najczesciej w formie ''[[Ty leptonie]]''
Dwa pierwsze znaczenia sa oznakowane szablonem, dzieki czemu bot wie, ze pierwszy link w danym punkcie jest "tym wlasciwym". Ostatni wiersz (oczywiscie wydumany) nie jest zgodny z ustalonym formatem, wiec nie zawiera szablonu i zostanie przez bota zignorowany.
Wydaje mi sie, ze takie podejscie byloby znacznie mniej inwazyjne niz to co proponowalem na poczatku i z czego sie wycofuje.
Poniewaz padalo wiele roznych uwag, postaram sie do nich zbiorczo ustosunkowac ponizej aby nie mnozyc postow ponad miare:
* Problem z pobieraniem PDF: u mnie dziala, ale jest tez kopia na wikimedia.org, pod adresem http://pl.wikimedia.org/wiki/Grafika:Netsprint_2007.pdf - moze ta pojdzie.
* Synonimy: uzylem tego slowa w niezbyt scislym znaczeniu. Chodzilo mi nie o synonimy w rozumieniu gramatyki jezyka polskiego, tylko o "alternatywne tytuly hasel" - slowa, ktorych wpisanie w wyszukiwarce powinno skutkowac wyswietleniem innego rekordu. Przykladowo: "Cassius Clay" to prawdziwe imie i nazwisko boksera znanego jako "Muhammad Ali". Jesli uzytkownik wpisze zapytanie "Cassius Clay", powinien moc znalezc strone "Muhammad Ali". Jesli takie haslo jest jednoznaczne, uzywamy redirectow i sprawa jest prosta. Jesli nie jest jednoznaczne, mamy strone ujednoznaczniajaca i tutaj zaczynaja sie schody. Wezmy np. strone "Tygrys (ujednoznacznienie)" - ktos kto wpisze haslo "tygrys", powinien moc znalezc informacje zarowno o zwierzeciu jak i o rzece jak i o niemieckim czolgu PzKpfw VI Tiger. O ile latwo jest z "Tygrys (rzeka)" usunac nawias, to dojsc automatycznie do tego, ze szukajac "tygrys" mamy znalezc m.in. "PzKpfw VI Tiger", raczej sie nie da - wymaga to juz pomocy ze strony czlowieka. Musimy wiedziec, ze mozna bezpiecznie wziac pierwszy link z wiersza, bo w tym wypadku mozna to zrobic, ale juz w kolejnym wierszu z tego samego artykulu: * tygrys – [[Krzyżówka (genetyka)|krzyżówka]] [[pstrąg potokowy|pstrąga potokowego]] i [[pstrąg źródlany|źródlanego]] nie mozna tego zrobic, bo wyjdzie, ze "krzyzowka" to jedno ze znaczen slowa "tygrys" i ze szukajac slowa "tygrys" mamy znalezc artykul "krzyzowka". Tak wiec istotne jest "znakowanie" tych hasel, ktorych nazwa nie zawiera slowa "tygrys". Z tymi, ktore je zawieraja, program umie sobie poradzic sam.
* Udostepnienie danych wygenerowanych na bazie Wikipedii: oczywiscie zawarte w wyniku wyszukiwania z netsprinta streszczenie artykulu z wikipedii jest dostepne na FDLu i mozna z nim robic wszystko, na co licencja pozwala. Aplikacja, ktora te rekordy generuje, jest niestety zamknieta i raczej taka pozostanie - na to nie mam wielkiego wplywu. Jak dokladnie jest z innymi danymi, ktore bot moze wygenerowac, tego nie wiem; sprawy licencyjne ustalal z Polimerkiem kolega z innego dzialu, w razie potrzeby moge dac na niego namiar. Jesli chodzi o prace wikipedystow, to o ile oczywiscie zachecalbym wszystkich do "znakowania" stron ujednoznaczniajacych, to chodzi mi glownie o *mozliwosc* takiego znakowania (czyli ustalenie mechanizmu, ktory nie zrobi zbyt wielkiego zamieszania i nie bedzie przeszkadzal osobom nim nie zainteresowanym), a nie o to zeby ktos cala prace za mnie *wykonal*. Dostawianie szablonow w "trudnych" stronach ujednoznaczniajacych moglbym prawdopodobnie w znacznej mierze wykonac sam (choc oczywiscie wszelka pomoc powitalbym z radoscia). Wyobrazam sobie tez, ze netsprint nie jest jedynym programem, ktory ze struktury stron ujednoznaczniajacyh moglby wyciagnac uzyteczne informacje, tak wiec te znaczniki moglyby sluzyc rowniez innym.
* Arizona (wino) - tez sie zdziwilem ze nie ma jeszcze tego artykulu, w sieci sa cale strony poswiecone "winom prostym".
Podsumowujac poczatek postu: wycofuje sie z pierwotnej koncepcji, prosze o komentarze do koncepcji nowej, uzywajacej tylko szablonu-markera :)
Mam nadzieje, ze nawet jesli ostatecznie koncepcja sie nie przyjmie (ale licze, ze wymyslimy cos co da sie zastosowac w praktyce), to przynajmniej wyniknie z tego jakas uzyteczna dyskusja na temat stron ujednoznaczniajacych.
Pozdrawiam, Michal
1. Tworzenie pustego szablonu chyba nie ma sensu, bo jego dołączanie tylko niepotrzebnie obciąży serwery. Jeśli już to proponuje użyć komentarza.
2. Jeśli w disambigu występuje linia *[[xxx]] - bla [[bla]] bla to możesz być praktycznie pewny, że chodzi o xxx, a nie bla. Pewność jest na pewno większa niż w przypadku redirectów. zresztą jeśli wyszukiwarka popełni tu błąd w przypadku dajmy 0,5% przypadków, to nie jest to chyba duży problem.
3. Ręczne sprawdzanie listy to mniej pracy, niż poprawienie disambigów.
4. Może po prostu ręcznie sprawdzać i poprawiać wszystkie disambigi, a zaraz zgłaszać do przeskanowania przez bota? Żeby to uaktualniać trzeba by sprawdzać regularnie zmiany w dolinkowanych do szablonu disambig. Tutaj raczej wymagało by zaangażowania społeczności wikipedii, czyli raczej lista musiała by być opublikowana.
5. Tak dla ścisłości. Chcecie wykorzystywać to przy wyświetlaniu materiałów z wikipedii, czy poszukiwanych stron?
- Tworzenie pustego szablonu chyba nie ma sensu, bo jego dołączanie
tylko niepotrzebnie obciąży serwery. Jeśli już to proponuje użyć komentarza.
Racja, nie pomyślałem o tym.
- Jeśli w disambigu występuje linia
*[[xxx]] - bla [[bla]] bla to możesz być praktycznie pewny, że chodzi o xxx, a nie bla. Pewność jest na pewno większa niż w przypadku redirectów. zresztą jeśli wyszukiwarka popełni tu błąd w przypadku dajmy 0,5% przypadków, to nie jest to chyba duży problem.
Przejrzałem trochę stron ujednoznaczniających i rzeczywiście w tej chwili sporo stron stosuje się do wymienionego wyżej schematu. Kiedy robiłem pierwsze podejście do interpretacji stron ujednoznaczniających przez program, odniosłem wrażenie, że ich format jest raczej swobodny i wypróbowawszy kilka heurystyk, stwierdziłem, że wszystkie dawały zbyt wiele fałszywych synonimów. Wygląda, że od tamtego czasu sporo się zmieniło na plus. Mogę sobie wyobrazić wpis, w którym przypadkowo będzie użyty taki format wiersza, ale pierwszy link nie będzie prowadził do ujednoznacznienia, np. ktoś mógłby napisać:
Słowo "wilk" może oznaczać: *[[zwierzę]] - drapieżnego [[ssak]]a
ale chyba będzie to raczej wyjątek.
Jeśli dałoby się uczynić ze wspomnianego formatu oficalne zalecenie edycyjne, to myślę, że mój problem byłby w znacznej mierze rozwiązany (może pojawią się jakieś niespodziewane wyjątki od tej reguły, ale w tym momencie liczę że nie będzie ich zbyt wiele). Chodzi o to, żeby nie było tak, że ktoś zmieni stronę aby używała nowego formatu, a ktoś inny ją przeformatuje w inny sposób, bo tak będzie jego zdaniem lepiej wyglądało. Jeśli format będzie oficjalnym zaleceniem, takie sytuacje nie powinny już mieć miejsca, a gdyby miały, to zalecenie edycyjne będzie poważnym argumentem za przywróceniem "oficjalnego" sposobu formatowania.
- Ręczne sprawdzanie listy to mniej pracy, niż poprawienie disambigów.
Nie do końca rozumiem, o sprawdzenie której listy chodzi?
- Może po prostu ręcznie sprawdzać i poprawiać wszystkie disambigi, a
zaraz zgłaszać do przeskanowania przez bota? Żeby to uaktualniać
Ważne byłoby dla mnie to, aby nie było wpisów pasujących do ustalonego formatu, ale zawierających w pierwszym linku "niewłaściwą" stronę. Jeśli jakieś strony używałyby innego formatu (bo jeszcze nie zostały sprawdzone), to nie byłoby to problemem - bot po prostu ignorowałby je. Więc jeśli chodzi o moje potrzeby, to nie ma konieczności sprawdzania od razu wszystkich disambigów (choć oczywiście taka akcja na pewno byłaby bardzo pomocna), możnaby to sprawdzanie rozłożyć w czasie (a nawet bez sprawdzania mechanizm powinien działać przyzwoicie).
- Tak dla ścisłości. Chcecie wykorzystywać to przy wyświetlaniu
materiałów z wikipedii, czy poszukiwanych stron?
Przy przeszukiwaniu Wikipedii.
Zmieniając po raz kolejny strategię proponuję zatem:
1. Na razie dać sobie spokój z szablonami i innymi markerami. Jeśli okaże się, że samo sprawdzanie ujednoznacznień pasujących do ustalonego formatu to za mało, najwyżej za jakiś czas ponownie wrócę do tematu.
2. Dopracować szczegółowo zalecenia edycyjne ze strony http://pl.wikipedia.org/wiki/Wikipedysta:Witek1988/brudnopis i jeśli będzie co do nich zgoda, na umieszczenie ich na http://pl.wikipedia.org/wiki/Wikipedia:Strony_ujednoznaczniaj%C4%85ce jako oficjalnego zalecenia dla tworzących strony ujednoznaczniające.
Prawdopodobnie trzeba by też dopuścić oprócz formatu *[[podobna nazwa]] - krótka definicja również dodatkowo *[[podobna nazwa]] (wyjaśnienie) - krótka definicja bo taki format wydaje się być używany na sporej liczbie stron, np. w taki sposób: * [[hrabstwo DeKalb (Alabama)|hrabstwo DeKalb]] ([[Język angielski|ang.]] ''DeKalb County'') – w stanie [[Alabama]] i przenoszenie nazwy oryginalnej za myślnik źle by wyglądało.
Pozdrawiam, Michał
09-05-07, Michal Kosmulski michal.kosmulski@netsprint.pl napisał(a):
Jeśli dałoby się uczynić ze wspomnianego formatu oficalne zalecenie edycyjne, to myślę, że mój problem byłby w znacznej mierze rozwiązany (może pojawią się jakieś niespodziewane wyjątki od tej reguły, ale w tym momencie liczę że nie będzie ich zbyt wiele). Chodzi o to, żeby nie było tak, że ktoś zmieni stronę aby używała nowego formatu, a ktoś inny ją przeformatuje w inny sposób, bo tak będzie jego zdaniem lepiej wyglądało. Jeśli format będzie oficjalnym zaleceniem, takie sytuacje nie powinny już mieć miejsca, a gdyby miały, to zalecenie edycyjne będzie poważnym argumentem za przywróceniem "oficjalnego" sposobu formatowania.
- Ręczne sprawdzanie listy to mniej pracy, niż poprawienie disambigów.
Nie do końca rozumiem, o sprawdzenie której listy chodzi?
To dopracuj to zalecenie i zgłoś je pod dyskusję w kawiarence technicznej - jak nikt nie będzie protestował to nie trzeba przeprowadzać głosowania - jak będą protesty no to trzebaby to głosować. Co ciekawe, na en-wikipedii już dawno na to wpadli, przy czym tam zasady są ostrzejsze - np: disambigi mają być ujednoznacznieniami - a nie stronami gdzie wsadza się wszystko co się "kojarzy". Skojarzenia można ew. wsadzać do sekcji "zobacz też" - natomiast w głównej części disambiga mają być tylko hasła, które mają identyczne brzmienie/zapis - ale różne znaczenia.
Np: żuraw: *żuraw (ptak) *żuraw (maszyna)
Zobacz też: *żurawina *dźwignia prosta
http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28disambiguation_pag...
Uporządowanie sprawy disambigów na pewno wszystkim wyjdzie na dobre.
| -----Original Message----- | From: ... Tomasz Ganicz | Sent: Wednesday, May 09, 2007 10:42 AM / | To dopracuj to zalecenie i zgłoś je pod dyskusję w kawiarence | technicznej
Z zaznaczeniem, że była owocna dyskusja na liście :-P - niech niechętni liście mają za swoje ;-) . Przy okazji obalono (kolejny raz) tezę Łorksa, że nic sensownego tu nie da(ło) się wypracować. Oczywiście wiem, że taka wypowiedź to była kolejna podpucha łorsksowa, ale wolę to napisać, bo sporo tu nowych i ktoś z nich nie znając naszego ;-) sympatycznego esfałgowca pewnie mógł się wystraszyć.
| - jak nikt nie będzie protestował to nie trzeba | przeprowadzać głosowania - jak będą protesty no to trzebaby | to głosować.
To zależy od tego jakie będą te hipotetyczne protesty. Jeśli merytoryczne, to jedno, jeśli w stylu "nie bo nie", to nie będzie po co tracić czasu. Sam wprawdzie tylko śledzę dyskusję, i choć z braku czasu nie wnikam w szczegóły, to jednak widzę że jest merytoryczna i prowadzona we wzorcowym wikianym stylu, a wnioski są słuszne i konsensusowe. Przy okazji uznanie dla Michała, który nie bronił swojej koncepcji jak ukochanego dziecięcia lub niepodległości. No i ważny argument, że na enwiki jest to uregulowane jest też istotny - choć oczywiście tak jak m.in. Beno nie uważam, że musimy wszystko kopiować z en.
I na marginesie - czy to nie jest pierwszy przypadek współpracy społeczności plwiki z komercją? Poza Helionem oczywiście, ale to coś innego.
Pzdr., Janusz "Ency" Dorożyński
Idąc za radą Polimerka, poruszyłem temat w kawiarence technicznej: http://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne_dyskusj... Mam nadzieję, że zachowałem właściwe formy :) Nie korzystałem wcześniej z kawiarenki. Jeśli w moim podsumowaniu zabrakło czegoś, to proszę o uzupełnienie. Zobaczymy, jaki będzie odzew kawiarenkowiczów. Pozdrawiam, Michał
On Tue, May 08, 2007 at 08:28:57PM +0200, Michał Kosmulski wrote:
- Tworzymy szablon o nazwie, dajmy na to, {{link-1-ujednoznacznia}}.
Moim zdaniem jest to nadal niepotrzebne komplikowanie życia. Trzeba by poprawić dokładnie wszystkie istniejące disambigi.
Lepiej byłoby przyjąć ujednolicony format jak ten z brudnopisu Witka1988 (który zwykle i tak intuicyjnie jest przestrzegany). Na pewno część disambigów trzeba będzie poprawić, ale mniej niż w pierwszym przypadku.
Wanted
Przejrzałem trochę disambigów i przynajmniej w ich przypadku znalazłem dwa wzorce lini w których mozna by bezbłędnie określić o który link chodziło. ^* ?[[([^]*)|?.*]] ?[-—] ?(.*)$ albo: ^* ?[[([^]*)|?.*]]$ jeśli nie ma tytułu.
P.S. mamy czasem niezłe jaja, ala [[Alba]], np. * [[alba (szata liturgiczna)|szata liturgiczna]] koloru białego * [[Alba (Włochy)|miasto]] we [[Włochy|Włoszech]] * [[Alba (wino)|wino]] włoskie z okręgu Alba * [[Okręg Alba|okręg]] w [[Rumunia|Rumunii]]
wygląda jakby nie było artykułów na temat tych haseł.
Dnia Tue, 08 May 2007 20:28:57 +0200, Michał Kosmulski michal.kosmulski@netsprint.pl napisał:
Wpadlem jednak na pomysl, jak mozna osiagnac [prawie] ten sam efekt bez potrzeby az tak silnej ingerencji w wyglad stron ujednoznaczniajacych. Oczywiscie tak samo jak pierwotna koncepcja, tutaj tez stosowanie tej techniki lub jej nie stosowanie nie byloby w zaden sposob wymuszone.
A ja na inny pomysł wpadłem - sprawdzanie botem netsprinta, który link wraca na stronę ujednoznaczniającą. Czyli sprawdzanie czy w artykułach docelowych jest szablon {{DisambigR}}. Wtedy bot wie, który linki są te właściwe. Można też przyjąć, że link właściwy jest pierwszy po znaku *. Chyba, że w nim nie ma {{disambigR}}-a - wtedy bot sprawdza czy drugi link (i tak do końca strony).
Taki sposób ma tą zaletę, że nas zmotywuje do wstawiania {{disambigR}} do artykułów.
A ja na inny pomysł wpadłem - sprawdzanie botem netsprinta, który link wraca na stronę ujednoznaczniającą. Czyli sprawdzanie czy w artykułach docelowych jest szablon {{DisambigR}}. Wtedy bot wie, który linki są te właściwe. Można też przyjąć, że link właściwy jest pierwszy po znaku *. Chyba, że w nim nie ma {{disambigR}}-a - wtedy bot sprawdza czy drugi link (i tak do końca strony).
To chyba dałoby marne rezultaty, bo disambigR jest stosowany raczej rzadko, i wydaje mi się, że takie było zamierzenie. Myślę, że nie chodziło o dodawanie tego szablonu w każdej stronie, do której jest link ze strony ujednoznaczniającej.
Jako, że zmiana w disambig nie zyskała poparcia, myślę, że i ten pomysł zarzućmy.
Proponuję: sformułujmy teraz ładne podsumowanie tego, na co chyba wszyscy się zgodzili, czyli uporządkowania stron ujednoznaczniających i dopasowanie ich w miarę możliwości do formatu *[[link docelowy]] (opcjonalna wersja obcojęzyczna itd.) - opis znaczenia
Następnie umieśćmy to gdzieś, gdzie będzie mogło uczynić krok w kierunku uznania za "oficjalne" zalecenie edycyjne i będzie to już bardzo dobry początek - i netsprint i wikipedia coś na tym zyskają.
Pozdrawiam, Michał
On Tue, 8 May 2007, Michał Kosmulski wrote:
*[[Lepton (mechanika kwantowa)]] - grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].{{link-1-ujednoznacznia}} *[[Lepton (moneta)]] - [[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].{{link-1-ujednoznacznia}} *Slowo lepton bywa takze stosowane jako [[obelga]], najczesciej w formie ''[[Ty leptonie]]''
ok, będzie, że szukam dziury w całym, ale przy akurat takim rozwiązaniu, wystarczy, że ktoś teraz zmodyfikuje tekst, nie modyfikując szablonu i już masz błąd...
wydaje mi się, że jeśli taki szablon miałby tam być, to musi on być nie tylko pusty i obok, ale jeszcze do tego niezależny od treści, bo nie możesz wymagać od każdego, że będzie wiedział jak tego użyć...
pozdrawiam, blueshade.
(...)
W zasadzie zamiast tego skomplikowanego systemu wystarczyłoby przyjąć zalecenie, że poszczególne wpisy w disambigu rozpoczynamy zawsze od linku do disambigowanej strony. Szansa na przestrzeganie tego prostego zalecenia będzie większa niż na to, że przyjmie się złożony mechanizm tworzenia dismabigów przy pomocy dwóch szablonów, z których jeden jest wariantowy i wymaga dwóch parametrów.
-- Tomek "Polimerek" Ganicz
System proponowany jest rzeczywiście skomplikowany - zastanawiam się, czy nie wystarczyłoby rozwiązanie znacznie prostsze.
Wstawianie linku bezpośrednio po gwiazdce ma głęboki sens.
Ale jeśli w niektórych przypadkach tak się nie da (pytanie, czy na pewno) - czy nie wystarczyłoby rozszerzyć szablon {{disambig}} w ten sposób, by po znaku | można było dawać nazwy haseł, do których disambig prowadzi? Najlepiej w kolejności ich występowania dalej, w gwiazdkach.
Np. zupełnie z głowy, w hipotetycznym haśle ABC {{disambig|ABC (stacja telewizyjna)|ABC (nowela)|ABC (organizacja polityczna)}}
A dalej już gwiazdki.
Pozdrawiam,
michał "aegis maelstrom" buczyński.
{{disambig|ABC (stacja telewizyjna)|ABC (nowela)|ABC (organizacja polityczna)}}
Pomysł jest ciekawy, dla mnie takie coś byłoby bardzo wygodne, ale obawiam się, że mogą tu paść podobne zarzuty jak względem poprzednich propozycji opierających się o szablony. Trzeba jednak przyznać, że twoje podejście ma tę zaletę, że nie zmienia w ogóle treści samych wypunktowań, czyli nie utrudnia życia osobom nie zainteresowanym.
Może dałoby się nawet zrobić jakąś prostą wizualizację (typu: wąska belka zawierająca tylko listę ujednoznacznianych haseł i ułatwiająca szybką nawigację), aby przekonać więcej osób do stosowania tego szablonu. Pewną trudnością może być lista parametrów zmiennej długości, na pewno można to obsłużyć czymś w rodzaju: {{#if:{{{1|}}}|[[{{{1}}}]]|}} {{#if:{{{2|}}}|[[{{{2}}}]]|}} ... {{#if:{{{100|}}}|[[{{{100}}}]]|}}
ale chyba nie byłoby to zbyt eleganckie ani wydajne. Może ktoś kto zna się na szablonach mógłby doradzić?
W każdym razie (nie wycofując się z tego co napisałem pozytywnego o ustalonym formacie wypunktowań), uważam koncepcję parametrów w disambig za ciekawą.
Pozdrawiam, Michał
A według mnie pomysł wcale nie jest aż taki ciekawy. Ten szablon nie jest aż tak potrzebny. Pomyślmy o tych, którzy zajmują się edytowaniem treści a nie kodu. Disambig w obecnym kształcie może zrobić każdy. Ale jak ktoś tylko jako tako zna się na programowaniu, to obsługa szablonu jest dość trudna i tylko będzie odstraszać nowicjuszy, a tego naprawdę nie chcemy.
To takie tam moje skromne przemyślenia.
Zureks
| -----Original Message----- | From: ... Stan Zurek | Sent: Wednesday, May 09, 2007 1:57 PM / | A według mnie pomysł wcale nie jest aż taki ciekawy. Ten | szablon nie jest aż tak potrzebny. Pomyślmy o tych, którzy | zajmują się edytowaniem treści a nie kodu. Disambig w obecnym | kształcie może zrobić każdy. Ale jak ktoś tylko jako tako zna | się na programowaniu, to obsługa szablonu jest dość trudna i | tylko będzie odstraszać nowicjuszy, a tego naprawdę nie chcemy.
Ujednoznacznianie nie jest dla nowicjuszy. Tak jak wiele innych rzeczy, choćby parser czy tabele. Na warsztatach w Białowieży dla nowicjuszy nawet o tabelach tylko zająknąłem się. Sam ujednoznacznianie robię rzadko, choć zapewne nowicjuszem nie jestem. Może nawet z czasem to będzie odrębna wikispecjalizacja - ujednoznacznianie ;-) .
Pzdr., Janusz "Ency" Dorożyński
Ujednoznacznianie nie jest dla nowicjuszy.
A co w przypadku jeśli ujednoznacznienie już istnieje i trzeba dodać pozycję (np. [[Ruch]] )? Normalnie każdy nowicjusz może to zrobić, bo jest to dziecinnie proste. W przypadku szablonu już tak niestety nie będzie.
Ale to tylko moje zdanie, bo ja bym się w ogóle bardziej zajął edycją treści niż zabawą w szablony i inne takie tam.
Pozdrawiam
Zureks
| -----Original Message----- | From: ... Stan Zurek | Sent: Wednesday, May 09, 2007 3:08 PM / | A co w przypadku jeśli ujednoznacznienie już istnieje i | trzeba dodać pozycję (np. [[Ruch]] )? Normalnie każdy | nowicjusz może to zrobić, bo jest to dziecinnie proste. W | przypadku szablonu już tak niestety nie będzie.
Dopóki będzie dziecinnie proste, to zrobi to, a jak przestanie być dziecinnie łatwe, to zostawi to fachowcom :-)) . Wiki w ogóle była dziecinnie prosta (o ile już znało się trochę hateemela) jakieś 3 lata temu. Teraz się coraz bardziej komplikuje i raczej nie ma od tego odwrotu. Tak przy okazji - oprogramowanie MW ma już około 300 rozszerzeń.
| Ale to tylko moje zdanie, bo ja bym się w ogóle bardziej | zajął edycją treści niż zabawą w szablony i inne takie tam.
Całkowicie popieram, dlatego mało grzebię w szablonach (zresztą i tak część jest dla mnie zablokowana) i innych takich.
Pzdr., Janusz "Ency" Dorożyński
Ujednoznacznianie nie jest dla nowicjuszy. Tak jak wiele innych rzeczy, choćby parser czy tabele. Na warsztatach w Białowieży dla nowicjuszy nawet o tabelach tylko zająknąłem się. Sam ujednoznacznianie robię rzadko, choć zapewne nowicjuszem nie jestem. Może nawet z czasem to będzie odrębna wikispecjalizacja - ujednoznacznianie ;-) .
Pzdr., Janusz "Ency" Dorożyński
Mam zrobić z tego
http://pl.wikipedia.org/wiki/Wikipedia:WikiFaktoria/Porz%C4%85dki_na_szlakac...
redirect [[Wikiprojekt:Naprawa disambigów]] ? po przeredagowaniu tekstu? Może by ożyło?
przykuta
Ogólnie odpowiem na wszystko.
Jak dla mnie, to w Wikipedii nie powinno znajdować się nic co nie służy Wikipedii i tutaj swojego zdania nie zmienię. Powinniśmy starać się aby jej treść była przyjazna generowaniu danych na jej podstawie, ale nie powinniśmy umieszczać w niej żadnych elementów służących jedynie innym projektom, czy jak chcecie to nazwać. Dodanie takich parametrów do szablonu disambig służyło by jedynie botowi netsprinta, bo wyświetlanie listy pod którą będzie druga lista to bezsens. A tak na marginesie, to szablonu nie trzeba by modyfikować, bo po prostu zignoruje te parametry.
Stosowanie disambigR na stronach typu [[xxx (yyy)]] nie ma moim zdaniem głębszego sensu. Prędzej proponował bym je usunąć. Jeśli ktoś trafi na hasło [[Bitwa pod grunwaldem (obraz)]] to znaczy, że szukał informacji o obrazie, a nie o bitwie. Jak ktoś trafi na [[Bitwa pod grunwaldem]] to już nie wiadomo, więc o ile dobrze się orientuje disambigR służy do tego, aby mógł znaleźć też inne hasła.
A co do sprawdzania listy, to chodziło mi o to, aby odrzucać błędnie wygenerowane synonimy.
*[[zwierzę]] - drapieżnego [[ssak]]a to totalna skrajnośc, już bardziej na redirectach można się przejechać.
A swoją drogą to ciekawe jakie rezultaty dało by generowanie na zasadzie [[(.*)|(.*)]] i pozostawieniu tych kombinacji które występują n razy, oraz odrzucenie tych, w których przypadku skrypt jest w stanie zauważyć, że są odmienionym słowem.
| -----Original Message----- | From: ... Przykuta | Sent: Wednesday, May 09, 2007 5:56 PM / | > [od Witka] | > Jak dla mnie, to w Wikipedii nie powinno znajdować się nic co nie | > służy Wikipedii i tutaj swojego zdania nie zmienię. | | Sorki, ale to Wikipedia jest dla ludzi, więc ludziom powinna | służyć... Taka mała dygresja ;)
Przykuta, czy mógłbyś cytaty lepiej formatować? Bo ten powyżej musiałem sam opisać tekstem w kwadratowych nawiasach.
Natomiast mnie też zainteresowało bezapelacyjne stwierdzenie o tym co służy Wikipedii. Jak i późniejsze wypowiedzi z konta Radomil ;-) . Obie zaistniały w oderwaniu od realiów, cokolwiek zrozumiałym w naszym jednak półświatku umiejącym edytować na poziomach od średniego do super zaawansowanego.
Faktycznie rzecz w tych ludziach. Otóż wiki jest produktem w pierwszej kolejności do czytania - przez większość ludzkości, czyli Wikipedia ma służyć do czytania i w żadnym wypadku nie ma służyć Wikipedii (lub społeczności jej edytorów). Natomiast w drugiej kolejności Wikipedia ma być do edytowania, ale to już jest adresowane do radykalnie mniejszej liczby ludzi. To że my jesteśmy w tej grupie i nieźle się przy tym bawimy nie ma aż tak wielkiego znaczenia wobec celu pierwszego. Bo dla niego znaczenie ma nie łatwość edytowania, tylko popularność i widoczność w wyszukiwarkach, głównie w komercyjnym Googlu. Proszę obalić tezę, że popularność Wikipedia zawdzięcza jakości swojego kontentu a nie pierwszym miejscom spośród miliona wskazań (często pewnie lepszym niż wskazanie na wiki) w wynikach guglania jakiegoś słowa. Jeśli obalić się nie da, to będzie to oznaczało, że wiki jest już uwikłana w relacje w biznesem. Oczywiście można z pozycji religijnych udawać, że tak nie jest, ale z takimi osobami ja osobiście nie będę w stanie porozumieć się, gdyż uważam, że uwikłanie jest. Może nawet groźniejsze niż jestem w stanie podejrzewać. Ale póki co nie widzę powodu, aby w takiej sytuacji nie wspierać - oczywiście jeśli ma to sens i służy Wikipedii, czyli celowi pierwszemu - i współpracować z takim ciekawym rodzimym przedsięwzięciem jak choćby Netsprint. Zresztą ludzie od niego też rodzimi ;-) i sympatyczni.
Pzdr., Janusz "Ency" Dorożyński
On Wed, 9 May 2007, Witek1988 wrote:
Stosowanie disambigR na stronach typu [[xxx (yyy)]] nie ma moim zdaniem głębszego sensu. Prędzej proponował bym je usunąć. Jeśli ktoś trafi na hasło [[Bitwa pod grunwaldem (obraz)]] to znaczy, że szukał informacji o obrazie, a nie o bitwie.
a skąd to wiadomo? mógł tu trafić z google'a i wcale nie szukać obrazu... disambigi wsteczne są niewiele mniej ważne niż te normalne...
A według mnie pomysł wcale nie jest aż taki ciekawy. Ten szablon nie jest aż tak potrzebny. Pomyślmy o tych, którzy zajmują się edytowaniem treści a nie kodu. Disambig w obecnym kształcie może zrobić każdy. Ale jak ktoś tylko jako tako zna się na programowaniu, to obsługa szablonu jest dość trudna i tylko będzie odstraszać nowicjuszy, a tego naprawdę nie chcemy.
Ja się z tym zdaniem zgadzam. Wikipedia powinna być jak najbardziej przjazna użytkownikom i jak najbardziej intuicyjna. Obecnie ze smutkiem obserwujędoążenie cześci "technokratycznej" części wikipedystów.
W swojej historii wikipedia zrobiła krok w dobrą strone- zastąpienie htmla kodem wiki w budowie tabel, który jestznacznie prostszy, z drugiej strony zaraz potem zrobiłą dwa kroki wstecz wprowadzając szablony warunkowe, które zniszczyły tą łatwość utrudniajac edycję tabel znacznie bardziej niż html.
Każde takie posunięcie, przesuwajace jakieś "kompetencje" w tworzeniu wikipedii do poziomu "specjalistów" jest takim krokiem wstecz. Ułatwi to być moze pracę maszynom, ale utrudni ludziom.
Zastanówmy się - dla kogo tworzymy Wikipedię - dla ludzi umiejących posługiwać się botami, bazami danych etc. czy dla przecietnego zjadacza chleba, którego to nie interesuje i interesować nie będzie?
Każde rozwiazanie komplikujące edycję wikipedii jest odstępstwem od naczelnych zasad tego projektu. Przypominam, że systemem do którego dążymy nie jest technokracja a merytokracja.
(To takie moje, laickie POV) Radomil
09-05-07, Radomil Binek radomilbinek@gmail.com napisał(a):
A według mnie pomysł wcale nie jest aż taki ciekawy. Ten szablon nie jest aż tak potrzebny. Pomyślmy o tych, którzy zajmują się edytowaniem treści a nie kodu. Disambig w obecnym kształcie może zrobić każdy. Ale jak ktoś tylko jako tako zna się na programowaniu, to obsługa szablonu jest dość trudna i tylko będzie odstraszać nowicjuszy, a tego naprawdę nie chcemy.
Ja się z tym zdaniem zgadzam. Wikipedia powinna być jak najbardziej przjazna użytkownikom i jak najbardziej intuicyjna. Obecnie ze smutkiem obserwujędoążenie cześci "technokratycznej" części wikipedystów.
W swojej historii wikipedia zrobiła krok w dobrą strone- zastąpienie htmla kodem wiki w budowie tabel, który jestznacznie prostszy, z drugiej strony zaraz potem zrobiłą dwa kroki wstecz wprowadzając szablony warunkowe, które zniszczyły tą łatwość utrudniajac edycję tabel znacznie bardziej niż html.
Zleży jak na to patrzeć. Jeśli np. osoba znając się dobrze na tym formatowaniu przygotuje coś w stylu infoboxów, to jest to krok do przodu, bo samo wstawienie ich jest banalne na tyle, ze może zrobić to każdy. Problem zaczyna się w momencie, gdy technikalia trzeba znać aby edytować artykuły, czy inne podstawowe rzeczy, do których należą właśnie np. disambigi.
Każde takie posunięcie, przesuwajace jakieś "kompetencje" w tworzeniu wikipedii do poziomu "specjalistów" jest takim krokiem wstecz. Ułatwi to być moze pracę maszynom, ale utrudni ludziom.
Tu zgodzę się w 90% przypadków, ale jeśli np. specjaliści będą tworzyć szablony, osoby nie chcące zawracać sobie głowy technikaliami mogą traktować je jako funkcje oprogramowania, które tworzyli by jeszcze więksi specjaliści. Znowu problem pojawia się dopiero w momencie kiedy znajomość danej rzeczy stanie się niezbedna do edycji artykułów. Póki są to opcjonalne, dodatkowe możliwości dla edytujacego, są one jak najbardziej pozytywne.
Zastanówmy się - dla kogo tworzymy Wikipedię - dla ludzi umiejących posługiwać się botami, bazami danych etc. czy dla przecietnego zjadacza chleba, którego to nie interesuje i interesować nie będzie?
Tu właśnie leży sedno całej sprawy. Boty na Wikipedii powinny służyć edytującym, a nie na odwrót. Jeśli na podstawie wiki uda się coś wygenerować bardzo dobrze, jeśli jednak taki materiał wymaga przekształcenia, to jest to już oddzielny projekt i prace nad nim nie powinny być prowadzone na wiki.
Każde rozwiązanie komplikujące edycję wikipedii jest odstępstwem od naczelnych zasad tego projektu. Przypominam, że systemem do którego dążymy nie jest technokracja a merytokracja.
I tego należy się trzymać. Więcej warty jest surowy, niesforamtowany artykuł, zawierający porządny tekst, niż dwa zdania, prawie pusty infobox, szablon zalążka, szablon tematyczny, pięć kategorii, piętnaście interwiki+sekcje zobacz też i linki zewnętrzne. Osoba nie edytująca wcześniej Wikipedii po kliknięciu edytuj może się w takim przypadku przestraszyć kodu, a w efekcie Wikipedia straci treść na rzecz technikaliów.
Cześć, ponieważ minął już jakiś czas od ustania dyskusji w tym wątku, chciałbym krótko podsumować co udało się nam osiągnąć. Dzięki ustalonemu na liście (po burzliwej dyskusji) formatowi stron ujednoznaczniających, byłem w stanie uwzględnić informacje z tych stron w Mikserze (dla przypomnienia: http://pl.wikimedia.org/wiki/Grafika:Netsprint_2007.pdf). Są one już wdrożone w serwisie. Poprawiła się też sytuacja jeśli chodzi o zgodność stron z w.w. formatem, co oprócz ułatwienia pracy mojego parsera ma, mam nadzieję, pozytywny wpływ na czytelność i użyteczność stron ujednoznaczniających dla wszystkich użytkowników Wikipedii. Porównując stan z końca czerwca z tym z połowy maja, widzimy, że ubyło dokumentów o najgorszych statusach: --, --- i !, i to pomimo, że przybyło około 800 nowych stron ujednoznaczniających. Dzięki Kociowi, który zauważył błąd w parserze wikitekstu, po naprawieniu tego błędu liczba dokumentów zupełnie się nie parsujących (status "!") spadła z ponad 100 do zaledwie 11, a te pozostałe 11 właśnie ręcznie poprawiłem, tak więc naprawdę jest ich teraz 0.
Oto porównanie:
Wersja z 14 maja: 25521 disambig-status 2142 disambig-status-- 383 disambig-status--- 1522 disambig-status---- 119 disambig-status-! 21355 disambig-status-+
Wersja z 29 czerwca: 26307 disambig-status 2268 disambig-status-- 319 disambig-status--- 1395 disambig-status---- 11 disambig-status-! 22314 disambig-status-+
Zaktualizowane szczegółowe dane i strony z linkami jak zwykle umieściłem pod adresem http://netsprint.pl/publikacje/generowane-z-wikipedii/ . Dodałem też plik invalid-see-also zawierający listę stron z niepoprawnymi wariantami nazwy sekcji "Zobacz też" (dotyczy wszystkich stron, nie tylko ujednoznaczniających). Ponieważ liczę, że kiedyś poprawi to jakiś bot, nie robiłem wersji "klikalnej".
Dziękuję wszystkim, którzy przyłączyli się do tego projektu czy to przez udział w dyskusji czy też edycję stron - widać, że przyniósł on spodziewane efekty, z czego bardzo się cieszę.
Pozdrawiam, Michał