index
La Novitade
Section titled “La Novitade”- Ricordate i 13 file in una notte di Meta? Ecco, si era bloccato. Era finito lo spazio su home, perché i log di docker non stavano ruotando e quello del database di provenance era arrivato a 70G a causa del bulk load.
Prima:
Ora: 
- Ho provato a implementare un indice per soggetto, nonché un indice per valore letterale identificatore e omid identificatore risorse con quell’identificatore, per aumentare la velocità di look up delle informazioni in fase di curatela ma poi ho scoperto che RDF Lib internamente crea degli indici nel momento in cui si aggiunge una tripla a un grafo infatti ho provato, dopo aver implementato questa soluzione e aver rimosso il grafo RDF Lib locale ho provato a eseguire il benchmark e ho riscontrato sì dei miglioramenti ma molto marginali.
Con rdflib:
Con indice custom: 
refactor: fix deprecation warnings and remove obsolete scripts
- Fix Python 3.12+ SyntaxWarnings by using raw strings for regex patterns in master_of_regex.py
- Migrate from deprecated ConjunctiveGraph to Dataset across all modules
- Replace deprecated Dataset.contexts() with Dataset.graphs()
- Fix BeautifulSoup findAll deprecation (replaced by find_all)
- Add spawn context to ProcessPoolExecutor and pebble.ProcessPool to prevent fork deadlock warnings in multi-threaded environments
- Remove obsolete scripts no longer needed in the codebase
refactor(cache): remove JSON file persistence, use Redis only
The cache now uses Redis exclusively for storing processed files.
- Make Redis a required dependency (raises RuntimeError if unavailable)
- Update on_triplestore.py and meta_process.py to use new interface
- Update tests to reflect Redis-only behavior
refactor(upload): improve SPARQL upload progress bar clarity
Add descriptive labels to differentiate data vs provenance uploads and hide progress bars when no SPARQL files need processing.
refactor(curator): remove index file writing, keep data in RAM
Remove unnecessary I/O operations that wrote index files (index_id_ra.csv, index_id_br.csv, index_ar.csv, index_re.csv, index_vi.json) to disk. These files were never read back during processing - data flows entirely in-memory via object attributes from Curator to Creator.
Changes:
- Remove path_index parameter from curator() and indexer() methods
- Remove index file writing while keeping dict-to-list transformations
- Remove indexes_dir creation in MetaProcess
- Update tests to verify in-memory transformations
- Remove unused json imports
Enriched CSV output and test fixtures are preserved.
feat(benchmark): add visualization for single-run benchmarks
Add plot_single_run_results function to generate graphs when running benchmarks with runs=1. Previously no visualization was generated for single runs. Also fix missing cache_db attribute in MetaBenchmark.
feat(benchmark): add granular curation timing with simplified 2-stack visualization
Add sub-phase instrumentation to Curator for performance profiling:
- collect_identifiers, clean_id, merge_duplicates, clean_vvi, clean_ra, finalize
Simplify benchmark visualization to show only 2 stacks (Collect IDs vs Rest) instead of 6 sub-phases, as collect_identifiers dominates processing time.
Extract _draw_phase_breakdown() to eliminate code duplication between plot_single_run_results() and plot_benchmark_results().
Questa immagine mostra le esecuzioni successive alla prima su un unico file con un’unica riga che contiene 3000 autori concatenati. E’ inutile che io perda tempo a migliorare l’efficienza delle varie fasi del curator quando la fase di query SPARQL e di recupero delle informazioni occupa il 99% del tempo. Mi devo focalizzare esclusivamente su quella.
La soluzione è abbastanza ovvia: parallelizzare.
perf(finder): parallelize SPARQL queries using ProcessPoolExecutor
Changes:
- Add module-level _execute_sparql_query() worker function for parallel execution
- Refactor get_everything_about_res() to use ProcessPoolExecutor with spawn context
- Parallelize batch processing at each depth level with visited subjects tracking
- Parallelize identifier and VVI query execution
- Remove unused blazegraph_full_text_search option
- Use 4 workers according to benchmark results
Direi che avevo ragione: 
Quanti worker? 4. Dai miei benchmark si ottengono i risultati migliori.
Risultato in produzione: 
Dal grafico non noto grandi cambiamenti, ma dal tempo previsto sì. Mancano 76 ore per completare Crossref. Prima ne mancavano tra le 400 e le 700. Devo introdurre il throughput medio perché altrimenti non si capisce niente.
feat(benchmark): add granular storage timing with 3-stack visualization
Split storage phase into three sub-phases for bottleneck analysis:
- Preparation: RDF serialization + query generation (parallel)
- SPARQL upload: query execution against triplestore
- Bulk load: Virtuoso bulk loading (0 in standard mode)
Update benchmark charts to show storage as stacked bar with legend.
<div> <strong style="display: block; color: #1f2328;">arcangelo7</strong> <span style="font-size: 0.85em; color: #656d76;">Nov 29, 2025</span></div>feat(benchmark): unify production and benchmark timing charts
- Add 6-segment stacked bars to plot_incremental_progress matching benchmark visualization (Collect IDs, Curation rest, RDF creation, Preparation, SPARQL upload, Bulk load)
- Add mean duration and throughput lines to production charts
- Remove storage_and_upload wrapper timer to use granular sub-phases
- Add helper functions for phase duration extraction from reports
In produzione: 
Chiaramente il salvataggio in RDF è la parte più dispendiosa. Però non posso fare modifiche in produzione, ho bisogno di estendere il benchmark per riprodurre il caso in cui sto aggiornando tante entità preesistenti.
feat(benchmark): add update scenario
Add --update-scenario flag to benchmark that preloads partial data (DOI only) then processes complete data (with venue/volume/issue/page), triggering graph diff comparisons.
Changes:
- Add partial_data parameter to BenchmarkDataGenerator
- Add run_update_scenario method with multi-run statistics support
- Move config to oc_meta/run/benchmark/benchmark_config.yaml
- Save reports to oc_meta/run/benchmark/reports/ with prefixes
- Fix curator __meta_ar to initialize resolved_ra_metaid before loop
Baseline con 1000 righe: 
Posso parallelizzare anche qui, dato che indicizzo le entità per file. Posso scrivere parallelamente su file diversi, chiaramente in batch. Tra l’altro, posso anche togliere i lock, sempre in maniera opzionale. Nuovo parametro workers che parallelizza sia l’aggiornamento degli RDF che la serializzazione in nquads per il bulk load successivo.
perf(meta_process): remove multiprocessing overhead from storage phase
Replace ProcessPoolExecutor with sequential execution to eliminate pickle serialization overhead.
Suprise surprise mf’er
Ancora nessuna differenza in produzione: 
Devo rendere il benchmark più realistico.
test(benchmark): add detailed storage sub-phase timing and visualization
Add sub-timers for storage phase breakdown in meta_process.py:
- storage__upload_data, storage__upload_prov
- storage__store_data, storage__store_prov
Update plotting.py to visualize all 7 storage sub-phases.
Ah: 
Incredibile quante sfumature possa avere l’acqua calda.
According to
dd if=/dev/zero of=/mnt/arcangelo/test_write.tmp bs=1M count=1024 conv=fdatasync
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null && if=/mnt/arcangelo/test_write.tmp of=/dev/null bs=1MIl disco di ServerGrosso che sto usando fa ~440 MB/s di scrittura e ~1.5 GB/s di lettura, mentre il mio PC 2.2 GB/s di scrittura e 2.8 GB/s di lettura, il che rende i benchmark eseguiti sul mio PC fallaci a prescindere, ma vedo di avvicinarmici.
Dopo svariati tentativi non sono riuscito a riprodurre questi risultati tramite benchmark, quindi devo farlo direttamente in produzione aggiungendo logging di performance.
cangelo/oc_meta_merge/meta_config.yaml --timing --timing-output ./meta_process_timing.json [91/92]Processing files: 0%| | 0/2735 [00:00<?, ?it/s][1/2735] Processing 900.csv.../mnt/arcangelo/meta_input_2025_10/crossref_1000/900.csv [curation__collect_identifiers] Starting... [curation__collect_identifiers] Completed in 50.17s [curation__clean_id] Starting... [curation__clean_id] Completed in 1.13s [curation__merge_duplicates] Starting... [curation__merge_duplicates] Completed in 0.10s [curation__clean_vvi] Starting... [curation__clean_vvi] Completed in 14.91s [curation__clean_ra] Starting... [curation__clean_ra] Completed in 1.96s [curation__finalize] Starting... [curation__finalize] Completed in 2.27s [rdf_creation] Starting... [rdf_creation] Completed in 35.01s [storage__upload_data] Starting... [storage__upload_data] Completed in 7.16s [storage__upload_prov] Starting... [storage__upload_prov] Completed in 1.72s [storage__store_data] Starting...
[store_all timing] Files: 348, Entities: 13035 Path indexing: 13.43s File read: 40.74s Entity store: 1.06s Serialization: 48.13s Total: 103.50s Overhead: 0.14s [storage__store_data] Completed in 103.51s [storage__store_prov] Starting...q [store_all timing] Files: 348, Entities: 13366 Path indexing: 13.15s File read: 153.60s Entity store: 5.84s Serialization: 285.54s Total: 458.29s Overhead: 0.16s [storage__store_prov] Completed in 458.29s [storage__sparql_upload] Starting...Uploading data SPARQL: 100%|██████████████████████████████████████████████████████████████████████████| 31/31 [00:00<00:00, 53.59it/s] [storage__sparql_upload] Completed in 2.28s██████████████████████████████████████████████████████▌ | 30/31 [00:00<00:00, 57.86it/s] [storage__bulk_load] Starting... [storage__bulk_load] Completed in 38.14s ✓ Completed in 716.71s
Virtuoso utilities
Section titled “Virtuoso utilities”
refactor(isql_helpers): always capture subprocess output
Remove the optional capture parameter from run_isql_command and _run_subprocess functions. Output is now always captured, simplifying the API and ensuring consistent behavior across all callers.
fix(bulk_load): clean up load_list table before bulk load
[release]
fix(launch_virtuoso): fix launch_virtuoso.py to remove deprecated capture parameter
Also add integration tests for virtuoso launcher
fix(launch_virtuoso): fix launch_virtuoso.py to remove deprecated capture parameter
Also add integration tests for virtuoso launcher
ci: add coverage reporting and README badges
Add test coverage with pytest-cov, deploy coverage report to GitHub Pages, and create dynamic coverage badge using BYOB. Add badges to README for tests, coverage, Python versions, lines of code, and license.
docs: add Astro Starlight documentation site
- Add docs/ directory with Astro Starlight setup
- Create documentation pages from README content
- Add docs.yml workflow for GitHub Pages deployment
- Remove deploy-pages job from test.yml (now handled by docs workflow)
- Simplify README.md with link to full documentation
https://opencitations.github.io/virtuoso_utilities/
feat(launch_virtuoso): add programmatic API for launch_virtuoso function
[release]
oc_ocdm
Section titled “oc_ocdm”class IsomorphicGraph(ConjunctiveGraph):
"""An implementation of the RGDA1 graph digest algorithm. An implementation of RGDA1 (publication below), a combination of Sayers & Karp's graph digest algorithm using sum and SHA-256 <http://www.hpl.hp.com/techreports/2003/HPL-2003-235R1.pdf> and traces <http://pallini.di.uniroma1.it>, an average casepolynomial time algorithm for graph canonicalization. McCusker, J. P. (2015). WebSig: A Digital Signature Framework for the Web. Rensselaer Polytechnic Institute, Troy, NY. http://gradworks.umi.com/3727015.pdf"""an average case polynomial time algorithm… Ne abbiamo veramente bisogno?
to_isomorphic(graph) └── IsomorphicGraph.__eq__() └── internal_hash() └── _TripleCanonicalizer.to_hash() └── canonical_triples() └── _traces()
- Se _discrete(coloring) è True (nessun blank node): salta _traces → O(n)- Se _discrete(coloring) è False (blank node presenti): chiama _traces → fino a O(2^n)A me sembra un overhead inutile. Una differenza di set mi sembra sufficiente, dato che noi non abbiamo blank node. Comunque dubito che stia qui il problema.
Aldrovandi
Section titled “Aldrovandi”- FIle organizzati con un criterio basato su un identificativo presente nei metadati
- Obiettivo: mettere su un sistema automatizzato per:
- Estrarre i metadati descrittivi di ciascun oggetto
- Provenance
- https://github.com/dharc-org/chad-ap
- Ontologia: https://dharc-org.github.io/chad-ap/current/chad-ap.html
- Sviluppata da Sebastian, parlare con lui
- Dump del triplestore: https://doi.org/10.5281/zenodo.16879033
- Io devo creare la provenance da caricare sullo stesso triplestore.
- Per ognuna di quelle cartelle che rappresentano un oggetto con vari file bisogna che lì dentro ci finiscano due file: meta.rdf e prov.rdf. meta.rdf deve contenere tutti i metadati delle entità per quella cartella, sia dell’oggetto fisico che dei processi per arrivarci. C’è della ridondanza. DCHOO dipende da DCHO, RWP e RAW. RAW non ha dipendenze. RAWP dipende da RAW. DCHO dipende da RAWP e RAW.
- Una volta ottenuti i file di meta.rdf e prov.rdf, Il contenuto di DCHOO e DCHO va caricato su Zenodo. Ogni cartella è un record Zenodo, per 2. 520 DOI.
- Su Zenodo solo la foglia, non l’albero, ma bisogna conservare un file di mapping tra il path e il DOI Zenodo. i metadati Zenodo li recupero dal file RDF.
- Gli autori sono gli autori dell’oggetto digitale. Sono nei metadati. Bisogna recuperare l’ORCID a mano. Sono una quindicina. Gli autori sono a cascata. Dato che per arrivare al DCHOO ho bisogno dei DCHO, gli autori di DCHOO sono entrambi. Dipende dall’oggetto.
- Nei metadati descrittivi dell’autore c’è l’istituzione, ovvero l’affiliazione.
- Alice mi ha condiviso per mail il link a un documento Word che descrive l’organizzazione delle directory.
- Silvio mi dovrà dare accesso a un repo Sharepoint che contiene i dati veri e propri.
- Scadenza: prima di Natale
SKG-IF Shacl extractor
Section titled “SKG-IF Shacl extractor”Attualmente, quando una proprietà punta a un’altra classe (es. datacite:hasIdentifier -> datacite:Identifier), il codice genera:
sh:or ( [ sh:class datacite:Identifier ] [ sh:nodeKind sh:BlankNodeOrIRI ] )
Questo permette di avere entità oggetto senza classe specificata.
Il problema è che:
- Se l’entità oggetto ha rdf:type datacite:Identifier, viene validata tramite datacite:IdentifierShape (perché ha sh:targetClass)
- Se l’entità oggetto NON ha rdf:type, passa la validazione tramite sh:nodeKind sh:BlankNodeOrIRI ma NON viene validata la sua struttura interna (le proprietà che dovrebbe avere)
La soluzione è usare SH.node seguito dalla shape dell’oggetto, in modo che il nodo venga validato sulla base di una shape. La shape mantiene SH.targetClass, per consentire la validazione doppia.
sparqlite
Section titled “sparqlite”| Libreria | HTTP/2 | Async | Sync | Connection pooling | Streaming |
|---|---|---|---|---|---|
| HTTPX | Sì (opzionale) | Sì | Sì | Sì | Sì |
| niquests | Sì (default) | Sì | Sì | Sì | Sì |
| aiohttp | No | Sì | No | Sì | Sì |
| requests | No | No | Sì | Sì | Sì |
| urllib3 | No | No | Sì | Sì | Sì |
| pycurl | Sì | No | Sì | Sì | Sì |
| SPARQLWrapper | No | No | Sì | No | No |
| https://oxylabs.io/blog/httpx-vs-requests-vs-aiohttp |
| Libreria | Chiusura connessioni | Retry automatico | Timeout granulare | Autenticazione |
|---|---|---|---|---|
| HTTPX | Sì, con client.close() | Sì, configurabile | Sì, connect/read/write separati | Basic, Digest, Bearer, custom |
| niquests | Sì, con session.close() | Sì | Sì | Basic, Digest, Bearer |
| aiohttp | Sì, con session.close() | Sì | Sì | Basic, Bearer |
| requests | Sì, con session.close() | No, va implementato | Sì | Basic, Digest |
| urllib3 | Sì, con pool.clear() | Sì, molto configurabile | Sì | Basic |
| pycurl | Sì, con curl.close() | No | Sì | Tutte |
| SPARQLWrapper | No | No | No | Basic, Digest |
Benchmark: https://github.com/perodriguezl/python-http-libraries-benchmark. Vince httpx ma sono solo GET a un URL. Mi serve un benchmark specifico per SPARQL.
Nuovo progetto: https://github.com/arcangelo7/sparql-http-benchmark
feat: add SPARQL HTTP benchmark project
Benchmark tool for comparing Python HTTP libraries performance on SPARQL 1.1 operations against Virtuoso endpoint.
Libraries tested: httpx, aiohttp, requests, urllib3, pycurl. Operations covered: SELECT, ASK, CONSTRUCT, INSERT, DELETE, UPDATE.
Confronto tra HTTP/1.1 e HTTP/2
Section titled “Confronto tra HTTP/1.1 e HTTP/2”| Aspetto | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Anno di rilascio | 1997 | 2015 |
| Connessioni | Una richiesta per connessione TCP, oppure keep-alive con richieste sequenziali | Multiplexing: più richieste e risposte simultanee su una singola connessione |
| Formato dei dati | Testuale (header leggibili in chiaro) | Binario (più efficiente da parsare per le macchine) |
| Compressione header | Nessuna compressione nativa degli header | HPACK: compressione degli header che riduce l’overhead |
| Server push | Non supportato | Il server può inviare risorse al client prima che vengano richieste |
| Prioritizzazione | Non disponibile | Le richieste possono avere priorità diverse |
| Head of line blocking | Presente a livello TCP e HTTP | Risolto a livello HTTP, rimane a livello TCP |
| Crittografia | Opzionale (HTTP o HTTPS) | Di fatto obbligatoria (i browser richiedono HTTPS) |
| Latenza | Maggiore a causa delle connessioni multiple e dell’assenza di multiplexing | Ridotta grazie al multiplexing e alla compressione |
| Consumo risorse | Più connessioni TCP aperte, maggior consumo di memoria e CPU | Meno connessioni, uso più efficiente delle risorse |
| Compatibilità | Universale | Supportato da tutti i browser moderni, richiede configurazione lato server |
Tutto molto bello, ma Virtuoso implementa il protocollo HTTP/2? No: https://docs.openlinksw.com/virtuoso/ch-webappdevelopment/, solo HTTP/1.1.
Ma possibile che nessuno si sia mai posto questi problemi?
Bamboat, M. A., Khan, A. H., & Wagan, A. (2021). “Performance of RDF Library of Java, C# and Python on Large RDF Models.” International Journal on Emerging Technologies, 12(1), 25-30.
Ho trovato solo questo: https://www.researchtrend.net/ijet/pdf/Performance%20of%20RDF%20Library.pdf
Per Python c’è solo RDFlib, che è anche quello che performa peggio: 
Confronto con PyOxigraph: https://github.com/oxigraph/oxigraph/discussions/1092
| Operazione | RDFLib Memory | Oxigraph In-Memory | Speedup |
|---|---|---|---|
| Parsing (Turtle) | 59,26 ms | 19,57 ms | ~3x |
| Query SPARQL | 752,35 ms | 19,99 ms | ~38x |
| Serializzazione | 58,17 ms | 5,56 ms | ~10x |
| Secondo me nella testa delle persone c’è che il bottleneck è solo il server, MA NON È COSÌ, il bottleneck è il client se usi RDFlib/SPARQLWrapper. Fare query SPARQL con SPARQLWrapper su QLever è come avere una Ferrari a metano. |
feat: initial implementation of sparqlite SPARQL 1.1 client
Add SPARQLClient with support for SELECT, ASK, CONSTRUCT, DESCRIBE and UPDATE queries. Includes automatic retry with exponential backoff, connection pooling via pycurl, and RDF graph handling with rdflib.
Features:
- Full SPARQL 1.1 query type support
- Configurable retry logic for transient failures
- Custom exception hierarchy for error handling
- Comprehensive test suite with integration tests
- Starlight documentation site
- GitHub Actions workflows for CI, releases and docs
Ecco qui: https://github.com/opencitations/sparqlite
GitHub Commit Embed
Section titled “GitHub Commit Embed”Ho creato un plugin Obsidian per generare delle card automaticamente quando si incolla un link di un commit di GitHub: https://github.com/arcangelo7/github-commit-embed. Entrambe le edizioni, Virtuoso Open Source 7.2.x e Virtuoso Commercial 8.x, condividono la stessa infrastruttura HTTP/1.x.
Stato dell’arte
Section titled “Stato dell’arte”| Plugin | Funzionalità | Supporta Commit | Stile embeddato |
|---|---|---|---|
| GitHub Embeds | Issues, PR | No | No |
| GitHub Issues | Issues | No | No |
| Link Embed | Qualsiasi URL | Sì, ma preview troncato | No |
Le card sono HTML con lo stile integrato, per essere renderizzate ovunque allo stesso modo indipendentemente dal plugin.
L’ho inviato al repo ufficiale di Obsidian, se lo accettano comparirà tra i plugin della community, altrimenti continuerò a usarlo localmente.
Domande
Section titled “Domande”oc_ocdm
Section titled “oc_ocdm”Perché pubblichiamo l’RDF in JSON-LD e non in NQuads? Serializzare in NQuads e anche deserializzare è molto più efficiente rispetto al JSON-LD. Oltre al fatto che è anche più resiliente rispetto a bug: ad esempio il bug del contesto che non viene incluso nel JSON-LD che oc_ocdm risolve ricopiando i dati all’interno di un dataset aggiunge un overhead decisamente importante.
Aldrovandi
Section titled “Aldrovandi”- Nel file ttl su https://doi.org/10.5281/zenodo.16879033 gli URI non rispettano la naming convention. È una delle cose che verrà aggiornata nella nuova versione?
- Dov’è l’endpoint sparql? Va beh che posso anche crearmelo da solo a partire dal file ttl.
- Io cosa posso fare al momento presente?
SKG-IF Shacl extractor
Section titled “SKG-IF Shacl extractor”Per classi esterne senza descrizione nell’ontologia (owl:Thing, foaf:Document), cosa devo fare? Attualmente, uso sh:nodeKind sh:BlankNodeOrIRI.
Vogliamo la doppia validazione o vogliamo che le entità che possono comparire solo come oggetto siano valide solo quando compaiono come oggetto. Se ho un identificatore da solo con la sua classe datacite:Identifier voglio che sia valido o invalido?
Infrastruttura
Section titled “Infrastruttura”- I server di OpenCitations usano memorie con ECC?
-
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
- Vedere come morh kgc rappresenta database internamente
- https://dylanvanassche.be/assets/pdf/iswc2024-krown-benchmark-rdf-graph-materialisation.pdf
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