Newest at the top
| 2025-05-03 19:48:31 +0200 | <EvanR> | if you just have a set of unique tuples the tuple itself can be the ID |
| 2025-05-03 19:48:22 +0200 | <monochrom> | Alternatively if it turns out RDF = prolog but in XML syntax, I can work with that too. >:) |
| 2025-05-03 19:48:04 +0200 | <[exa]> | yes datalog is prolog without actual computation |
| 2025-05-03 19:48:01 +0200 | <EvanR> | if object = entity, then you need IDs, to name the entity |
| 2025-05-03 19:47:53 +0200 | <monochrom> | I don't know datalog. May I think in prolog instead? |
| 2025-05-03 19:47:25 +0200 | <monochrom> | Then you hash (the value and a serial number). |
| 2025-05-03 19:47:12 +0200 | <[exa]> | monochrom: imagine datalog where all facts are `sompredicate(somesubject, someobject).` |
| 2025-05-03 19:46:29 +0200 | <[exa]> | monochrom: yes (in the future they might differentiate by people attaching stuff to either identifier) |
| 2025-05-03 19:46:13 +0200 | <monochrom> | Frankly I don't know RDF. |
| 2025-05-03 19:46:12 +0200 | michalz | (~michalz@185.246.207.221) |
| 2025-05-03 19:45:43 +0200 | <monochrom> | Do you have a scenerio where there are two objects, all their fields have the same value, but you would prefer to call them 2 objects rather than 1 object? This question determines whether you can just hash the values. |
| 2025-05-03 19:45:27 +0200 | <[exa]> | again with RDF you more like "prove that something exists by finding all its bits in the heap" instead of deserializing per se |
| 2025-05-03 19:45:04 +0200 | <EvanR> | if it's not objects but just values with nested structure, a classic serialization is lisp expressions |
| 2025-05-03 19:44:44 +0200 | <[exa]> | ok so maybe serialization is not the right thing to even say here |
| 2025-05-03 19:44:20 +0200 | <[exa]> | it's super effective! |
| 2025-05-03 19:43:43 +0200 | <EvanR> | plays the rainbow table card |
| 2025-05-03 19:43:26 +0200 | [exa] | ties EvanR in a loop! hash out of that! |
| 2025-05-03 19:43:03 +0200 | <EvanR> | hides |
| 2025-05-03 19:43:00 +0200 | <EvanR> | [exa], ID = hash of the value! |
| 2025-05-03 19:42:20 +0200 | <EvanR> | like IORefs |
| 2025-05-03 19:42:16 +0200 | <EvanR> | maybe all your objects actually be expressions (often, they're not) |
| 2025-05-03 19:42:05 +0200 | <[exa]> | I'm literally trying to find the above abstraction that would make the identifiers somewhat manageable |
| 2025-05-03 19:41:52 +0200 | bilegeek | (~bilegeek@2600:1008:b01a:5c24:8c91:aa31:8c9:aaf) bilegeek |
| 2025-05-03 19:41:33 +0200 | <[exa]> | it's not an object, instead it is _____ ? |
| 2025-05-03 19:41:26 +0200 | <monochrom> | Hell, object = record = data = data structure = ... |
| 2025-05-03 19:41:16 +0200 | <[exa]> | good we're getting somewhere |
| 2025-05-03 19:41:11 +0200 | <monochrom> | Oh I just define "object = record". :) |
| 2025-05-03 19:40:53 +0200 | <monochrom> | haha |
| 2025-05-03 19:40:52 +0200 | <EvanR> | if it's a document with nested records then maybe it's not "an object" |
| 2025-05-03 19:40:42 +0200 | tromp | (~textual@2001:1c00:3487:1b00:31c9:5f27:18bf:4d4e) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-05-03 19:40:32 +0200 | <int-e> | EvanR: how to troll efficiently by ignoring context? |
| 2025-05-03 19:40:10 +0200 | <EvanR> | but what's the original subject |
| 2025-05-03 19:40:10 +0200 | <monochrom> | Yeah in practice, one writes in Haskell and compile by MicroHs! |
| 2025-05-03 19:40:03 +0200 | <EvanR> | unless the database has json support |
| 2025-05-03 19:39:50 +0200 | <EvanR> | if the original subject was "a json value" then yeah, you would have to make up artificial and irrelevant IDs to store it in a database |
| 2025-05-03 19:39:44 +0200 | <monochrom> | "How do I serialize objects?" "Use SKI so it's /dev/null when you deserialize!" |
| 2025-05-03 19:39:34 +0200 | <int-e> | (I'm too weak for combinatory logic; the only way I've ever been able to write combinatory logic programs is using abstraction elimination.) |
| 2025-05-03 19:39:24 +0200 | <[exa]> | monochrom: ofc the IDs are a technical necessity but I thought more of the data model layer. Esp. for RDF when you want the IDs to be somewhat stable and carry some mild meaning |
| 2025-05-03 19:39:02 +0200 | <int-e> | I escaped identifiers but at what cost! |
| 2025-05-03 19:38:43 +0200 | <monochrom> | Oh well I guess that's another solution, by having no objects at all! |
| 2025-05-03 19:38:17 +0200 | <int-e> | :P |
| 2025-05-03 19:38:16 +0200 | <int-e> | No ids, just two combinators and application. |
| 2025-05-03 19:37:56 +0200 | <monochrom> | And especially if your object graph is not a tree, all the more important to use IDs so n objects do not become a tree of 2^n nodes, or even worse, an infinite tree just because there is a cycle. |
| 2025-05-03 19:37:55 +0200 | <int-e> | monochrom: just do combinatory logic |
| 2025-05-03 19:36:29 +0200 | <monochrom> | One can never escape IDs. High-level languages deceive you into thinking that you can, by not telling you that pointers and addresses look like 0xdeadbeef which are totally IDs. |
| 2025-05-03 19:36:01 +0200 | <EvanR> | instead of the main model |
| 2025-05-03 19:35:46 +0200 | <EvanR> | and in that perspective, objects nested inside each other is just one way to view the entities and relations |
| 2025-05-03 19:35:21 +0200 | <[exa]> | hm good point |
| 2025-05-03 19:34:56 +0200 | <EvanR> | so not sure if it's not part of the model |
| 2025-05-03 19:34:45 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |