User talk:Zdzislawdyrman

Cześć! Dzięki za czujne oko re: pisownia ww. nazwisk. Rozumiem, że polegasz tutaj m.in. na https://rjp.pan.pl/porady-jezykowe-main/1044-zapis-nazwisk-dwuczonowych. Myślę, że w wypadku wpisów nt. tychże nazwisk na Wikidata, warto uwzględnić definicję Property:P460:

uważa się za to samo co

niektórzy uważają że ta rzecz jest tym samym co tamta rzecz, ale nie wszyscy się z tym zgadzają

Myślę, że w wypadku tych nazwisk to jest zasadne. Bez kontekstu, osoba zainteresowana informacjami na temat żmuda trzebiatowska (zapis najbardziej neutralny na potrzeby warsztatowe) skorzysta na takiej wzmiance. Ostatecznie, bez wiedzy czy ktoś nosi nazwisko góralskie, dwuczłonowe, czy o herb chodzi, będzie mieć łatwy dostęp do powiązanych konceptów.

W P460 podałem też uzasadnienie, które może skłaniać do uznania, że to jest to samo. Sporo osób ma kłopot z zapisem nazwisk, często własnych (co najczęściej przejawia się błędnym użyciem – lub — zamiast - oraz dodanie spacji przed/po takim łącznikiem).

Może rozwiązaniem, które byłoby wizualnie dziwne, ale logicznie „żelazne”, byłoby dodanie proponowanego przeze mnie P460 oraz dodanie Q35245 w Q66087861

Czyli mielibyśmy:

uważa się za to samo (na podstawie) alternatywny zapis

inne niż (na podstawie) etymologia

tak - tak będzie ok

Cześć, jestem tutaj nowy, więc wybacz jeśli nieodpowiednio wykorzystuję funkcję user talk :)

Zauważyłem, że zmieniłeś parę moich zmian i mam pytania, jaka jest konwencja tworzenia itemów dla nazwisk. Konkretnie chodzi mi o dylematy typu: Iksiński vs Iksinki vs Iksińka vs Iksinska.

Polski kontekst: w większości te formy są de facto tożsame. Inna może być oczywiście optyka osób, które żyją poza polską i ktoś może mieć na nazwisko Iksinka po mamie, mimo że identyfikuje się jako mężczyzna i w Polsce miałby zapewne końcówkę -ski zamiast -ska. Rozumiem, też, że ktoś może być Iksinki z racji np. na polskiego przodka, który był za granicą „pozbawiony” znaku diakrytycznego lub nawet zmienił nazwisko, by unikać znaków specjalnych. Więc jest to jakiś argument za rozbijaniem ich na osobne itemy. Moje pytanie jest raczej o Property:P460. Moim zdaniem, we wszystkich 4 przypadkach taka opcja byłaby odpowiednia, ponieważ sugeruje pewną tożsamość, a zarazem zostawia przestrzeń dla tych, którzy jej nie widzą. Czy rozsądnym kompromisem nie byłoby właśnie tworzenie osobnych bytów, a „spinanie” ich P460? I wilk syty i owca cała (i z automatu można wtedy też wszystkim czterem bytom dawać taką adnotację). Kieruję się tutaj notkami stron na PWN, które zaznaczają, że forma Iksińki może występować bez polskich znaków diakrytycznych, a i że formy żeńskie są wariantami form -ski.

Dzięki - patrzę na to z perspektywy: wikidata jest przeznaczone głównie dla 'robotów' - mają tu uporządkowane dane których nie muszą dodatkowo interpretować - wszystko jest opisane - wiadomo co jest czym (i z czego wynika) - im lepiej (tzn. precyzyjniej, jednoznaczniej) opisane dane - tym łatwiej 'robotowi' odnaleźć 'sens' danych.

Rozumiem co masz na myśli z ograniczeniem ilości wpisów z odmianami nazwisk i umieszczeniem wszystkiego w jednym wpisie - ale takie rozwiązanie spowoduje sytuację gdy nie będzie osobnych wpisów z odmianami nazwisk do których można by użyć P460 bo odmiany będą już w tym pojedynczym wpisie.

Dla mnie kłopot z tym podejściem zaczął się gdy trzeba było przypisać nazwisko do osoby: gdy wszystkie formy odmiany nazwiska są w jednym wpisie - można wybrać tylko ten pojedynczy wpis - dla pani Alice Kat i pana Zbigniewa Kąt to będzie ten sam wpis i teraz nie wiadomo jak które ma na nazwisko - Kat czy Kąt?

Jeszcze bardziej interesująco zaczęło się robić przy nazwiskach pisanych cyrylicą: te potrafią być transliterowane na wiele sposobów: Икински potrafi być: Iksiński, Iksynsky, Iksinskyi, Jiksinsky - jeśli wszystkie te odmiany, warianty, transliteracje zamieścić w jednym wpisie (a także 'odwrotne' - transliteracje z łacińskich znaków na cyrylicę - bo to jest identyczne nazwisko) - jeśli to wszystko będzie w jednym wpisie to nie da się ustawić właściwego nazwiska pani Georgii Yksinsky (a właściwie się da, tylko że wszystkie formy będą w jednym wpisie i ostatecznie nie wiadomo jak powinno być zapisywane jej nazwisko).

Jestem za ograniczaniem niepotrzebnych bytów - ale w praktyce to trudne jeśli chce się zachować precyzję i jednoznaczność - na przykład: Szymon Kita i 北良治 mają to samo nazwisko - Kita to transliteracja z japońskiego, a Kita to znajome polskie słowo - poza brzmieniem nie mają ze sobą nic wspólnego - ale są użyte w pojedynczym wpisie jako nazwisko - to nie jest precyzyjne ani jednoznaczne.

Bardzo dziękuję za odpowiedź! Tak, bez wątpienia stworzenie jednego bytu byłoby złe; moje dylematy były jednak ograniczone do przykładów Iksińskich, a konkretniej do właśnie kwestii P460. Czy zgodziłbyś się, że P460 byłoby stosowne dla dokładnie tych czterech wariantów: Iksińki, Iksinki, Iksińska, Iksinska? Takie podejście (z użyciem również P5278) byłoby dla mnie bardzo naturalne, a i użyteczność dla robotów byłaby chyba odpowiednia, bo dostają sygnał typu „te warianty to osobne byty, ale probabilistycznie, w pewnych wypadkach możesz traktować je jako tożsame”. Zwł., że z polskiej perspektywy, to byłoby podejście uzasadnione choćby danymi z katalogu nazwisk PWN (i stawiam, że werdyktem większości językoznawców). Plus, w ten sposób John Zazolkowski może swoje genealogiczne poszukiwania potencjalnie poszerzyć o Zażółkowskich.

Dzięki - jasne - wygląda zupełnie ok - kiedy się da można dodać przy wartości 'qualifier' criterion used w sensie 'podpowiedzi' jakiego rodzaju 'identyczność' łączy te nazwiska (ja z takich adekwatnych znalazłem ledwie Q27955642 albo Q89410507),

Tylko do odmian męskich i żeńskich nazwiska nie używałbym 'same as' P460, ale bardziej szczegółowo - jako osobna właściwość P5278 (mam na myśli że logicznie rzecz biorąc: 'Iksiński' jest 'same as' 'Iksińska' + criterion used: 'feminine family name', i robot też 'zrozumie' to w ten sposób - ale będzie mu odrobinę łatwiej jeśli będzie to miał jako osobną właściwość).

Dobra, mamy to, dzięki!

Incorrect use of instance of (P31)

Hello –

This edit to "Klimek tower (reconstruction)" (Q106462927) was in error. The properties instance of (P31) and subclass of (P279) define key ontological relationships. Because subclass of (P279) is transitive, such errors lead to numerous false inferences, such as Klimek tower (reconstruction) (Q106462927)instance of (P31)economic activity (Q8187769). Before you use these properties, please look at the object item to be sure it's the one you intend. You can also review the usage instructions on these two properties, and Help:Basic membership properties. (In particular, note that all instances of a class must be of the same type.) There is often another property better suited to expressing the relationship you had in mind; you can search for one here. Thanks!

Tak tylko informacyjnie. Widzę, że w katalogu z nazwiskami było kilka nazwisk przypisanych do ukraińskich nazwisk (https://mix-n-match.toolforge.org/#/list/5941/unmatched), które usunąłem. W zasadzie trzeba by cofnąć edycje User:Reinheitsgebot na nich dokonane i utworzyć ajtemy do polskich nazwisk. W zasadzie etykieta nazwisk w nie-łacińskich alfabetach jest pusta, jedynie jako alias daje się dane nazwisko i w opisie w nawiasie (albo przynajmniej w opisie jest nazwisko w oryginalnym alfabecie - tak widziałem najczęściej).

When making the English labels and descriptions, could you make the label "War at Home S1E<num>" and description "Episode <num> of season 1 of War at Home"?

why this way? (usually i put title of episode in label, episode number etc. in description)

The title of the episode is not in English. If there is an official English translation of the title then use that.

Hej! Myślę, że niestety to masowe tworzenie elementów o żeńskich nazwiskach nie wyszło Ci najlepiej. Po pierwsze, nie wiem kiedy ostatnio sprawdzałeś swoją listę pod kątem ewentualnych dubli. Od kilkunastu tygodni działa fantastyczne narzędzie do półautomatycznego tworzenia elementów o nazwiskach, nazywa się QuickNames, i mnóstwo ich ostatnio powstaje. Ja w ciągu 5 minut znalazłem dwa utworzone przez Ciebie duble, pewnie jest ich dużo więcej. Po drugie, przy elementach o nazwiskach bardzo mocno rekomendowane (co można sprawdzić, tworząc choćby 1 taki element ręcznie i patrząc, co będzie wyświetlał interfejs) jest dodanie od razu właściwości native label (P1705) z odpowiednim kwalifikatorem. U Ciebie tego nie ma. Zachęcałbym do możliwie szybkich poprawek, inaczej możesz pewnie spodziewać się głosów krytyki również po angielsku, bo już niektórzy zaczęli po Tobie poprawiać. Pozdrawiam!

Dzięki - w wikidata brakuje sporo nazwisk, przetworzyłem nazwiska z nazwiska.ijp.pan.pl (z odmianami, wersjami, odmianami męskimi, odnośnikami do odmian, żeńskimi, native label zwyczajne i z wersjami odmężowskimi itp. nawet ilością wystąpień w bazie pesel wg. płci - bardzo dumny jestem z tej listy) wyszukałem rzecz jasna które nazwiska już istnieją żeby nie robić duplikatów (i mieć odnośniki do odmian, wersji bez polskich znaków itp.) brakujących w wikidata nazwisk wyszło 14k, dodawanie takiej ilości ręcznie jest mozolne - przerobiłem listę brakujących nazwisk na format v1 quickstatements i tam zacząłem dodawać.

O tym że był to zły pomysł zorientowałem się po dodaniu kilkuset nazwisk - poprawiłem te duplikaty które znalazłem (to nie były duplikaty istniejących nazwisk - quickstatements dodał nowe wpisy po kilka razy), po tym wypadku zacząłem obmyślać strategię - quickstatements w formacie csv sprawdza czy coś już istnieje więc nie będzie robić duplikatów - ale w formie csv nie pozwala dodawać pustych wartości (a takie też by były) - zrobiłem więc zupełnie minimalną listę w csv (bez native label) z myślą że w tym 'przebiegu' pododaję tylko nowe wpisy (z zapewnieniem że nie będzie robił duplikatów) i kiedy będą miały identyfikatory (Q...) przekonwertuje dane na v1 quickstatements i w następnym 'przebiegu' tylko uzupełnię brakujące dane nowo-dodanych wpisów (quickstatements w formacie v1 nie powinien robić duplikatów już istniejących wpisów).

Tak zrobiłem, ale quickstatements zaczął blokować dodawanie nowych wpisów - przekroczyłem limit, nie mogłem dodawać nowych wpisów z csv, a najgorzej że nie mogłem uzupełniać nowo-dodanych wpisów - tak powstały wpisy bez native label - na szczęście nie ma ich zbyt wiele i da się je ręcznie uzupełnić.

Po tej przygodzie zostało mi jeszcze 10k nazwisk pięknie sformatowanych, ale już nie będę ich dodawał - moja frustracja sięgnęła zenitu, używanie quickstatements jest niehumanitarne, a na koniec - jak wspominasz - dostanę baty po angielsku za dobre uczynki, i całe godziny użerania się z quickstatements.

Teraz są uzupełnione - przy okazji okazało się że niektórzy w Zimbabwe nazywają się Q97247145 , mogłem się tego spodziewać

Super, wielkie dzięki! Co do Twoich kłopotów z QS, trudno mi to jakoś specjalnie komentować, bo ostatnio używałem QS wiele miesięcy temu. Teraz wolę edytować wolniej, choć oczywiście też nie do końca ręcznie (używam całej galerii narzędzi i skryptów), ale mając nad tym wszystkim większą kontrolę. Polecam też w razie czego rozmowę z kolegą Piastu - moim zdaniem on spośród polskojęzycznych edytorów Wikidanych jest teraz najsprawniejszy w technikaliach. Pozdrowienia!

Hej! Proponowałbym, żebyś nie tworzył dla podwójnych nazwisk osobnych elementów, tylko jednak został przy tym, że dana osoba ma dwa nazwiska (każde z osobnym numerem Q), uszeregowane kwalifikatorami. Po pierwsze, tworzysz nieuzasadniony, moim zdaniem, wyłom w istniejącej praktyce. Po drugie, zobacz np. [https://commons.wikimedia.org/wiki/Category:Stefania_Jarkowska tu], co się dzieje, gdy dane o takim nazwisku zostaną automatycznie zaciągnięte na Commons (mam na myśli zamęt w kategoryzacji). Jest jeszcze taka masa polskich pojedynczych nazwisk bez elementu WD, że naprawdę lepiej skupić się na tym i nie tworzyć takich potworków. Pozdrawiam!

Dzięki za uwagę - do tworzenia podwójnych nazwisk w taki sposób natchnęła mnie pani Q2509820 - ona ma podwójne nazwisko, ale bez łącznika pośrodku - gdyby ją wprowadzić normalnie: Żmuda(1) Trzebiatowska(2) i odczytać zgodnie z konwencją - to by wyszło: 'Żmuda-Trzebiatowska' a w ten sposób nigdzie nie jest przedstawiana (za każdym razem ma spację zamiast łącznika) - zamiast jakoś kombinować - łatwiej było mi zrobić 'pojedyncze' podwójne nazwisko i jej przypisać, przy okazji odkryłem Q76425243 - po tym wszystkie podwójne nazwiska z łącznikiem wydały mi się 'nieprecyzyjne' - ale jak mówisz że taka konwencja to nie będę 'poprawiać'.

Nie mam niestety doświadczenia w commons, nie widzę co wyszło tam źle z kategoriami (za to w wikidata u pani przy nazwisku powinienem kwantyfikator P3831 zamiast P1013).

Szczerze mówiąc, przypadek nazwiska "Żmuda Trzebiatowska" wydaje mi się dość szczególny. Do takich i podobnych sytuacji przydałaby nam się opinia np. językoznawców, czym właściwie jest w polszczyźnie nazwisko (w sensie językowym właśnie, nie prawnym) i czy faktycznie istnieją dwuwyrazowe nazwiska, które zawsze należy traktować jako całość. Tego po prostu nie wiem, więc nie chcę zajmować mocnego stanowiska. Ale umówmy się, w praktyce większość podwójnych nazwisk jest efektem małżeństw i tutaj podtrzymuję moją powyższą opinię. Co do Commons - w tej chwili działa tam mechanizm zaciągania nazwisk z WD i tworzenia na ich podstawie kategorii (tak aby łatwo było znaleźć np. wszystkie kategorie biograficzne o przysłowiowych Nowakach czy Kowalskich). Jeśli na WD podajemy dwie wartości dla P734, wówczas dana osoba trafia do dwóch opartych na nazwiskach kategorii na Commons. A jeśli w P734 (tak jak było w przypadku S. Jarkowskiej) jako niezależne od siebie wartości występują nazwisko dwuczłonowe oraz jeden z członów, wówczas od jednego i drugiego powstają kategorie i robi się już niezły zamęt. Mam nadzieję, że udało mi się wyjaśnić w miarę czytelnie :)

Tak się nie modeluje danych dotyczących tekstów, wydań i książek. Wcześniej usunąłem opisy, które ty dodałeś, bo były błędne językowo. Jestem za tym, żeby usuwać elementy, które zawierają tylko stronę całości w Wikiźródłach. @Emu: - zadanie dla ciebie. (eng. A work for you. I would like to do this myself, but... You know, there is a lack of admins...).

Dzięki - doszedłem do wniosku że skoro to jest w wikidata - to dobrze byłoby aby miało 'opis' czym konkretnie to jest, ale może faktycznie szkoda fatygi. Które opisy były błędne językowo?

Błędy językowe tutaj ujmuję szeroko, z tzw. białymi znakami włącznie.