Wikidata:Bar

Il luogo per discutere dei diversi aspetti di Wikidata: il progetto in quanto tale, regole e proposte, dati dei singoli elementi, problemi tecnici, etc.

Inizia una nuova discussione

Puoi verificare nelle domande più frequenti.

Edit

In questa pagina, le vecchie discussioni sono archiviate. Una panoramica di tutti gli archivi può essere trovata nell'indice. L'archivio attuale si trova in 2023/06.

Aggiornato: 3 giugno 2023, 14:54 Utente: Divudi85

Liste dei musei per Regione su itwiki[edit]

Ciao, segnalo questa discussione in corso su itwiki, in particolare i punti 1. e 7. del mio riassunto, sono emerse alcune considerazioni interessanti sui musei su Wikidata. Ping Notified participants of WikiProject Italy. Buon wiki, Patafisik (talk) 12:42, 16 May 2023 (UTC)Reply[reply]

Wikiraduno a Bologna, il 3 giugno 2023[edit]

Ciao,

spero stiate tutti bene. Vi segnalo il wikiraduno di sabato 3 giugno 2023 a Bologna.

Programma

mattino visita al Museo geologico Giovanni Capellini e all'Orto botanico
pranzo di gruppo al ristorante greco
pomeriggio editathon - mapping party al Salaborsa Lab (per wikimediani e mapper esperti)

Durante l'editathon - mapping party aggiorneremo le informazioni sui musei e i beni culturali e più in generale sulle zone colpite dall'alluvione. Non esitate a fare proposte.

Si puo' partecipare on line o da vivo, tutta la giornata o anche solo a una parte delle attività. Spero di rivedere i colleghi di vecchia data e anche facce nuove!

Fateci sapere se venite sulla pagina dell'evento o se preferite prenotate su Eventbrite. Fatevi vivi soprattutto per permettermi di precisare i posti prenotati al ristorante. ;) A presto, Patafisik (talk) 07:49, 22 May 2023 (UTC)Reply[reply]

Coordinate di dati provenienti da istituzioni e GLAM: stabiliamo una regola chiara?[edit]

Ciao,

riapro un discorso che è rimasto in sospeso da tanto tempo.

Su Wikidata importiamo spesso basi di dati di GLAM e istituzioni. Dati che hanno quindi una fonte ufficiale.

E' prassi comune, ad esempio per le date di nascita di personaggi storici, di avere diversi valori provenienti da fonti diverse, si tengono tutti con le loro fonti e se ne indica uno come preferito, di solito con il qualificatore "motivo di classificazione preferita". Certo, per le date di nascita è facile, ce n'è una sola giusta e precisa (es. 1° luglio 1937), al limite puo' essere incompleta (es. 1937) o errata (es. 1973).

Parlando con varie persone on line o dal vivo, ad esempio durante i nostri Open Data Pax, ho sempre trovato l'unanimità concorde nel dire che i dati dei GLAM vanno tenuti, se sono sbagliati si mette "valore sconsigliato" o "non corretto", ma che i dati con fonte autorevole non si buttano mai, neanche se non ci piacciono e/o sono sbagliati.

Questa prassi che a me sembra una regola generale (correggetemi se sbaglio) ha pero' un'eccezione nella pratica, nel caso specifico delle coordinate geografiche. Per le coordinate non vale la regola del "c'è un solo valore giusto e preciso".

Guardando i miei osservati speciali, ho visto spesso che coordinate fontate da ente ufficiale siano eliminate allo scopo di valorizzarne altre, a volte senza fonte, per avere un valore unico e veder scomparire quel fastidioso avviso che dice "di coordinate ce ne puo' essere una e una sola".

L'incoerenza (che forse vedo solo io) emerge in modo particolarmente acuto quando si devono fare dei merge, per cui nell'elemento unito si sommano le coordinate da fonti diverse. E' quello che è successo in passato con i dati del TourER, di cui ho riparlato recentemente con Ilaria Di Cocco e Giuseppe per riprendere in mano il lavoro lasciato in sospeso^[1], anche a causa di questo problema mai risolto.

Moltissime coordinate del TourER erano state soppresse da qualcuno che preferiva le coordinate al centro dell'edificio anziché sull'ingresso (parlando con esperti di OpenStreetMap, ad esempio Mmo o Jirachi, sembra invece abbastanza comune avere le coordinate all'ingresso e sul civico). Quando chiesi al Bar il ripristino dei dati, e al massimo di indicare come preferito il valore che si riteneva più pertinente senza sopprimere l'altro, non ho ottenuto nulla e nessuno ha più partecipato alla discussione.

Eppure un consenso ci vuole per permetterci di procedere nel modo più sensato.

Una soluzione per non perdere dati c'è, ed è quella di usare reason for deprecated rank (P2241)incorrect value (Q41755623) o reason for preferred rank (P7452)referenced value (Q71536081), di modo da avere sempre un solo valore di coordinate che emerge sugli altri. Ma finché non ci mettiamo tutti d'accordo che è cosi' che si deve fare, passerà sempre qualcuno a buttare dati in modo arbitrario, facendo di fatto perdere di valore a Wikidata.

Altrimenti, se il consenso va da un'altra parte e i dati da tenere sono quelli preferiti dal primo wikidatiano che passa, e c'è consenso a eliminare i dati dei GLAM, per me basta saperlo e mi adeguero', ma magari dovremmo essere corretti e trasparenti e formalizzarla questa convenzione, e dirlo anche agli enti che ce li forniscono quei dati.

Se invece il consenso è sul dire "i dati con fonte autorevole non si buttano mai" anche se sono errati, allora formalizziamo questo e spargiamo la voce tra gli utenti che editano Wikidata ed esigiamo che rispettino la regola.

Notified participants of WikiProject Italy

Grazie per l'attenzione, Patafisik (talk) 10:18, 23 May 2023 (UTC)Reply[reply]

Si potrebbe sempre proporre una proprietà per le coordinate dell'ingresso o iniziare a usare i qualificatori. ValterVB (talk) 11:38, 23 May 2023 (UTC)Reply[reply]

↑ Dato che alcuni me l'avevano chiesto, non ho più proceduto a fare dei merge in quantità sia per la questione lasciata in sospeso che per motivi personali.

Concordo con la proposta di @Patafisik: definire con precisione 1. non cancellazione dei dati di GLAM 2. definizione di regole chiare sull geolocalizzazione. Va tenuto conto per quanto riguarda i GLAM che molti dati importati dai DB del Ministero beni culturali sono molto approssimativi e per disgrazia sono stati importati massicciamente e grossolanamente in Wikidata; abbiamo molto da correggere.--Susanna Giaccai (talk) 18:09, 23 May 2023 (UTC).Reply[reply]

Concordo sulla necessità di trovare il consenso su delle regole condivise.

Personalmente penso che servano delle regole più complesse del semplice "i dati con fonte autorevole non si buttano mai".

Per esempio, se un dato è palesemente sbagliato e dopo che è stato importato su Wikidata la fonte originale si corregge il dato va tenuto?

Un esempio concreto è la dichiarazione Palazzo Comunale in via Ugo Bassi, 2 (Q106223387)coordinate location (P625)45° 29' 18.798", 9° 11' 0.218". Questa era stata importato da Bibliotecasalaborsa.it (Q105836994), era palesemente sbagliata (e già stata deprecata per questo) e in seguito sulla fonte originale è stata corretta con un valore corretto (visibile sulla mappa qui). A questo punto di che utilità era questa informazione? Era palesemente sbagliata e non era più indicata neanche dalla fonte originale. Anche seguendo le indicazioni di Help:Deprecation non mi pare che superi le ragioni per preferire la deprecazione all'eliminazione:

non è un'informazione superata (è sempre stata errata)
la posizione è a Milano e l'edificio è a Bologna quindi si è trattato di un errore tecnico e neanche qualcuno interno alla fonte l'avrà mai considerato corretto
il bisogno di prevenire l'inserimento per errore da parte di qualcuno è praticamente nullo perchè l'unica fonte da cui potrebbe ri-entrare quel valore è un ri-import dei VECCHI dati
questo valore non raprresenta l'evoluzione nel tempo dell'informazione, è semplicemente sbagliato

Per questo io stesso l'ho rimossa.

Perchè le regole condivise abbiano veramente effetto non basterebbe spargere la voce, bisognerebbe trovare un consenso globale per aggiungere le indicazioni anche su Help:Deprecation, ma mi rendo conto che si un passo in più non piccolo, facciamo un passo alla volta. Danysan1 (talk) 21:01, 23 May 2023 (UTC)Reply[reply]

(confl.)Son temi noti mi pare (non ho molta rete e leggo molto di fretta). In Toscana se ricordo la tedenza era sbarbare totalmente coordinate del tutto errate e senza informazioni temporali (caso frequente per enti comunali, quelle che finivano sul municipio e non si capiva se la sede era stata temporanea o una coordinata "di comodo") ma fuori da questo caso ho preferito tenerle quando fontate lasciando un rank minore e questo per non poche coordinate provenienti da import generalisti, se non potevo dimostrarne l'errore.

Il punto è che si può fssare un'ottima linea guida procedurale, ma alla fine solo chi conosce davvero il territorio sa cosa fare. Diciamo che bisogna iniziare a chiudere il rubinetto a import verticistici in alcune zone perché aumentano il rumore di fondo e ci scaricano lavoro senza un rapporto ottimale pro/contro. Questo non vale solo per i luoghi della cultura ma per molti altri dati georeferenziati (scuole, monumenti, cimiteri...). Il problema alla base sta lì. Si può anche avere il protocollo perfetto su come procedere in teoria per gestire lo sporco presente, ma forse il problema è dare un taglio in ingresso. Nel tempo che devo correggere una doppia coordinata su un elemento esistente potrei creare un elemento ex novo di qualche cosa che ancora manca e che non apparirebbe probabilmente in nessun archivio facile da importare nei prossimi anni.

Esiste poi invece il tema dell'ambiguità intrinseca delle coordinate, che da vari anni spero si affronti... ma quello dipende dall'estensione degli oggetti fisici e ci si può fare poco. A parte un giorno collegare a oggetti univoci su OSM, perdersi in una serie di osservazioni su quale sia il vero ingresso o dove sia il "baricentro" di un locale è pura speculazione. In quel caso l'ambiguità di coordinate vicine da archivi diversi andrebbe invece tenuta perhé sottende a una "pluralità" di interpretazioni che è fisiologica.--Alexmar983 (talk) 21:12, 23 May 2023 (UTC)Reply[reply]

@Danysan1 il conservare le coordinate sbagliate puo' essere utile per correggerle lato GLAM e per un successivo import: ossia, per fare una ricerca di quali dei loro dati sono stati classificati dalla nostra comunità come sbagliati, e rendergli servizio. Faciliterebbe anche l'import successivo di loro dati corretti. Ho segnalato a Salaborsa i dati errati proprio dopo averli verificati, la collaborazione con i GLAM è anche questo IMHO. Patafisik (talk) 07:21, 25 May 2023 (UTC)Reply[reply]

@Danysan1 Non sono contraria a priori alla creazione di una nuova proprietà per le coordinate dell'ingresso, ma mi sembra spostare l'attenzione dal problema principale, che è quello di come gestire le coordinate in generale coordinandoci tra noi il più possibile. Patafisik (talk) 07:23, 25 May 2023 (UTC)Reply[reply]

Condivido e secondo me i punti sono

- coordinate ingresso ci stanno (rischia di diventare ENORMEMENTE ridondante, ma stiamo parlando comunque di un processo lunghissimo)

- qualità del dato: imho si può giocare di qualificatori, segnando che la fonte del dato è ufficiale MA la qualità del dato è bassa. MMo (talk) 11:28, 27 May 2023 (UTC)Reply[reply]

Ciao, forse centra relativamente ma molto spesso gli import riversano sia coordinate (coi problemi sopra evidenziati) che gli indirizzi, vi faccio questo esempio magari non troppo calzante (l'indirizzo è 14 o 14a?) divudì 14:53, 3 June 2023 (UTC).Reply[reply]

Dismissione dominio beniculturali.it[edit]

Ciao, ho scoperto per caso (tramite una mail di risposta automatica) che il dominio beniculturali.it è indicato come in via di dismissione da mesi. Se non se ne era ancora parlato qui, sollevo la questione già indicata da @Atomotic dei potenziali link interrotti a venire per le biblioteche. Qualcuno sa niente in proposito? Ho aperto anche una discussione su itwiki.

CC Notified participants of WikiProject Italy, se riuscite segnalate anche al GWMAB, grazie. Patafisik (talk) 07:02, 2 June 2023 (UTC)Reply[reply]

@Patafisik: a quanto so il problema riguarda soltanto le caselle e-mail, ma non i siti web, quindi non dovrebbe avere particolare impatto su di noi. --Epìdosis 07:17, 2 June 2023 (UTC)Reply[reply]

Province sarde[edit]

Segnalo il problema che riguarda la Sardegna, in particolare. Negli ultimi 20 anni una buona metà dei comuni ha cambiato provincia, anche per tre volte e molti comuni si apprestano a cambiare provincia per la quarta volta. Province nuove sono state create e altre sono state cancellate. Ne consegue che molti indirizzi internet di comuni non funzionano più, per non parlare delle e-mail di biblioteche, di istituti culturali, di amministrazioni che si trovano in Sardegna. Tre province sarde sono in via di estinzione (da tre anni) e saranno sostituite da due nuove province e dalla Città metropolitana di Sassari. Non conosco il numero dei comuni sardi (circa 400), ma un controllo bisognerebbe farlo. Su it.wiki molti link a siti istituzionali di comuni della Sardegna non funzionano più. Ci sono indirizzi internet di comuni sardi che posseggono ancora il ca, ma non appartengono più alla provincia di Cagliari, estinta e sostituita con la Città metropolitana di Cagliari che è meno estesa della vecchia provincia: appartengono infatti alla provincia di Sud Sardegna che è in via di estinzione e che sarà presto spezzata in due nuove province. Un saluto. --Fausta Samaritani (talk) 08:30, 2 June 2023 (UTC)Reply[reply]

[1] Dato che alcuni me l'avevano chiesto, non ho più proceduto a fare dei merge in quantità sia per la questione lasciata in sospeso che per motivi personali.

[1]