Overview
Context
Alcuni punti discussione
Assunzione scenario object-centric: In letteratura, l'interesse per i grafi sembra corrispondere a quello per scenari object-centric. Si può quindi prendere tale scenario come riferimento. In tal caso, abbiamo un grafo che contiene eventi, oggetti che co-evolvono nel tempo, e relazioni tra essi. Lo scenario "standard" (XES like) si può vedere come caso particolare e forse meno interessante, dove gli oggetti non ci sono oppure sono locali a ciascuna traccia, e questo permette di partizionare i dati di log per traccia semplificando il process mining (banalmente, non servono soluzioni di indicizzazione o interrogazione efficiente finché si lavora sui pochi dati di una traccia). Possiamo assumere anche OCBC come contesto?
Informazione temporale: In XOC e in OCBC gli oggetti co-evolvono, quindi attributi, relazioni e oggetti stessi nascono, cambiano e scompaiono nel tempo. Questo aspetto temporale è presente solo in parte negli studi su event graphs codificati come property graphs (Esser et al). In generale il modello property graph non fornisce supporto specifico per l'informazione temporale: per le relazioni (archi) si possono usare le proprietà, ma per restringere la validità degli attributi può servire reificare oppure usare valori strutturati se supportati dal modello. Allo stesso tempo, probabilmente serve un supporto specifico per esprimere constraint temporali nelle query, e questo credo manchi nei principali graph query language.
Named paths: indispensabili?: G-CORE assume che una query possa ritornare dei path, e ai fini della composability quindi se sono in output alla query devono essere anche in input e pertanto sono primitiva del data model. Questo non è però strettamente necessario. Un path è un grafo, e un modello alternativo è quello di data model con più named graphs (che possono contenere path), e query che parte da 1 o più named graphs e ritorna 0 o più named graphs in output (tipo SPARQL INSERT { ... } WHERE { ... } che può simulare Construct + named graphs). Cypher 10 (che non ho trovato come specifica) in teoria supporta pure composability lavorando su più grafi, e non prevede i path come primitiva.
Contributo? La baseline è fare come Esser et al e fornire una metodologia per fare l'encoding dei dati di log in un property graph interrogabile con graph query language esistente. In alternativa si può definire (sintassi, semantica) un query language ad hoc da usare abbinato a XOC / OCBC, e fornire un prototipo basato su graph database a fini di evaluation. Da verificare rapporto con OBDA e serializzazioni direttamente interrogabili stile HDT.