13-03-2025 SPBv

La Novitade

NODEGOAT

  • Il codice è open source? Sì, è open source con licenza AGPLv3.
  • Posso usare modelli di dati in OWL o SHACL? Supporto per dati semantici, SPARQL endpoint, esportazione: No nativamente. Sì, tramite API.
  • Posso personalizzare l’interfaccia? No per il design generale, sì per viste e report dei dati.
  • Quanto è flessibile? Posso mappare dati senza rilevanza spazio-temporale, ad es. metadati bibliografici? Molto flessibile, sì, può gestire tali dati.
  • Tecnologie usate: Server: PHP, Client: HTML, CSS, JavaScript, Database: SQL (probabilmente MySQL).
  • Change tracking? Sì, con cronologia delle versioni.
  • Curatela? Sì, supporta editing collaborativo e validazione.
  • Scalabilità? Sì, gestisce grandi dataset secondo i casi d’uso.

HERITRACE

  • Lock risorse collegate, ingoing e outgoing

    1. Chiave di blocco per la risorsa principale

    Chiave: resource_lock:https://w3id.org/oc/meta/br/0601

    Valore: Un JSON serializzato contenente le informazioni sul blocco

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    resource_lock:https://w3id.org/oc/meta/br/0601: {
      "user_id": "0000-0002-8420-0696",
      "user_name": "Arcangelo Massari",
      "timestamp": "2025-03-07T17:10:27.954036+00:00",
      "resource_uri": "https://w3id.org/oc/meta/br/0601",
      "linked_resources": [
        "https://w3id.org/oc/meta/id/0601",
        "https://w3id.org/oc/meta/ar/0602",
        "https://w3id.org/oc/meta/ar/0603",
        "https://w3id.org/oc/meta/br/0610183",
        "https://w3id.org/oc/meta/re/0601",
        "https://w3id.org/oc/meta/ar/0601"
      ]
    }

    2. Collegamenti inversi (risorse che sono collegate a questa risorsa)

    Per ogni risorsa collegata, viene creato un set inverso. Ad esempio:

    Chiave: reverse_links:https://w3id.org/oc/meta/ar/0601

    Valore: Un set Redis contenente gli URI delle risorse che si collegano a questo autore

    1
    2
    3
    [
        "https://w3id.org/oc/meta/br/0601"
    ]

    Flusso

    1. Quando un utente acquisisce un blocco:
      • Viene creata la chiave resource_lock:URI con i dettagli del blocco
      • Vengono recuperate tutte le risorse collegate (ingoing e outgoing) tramite query SPARQL (se non già in cache)
      • Viene creata la chiave reverse_links:URI per tutte le risorse collegate
    2. Quando un utente verifica lo stato di un blocco:
      • Viene controllata la chiave resource_lock:URI per vedere se la risorsa è direttamente bloccata
      • Vengono controllate tutte le risorse in linked_resources per vedere se qualcuna è bloccata da un altro utente
      • Vengono controllate tutte le risorse in reverse_links:URI per vedere se qualcuna è bloccata da un altro utente
    3. Quando un utente rilascia un blocco:
      • Viene eliminata la chiave resource_lock:URI
      • Per ogni risorsa collegata, viene rimosso l’URI della risorsa principale dal set reverse_links:URI_collegato

    Vantaggi

    1. Efficienza: Le operazioni di verifica dei blocchi sono molto veloci (complessità O(1) per i controlli di appartenenza ai set). Inoltre, sia i collegamenti “outgoing” che “ingoing” vengono già recuperati al caricamento dell’entità; quindi, non c’è bisogno di recuperarli due volte per questa operazione, che rimane istantanea.
    2. Scalabilità: Il sistema può gestire un gran numero di risorse e relazioni
    3. Coerenza: I collegamenti bidirezionali garantiscono che non ci siano blocchi “orfani”

  • Rotellina sul pulsante di edit mentre si controlla il lock. Però dovrebbe essere istantaneo.

  • Heritrace ora utilizza Redis anziché SQLite per gestire i contatori. Dato che utilizzo già Redis per il sistema di lock, tanto vale utilizzarlo per tutto, dato che è più veloce.

  • Bugfix

    • La validazione SHACL deve considerare non solo il tipo diretto di un’entità, ma anche il contesto in cui questa entità viene utilizzata. Questo è particolarmente importante per entità come gli identificatori (DOI, ISSN, ORCID) che hanno vincoli diversi a seconda dell’entità a cui sono associati.

    • Il Time Vault ha un tempo di caricamento lunghissimo quando il numero di entità cancellate diventa molto elevato (817!!!)

      • Passare da Thread Pool Executor a Process Pool Executor per ricostruire lo stato immediatamente precedente alla cancellazione delle entità cancellate ha quantomeno permesso di non sforare il timeout di nginx, ma è comunque troppo lento e sicuramente non è scalabile.

    • In fase di inizializzazione, venivano inizializzati soltanto i contatori dell’entità e non i contatori della provenance.

      Questo è chiaramente rilevante nel caso in cui si avvino per la prima volta dei database che hanno già dei dati e della provenance al loro interno.

    • C’era un errore di architettura per cui l’inizializzazione dei contatori dei dati avveniva a livello di sistema e non a livello di plug-in del sistema.

      E dato che l’inizializzazione dei contatori è specifica per il modo in cui gestiamo noi i contatori, ma potenzialmente diversa, ho delegato la parte di inizializzazione al plug-in.

      Mi sono anche accorto che l’inizializzatore dei contatori per i dati non teneva conto delle entità cancellate.

  • Altri problemi segnalati da Francesca

Paper time-agnostic-library

  • Mi sono interrogato se esistano dei benchmark più recenti e aggiornati per le Time traversal queries realizzati dopo BEAR (2018)
    • EvoGen (2016)

      • Permette di creare versioni multiple di un dataset, controllando percentuale e tipo di cambiamenti (aggiunte/rimozioni sia a livello di istanze che di schema). Fornisce anche workload di query “adattative” su dati in evoluzione.

      • BEAR critica EVOGEN perché utilizza dati sintetici e non reali. Inoltre, non mi dà nessun vantaggio rispetto a BEAR, in quanto BEAR già fornisce dei benchmark per sistemi attuali con i quali posso confrontare il mio.

        Su EVOGEN, dovrei fare lo stesso lavoro che devo fare su BEAR, ovvero la generazione dei dati di provenance a mano. Produce arbitrariamente N versioni con rapporti di inserzione/cancellazione configurabili, e definisce ~8 tipologie di query per interrogare dati storici: snapshot query, query di delta, query “longitudinali” temporali, ecc.

    • SPBv (2018) Semantic Publishing Versioning Benchmark

      • Genera un flusso di versioni di un dataset sintetico arricchito con dati reali (DBpedia) e un insieme di query SPARQL che coinvolgono più versioni

      • Confronto con BEAR: come BEAR, testa operazioni di version materialization e delta query, ma SPBv supera i limiti di BEAR offrendo un dataset generato su misura (scalabile in dimensione e numero di revisioni) e un workload di query più vario. Inoltre, SPBv valuta metriche di performance aggiuntive (es. tempi di ingestione iniziale, throughput di query) per confrontare soluzioni di versioning

      • https://master.project-hobbit.eu/experiments c’è una piattaforma funzionante che fornisce già dati di benchmark di sistemi esistenti e, in teoria, permette di eseguire i benchmark su hardware standardizzato. Ho trovato OSTRICH, R43ples, Virtuoso, Blazegraph, GraphDB

        Dato che i sistemi vengono caricati sulla piattaforma tramite adapter programmato in Java, è anche possibile riprodurre gli esperimenti in maniera tale da fare esperimenti mirati e confrontabili.

        L’ultimo aggiornamento alla piattaforma è di giugno 2024.

        Ho notato qualche rallentamento nell’utilizzo della piattaforma, in particolare nel caricare i risultati degli esperimenti.

        C’è un tempo massimo di esecuzione per gli esperimenti, il che, secondo me, quasi sicuramente comprometterà l’esito degli esperimenti, a meno di non selezionare dei dataset veramente molto, molto piccoli.

        Ho provato a fare un benchmark per R43ples: https://master.project-hobbit.eu/experiments/1741607044281

        https://dice-research.org/HOBBIT-demo

  • Uso Docker per i test + script per avvio e stop automatico dei db e caricamento dati di test

Meta

  • Ho aggiunto dei log al processo di merge per individuare eventuali blocchi. Finora non ho individuato alcun blocco. Ho semplicemente riscontrato che il file problematico contiene 350 mila righe e passa e che quindi ci vuole molto, molto tempo per arrivare fino in fondo.

Domande

  • Internet Archive: In September 2024, the digital library of internet sites Internet Archive suffered a data breach that exposed 31M records. The breach exposed user records including email addresses, screen names and bcrypt password hashes.

    Compromised data: Email addresses, Passwords, Usernames

    Cambierei la password, che dite?

  • La pagina sul Time Vault continua a essere lentissima e, nonostante ci abbia riflettuto due giorni, non trovo un modo per renderla più veloce mantenendo l’architettura attuale.

    In particolare, quello che rallenta tantissimo il caricamento della pagina e che non è aggirabile è la suddivisione per classi delle entità cancellate e il conteggio del numero di entità cancellate per classi. Non se ne esce, perché l’informazione sulla classe si trova nello snapshot cancellato; quindi, va ricostruito per tutte le entità per avere quell’informazione.

    Ho anche provato a riscrivere il sistema in maniera tale da sfruttare la reattività di React, cioè a caricare le informazioni progressivamente. Ma comunque, da qualunque lato la prendi, anche se carichi prima le entità per classe, poi dopo carichi i conteggi in maniera sincrona, comunque, anche la suddivisione delle entità per classe richiede che tutte quante le entità cancellate vengano ricostruite.

    Questo mette chiaramente in luce quanto la Time Agnostic Library sia, nella pratica dei fatti, estremamente inefficiente e inutilizzabile!

  • A volte voglio cercare il genitore, a volte se stesso. Come si fa?

Tu vuo far el phdino
13-03-2025 SPBv
https://arcangelo7.github.io/p/acd77b03ee954f8d96cf4e4996859eef/
Author
Arcangelo Massari
Posted on
March 12, 2025
Licensed under