I am thinking about an interesting problem right now.

Suppose I have a DAG of objects. Every object contains three data points:

* A list of parents (via Content-address hashes)
* A pointer to some content (almost irrelevant for this thought process)
* A version number (irrelevant for this thought process)

I have a limited but unknown number of peers that are allowed to "post" to that DAG. Once a peer discovers that another node has posted to the DAG, they either fast-foward or merge (which is trivial here) and go on.
All peers gossip all the time, so fast-forwarding is expected to be the "normal case" when all peers are online - but in case of network split there is no issue.

Now, suppose I want to allow "rewriting" the DAG.
That means, one node decides that deep down in the DAG, they want to change a node. That would change all other nodes that come after it.

How would the other peers know that the node was rewritten?

Two ideas:

* All peers keep track of "this other peer points to this hash right now". Once a peer rewrites their DAG, other peers can see that rather easily. That would involve some tricky logic, but I guess would be possible 🤔 The other peers can then update their stuff to that new DAG (and if needed even "rebase" changes that they have done between the rewrite and now, if there was a network split during that time)
* The second option would involve adding timestamps to the DAG nodes, so other nodes can see that a portion of the DAG was rewritten

The second option would add more fields to the DAG nodes, which I would like to not do, because they should be as light as possible.

What do you think?  

#algorithms #softwaredevelopment #dag #distributedsystems #graphdata #datatypes

I am looking for a PhD student in graph data management and analysis.

Application deadline:
December 19, 2024.

More details:
https://jobs.tuwien.ac.at/Job/243871

#hiring #PhDposition #knowledgegraphs #graphData

I am looking for a postdoc in graph data management and analysis.

Application deadline: December 1st, 2024.

More details on the website:
https://www.dbai.tuwien.ac.at/staff/khose/Postdoc.html

#hiring #postdoc #knowledgegraphs #graphData #health

Transactions on Graph Data & Knowledge (TGDK) is indexed now in the
Directory of Open Access Journals (DOAJ)
https://doaj.org/toc/2942-7517

#knowledgegraphs #semanticweb #graphdata #knowledge @tgdkjournal

I can't believe I spent 20 minutes watching this, but if you have a spare 20 minutes do. Its exceptional.

#GraphData #DataScience

https://youtu.be/JheGL6uSF-4?si=BUUG3l4dmYycMT7N

The new TGDK website in online via our new publisher Dagstuhl. Transactions on Graph Data and Knowledge (TGDK) is a Diamond #OpenAccess journal that publishes research contributions relating to the use of graphs for data and knowledge management.

https://www.dagstuhl.de/en/publishing/series/details/TGDK

#knowledgegraphs #ontologies #knowledgegraph #semanticweb #graphdata #ontologicalengineering #llms #knowledgeextraction #knowledgemining ##tgdk @gdm @katjahose @ejimenez_ruiz @keet @catiapesquita @AxelPolleres @juan

Quite happy with how my little side-project has turned out so far.

It started off as an itch I wanted to scratch about named entity recognition, took me through #lstm to #transformer to #graphdata etc. Been a lot of fun and I've learnt a lot.

https://syracuse.1145.am

`This work examines the problem of learning a network graph from signals emitted by the network nodes, according to a diffusion model ruled by a Laplacian combination policy. The challenging regime of partial observability is considered, where signals are collected from a limited subset of nodes, and we wish to estimate the subgraph of connections between these probed nodes`

https://ieeexplore.ieee.org/abstract/document/10097221

#signalProcessing #graphData #dataAnalysis #dataScience #graphLaplacian #machineLearning