Wizja lepszej mapy - dyskusje

Moim zdaniem Wiki jest obecnie niedoinwestowana i dobrze byłoby gdyby się poprawiła, ale takiej roli, jakiej chyba od niej oczekujecie, chyba po prostu nie jest w stanie unieść.

Jako mapowicz oczekuję, że 1) mogę łatwo zgadnąć jak powinien się nazywać potrzebny tag, 2) będzie to gdzieś dokładnie udokumentowane, gdybym chciał/musiał sprawdzić. I to jest rozsądne i zrozumiałe, tylko niestety nierealne. Projekt jest już zbyt szeroki, ma zbyt wiele wyjątków i sytuacji granicznych i w dodatku dźwiga zbyt duży bagaż starych decyzji (lepszych dla budynków, ale gorszych dla obszarów), żeby dało się to załatwić kazuistyką - bo do tego się sprowadza idea “Wiki jako książka telefoniczna”, gdzie każdy numer jest opisany z osobna i żeby z niej skorzystać trzeba ściśle trzymać się zapisu, bo inaczej - klapa.

Ja w wizji reformy systemu tagowania stawiam bardziej na 1), czyli lepszą wewnętrzną logikę systemu, żeby 2) było mniej istotne (choć rzeczywiście nadal przydatne). Dyskusja na Tagging (“Wiki 2.0”) skupia się na samym Wiki i jeszcze nie wiem jakie będą końcowe wnioski, bo póki co - co symptomatyczne - kombinują nad zmianą systemu głosowania, ale w samej dyskusji nie bardzo wiedzą, jak głosować nad wnioskami w sprawie głosowań (sic! =} )…

I trochę to jest zabawne, ale dobrze ilustruje problem z wiki - jak coś jest trudniejsze i dyskusyjne, to jest za “ciężkie” jako narzędzie. Dlatego wydaje mi się, że ważne jest odchudzenie i model bardziej w stylu StackExchange - bo w dyskusji okazało się, że także forum ma swoje ograniczenia w tym względzie, tak samo jak lista dyskusyjna, więc to nie jest tylko problem z wiki, tylko skala decyzji i dyskusji jest zbyt wielka jak na te narzędzia. Już samo to, że dyskusja nad Wiki 2.0 zdominowała całą listę, świadczy o tym, że przekroczona została masa krytyczna problemów i już się nie da “tak jak dotąd”.

Oczywiście, można oczekiwać, że będzie więcej tłumaczeń, ale zobaczcie, ile jest jeszcze do zrobienia (po polsku jeszcze nie jest źle, pewnie dzięki wielkiej pracy Władka), żeby tylko mieć z grubsza komplet języków. A dochodzi jeszcze aktualizacja (nawet u nas widzę duże dziury) oraz wciągnięcie większej ilości uczestników do głosowań, żeby to było bardziej reprezentatywne w skali globalnej. W zasadzie właśnie od tego problemu rozpętała się cała dyskusja - bo do tego trzeba by tłumaczyć na bieżąco dyskusję w wielu językach, żeby nie było wykluczenia, skoro potem ma to obowiązywać bezwzględnie…

Nie zapominajmy, że i tak mamy potem kolejne “filtrowanie” w postaci stylów renderowania, zwłaszcza na domyślnej warstwie, więc to też ma wpływ na standardy tagowania - czy tego chcemy, czy nie, do pewnego stopnia to też jest ważne w kwestii tagowania, a jakoś Andy Allan i tak nie wdraża wszystkiego, co zostało udokumentowane i nie budzi wątpliwości.

Dlatego uważam, że Wiki dopiero po odchudzeniu i odpuszczeniu części pretensji do jej roli jako wyroczni ma szansę rzeczywiście działać. Maksymalistyczne oczekiwania rozumiem, ale wobec nich rzucam “sprawdzam” - czyli powiedzcie jak da się ten stan osiągnąć i dlaczego ogólny wydźwięk dyskusji nad Wiki 2.0 jest właśnie w kierunku odchudzenia i prezentacji różnych poglądów (czyli przerzucenie ostatecznej decyzji na użytkownika) zamiast dotychczasowego odgórnego systemu przyjęte/odrzucone?

Udało mi się w końcu wymyślić schemat drzewiastej hierarchizacji!

Zasadniczo powiedzmy, że jest ten hotel z restauracją otwarte w różnych godzinach (problem podrzucony przez Domissa) - wyrażone w obecnych tagach, ale hierarchicznie, wygląda to mniej więcej tak:

tourism=hotel
opening_hours=24/7
amenity=restaurant
opening_hours=10:00-22:00

czyli w uproszczeniu:

A
A1
B
B1

Na płasko można to przedstawić tak:

(A (A1) B (B1))

a jeśli się skomplikuje przez nowy tag A3, podrzędny wobec A2, to np. tak:

(A (A1 A2 (A3)) B (B1))

To oznacza, że ważna jest kolejność, przynajmniej w tym sensie, że rodzic (tag nadrzędny) musi stać bezpośrednio przed nawiasem z potomkami (czyli tagami podrzędnymi), bo przecież jak zamienimy całe człony:

(B (B1) A (A1 A2 (A3)))

to w sensie znaczenia tagowania jest to samo.

Ok, ale jak to zapisać w obecnym schemacie? To już zależy - każde rozwiązanie będzie miało swoje wady i zalety. Najlepiej chyba po prostu:

nested_objects=(tourism=hotel (opening_hours=24/7) amenity=restaurant (opening_hours=10:00-22:00))

(zewnętrzny nawias może załatwiać sprawę czytelności przy wielu znaków równości, ale technicznie jest zbyteczny, bo wystarczy zauważyć, że nazwa klucza to ciąg do pierwszej równaśki licząc od lewej). Wtedy tracimy czytelny podział na klucze i wartości, ale łatwo się to ręcznie modyfikuje. Można też odwrotnie - najpierw ustalamy kolejność alfabetycznie (to ważne):

amenity=restaurant
opening_hours=10:00-22:00
opening_hours=24/7
tourism=hotel

i dodajemy tylko tag z opisem struktury:

nesting=(1 (2) 4 (3))

Wówczas jest wszystko tak jak dotąd (plus jeden dodatkowy, dziwny tag), ale za to zmiana nazwy lub wartości, a nawet dodanie nowego tagu zwykle będzie wymagać zmiany elementów struktury.

Być może do tego najlepsza byłaby relacja (type=nested_objects), bo tam elementy chyba mają znaną kolejność. Choć w zasadzie można wówczas obejść się bez dodatkowego tagu i załatwić wszystko odpowiednią rolą dla tagów podrzędnych (np. “child” na pojedynczy element podrzędny, “child_start” w znaczeniu otwarcia nawiasu/grupy podrzędnej do poprzedniego elementu, “child_end” jako zamknięcie nawiasu/grupy podrzędnej). Minus jest niestety taki, że relacja dotyczy obiektów (węzłów, linii, relacji), a nie gołych tagów…

Oczywiście można też przeprowadzić rewolucję i z k=v przejść na inny zapis danych, np. jakiś rodzaj XML. :slight_smile: Bo te wszystkie zapisy są skomplikowane tylko dlatego, że nie były wymyślone jako takie od początku i to kolejne sztukowanie. Ale z drugiej strony nie wydaje mi się, żeby to był duży problem, bo wydaje mi się, że tylko mała część obiektów wymaga zagnieżdżania drzewiastego. Nawet z równorzędnymi funkcjami:

nested_objects=(shop=clothes) (shop=jewelry)

(to jest to samo co “shop=clothes;jewelry”, ale bez średnika) będzie to mniejszość. Ale dobry system polega na tym, żeby łatwe rzeczy robić łatwo (czyli jak dotąd), a trudne żeby też były możliwe - i to by było rozszerzenie właśnie do takich przypadków.

Na pewno bardzo pomogłoby, gdyby nasze narzędzia oferowały wygodną reprezentację drzewek (taką z wcięciami na przykład), ale i bez graficznej reprezentacji dałoby się tego schematu używać w tych specjalnych przypadkach, kiedy nie chcemy oszukiwać przyjmując nadmierne uproszczenia.