Wikidata:Bar/Archive/2023/11

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

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

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, 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.

Airon90 ValterVB Alexmar983 Epìdosis Pietro Jura Beta16 Yiyi Sannita Camelia Sentruper Pierpao Marcok CristianNX Daniele Pugliesi (WMIT) AttoRenato Parma1983 Aborruso Sabas88 Lalupa DnaX Fausta Samaritani Patafisik Malore Jtorquy Nicholas Gemini Civvì Devbug Afnecors Susanna Giaccai FabC FeltriaUrbsPicta Horcrux Uomovariabile Luckyz Francians Carlobia Ferdi2005 Luca.favorido Lemure Saltante Giacomo Alessandroni divudì Federica Gaspari Zwolfz Daniele Santini Bargioni Wiccio S4b1nuz E.656

Notified participants of WikiProject Italy

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

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)

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).

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)

(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)

@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)

@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)

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)

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).

Tornando alle coordinate, appoggio anche il link a questa vecchia discussione su moveClaim.jsavuta con @Valerio Bozzolan:. Patafisik (talk) 14:48, 10 November 2023 (UTC)