Data
Let the data discussions flow- onchain or offchain.
3 replies
6 recasts
29 reactions
0 reply
0 recast
5 reactions
0 reply
2 recasts
8 reactions
0 reply
0 recast
1 reaction
6 replies
4 recasts
33 reactions
0 reply
0 recast
7 reactions
0 reply
0 recast
4 reactions
Musings:
One of the coolest thing's I've gotten from working with @ruminations has been properly graph database pilled. I've worked in ML and general software engineering for over 10 years, and one of the points I have leaned on has been learning that most modern organizational problems are "Knowledge engineering" problems. If you look at Uber for example, the major technical issue is matching a driver to someone who wants to get somewhere. This idea pretty much culminates to almost every business, digital or real, where we have now even started to use AI to build products. This in some sense, is also a matching problem where you need to "find" a good code solution to a particular user problem. I feel like this in general is everywhere.
Finance. Biology. Social. All are knowledge engineering problems.
Now the key point is, I believe we are now moving into a world where we do have the data, but we don't have ontologies that help prioritize the data. For example here on Farcaster, we have data for particular users, their casts, third party scores, but how do we rank them? How do we target specific users? How do we eliminate bots?
This is where graph databases and ontologies come in.
Let's take a standard CRM for example. We have a list of companies, maybe some metadata for those companies as well. If you're a BD, how do you identify and prioritize who you should actually spend your time with? We've gone past knowledge engineering of just finding data as a society, pretty much everything *is* available, but now we are moving into a society of optimizing. The cool part about graph databases and network science in general is we actually *do* have statistical science that has been around for over 50 years now that tackles that exact problem.
Professionally I used to be a guy that's all about SQL (just store the data), and NoSQL (just store as much data as possible), but these databases in general make it hard to identify relationships between entities and do very complex ontology and topology studies. In the CRM example, you have a list of companies, but what if you enriched your analysis with data about who works at each company? Maybe you can generate a network of not only organizations to target, but identify whether employees at one company you're a customer with, also work at a different company and could use a solution? Typically this is just sitting in the heads of different high level employees, but we are now in a world where these graph databases can identify these relationships very easily and quickly. There's a reason why Palantir, good or bad, is one of the top data companies.
All in all I'm slowly but surely becoming more of an ontology guy, and I'm slowly realizing I need to update my theory that organizational problems are "knowledge engineering", to organizational problems are "ontology engineering". Thinking about how to quickly rank and optimize what to do is far more important now that we really do have access to the information. In the 2000s, the databases didn't exist. Now they all exist, but it's a matter of focusing on what data is actually important and how to add more signal to the data. 1 reply
2 recasts
5 reactions
1 reply
1 recast
4 reactions
0 reply
0 recast
3 reactions
0 reply
0 recast
2 reactions
0 reply
0 recast
4 reactions
0 reply
0 recast
15 reactions
3 replies
2 recasts
31 reactions
3 replies
0 recast
8 reactions
