Layout del query graph deve preservare la struttura ad albero rispetto alle inverseObjectProperties
Closed this issue · 4 comments
L'eliminazione di una classe prevede l'eliminazione anche di tutti gli elementi "successivi" collegati da objectProperties (archi uscenti), mi chiedo però se andrebbero saltate le classi collegate da inverseObjectProperties (archi entranti).
Es:
su book se si seleziona Edition e poi hasEdition su book si ottiene: Book hasEdition Edition.
Eliminando Edition viene eliminato anche Book che però secondo me dovrebbe rimanere.
Nel caso di una query più lunga che si sviluppi tutta su book, si ottiene che eliminando edition viene eliminata tutta la query.
Il problema è che così facendo si potrebbero creare anche due core non collegati tra loro. Questo rende tutto un po' più complicato, penso che se decidiamo di fare csì dobbiamo rivedere la struttura ad "albero" del QueryGraph per passare ad una a vero e proprio grafo.
L'alternativa è segnalare in maniera chiara la struttura ad albero per esempio lasciando la direzione di crescita da sx a dx in modo che è chiaro se si cancella un nodo quali saranno quelli persi.
Io semplificherei: se Edition è stato il primo elemento aggiunto al grafo, e lo cancelli, allora si cancella tutto il grafo. Ci può stare come scelta.
Sennò come dice @giacomoronconiobda siamo costretti ad interpretare l'albero come un grafo, che complica molto.
Si ma quello che succede è che si perde un po' qual è la radice dell'albero. Il rapporto padre figlio non si nota perché le frecce vengono messe tutte da sx a dx.
Ok allora direi di lasciare tutto com'è ora e provare a cambiare il layout in modo che sia chiara la struttura ad albero.
Sposto la issue su sparqling almeno ne tengo traccia.