index

7 minuti

La Novitade

Meta

  • Adesso l’aggiornamento dei file RDF per dati provenance, nonché la generazione delle query SPARQL per aggiornare i database avvengono in parallelo usando il multi-threading, trattandosi di operazioni I/O-bound non CPU intensive, che quindi verrebbero penalizzate dalla duplicazione intera della memoria necessaria per generare nuovi processi (o almeno così spero).
  • Dopodiché, i database vengono aggiornati anche in questo caso in parallelo subito dopo che sono stati generati i file con le query SPARQL, senza aspettare che venga completata la modifica dei file RDF. Tutto questo deve concludersi prima che parta il processing del file CSV successivo.
  • Precedentemente i file con le query SPARQL si chiamavano {timestamp_fino_ai_microsecondi}{numero_di_triple_aggiunte}{numero_di_triple_tolte}.sparql. Questo potrebbe causare delle race condition nel momento in cui abbiamo due thread paralleli che generano query SPARQL, nel momento in cui due query contengono la stessa quantità di triple aggiunte tolte e sono generate nel nostro micro secondo, che è una cosa altamente probabile data la nostra dimensionalità. Di conseguenza, adesso invece del timestamp utilizzo l’MD5 della query SPARQL contenuta.
  • Le tempistiche previste rimangono proibitive, si parla di oltre 3000 ore per processare il nuovo dump di Crossref. Per diagnosticare correttamente la malattia prima di elaborare una cura ho realizzato un benchmark che genera dati sintetici di input per Meta data una certa dimensionalità, ovvero il numero di righe, e misura le tempistiche per ogni singolo passaggio.
    • Il generatore di dati riceve in input un seed che poi viene passato alla funzione random di Python in maniera tale che restituisca sempre lo stesso risultato tra run diverse per renderle confrontabili, con un seed di default che è ovviamente 42.
  • Su un CSV di 1000 righe l’introduzione del parallelismo sull’I/O sposta da 166s a 163s. Molto male! Il multi threading su Python è veramente una ciofeca. Proviamo col multi processing: 114s.
  • A causa di un merge passato ci siamo ritrovati con diverse catene di ordini di autore rotti perché il sistema di merge di oc_ocdm non gestiva e attualmente non gestisce le catene degli autori in caso di merge. Finora Meta correggeva questi casi al volo ricostruendo le catene con delle euristiche, ma i risultati sono veramente mediocri perché mi sono reso conto che ci sono diverse catene che hanno adesso autori duplicati. Quindi su quello va fatto poi un lavoro a parte, anche recuperando i metadati originali dagli articoli che sono stati corrotti. Anche per ragioni di performance ho eliminato queste correzioni al volo che vanno a rompere il principio di separazione delle responsabilità.
  • Il processo effettivo di Meta tuttavia rimane lentissimo. Utilizzando Strace mi sono accorto che il processo è bloccato su una specifica risorsa di CERN Atlas che contiene quasi 3000 autori. In teoria io avevo implementato un sistema di silenziamento per l’aggiornamento degli autori, per cui se c’erano già autori preesistenti il sistema non doveva aggiornare le catene degli autori. Evidentemente c’è un bottleneck da qualche parte che non sto vedendo.
    • Ho quindi aggiornato il benchmark per sopportare il pre-caricamento, cioè un sistema per testare il recupero di entità preesistenti simulando proprio la presenza di un paper come quello di CERN Atlas.
    • I risultati hanno dimostrato buone performance anche in questo caso, non solo, ma come mi aspettavo, gli autori e comunque il record è stato processato solo alla prima run, quella di pre-caricamento, mentre alla seconda non ci sono stati nuovi aggiornamenti. C’è da dire che processare un unico record la seconda volta con 3000 autori ha richiesto 68 secondi in totale e quasi 2742MB di RAM al picco. La prima 294 secondi e sempre 2742MB. Ci sono margini di miglioramento ma comunque non ho capito perché Meta impiega ore, possibile che ci siano tanti casi come questo in ciascun file in tutti i file? C’è un problema di SWAP della RAM? Effettivamente Redis è crashato un paio di volte.
    • Mi sono accorto che la funzione di silenziamento era attiva solo per il curator e non per il creator, che riprocessava inutilmente le 3000 entità autori per poi rilevare che non c’erano differenze con la condizione preesistente. Quindi ho aggiunto la funzione di silenziamento anche al creator, che si attiva solo se la br è preesistente e conteneva già autori. Questa modifica ha portato la seconda esecuzione da 66 secondi a 27!
  • Eppure il software in produzione continua a essere lentissimo. Comincio a sospettare che si tratti di un problema di RAM. Mario ha già aumentato la RAM dal 200 a 300 GB, ma arrivava al 93% prima e continua ad arrivare al 93% anche adesso con la memoria di swap completamente occupata. Potrebbe essere che il problema sia semplicemente il processare 10.000 righe alla volta oppure che il continuo ad avere su Redis la cache con i file con le query SPARQL già processate per i dump precedenti.

SPARQLWrapper

Infrastruttura

HERITRACE

Domande

Memo

  • HERITRACE

    • C’è un bug che si verifica quando uno seleziona un’entità preesistente, poi clicca sulla X e inserisce i metadati a mano. Alcuni metadati vengono duplicati.
    • Se uno ripristina una sotto entità a seguito di un merge, l’entità principale potrebbe rompersi.

  • Meta

    • Bisogna produrre la tabella che associa temp a OMID per produrre le citazioni.

  • OpenCitations

    • Rifare dump (CrossRef e DataCite)
    • Risolvere la questione ORCID
    • Rilanciare processo eliminazione duplicati

  • “reference”: { “@id”: “frbr:part”, “@type”: “@vocab” } → bibreference

  • “crossref”: { “@id”: “biro:references”, “@type”: “@vocab”} → reference

  • “crossref”: “datacite:crossref”

  • Ripubblicare dbpedia agnostica su Zenodo e si può usare time-agnostic-library su db pedia agnostica

  • oc_ocdm

    • Automatizzare mark_as_restored di default. è possibile disabilitare e fare a mano mark_as_restored.

  • https://opencitations.net/meta/api/v1/metadata/doi:10.1093/acprof:oso/9780199977628.001.0001

  • Guida per Meta e cerotti

  • DELETE con variabile

  • Modificare Meta sulla base della tabella di Elia

  • embodiment multipli devono essere purgati a monte

  • Portare il Meta Editor fuori. oc_editor

  • Modificare documentazione API aggiungendo omid

  • Heritrace

    • Per risolvere le performance del time-vault non usare la time-agnostic-library, ma guarda solo la query di update dello snapshot di cancellazione.
    • Ordine dato all’indice dell’elemento
    • date: formato
    • anni: essere meno stretto sugli anni. Problema ISO per 999. 0999?
    • Opzione per evitare counting
    • Opzione per non aggiungere la lista delle risorse, che posso comunque essere cercate
    • Configurabilità troppa fatica
    • Timer massimo. Timer configurabile. Messaggio in caso si stia per toccare il timer massimo.
    • Riflettere su @lang. SKOS come use case. skos:prefLabel, skos:altLabel
    • Possibilità di specificare l’URI a mano in fase di creazione
    • la base è non specificare la sorgente, perché non sarà mai quella iniziale.
    • desvription con l’entità e stata modificata. Tipo commit
    • display name è References Cited by VA bene
    • Avvertire l’utente del disastro imminente nel caso in cui provi a cancellare un volume

  • Meta

    • Fusione: chi ha più metadati compilati. A parità di metadato si tiene l’omid più basso
    • Issue github parallelizzazione virtuoso
    • frbr:partOf non deve aggiungere nel merge: https://opencitations.net/meta/api/v1/metadata/omid:br/06304322094
    • API v2
    • Usare il triplestore di provenance per fare 303 in caso di entità mergiate o mostrare la provenance in caso di cancellazione e basta.

  • RML

    https://github.com/oeg-upm/gtfs-bench

    • Chiedere Ionannisil diagramma che ha usato per auto rml.

  • Crowdsourcing

    • Quando dobbiamo ingerire Crossref stoppo manualmente OJS. Si mette una nota nel repository per dire le cose. Ogni mese.
    • Aggiornamenti al dump incrementali. Si usa un nuovo prefisso e si aggiungono dati solo a quel CSV.
    • Bisogna usare il DOI di Zenodo come primary source. Un unico DOI per batch process.
    • Bisogna fare l’aggiornamento sulla copia e poi bisogna automatizzare lo switch