RESEARCHERS HIGHLIGHT LIMITATIONS IN AI MODEL ANNOTATION FOR GRAPH DATA

New research shows AI models find it hard to label graph data without examples. This affects AI development for complex data.

#AILabels, #GraphData, #MachineLearning, #DataAnnotation, #AIResearch

https://newsletter.tf/ai-models-fail-label-graph-data-without-examples/

A new study found AI models are not good at labeling graph data if they don't have examples first. This is different from how they work with text.

#AILabels, #GraphData, #MachineLearning, #DataAnnotation, #AIResearch
https://newsletter.tf/ai-models-fail-label-graph-data-without-examples/

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