3 ms·

> Maybe this all changes when AI takes over, but AI seems to do fine without us defining ontologies, etc. If you say "AI" in 2024, you are probably talking abo

> Maybe this all changes when AI takes over, but AI seems to do fine without us defining ontologies, etc. If you say "AI" in 2024, you are probably talking about an LLM. An LLM is a program that pretends to solve semantics by actually entirely avoiding semantics. You feed an LLM a semantically meaningful input, and it will generate a statistically meaningful output that just so happens to look like a semantically meaningful transformation. Just to really sell this facade, we go around calling this program a "transformer" and a "language model", even though it truthfully does nothing of the sort. The entire goal of the semantic web was to dodge the exact same problem: ambiguous semantics. By asking everyone to rewrite their content as an ontology, you compel the writer to transform the semantics of their content into explicit unambiguous logic. That's where the category error comes in: the writer can't do it. Interesting content can't just be trivially rewritten as a simple universally-compatible ontology that is actually rooted in meaningfully unambiguous axioms. That's precisely the hard problem we were trying to dodge in the first place! So the writer does the next best thing: they write an ontology that isn't rooted. There are no really useful axioms at the root of this tree, but it's a tree, and that's good enough. Right? What use is an ontology when it isn't rooted in useful axioms? Instead of dodging the problem of ambiguous semantics, the "semantic web" moves that problem right in front of the user. That's probably useful for something, just not what the user is expecting it to be useful for. --- I have this big abstract idea I've been working on that might actually solve the problem of ambiguous semantics. The trouble is, I've been having a really hard time tying the idea itself down to reality. It's a deceptively challenging problem space.

brimwats 2y ago
I would happily bite on that; I mostly deal with archives, libraries, museums and how they deal with people and communities. Because of that there is a ton of nuance when it comes to identities (there is a lot of gradation in meaning between "African American" and "Black" or gay and homosexual for example). Things that seem simple are often very complicated and I've spent a good deal of my PhD work working on that (the Homosaurus is the most popular example of this work); and lately I've been working on how to represent identities in a linked and changing way that can still be used by cultural heritage institutions (i.e. simple enough to be linked to SKOS and Wikidata). I feel pretty close on how to represent some aspects of this semantically, thanks to help from a brilliant ontologist friend.
- thomastjeffery 2y ago
  I don't think I'll live up to "brilliant ontologist", but here goes: First of all, what's the problem? Computing human-written text. What's the problem domain? Story. In other words: intentionally written text. By that, I mean text that was written to express some arbitrary meaning. This is smaller than the set of all possible written text, because no one intentionally writes anything that is exclusively nonsensical. So what's my solution? I call it the Story Empathizer. --- Every time someone writes text, they encode meaning into it. This even happens on accident: try to write something completely random, and there will always be a reason guiding your result. I call this the original Backstory. This original Backstory contains all of the information that is not written down. It's gone forever, lost to history. What if we could dig it up? Backstory is a powerful tool. To see why, let's consider one of the most frustratingly powerful features of Story: ambiguity. In order to express a unique idea in Story, you don't need an equivalently unique expression! You can write a Story that literally already means some other specific thing, yet somehow your unique meaning still fits! Doesn't that break some mathematical law of compression? We do this all day every day, so there must be something that makes it possible. That thing is Backstory. We are full of them. In a sense, we are even made of them. We can never get the original Backstory back, but we can do the next best thing: make a new one. How? By reading Story. When we successfully read a Story, we transform it into a new Backstory. That goes somewhere in the brain. We call it knowledge. We call it memory. We call it worldview. I call this process Empathy. Empathy is a two way street. We can use it to read, and we can use it to write. When two people communicate, they each create their own contextual Backstory. The goal is to make the two Backstories match. --- So how do we do it with a computer? This is the tricky part. First, we need some fundamental Backstories to read with, and a program that uses Backstory to read. Then we should be able to put them to work, and recursively build something useful. I envision a diverse library of Backstories. Once we have that, the hardest part will be choosing which Backstory to use, and why. Backstories provide utility, but they come with assumptions. Enough meta-reading, and we should be able to organize this library well enough. The simple ability to choose what assumptions we are computing with will be incredibly useful. --- So that's all I've got so far. Every time I try to write a real program, my surroundings take over. Software engineering is fraught with assumptions. It's very difficult to set aside the canonical ways that software is made, and those are precisely what I'm trying to reinvent. I'm getting tripped up by the very problem I intend to solve, and the irony is not lost on me. Any help or insight would be greatly appreciated. I know this idea is pretty out there, but if it works, it will solve NLP, and factor out all software incompatibility.

brimwats 2y ago

I would happily bite on that; I mostly deal with archives, libraries, museums and how they deal with people and communities. Because of that there is a ton of nuance when it comes to identities (there is a lot of gradation in meaning between "African American" and "Black" or gay and homosexual for example). Things that seem simple are often very complicated and I've spent a good deal of my PhD work working on that (the Homosaurus is the most popular example of this work); and lately I've been working on how to represent identities in a linked and changing way that can still be used by cultural heritage institutions (i.e. simple enough to be linked to SKOS and Wikidata). I feel pretty close on how to represent some aspects of this semantically, thanks to help from a brilliant ontologist friend.

thomastjeffery 2y ago
I don't think I'll live up to "brilliant ontologist", but here goes: First of all, what's the problem? Computing human-written text. What's the problem domain? Story. In other words: intentionally written text. By that, I mean text that was written to express some arbitrary meaning. This is smaller than the set of all possible written text, because no one intentionally writes anything that is exclusively nonsensical. So what's my solution? I call it the Story Empathizer. --- Every time someone writes text, they encode meaning into it. This even happens on accident: try to write something completely random, and there will always be a reason guiding your result. I call this the original Backstory. This original Backstory contains all of the information that is not written down. It's gone forever, lost to history. What if we could dig it up? Backstory is a powerful tool. To see why, let's consider one of the most frustratingly powerful features of Story: ambiguity. In order to express a unique idea in Story, you don't need an equivalently unique expression! You can write a Story that literally already means some other specific thing, yet somehow your unique meaning still fits! Doesn't that break some mathematical law of compression? We do this all day every day, so there must be something that makes it possible. That thing is Backstory. We are full of them. In a sense, we are even made of them. We can never get the original Backstory back, but we can do the next best thing: make a new one. How? By reading Story. When we successfully read a Story, we transform it into a new Backstory. That goes somewhere in the brain. We call it knowledge. We call it memory. We call it worldview. I call this process Empathy. Empathy is a two way street. We can use it to read, and we can use it to write. When two people communicate, they each create their own contextual Backstory. The goal is to make the two Backstories match. --- So how do we do it with a computer? This is the tricky part. First, we need some fundamental Backstories to read with, and a program that uses Backstory to read. Then we should be able to put them to work, and recursively build something useful. I envision a diverse library of Backstories. Once we have that, the hardest part will be choosing which Backstory to use, and why. Backstories provide utility, but they come with assumptions. Enough meta-reading, and we should be able to organize this library well enough. The simple ability to choose what assumptions we are computing with will be incredibly useful. --- So that's all I've got so far. Every time I try to write a real program, my surroundings take over. Software engineering is fraught with assumptions. It's very difficult to set aside the canonical ways that software is made, and those are precisely what I'm trying to reinvent. I'm getting tripped up by the very problem I intend to solve, and the irony is not lost on me. Any help or insight would be greatly appreciated. I know this idea is pretty out there, but if it works, it will solve NLP, and factor out all software incompatibility.