#graphdata — Public Fediverse posts

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? :boost_ok:

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

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? :boost_ok:

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

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? :boost_ok:

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

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? :boost_ok:

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

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? :boost_ok:

#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 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 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 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 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

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

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

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

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

Rules Of River Avulsion Change Downstream
--
https://doi.org/10.1038/s41586-024-07964-2 <-- shared paper
--
#GIS #spatial #mapping #river #water #hydrology #avulsion #geomorphology #geomorphometry #floodplain #flood #flooding #course #risk #hazard #elevation #topography #hydromorphic #hydrospatial #model #modeling #factors #coast #coastal #mountain #fan #riskassessment #global #spatialanalysis #management #mitigation #prediction #remotesensing #ICESat2 #FABDEM #Copernicus #algorithm #fluvial #alluvial #sediment #alluvium #sediment #machinelearning #graphdata #geostatistics #spatiotemporal

Rules Of River Avulsion Change Downstream
--
https://doi.org/10.1038/s41586-024-07964-2 <-- shared paper
--
#GIS #spatial #mapping #river #water #hydrology #avulsion #geomorphology #geomorphometry #floodplain #flood #flooding #course #risk #hazard #elevation #topography #hydromorphic #hydrospatial #model #modeling #factors #coast #coastal #mountain #fan #riskassessment #global #spatialanalysis #management #mitigation #prediction #remotesensing #ICESat2 #FABDEM #Copernicus #algorithm #fluvial #alluvial #sediment #alluvium #sediment #machinelearning #graphdata #geostatistics #spatiotemporal

Rules Of River Avulsion Change Downstream
--
https://doi.org/10.1038/s41586-024-07964-2 <-- shared paper
--
#GIS #spatial #mapping #river #water #hydrology #avulsion #geomorphology #geomorphometry #floodplain #flood #flooding #course #risk #hazard #elevation #topography #hydromorphic #hydrospatial #model #modeling #factors #coast #coastal #mountain #fan #riskassessment #global #spatialanalysis #management #mitigation #prediction #remotesensing #ICESat2 #FABDEM #Copernicus #algorithm #fluvial #alluvial #sediment #alluvium #sediment #machinelearning #graphdata #geostatistics #spatiotemporal

Rules Of River Avulsion Change Downstream
--
https://doi.org/10.1038/s41586-024-07964-2 <-- shared paper
--
#GIS #spatial #mapping #river #water #hydrology #avulsion #geomorphology #geomorphometry #floodplain #flood #flooding #course #risk #hazard #elevation #topography #hydromorphic #hydrospatial #model #modeling #factors #coast #coastal #mountain #fan #riskassessment #global #spatialanalysis #management #mitigation #prediction #remotesensing #ICESat2 #FABDEM #Copernicus #algorithm #fluvial #alluvial #sediment #alluvium #sediment #machinelearning #graphdata #geostatistics #spatiotemporal

Rules Of River Avulsion Change Downstream
--
https://doi.org/10.1038/s41586-024-07964-2 <-- shared paper
--
#GIS #spatial #mapping #river #water #hydrology #avulsion #geomorphology #geomorphometry #floodplain #flood #flooding #course #risk #hazard #elevation #topography #hydromorphic #hydrospatial #model #modeling #factors #coast #coastal #mountain #fan #riskassessment #global #spatialanalysis #management #mitigation #prediction #remotesensing #ICESat2 #FABDEM #Copernicus #algorithm #fluvial #alluvial #sediment #alluvium #sediment #machinelearning #graphdata #geostatistics #spatiotemporal

Since http://onodo.org/ is shutting down:
https://flourish.studio/visualisations/network-charts/ is a nice tool for visualizing network graphs.
#graphdata #dataviz

Since http://onodo.org/ is shutting down:
https://flourish.studio/visualisations/network-charts/ is a nice tool for visualizing network graphs.
#graphdata #dataviz

Since http://onodo.org/ is shutting down:
https://flourish.studio/visualisations/network-charts/ is a nice tool for visualizing network graphs.
#graphdata #dataviz

Since http://onodo.org/ is shutting down:
https://flourish.studio/visualisations/network-charts/ is a nice tool for visualizing network graphs.
#graphdata #dataviz

Since http://onodo.org/ is shutting down:
https://flourish.studio/visualisations/network-charts/ is a nice tool for visualizing network graphs.
#graphdata #dataviz

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

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

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

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

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

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

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

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

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

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

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

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

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

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

`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

`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

`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

"This suggests that the organization of social contact networks is based on large amounts of shortest-path redundancy which shapes epidemic spread in human populations. Thus, the metric backbone is an important subgraph with regard to epidemic spread, the robustness of social networks, and any communication dynamics that depend on complex network shortest paths"
https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1010854#:~:text=This%20suggests%20that,network%20shortest%20paths

cc @gabrielpeyre #graphTheory #networkAnalysis #graphData #dataAnalysis #dataScience

"This suggests that the organization of social contact networks is based on large amounts of shortest-path redundancy which shapes epidemic spread in human populations. Thus, the metric backbone is an important subgraph with regard to epidemic spread, the robustness of social networks, and any communication dynamics that depend on complex network shortest paths"
https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1010854#:~:text=This%20suggests%20that,network%20shortest%20paths

cc @gabrielpeyre #graphTheory #networkAnalysis #graphData #dataAnalysis #dataScience

"This suggests that the organization of social contact networks is based on large amounts of shortest-path redundancy which shapes epidemic spread in human populations. Thus, the metric backbone is an important subgraph with regard to epidemic spread, the robustness of social networks, and any communication dynamics that depend on complex network shortest paths"
https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1010854#:~:text=This%20suggests%20that,network%20shortest%20paths

cc @gabrielpeyre #graphTheory #networkAnalysis #graphData #dataAnalysis #dataScience

GitHub - cozodb/cozo: "A general-purpose, transactional, relational #database that uses Datalog and focuses on #graphdata and algorithms"

#opensource

https://github.com/cozodb/cozo

GitHub - cozodb/cozo: "A general-purpose, transactional, relational #database that uses Datalog and focuses on #graphdata and algorithms"

#opensource

https://github.com/cozodb/cozo