Progetto Dati Lombardia/Relazione

Da Wikimedia Italia.
< Progetto Dati Lombardia
Versione del 31 mar 2022 alle 11:00 di Elemar (Discussione | contributi) (documentazione progetto LombardiaBeniCulturali)
(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)
Jump to navigation Jump to search

Documentazione del progetto “LombardiaBeniCulturali” e Wikimedia Italia

14/02

In un primo momento, si è deciso di procedere condividendo su OneDrive il file csv scaricato dal sito della Regione Lombardia. Infatti, operando modifiche sul dataset di partenza delle Architetture in locale, a fine sessione si esporta il progetto archiviandolo come file, inserendo nel commento delle cronologie delle versioni quali sono le modifiche che interessano tale versione, al fine di agevolare una futura consultazione per gli operatori. Tale scelta trova le sue motivazioni nel fatto che sarebbe controproducente dividere fisicamente in due il file dal punto di vista operativo poiché l’ordine dei beni non rispecchia una divisione per comuni o per tipologia architettonica, rendendo così ridondante il lavoro di esportazione dello schema in Wikidata. Si prevede dunque una modalità di lavoro asincrona, che può divenire sincrona tramite condivisione schermo, sebbene solamente si operi solamente da una postazione. Si valuta inoltre l’impiego futuro di GitHub per permettere invece la sovrapposizione e il confronto tra versioni differenti riconciliabili.

Avendo stabilito il modus operandi, la fase successiva è stata quella di sistematizzare e correggere gli errori di battitura principali presenti nel dataset di partenza (maiuscole, minuscole, plurali o singolari). Procedendo di colonna in colonna, si sono riscontrati errori tramite l’apertura della finestra dei filtri per testo. Attraverso l’impiego di flag e star, è stato agevolato il processo di ricongiungimento dei campi relativi ad un’unica architettura spezzata su più righe e di eliminare i duplicati (tutti > modifica righe > rimuovi righe combacianti), giungendo da 17833 a 17826 righe totali. Sono stati inoltre eliminati gli spazi che fungevano da fonte di errore attraverso la funzione trim. Inoltre, attraverso la funzione cluster, è stato possibile operare modifiche su più righe come nel caso della colonna della denominazione dei beni, raggruppando ad esempio le nomenclature delle chiese affini e uniformandoli, valutando di volta in volta se mantenere le differenze o meno, cercando di trovare la soluzione grammaticalmente corretta, oltre che accettata maggiormente dalla community wikimediana (cosa fare in Casa di Casa di Gorni --> inserirlo la denominazione ufficiale SIRBeC in alias e nominare la scheda Q con la dicitura più scorrevole). Durante questa fase è stata riscontrata la necessità di creare successivamente la scheda Wikidata per la tipologia architettonica del tempietto ossario, qualora non la si associ alla tipologia cappella ossario. Nel caso della Casa di via Pietro fortunato 3-7, si fa riferimento a elementi SIRBeC differenti rispetto all’omonimo al civico 37, per cui si sottolinea la necessità di controllare di volta in volta le unioni per cluster, al fine di ridurre al minimo l’errore nonostante le affinità. Attraverso espressioni di trasformazione sono stati inoltre eliminati dalla denominazione del bene i riferimenti alla tipologia di complessità del bene (eg.: “- complesso”).

15/02

Sapendo già i dati utili alla futura esportazione in Wikidata, sono state eliminate le colonne relative all’ubicazione non viabilistica, autori, stile/scuola, datazione, uso attuale e uso storico. Le colonne relative alla provincia, nonostante non siano di interesse, serviranno al controllo incrociato al momento della riconciliazione dei comuni. In seguito, è stata operata la trasformazione dei record delle coordinate, eliminando le parentesi tonde per permettere il loro inserimento nel formato previsto dalla proprietà coordinate geografiche di Wikidata.

Dopo queste operazioni di pulizia dati, si è avviata la riconciliazione dei comuni. Per poter riconciliare i comuni unreconcliated e none – tramite la finestra dei filtri che è recuperabile ad ogni riapertura del progetto da riconciliazione > faccette > per giudizio - è stato necessario intervenire manualmente per i casi di ex comuni, oggi frazioni di città di recente costituzione (former municipality Q19730508) o municipality seat (Q15303838) - in quest’ultimo caso si auspica l’uso di un bot (eg.: Cavallasca), aggiornando il dato attuale corretto e trasferendo nella colonna località il dato originario. Infatti, la riconciliazione sul tipo commune of Italy (Q747074) non ritrova tutti i comuni o ex comuni.

17/02

Successivamente è stata avviata la riconciliazione sulla colonna del numero scheda SIRBeC, ritrovando 2499 elementi su Wikidata sui 2768 riscontrabili dall’elenco generato grazie al bot Listeria < https://it.wikipedia.org/wiki/Utente:Yiyi/Lombardiabeniculturali> e riscontrabile anche su Wikidata Query Service con i seguenti comandi SELECT ?item WHERE { ?item wdt:P3503 ?sub0 }. Inoltre, sono stati aggiunti i dati manualmente della denominazione del bene complesso e del numero scheda bene complesso che risultavano blank da quest’ultima colonna. Per ottenere un maggior numero di riscontri, si preferisce la riconciliazione sulla SIRBeC con vincolo di Comune (P131), presupponendo di poter massivamente aggiornare le schede già esistenti su Wikidata con i dati mancanti da OpenRefine. In questo modo si individua il primo gruppo di architetture su Wikidata con già il Codice SIRBeC, sottraendolo tramite filtri alla ricerca del secondo gruppo di elementi, ovvero item esistenti su Wikidata ma senza il SIRBeC, effettuando una nuova riconciliazione sulla denominazione con vincolo comune. Sottratti con filtro i bene componenti, al fine di prendere in considerazione i soli beni individuo e complessi per una maggiore sicurezza nell’operazione di matching massivo nei casi di corrispondenza con valutazione 100, per proseguire poi con il matching manuale per tutte le riconciliazioni con valutazione da 70 in su WHY (riconcilia>faccette>miglior score dei candidati).

18/02

Indagine sulla possibilità di riconciliazione complessa e come strumento di lavoro l’impiego.

21/02

Riconciliazione denominazione con vicolo comune, molti senza label da individuare meccanicamente. Emersa problematica di lavoro poiché le anteprime degli elementi su Wikidata sono visibili, e dunque utilizzabili per la riconciliazione manuale solo dall’operatore che ha svolto la relativa riconciliazione nonostante il file su cui si lavora sia lo stesso. È possibile ovviare a ciò ripetendo ciascun operatore la riconciliazione. Si utilizza inoltre Discord per la duplice condivisione dello schermo e per non appesantire la RAM sul web e velocizzando quindi i processi su OpenRefine. Si segnala la presenza dal catalogo lombardo di un doppio identificativo per un’unica architettura, eg.: Palazzo Giovio (doppio id da inserire).

22/02

Una volta stimata la possibilità di esportazione tramite QuickStatements anche per l’integrazione di record di specifiche colonne in schede Wikidata già esistenti, coinvolgendo sia il primo gruppo di architetture matchate sulla chiave del numero della scheda SIRBeC (2474*), sia il secondo gruppo di elementi riconciliati su chiave denominazione con vincolo comune, si rende possibile l’integrazione nel primo caso volta all’arricchimento con informazioni note dal catalogo regionale, nel secondo l’inserimento dell’identificativoLombardiaBeniCulturali di un edificio che permette il collegamento tra i due dataset. Vd: <https://www.wikidata.org/wiki/Help:QuickStatements#Add_simple_statement>. Inoltre, si valuta il possibile impiego di bot per rendere omogenea la situazione relativa alle unità amministrative soppresse (eg.: Alta Valle Intervi) e le former city [sentire Luca a riguardo].

  • Una breve parentesi va dedicata ad un altro meramente pragmatico del lavoro. Importando il progetto, non vengono mantenute le riconciliazioni manuali, per cui si valuta l’estrazione e la conseguente applicazione delle singole operazioni, che OpenRefine registra progressivamente in uno storico, che possono dunque essere scambiate tra gli operatori condividendo il testo relativo in JSON. Per questo è necessario aggiornare le singole operazioni via via che queste vengono elaborate, per non perderne traccia ed evitare computi numerici differenti e lavoro ridondante su entrambe le postazioni.

A seguito di ciò, è stato messo a fuoco come poter recuperare il gruppetto di 269 elementi, appartenenti al primo gruppo di elementi esistenti con già presente il codice SIRBeC, che non sono stati individuati dalla riconciliazione sul tipo building, ma che sappiamo esistere dalla sopracitata lista su Wikipedia. Isolando le colonne di nostro interesse, sia su OpenRefine sia dal file csv estraibile dalla tabella di architetture con SIRBec in Wikidata, sono state poste a confronto su Excel e infine caricare come nuovo progetto su OpenRefine. Preliminarmente alla riconciliazione su NUM_SCHEDA_SIRBEC, si duplica questa stessa colonna al fine di conservare l’identificativo, chiave nel confronto appena esposto, che si perde una volta effettuato il matching. Si individuano 321 elementi rimanenti (70 blank), successivamente riconciliati su struttura architettonica (, scuola (14); serie di dipinti (1); GLAM (19 tra cui il Museo civico Treviglio BG080-00007), di frequente si individua l’istanza di cascina (intesa come insieme di edifici che quindi posso costituire un insediamento urbano eg.: cascina Gavazzo trovata su building), sebbene in un caso si riscontra un errore poiché si fa rimando all’omonimo comune italiano: Cascina Fontana), portale (quindi elemento architettonico) o ancora foresteria, chiesa non trovata perché istanza di chiesa cattolica (2, di cui una da non considerare, vd. Sotto al 24.02), edicola (1), bene immobile (2 rettificati con istanza di palazzo), albergo (trovato su building) e università (unimi) non riconciliate poiché l’istanza è riferibile piuttosto all’ente che all’edificio e nel catalogo SIRBeC è tipo architettura ospedale, associato a Ca’ Granda, insediamento urbano, quartiere, monumento storico che in catalogo SIRBec è tempio civico). Se ne deduce che la varietà di istanze attribuite agli item, non sempre riconducibili all’elemento base building, sia all’origine di questa frammentazione che tuttavia ha permesso la correzione di errori individuati nel percorso di riconciliazione. Si segnalano due casi di sostituzione idLombardia edificio al posto di toponimo, eliminati Tolcinasco eg. (https://www.wikidata.org/wiki/Special:Contributions/2A02:8109:B540:99E4:D9D6:188B:3AD9:51E5 https://www.wikidata.org/w/index.php?title=Q3992388&action=history) Corretto su Wikidata l’id regionale “0065” incompleto.

24/02

Focus su possibile problematica nella riconciliazione e conseguente matching sulla tipologia architettonica, in previsione dell’inserimento di questo tipo di record in qualità di istanza di nello schema di Wikidata. Si segnalano la chiesa di Santa Maria d’Ognissanti di Pavia, ritrovata dal bot ma non presente del db lombardo delle architetture quanto in quello delle sculture in qualità di oggetto e opera d’arte (https://www.wikidata.org/wiki/Q101500286, https://www.lombardiabeniculturali.it/opere-arte/schede/r0920-00319/); la scheda di catalogo della regione Lombardia relativa all’Università di Milano, riferibile all’architettura storia dell’ospedale, è stato corretto associando il codice correttamente a Ca' Granda. Problema omonimia elementi ma istanze diverse (vd. Cascina in riferimento alla località/frazione o architettura) emergerà come problema nell’esportazione in QS, cercare di aggiungere proprietà distinto da in questi casi.

28/02

La problematica dell’aumento degli identificativi LombardiaBeniCulturali, ascrivibile al contributo di membri della community e riscontrabile dall’aggiornamento del bot, è risolvibile rilanciando riconciliazioni poco prima dei caricamenti massivi. Inoltre, grazie al template Constraint violation [1], si individuano casi particolari di item da controllare prima del nuovo confronto fra gli item con IdLombardia di un edificio da Wikidata Query Service (2811) e quelli precedentemente individuati tramite la riconciliazione su OpenRefine.

Errore caricamento prob da https://www.wikidata.org/wiki/Q102175468 corretto sosoti

Cascine anche comuni soppressi eg.: https://www.wikidata.org/wiki/Q3559059 , nel momento in cui si esporta su QS aggiungere proprietà distinto da.

Corretto Chiese Sant’Apollinare a Baggio, Milano per presenza dati scorretti.

Tre i “single value” violations si segnalano:

doppie schede SIRBeC nel seguente caso, da comunicare alla Regione Lombardia per evitare le ripetizioni delle schede di catalogo (situazione analoga a Palazzo Giovio per cui si è deciso di mantenere il doppio id): https://www.wikidata.org/wiki/Q57750432 .

Nel caso di Cascina Villarossa (Q3559059), su Wikidata corretta associazione tra beni componenti e complessi, ma errato considerarla comune soppresso: problema voce Wikipedia [...]


10/03

Accertata la possibilità di aggiornare tramite QS solo alcune proprietà nelle schede su Wikidata, funzionalmente all’espletamento del primo e secondo gruppo individuato nel db SIRBeC (elementi riconciliati sull’idLombardiaBeniCulturali e elementi riconciliati su denominazione con chiave paese), emerge la necessità di effettuare un controllo successivo al caricamento dato che non dovremmo poter sapere se viene aggiunto un valore già esistente o se inserito ex novo. Nel caso della descrizione di spunta la possibilità di sovrascrivere se esiste dallo schema Wikidata, e per altre proprietà, quali designazione del patrimonio culturale, indirizzo e coordinate (sufficienti 6 cifre), si ritiene opportuno inserire come fonte dell’affermazione SIRBeC. Inoltre, si auspica la segnalazione in GitHub dei problemi relativi alla visualizzazione dell’anteprima qualora la riconciliazione non sia effettuata in loco, ostacolando il lavoro in team. Inoltre, tenere a mente problemi che emergono nella creazione dello schema per individuare ulteriori errori.


11/03

Violazioni valore unico --> stesso id per chiesa e convento(palazzo), una volta eliminate da chiesa (con proprio id che verrà integrato con QS), eg.: del complesso della chiesa di San Cristoforo a Lodi (LO620-00018) riconciliato con palazzo omonimo, non corretto, da ripetere quindi riconciliazione. Matching della tipologia architettura manuale, ai fine dell’inserimento in qualità di istanza di. MEMO: Stalla-fienlile gruppo non riconciliato per distinguerlo da stalla e fienile per aggiungere doppia istanza al momento della creazione schema per WD. Da edificio a schiera lavoro in asincrono con scambio cronologia per velocizzare il processo.

? Nell'esportazione mantiene nome dal db originario o assume il testo generato dalla riconciliazione+matching?

Problema riconciliazione CO180-00030 non risolto con matching sulla tipologia building o le altre tipologie specifiche di edifici individuati perché associato con la scheda id cervical cancer (Colonnato di St. Cecilia)


14/03

Finito matching per tipo architettura: PV230-00285 esistendo già la scheda Wikidata con istanza di palazzo, si asseconda il tipo architettura proposta nel SIRBeC che sottolinea come la parte del maschio del castello sia poi stato trasformato in palazzo. Arengario di Brescia BS400-00622 storicamente noto così anche e l’istanza non corrisponde alla definizione intesa nel nome, si propone elemento architettonico essendo arengario presente già nel nome dell’elemento che si verrà a creare. Nel caso della casaforte, casa-torre inserito Casaforte essendo la casa torre una sua sottoclasse, oltre ad essere presente nel nome la “torre”.

15/03

Per i tipi di architettura Cementificio e Impianto idrovoro si valuta l’istanza di architettura industriale o edificio industriale anche se da preferire il primo poiché in caso di complesso di edifici risulta più idoneo. Nel caso della Serra, usata oggi come biblioteca/asilo, si prevede l’uso di più istanze. Nel caso dell’ala del palazzo vescovile, istanza del palazzo di riferimento o parte di un edificio Q19603939? Pozzo --> non pozzo in strictu sensu perché si tratta di edifici che ospitavano il pozzo vero e proprio?

17/02

plenaria

18/03

Ok in schema wikidata doppia istanza con creazione ulteriore colonna e tipo architettura modificata.

Tutti i dubbi relativi alle violations sono flaggati con stella:

Cascina Vigadore ha più elementi duplicati sul db lombardia (così sembra), esiste poi l'elemento su wikidata con 3 schede sirbec diverse. Per ora ho soltanto tolto il matching a tutti gli elementi RISOLTO 
Castello di Chignolo Po è bene complesso con solamente sè stesso come bene componente, le schede differiscono solamente sulle coordinate, eliminerei il bene componente, anche qua ho tolto il match 
Cascina paderno, altro duplicato su lombardia. due beni complessi con le stesse proprietà, stesso indirizzo cambiano di poco le coordinate (77metri), tolto il match 
Cascina Ca' Repellini sono due cascine con lo stesso nome ma il civico diverso, una è il numero 1 l'altra il numero due, semplicemente passa in mezzo una strada, unmatch 
Cascina Bosco Repellini stessa identica cosa, in realtà anche stessa strada (quasi) 


24/03

Pubblicazione su Wikibar e WikiProjects. Trasformazione della tipologia bene componente in bene individuo per tutti i blank nel sirbec del bene complesso di riferimento. Eliminazione dallo schema Wikidata dell’identificativo SIRBeC in preparazione dell’esportazione su QS del primo gruppo di elementi.

25/03

Prova di integrazione di proprietà del primo gruppo (item già su Wiki con già identificativo LombardiaBeniCulturali di un edificio) nel cui schema eliminata la proprietà chiave per evitare ridondanze, con un gruppo di 10 tuple appartenenti a tipologia bene individuo.

Situazione di partenza su un totale di 17826 righe:

2477 matched (poi 2454) di cui 820 complessi, 199 componente e 1458 individuo (poi 1435).

15349 none

Segnalati problema coordinate

85 coordina

Problema etichetta alias non sovrascrivibile se esiste--> solo alias

Come inserire coordinate valore preferito, non possibile

Olaf per cfr piccoli grppi


Divisioni per provincia: Mattia: MI, BG, MB, VA, il resto Elena. Per futura importazione di id wikiloves monuments e commons, non eliminazione degli elementi elaborati ma slettinate.

MEMO: doppia istanza di questo primo gruppo.


Inizio relazione con Regione con dati alla mano per proposta liberazione dati e segnalazione errori in db di partenza.


NOMINARE BATCH

Cell.recon.match.name

Bandierinati violazioni da lasciare indietro alla esportazione del primo rppo die beni complesso.

Chignolo po castle, Cascina Paderno (Q63960779), cascina bosco repellini, da creare subito e inserire rapporto con item nuovo da creare del bene complesso di riferimento e le proprietà parte di e consiste di


Duplicati complessi corretti.


31/03

Proposta bot per inserire in wikidata relazione “consiste di” per tutti i beni complessi. Mantenuti relazione “parte di” per tutti i beni componenti.

LO-CO vs resto

Come far ANDARE QD PIù VELOCEEEEEEE