02-05-2023 Meta 28 min → 3 min
Novità
oc-meta
Risolto il bug che causava errori nell’ordine degli agenti: era uno spazio di troppo nel match nei nomi. In caso di cognome senza nome, il nome veniva preso dal triplestore senza spazio e matchato con lo spazio in fondo.
Risolto un bug per cui, nel caso in cui la risorsa fosse già presente nel triplestore, poteva succedere che ne venisse creata una nuova anziché considerare quella esistente, in particolare per gli id dei publisher. Questo spiegherebbe la presenza di id multipli.
Risolto un bug per cui le venue venivano parificate al triplestore senza passare per l’albero decisionale di disambiguazione degli id. Quindi, id aggiuntivi venivano ignorati, così come eventuali conflitti.
Ho finalmente capito cosa causava il bug degli agenti responsabili multipli relativi al publisher facenti riferimento allo stesso publisher e senza has_next. Il problema riguardava tutte le venue con la seguente condizione
Sul triplestore
br/065018634
title: Endoscopy
type: journal
identifiers:
- id/0650286: issn:1439-3964
- id/0650287: issn:0172-4622
- id/0650288: issn:1438-8812
- id/0650289: issn:0013-726X
publisher:
Nei CSV di partenza
International Journal of Sports Medicine [issn:0172-4622 issn:1439-3964]
“doi:10.1055/s-00000028 issn:0172-4622 issn:1439-3964”,”International Journal of Sports Medicine”,””,””,””,””,””,””,“journal“,“Georg Thieme Verlag KG [crossref:194]”,””
“
doi:10.1055/s-00000012issn:0013-726X issn:1438-8812”,”Endoscopy”,””,””,””,””,””,””,“journal”,“Georg Thieme Verlag KG [crossref:194]”,””Endoscopy [issn:0013-726X issn:1438-8812]
Nei CSV da preprocessare
- “doi:10.1055/s-00000028 issn:1439-3964 issn:0172-4622”,”International Journal of Sports Medicine”,””,””,””,””,””,””,“journal”,“”,””
- “
doi:10.1055/s-00000012issn:1438-8812 issn:0013-726X”,”Endoscopy”,””,””,””,””,””,””,“journal”,“”,””
Queste due entità si trovavano in file separati e venivano processate in parallelo. Fin qui nessun problema, entrambi i processi aggiungevano il nuovo id (il DOI) alla stessa entità. Il problema è che nessuna delle due entità aveva indicato il publisher. Quindi, durante, il processo vero e proprio di Meta, due processi paralleli hanno provato ad aggiungere il publisher alla stessa entità.
Il plugin di POCI ha una cache automatica basata sul numero di file già processati e il numero di item per file. La barra di caricamento tiene conto del numero totale di righe
Il prefisso degli OMID nei CSV ora è “omid” e non più “meta”
Meta più veloce
Una sola query al triplestore. Un CONSTRUCT che costruisce i grafi delle entità ricorsivamente a partire da quella gerarchicamente superiore.
- Il CONSTRUCT avviene a partire da tutti gli id presenti nella riga, sia id che omid. Gli id non vengono mai cercati più volte, prima di ogni ricerca si controlla che l’id non sia già presente in memoria.
- Perché non fare la query solo sugli id del campo id? Tanto gli altri elementi si trovano nel grafo dell’entità della riga, no? Sì, ma non in caso di entità interne conflittuali (autori, editor, venue, publisher). In quel caso serve trovare tutte le entità che puntano a un certo id.
- E se il campo id è vuoto e ci sono soltanto volume, issue, e venue? In quel caso la query avviene sull’elemento gerarchicamente superiore, cioè l’issue, se presente, altrimenti il volume. Altrimenti non è possibile ricavare il metaid di volume e issue a partire dal grafo della venue.
Ecco come appare il CONSTRUCT più ricco possibile.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23PREFIX eea: <https://jobu_tupaki/>
CONSTRUCT { ?s ?p ?o } WHERE {
{
?res (<eea:everything_everywhere_allatonce>|!<eea:everything_everywhere_allatonce>)* ?s.
?s ?p ?o.
VALUES ?res {<https://w3id.org/oc/meta/br/06014416>}
}
UNION
{
?br <http://purl.org/spar/datacite/hasIdentifier> ?id.
?id <http://purl.org/spar/datacite/usesIdentifierScheme> ?scheme;
<http://www.essepuntato.it/2010/06/literalreification/hasLiteralValue> ?literal.
VALUES (?scheme ?literal) {(<http://purl.org/spar/datacite/doi> "10.1001/archderm.104.1.106")}
?br (<eea:everything_everywhere_allatonce>|!<eea:everything_everywhere_allatonce>)* ?s. ?s ?p ?o.
}
UNION
{
?vvi <http://purl.org/vocab/frbr/core#partOf>+ <https://w3id.org/oc/meta/br/06014480>;
a <http://purl.org/spar/fabio/JournalIssue>;
<http://purl.org/spar/fabio/hasSequenceIdentifier> "11".
?vvi (<>|!<>)* ?s. ?s ?p ?o.
}
}- Il CONSTRUCT avviene a partire da tutti gli id presenti nella riga, sia id che omid. Gli id non vengono mai cercati più volte, prima di ogni ricerca si controlla che l’id non sia già presente in memoria.
In fase di creazione della provenance, i grafi preesistenti non vengono ricavati dal triplestore, ma come sottografi del grafo in memoria.
- Il grafo viene esplorato solo se un’entità è stata precedentemente marcata come preesistente, come già avveniva
- Il grafo viene esplorato una volta sola per entità, dopodiché il sottografo viene salvato in un indice
I test sono notevolmente più veloci. Ho raggruppato le operazioni di caricamento del triplestore e di popolamento dei grafi preesistenti in una setUpClass, in modo che queste operazioni vengano eseguite una volta sola all’inizio e non per ogni test.
Test sul 1000 righe:
- Tempo totale col vecchio software: 28 minuti
- 11 minuti per fare curator, creator e generazione della provenance
- 17 minuti per scrivere il dump dei dati, meno di un minuto per la provenance e aggiornare il triplestore.
- Tempo totale col nuovo software: 20 minuti
- 3 minuti per fare curator, creator e generazione della provenance (-73%!)
- 17 minuti per scrivere il dump dei dati, meno di un minuto per la provenance e aggiornare il triplestore.
- Tempo totale col vecchio software: 28 minuti
In soldoni, la parte del processo che leva più tempo è il salvataggio delle entità su file. Avevo già migliorato oc_ocdm per raggruppare le entità per file in maniera tale da aprire una volta sola ogni file. Non so cos’altro inventarmi.
rdflib-ocdm
time-agnostic-library