WEBVTT

00:00:02.000 --> 00:00:02.000


00:00:02.000 --> 00:00:05.780
 All right. I think we're live. Thank you, Andrew, for the

00:00:05.780 --> 00:00:06.480
 great talk.

00:00:06.480 --> 00:00:09.040
 Folks, if you'd like to ask your questions, please post

00:00:09.040 --> 00:00:11.280
 them on the pad. And at some point

00:00:11.280 --> 00:00:13.340
 in like a minute or two, we'll also open this big blue

00:00:13.340 --> 00:00:14.560
 button room if you'd like to

00:00:14.560 --> 00:00:17.480
 join here directly and ask questions here. Take it away,

00:00:17.480 --> 00:00:18.000
 Andrew.

00:00:18.000 --> 00:00:25.200
 Yeah, thanks. So should I be reading the questions from the

00:00:25.200 --> 00:00:26.880
 pad? Yeah.

00:00:26.880 --> 00:00:28.400
 Yeah, that would be great.

00:00:29.040 --> 00:00:34.760
 OK, so I see there's a question about is this built into Em

00:00:34.760 --> 00:00:37.440
acs? I guess that refers to SQLite.

00:00:37.440 --> 00:00:41.630
 And is it possible to have multiple schemas, multiple

00:00:41.630 --> 00:00:43.840
 databases? Yes, you could do all that

00:00:43.840 --> 00:00:48.270
 with Emacs 29. SQLite is built in. You can open up multiple

00:00:48.270 --> 00:00:50.000
 databases simultaneously and do just

00:00:50.000 --> 00:00:53.460
 the normal things that you can do with databases. You can

00:00:53.460 --> 00:00:54.640
 create whatever tables you want.

00:00:55.440 --> 00:01:00.720
 You can create-- you can have transactions. So it's pretty

00:01:00.720 --> 00:01:04.000
 full featured. With SQLite,

00:01:04.000 --> 00:01:08.270
 there's also a notion of additions. You could kind of

00:01:08.270 --> 00:01:10.880
 compile new things into it. And I'm not

00:01:10.880 --> 00:01:14.560
 exactly sure to the extent that that is possible as well.

00:01:14.560 --> 00:01:16.400
 So it's like how full featured of a

00:01:16.400 --> 00:01:19.540
 SQLite is it? I'm not sure. But the basic stuff, you can

00:01:19.540 --> 00:01:21.680
 certainly do. And that basic stuff is

00:01:21.680 --> 00:01:26.860
 fantastic. Next question is, what about collaborative

00:01:26.860 --> 00:01:29.920
 editing with this? Can you

00:01:29.920 --> 00:01:35.070
 have multiple computers with multiple Emacs with org mode?

00:01:35.070 --> 00:01:37.840
 I think it sort of depends. Yes,

00:01:37.840 --> 00:01:41.640
 I mean, databases are fantastic for having multiple users

00:01:41.640 --> 00:01:44.080
 doing multiple things at the same time.

00:01:44.080 --> 00:01:48.990
 And they're really designed for this use case. So I would

00:01:48.990 --> 00:01:51.760
 say, yes, you could have multiple

00:01:51.760 --> 00:01:56.810
 editing of the database, multiple editing, whereas you see

00:01:56.810 --> 00:02:04.160
 some [AUDIO OUT] probably not the best

00:02:04.160 --> 00:02:06.830
 solution. I suspect it might be possible, but I wouldn't

00:02:06.830 --> 00:02:08.720
 want to try it. I think it's better for,

00:02:08.720 --> 00:02:12.660
 like, oh, you can have multiple processes, multiple users,

00:02:12.660 --> 00:02:14.400
 perhaps contributing to the

00:02:14.400 --> 00:02:17.610
 same database. And you're growing the database, but not

00:02:17.610 --> 00:02:20.080
 such tight synchronous interactivity that

00:02:20.080 --> 00:02:24.520
 I think you might be imagining here. What about using this

00:02:24.520 --> 00:02:26.880
 on multiple computers? How do you

00:02:26.880 --> 00:02:31.140
 synchronize your data? I don't know. I need to figure that

00:02:31.140 --> 00:02:33.040
 out. I think there's a-- like,

00:02:33.040 --> 00:02:36.470
 yes, you can synchronize your database in the same [AUDIO

00:02:36.470 --> 00:02:38.320
 OUT] Emacs doesn't have any great

00:02:38.320 --> 00:02:43.000
 solutions for this. That is, like, when-- let's say I want

00:02:43.000 --> 00:02:45.680
 to synchronize the things I'm editing

00:02:45.680 --> 00:02:49.280
 on Emacs with my phone. There's all sorts of various

00:02:49.280 --> 00:02:52.320
 solutions. You could use Dropbox, Google

00:02:52.320 --> 00:02:56.930
 Drive, these kinds of things. The database makes that a

00:02:56.930 --> 00:02:59.600
 little bit harder in the sense that it's

00:02:59.600 --> 00:03:04.400
 one giant database. I suspect there are interesting ways to

00:03:04.400 --> 00:03:06.560
 do this, but I haven't explored this area

00:03:06.560 --> 00:03:09.180
 yet. I think it's a great question, though, and I would

00:03:09.180 --> 00:03:10.800
 like to investigate this further.

00:03:10.800 --> 00:03:16.640
 Are you planning to further-- this is a new other question.

00:03:16.640 --> 00:03:18.720
 Are you planning to further develop EKG?

00:03:18.720 --> 00:03:22.330
 It's highly [AUDIO OUT] me, and I do prefer SQLite over

00:03:22.330 --> 00:03:23.920
 Text. Thank you for buying into

00:03:25.200 --> 00:03:29.280
 the vision. I really like to hear that. Yeah, I am

00:03:29.280 --> 00:03:32.080
 personally using EKG. I am developing it.

00:03:32.080 --> 00:03:36.940
 I don't think it's ready for general use yet. I'd like to

00:03:36.940 --> 00:03:39.680
 get it to a state where it is ready

00:03:39.680 --> 00:03:43.410
 for general use probably by the end of the month. I think I

00:03:43.410 --> 00:03:45.600
'll have a lot of time. There's a pretty

00:03:45.600 --> 00:03:50.500
 slow month. So that would be really nice. I've just added a

00:03:50.500 --> 00:03:52.160
 bunch of stuff to it.

00:03:53.360 --> 00:03:55.970
 I'm exploring. I think the difficult thing is not

00:03:55.970 --> 00:03:58.000
 necessarily to make it production,

00:03:58.000 --> 00:04:01.800
 like to make it stable and everything like that and to do

00:04:01.800 --> 00:04:04.320
 all the developer things that you want

00:04:04.320 --> 00:04:09.380
 to see in the state of the art era, but really, it's a

00:04:09.380 --> 00:04:12.240
 different model of how to have notes.

00:04:12.240 --> 00:04:16.860
 I'm still thinking about some of these fundamental concepts

00:04:16.860 --> 00:04:18.080
. It took me a long

00:04:18.080 --> 00:04:22.030
 time to iterate on various designs before I came up with EK

00:04:22.030 --> 00:04:24.240
G, which I think is [AUDIO OUT]

00:04:24.240 --> 00:04:27.200
 and so we're going to really see how this goes. But yes,

00:04:27.200 --> 00:04:29.920
 look for it soon. I'll probably announce it

00:04:29.920 --> 00:04:39.410
 and maybe on email. And then I will make it available

00:04:39.410 --> 00:04:40.960
 probably maybe on

00:04:42.000 --> 00:04:46.780
 new alpha is what I would like to do. Is it possible to

00:04:46.780 --> 00:04:47.760
 combine the

00:04:47.760 --> 00:04:51.610
 triples database with some custom tables in the same SQLite

00:04:51.610 --> 00:04:56.240
 file? Yes. I'm sorry. Let me continue

00:04:56.240 --> 00:04:59.670
 reading. You need to build a log table next to the triples

00:04:59.670 --> 00:05:02.080
 table or a quick query of event data.

00:05:02.080 --> 00:05:04.270
 Yeah, you certainly could do that. And I've been thinking

00:05:04.270 --> 00:05:04.720
 of adding,

00:05:05.520 --> 00:05:09.210
 like, just having a record of changes might be an

00:05:09.210 --> 00:05:12.720
 interesting thing. But yeah, it's just one table

00:05:12.720 --> 00:05:17.840
 and you really could use this one table called triples, the

00:05:17.840 --> 00:05:22.000
 triples table, in any other database

00:05:22.000 --> 00:05:24.230
 or with any other database. It's kind of designed to be its

00:05:24.230 --> 00:05:26.080
 own database though. But yeah, you could

00:05:26.080 --> 00:05:28.500
 certainly add things to the side and I can imagine people

00:05:28.500 --> 00:05:29.840
 writing extensions that do

00:05:30.560 --> 00:05:34.000
 add some tables to the side to do whatever. It's just that

00:05:34.000 --> 00:05:37.680
 I think you want to be careful because

00:05:37.680 --> 00:05:42.660
 that once you start doing that, you might want to, you don

00:05:42.660 --> 00:05:45.040
't want to kind of duplicate information or

00:05:45.040 --> 00:05:47.490
 start having things go out of sync. It's kind of nice just

00:05:47.490 --> 00:05:49.600
 to have one kind of data. But I think

00:05:49.600 --> 00:05:52.090
 in certain circumstances, like the kind you're thinking

00:05:52.090 --> 00:05:54.320
 about, it'd be appropriate. Yeah, so

00:05:54.320 --> 00:06:00.010
 seems like a good idea. And then I see this final question

00:06:00.010 --> 00:06:02.800
 here, final for now. What are your

00:06:02.800 --> 00:06:05.270
 thoughts on adding a timestamp attribute to triple so that

00:06:05.270 --> 00:06:07.280
 the database becomes append-only and by

00:06:07.280 --> 00:06:10.570
 default you return the latest fact for a subject-object

00:06:10.570 --> 00:06:13.360
 pair? Oh, really interesting question.

00:06:13.360 --> 00:06:19.560
 Let's just say I haven't thought of that and I'll have to

00:06:19.560 --> 00:06:21.680
 think about it. I don't think,

00:06:21.680 --> 00:06:26.110
 I haven't seen other triples databases do this. I'd be

00:06:26.110 --> 00:06:28.000
 interested in what you thought

00:06:28.000 --> 00:06:33.610
 would be some of the, what you thought might be some of the

00:06:33.610 --> 00:06:34.960
 interesting

00:06:34.960 --> 00:06:39.440
 things that come out of this. Yes, you can maybe go back in

00:06:39.440 --> 00:06:41.760
 time, which is nice,

00:06:41.760 --> 00:06:45.620
 but then it seems hard to do things like deletes. I guess

00:06:45.620 --> 00:06:48.000
 you could have tombstones or something

00:06:48.000 --> 00:06:51.110
 like that, but it becomes a little bit more complicated.

00:06:51.110 --> 00:06:52.880
 And also just one thing is like,

00:06:52.880 --> 00:06:55.390
 these kind of databases, I didn't really talk about this in

00:06:55.390 --> 00:06:57.120
 the talk, but they take up a little

00:06:57.120 --> 00:06:59.870
 bit of room and I'm a little bit reluctant to have them

00:06:59.870 --> 00:07:01.760
 even more kind of heavyweight.

00:07:01.760 --> 00:07:05.380
 On the other hand, perhaps this would go well with the

00:07:05.380 --> 00:07:07.680
 question about synchronization. If you

00:07:07.680 --> 00:07:11.840
 were to do as you suggest and have timestamped triples,

00:07:11.840 --> 00:07:14.080
 synchronization actually becomes pretty

00:07:14.080 --> 00:07:18.110
 easy. So definitely an interesting thought that I'll have

00:07:18.110 --> 00:07:19.600
 to think a little bit more about. I

00:07:19.600 --> 00:07:23.970
 would love to solve the synchronization problem. All right.

00:07:23.970 --> 00:07:29.520
 I don't see any other, oh yeah,

00:07:29.520 --> 00:07:33.740
 I don't see any other questions, but you can ask on this,

00:07:33.740 --> 00:07:38.160
 on the big blue button or type in any

00:07:38.160 --> 00:07:42.730
 other questions. Otherwise I think we might be done. Cool.

00:07:42.730 --> 00:07:45.280
 And I will add that. I think we still

00:07:45.280 --> 00:07:48.590
 have about like, I guess, 15 minutes or so of live Q&A talk

00:07:48.590 --> 00:07:52.320
 for this talk on stream. If there are no

00:07:52.320 --> 00:07:54.790
 questions, you're welcome to cut it short, but otherwise we

00:07:54.790 --> 00:07:56.320
 have plenty of time. So yeah, if

00:07:56.320 --> 00:07:59.910
 people want to get more questions in, please do. I'm just

00:07:59.910 --> 00:08:01.680
 going to sit back and wait for the

00:08:01.680 --> 00:08:06.000
 questions to roll in then. Sounds good. Thank you.

00:08:06.000 --> 00:08:35.920
 All right. I see another question pop up.

00:08:37.040 --> 00:08:37.040


00:08:37.040 --> 00:08:41.400
 With EKG, what about views like org-roam-node-mindmap-views

00:08:41.400 --> 00:08:44.080
? Yeah. I personally have

00:08:44.080 --> 00:08:47.280
 not found those views to be super helpful, but I know

00:08:47.280 --> 00:08:49.680
 people like them a lot. I don't see any

00:08:49.680 --> 00:08:52.800
 reason why you couldn't do this. It just would be a

00:08:52.800 --> 00:08:56.000
 slightly different implementation. Like this

00:08:56.000 --> 00:09:02.940
 stuff forms a graph. You can do whatever you, you know, you

00:09:02.940 --> 00:09:05.920
 could easily transform it like that same

00:09:05.920 --> 00:09:09.560
 org-roam UI. You just have to have like another sort of

00:09:09.560 --> 00:09:12.160
 translation layer basically to kind of

00:09:12.160 --> 00:09:16.450
 like figure out how to deal with the stuff in EKG or really

00:09:16.450 --> 00:09:19.520
 anything with triples. Like fundamentally

00:09:19.520 --> 00:09:23.240
 it's a graph database, so it lends itself naturally to

00:09:23.240 --> 00:09:25.680
 things that you're going to be doing,

00:09:25.680 --> 00:09:30.080
 that anything you're going to be doing with the triples

00:09:30.080 --> 00:09:30.800
 library.

00:09:32.400 --> 00:09:32.400


00:09:32.400 --> 00:09:52.480
 [silence]

00:09:52.480 --> 00:09:46.220
 I see another question. Can ordinary Lisp data types, Lisp

00:09:46.220 --> 00:09:59.440
 symbols, etc. be stored in the

00:09:59.440 --> 00:10:04.760
 database? Yes, they can. In fact, it's primarily like if

00:10:04.760 --> 00:10:07.120
 you don't specify anything, it kind of

00:10:07.120 --> 00:10:10.900
 defaults to a list. That's sort of, I'm not exactly sure

00:10:10.900 --> 00:10:13.520
 that's the right design choice, but that's

00:10:13.520 --> 00:10:19.230
 kind of, it seems like a lot of the times it, this kind of

00:10:19.230 --> 00:10:24.000
 makes sense. Like what if I just added

00:10:24.000 --> 00:10:27.000
 like a title, I think, if I remember. I did add a title,

00:10:27.000 --> 00:10:29.360
 but I'm trying to remember. If I just added

00:10:29.360 --> 00:10:33.770
 the notion of like having a title to EKG and I believe that

00:10:33.770 --> 00:10:36.240
's a list. Because you think about it,

00:10:36.240 --> 00:10:39.160
 you could maybe have alternate titles or multiple titles.

00:10:39.160 --> 00:10:40.880
 So these are ordered lists and so it kind

00:10:40.880 --> 00:10:44.380
 of stores it. So basically what happens is you store in the

00:10:44.380 --> 00:10:46.560
 list of like, but each list item is

00:10:46.560 --> 00:10:49.910
 a separate row in the table and it has, we call them tri

00:10:49.910 --> 00:10:52.880
ples, but there's actually one more column

00:10:52.880 --> 00:10:54.720
 that I don't talk about a lot because it just confuses the

00:10:54.720 --> 00:10:56.160
 story. But in this case it's relevant

00:10:56.160 --> 00:10:59.040
 because there you just say what the index is of the item

00:10:59.040 --> 00:11:01.120
 that you're doing it. So like you'd be

00:11:01.120 --> 00:11:09.150
 subject and then the predicate would be title in a sense.

00:11:09.150 --> 00:11:12.400
 And then title one and then like,

00:11:12.400 --> 00:11:15.860
 okay, that's index one on the fourth column. And then same

00:11:15.860 --> 00:11:17.200
 thing with the other items.

00:11:17.840 --> 00:11:24.090
 You can store symbols, SQLite and Emac SQL allow you to

00:11:24.090 --> 00:11:27.920
 sort of kind of, well, Emac SQL kind of

00:11:27.920 --> 00:11:31.130
 naturally lets you store lots of different things. And SQL

00:11:31.130 --> 00:11:33.840
ite, I kind of had to do something that

00:11:33.840 --> 00:11:39.790
 was very similar to Emac SQL. Emac SQL, in SQL, you have to

00:11:39.790 --> 00:11:43.120
 just, in your database, it basically

00:11:43.120 --> 00:11:47.000
 has to be string. Like almost everything besides the predic

00:11:47.000 --> 00:11:49.120
ates, like the object has to be a string

00:11:49.120 --> 00:11:52.250
 because it could really be anything. And the subject has to

00:11:52.250 --> 00:11:53.840
 be a string because it could be

00:11:53.840 --> 00:12:00.490
 anything. And because of that, we kind of have to make sure

00:12:00.490 --> 00:12:04.080
 that we kind of have to just store

00:12:04.080 --> 00:12:06.840
 things in a certain way. Like symbols are just strings and

00:12:06.840 --> 00:12:10.720
 lists. You could even have a list,

00:12:12.640 --> 00:12:17.810
 you could have really any list expression as a subject,

00:12:17.810 --> 00:12:21.600
 right? But it gets just written to a

00:12:21.600 --> 00:12:27.720
 string and then it gets, when it gets read, it basically,

00:12:27.720 --> 00:12:30.960
 if it's just a string, it gets read

00:12:30.960 --> 00:12:36.370
 basically as a list symbol or expression. And if it's a

00:12:36.370 --> 00:12:39.840
 string, it's a string with a string inside,

00:12:39.840 --> 00:12:44.130
 that is like the string actually has quotes on either end.

00:12:44.130 --> 00:12:46.000
 Then we say it's actually a string.

00:12:46.000 --> 00:12:48.770
 That's how kind of the internal implementation works. And

00:12:48.770 --> 00:12:50.320
 that's what Emac SQL does as well.

00:12:50.320 --> 00:12:55.040
 For those who are not familiar, Emac SQL is like this other

00:12:55.040 --> 00:12:58.560
 way to kind of interact with SQL in

00:12:58.560 --> 00:13:02.210
 your databases and it works well with SQLite and allows you

00:13:02.210 --> 00:13:04.400
 to do things like store numbers and

00:13:05.600 --> 00:13:08.960
 lists as well. And it does this exact same thing. So we try

00:13:08.960 --> 00:13:10.320
 to keep compatibility.

00:13:10.320 --> 00:13:18.910
 So you could start a database in Emacs 28 using Emacs SQL

00:13:18.910 --> 00:13:23.440
 and then you could read it with Emacs 29

00:13:23.440 --> 00:13:27.430
 using the built in SQLite. That's the hope. I mean, I have

00:13:27.430 --> 00:13:28.720
 tests, but I don't think anyone

00:13:28.720 --> 00:13:35.050
 has actually tried to do that exact thing yet. Let's see.

00:13:35.050 --> 00:13:39.040
 Are there any other new questions?

00:13:39.040 --> 00:13:44.240
 Oh, there are some. Beyond note taking, what kind of

00:13:44.240 --> 00:13:45.360
 packages do you

00:13:45.360 --> 00:13:49.680
 think would benefit from a triple library? I think,

00:13:49.680 --> 00:13:53.830
 I mean, I think it's generally just an easy way to store

00:13:53.830 --> 00:13:54.880
 things. So

00:13:56.800 --> 00:14:03.200
 anything in which you, think of packages that have to store

00:14:03.200 --> 00:14:03.440
 like

00:14:03.440 --> 00:14:09.440
 list expressions on the side. Like for example, like BBDB,

00:14:09.440 --> 00:14:11.200
 if you've used that,

00:14:11.200 --> 00:14:14.110
 it's just a, it is a database. It's the big brother

00:14:14.110 --> 00:14:17.200
 database. It's not in a database because

00:14:17.200 --> 00:14:19.890
 it was written before. Like there was an easy way to use

00:14:19.890 --> 00:14:22.480
 databases in Emacs. Like that should,

00:14:22.480 --> 00:14:24.640
 that could definitely, like you don't need the triples

00:14:24.640 --> 00:14:26.160
 library, but you could easily do this

00:14:26.160 --> 00:14:31.120
 in the triples library. And I would kind of think triples,

00:14:31.120 --> 00:14:33.120
 you know, just takes care of a lot of

00:14:33.120 --> 00:14:37.280
 things and gives a little option over everything. So I mean

00:14:37.280 --> 00:14:39.760
, there's all sorts of things like,

00:14:39.760 --> 00:14:42.210
 as I, as I kind of demoed like bookmarks, like why are book

00:14:42.210 --> 00:14:43.920
marks not in the database? They should be.

00:14:43.920 --> 00:14:48.150
 So I think if you just look around and look at all these,

00:14:48.150 --> 00:14:50.640
 all these things as,

00:14:51.280 --> 00:14:55.680
 as just, just dumping, dumping list expressions to a file,

00:14:55.680 --> 00:14:57.440
 those probably

00:14:57.440 --> 00:15:01.870
 SQLite and, and, you know, maybe triples would be a useful

00:15:01.870 --> 00:15:03.200
 way to do that.

00:15:03.200 --> 00:15:08.720
 Are you, another question, are you trying to PIM? I think

00:15:08.720 --> 00:15:11.120
 that means personal information management

00:15:11.120 --> 00:15:16.160
 with EKG. And what information do you want to manage? I'm

00:15:16.160 --> 00:15:17.120
 kind of wondering

00:15:18.720 --> 00:15:21.400
 how I, what I want to do, but like, as I just said in the

00:15:21.400 --> 00:15:23.440
 previous question, like, I think

00:15:23.440 --> 00:15:26.960
 you should be storing everything. Yeah. Like libraries,

00:15:26.960 --> 00:15:28.880
 like, yeah, actually, yeah. BBBB,

00:15:28.880 --> 00:15:32.180
 you can store contacts and email addresses. And I would

00:15:32.180 --> 00:15:34.320
 like to, you know, why, if you're storing

00:15:34.320 --> 00:15:37.110
 that, then it's kind of natural, like, oh, well, you know,

00:15:37.110 --> 00:15:38.880
 sometimes I want to have a annotation.

00:15:38.880 --> 00:15:41.380
 I want to write something about this person and, you know,

00:15:41.380 --> 00:15:44.000
 maybe I want to have something and have,

00:15:46.400 --> 00:15:48.930
 you know, maybe I want to tag this person. Maybe I want to,

00:15:48.930 --> 00:15:53.200
 maybe I want to have notes that refer

00:15:53.200 --> 00:15:55.700
 to this person. So like, it all starts to look like one

00:15:55.700 --> 00:15:57.280
 giant database when I, when you kind

00:15:57.280 --> 00:16:01.120
 of think about it a lot, which is kind of why in a, if you

00:16:01.120 --> 00:16:04.800
 look at the develop, develop branch of

00:16:04.800 --> 00:16:08.290
 triples, I, I'm work, I think what's going to be in the

00:16:08.290 --> 00:16:10.400
 next version is, is going to be a

00:16:10.400 --> 00:16:14.110
 standardized place to, to have a database. That is, you can

00:16:14.110 --> 00:16:17.360
 just connect to a, to a, the standard

00:16:17.360 --> 00:16:19.360
 database and you don't have to worry about where the

00:16:19.360 --> 00:16:21.280
 database is. We'll keep track of that for you.

00:16:21.280 --> 00:16:27.540
 And, and then everything should be working very easily and

00:16:27.540 --> 00:16:30.320
 like allow this kind of collaborative

00:16:30.320 --> 00:16:32.770
 use of, of these things. So like, yeah, it could be a

00:16:32.770 --> 00:16:34.720
 personal information manager that has all

00:16:34.720 --> 00:16:37.330
 sorts of information because I think that's what people

00:16:37.330 --> 00:16:39.440
 tend to use Emacs for is that, you know,

00:16:39.440 --> 00:16:43.610
 I have my own notes, my own contacts, my own tasks, you

00:16:43.610 --> 00:16:46.080
 know, why aren't tasks in, tasks should

00:16:46.080 --> 00:16:49.820
 also perhaps be in, in, in the database. Like, yeah, it's

00:16:49.820 --> 00:16:52.000
 kind of, org mode is completely awesome,

00:16:52.000 --> 00:16:56.110
 like really incredible. And it's, it's nice to mix to do's

00:16:56.110 --> 00:16:58.480
 with things with text, but sometimes

00:16:58.480 --> 00:17:01.850
 maybe you just want to do's that are not with text and

00:17:01.850 --> 00:17:04.160
 maybe those could be also in the database.

00:17:04.160 --> 00:17:06.050
 I don't know. It's just things I, things I'm thinking about

00:17:06.050 --> 00:17:07.200
. I'm not sure how far I want to

00:17:07.200 --> 00:17:12.160
 take that. Another question. What about using other

00:17:12.160 --> 00:17:16.000
 database programs like Postgres, MonoDB?

00:17:16.000 --> 00:17:27.550
 You, so I think you could, yes, you could do that. I don't

00:17:27.550 --> 00:17:29.920
 see it's a, I don't know why you,

00:17:29.920 --> 00:17:32.720
 I don't know if there's any advantage to doing this. Like

00:17:32.720 --> 00:17:35.280
 SQLite is kind of nice because it is

00:17:35.280 --> 00:17:38.490
 light. It is kind of, it is built into Emacs and we don't

00:17:38.490 --> 00:17:39.760
 really need anything incredibly

00:17:39.760 --> 00:17:42.210
 sophisticated here. Just having a database is like such a

00:17:42.210 --> 00:17:43.680
 higher level of sophistication than

00:17:43.680 --> 00:17:47.500
 what we've been doing in Emacs are so far. Then you know, I

00:17:47.500 --> 00:17:50.000
 think the other stuff might be overkill,

00:17:50.000 --> 00:17:52.800
 but I see no reason why it wouldn't work. I just don't

00:17:52.800 --> 00:17:54.640
 really see if there's really any big

00:17:54.640 --> 00:18:00.620
 advantages. What is your preferred reference to underscan

00:18:00.620 --> 00:18:04.960
 triples graph DBs? To sort of think

00:18:04.960 --> 00:18:07.330
 about better schema design? Oh, that's a really awesome

00:18:07.330 --> 00:18:12.480
 question. And I would, I don't, I don't

00:18:12.480 --> 00:18:15.570
 think I can answer that immediately. I kind of know all

00:18:15.570 --> 00:18:17.520
 this stuff from talking to people

00:18:17.520 --> 00:18:21.730
 basically, instead of like reading things. And like in my

00:18:21.730 --> 00:18:25.040
 work, I use these triples. That is,

00:18:25.040 --> 00:18:28.100
 that's kind of like, you know, I kind of work on a

00:18:28.100 --> 00:18:30.560
 knowledge graph. So I just have a, from,

00:18:30.560 --> 00:18:35.860
 you know, working knowledge of how these things work. So,

00:18:35.860 --> 00:18:38.400
 but it is an awesome question that let

00:18:38.400 --> 00:18:41.530
 me, let me look into it after I kind of finished this and I

00:18:41.530 --> 00:18:43.440
'll, I'll try to fill it in, in the,

00:18:43.440 --> 00:18:47.210
 in the either pad that is connected to this talk. So thank

00:18:47.210 --> 00:18:49.200
 you for that great question.

00:18:49.200 --> 00:18:53.960
 So another question, will it slow down with the growth of a

00:18:53.960 --> 00:18:56.960
 database? Yeah, I need to do

00:18:56.960 --> 00:19:00.040
 tests about this. Cause I'd like to see like how much, how

00:19:00.040 --> 00:19:01.360
 much the database blows up,

00:19:01.360 --> 00:19:05.120
 how much it slows down for sure. Triples is not the most

00:19:05.120 --> 00:19:07.360
 efficient way. It's not even close

00:19:07.360 --> 00:19:10.650
 to being a greatly efficient way to store data for doing

00:19:10.650 --> 00:19:13.120
 any arbitrary things. But what it is,

00:19:13.120 --> 00:19:17.510
 it you're trading off standardization, which is, so you get

00:19:17.510 --> 00:19:19.600
 standardization, but you lose,

00:19:19.600 --> 00:19:24.880
 you lose the power of getting things in one SQL expression.

00:19:24.880 --> 00:19:26.480
 So you often have to kind of like do

00:19:26.480 --> 00:19:31.400
 a bunch of round trips and that's slow. However, I I'm

00:19:31.400 --> 00:19:36.320
 using this now. I have a bunch of data

00:19:36.320 --> 00:19:40.440
 and you know, quite a bit. I've, I kind of poured it over

00:19:40.440 --> 00:19:42.720
 my old org Rome to, to EKG.

00:19:42.720 --> 00:19:45.860
 And you know, I've been accumulating stuff in our room for

00:19:45.860 --> 00:19:47.920
 like, you know, two years now,

00:19:47.920 --> 00:19:52.510
 and it's pretty big, but it's very fast, really just no, no

00:19:52.510 --> 00:19:55.200
 problems at all. So yes, I'm sure

00:19:55.200 --> 00:20:00.750
 that there is a, a size in which it's too big to be fast.

00:20:00.750 --> 00:20:04.400
 But I haven't hit it. And I suspect for

00:20:04.400 --> 00:20:09.230
 most ordinary uses of, of, of Emacs, I doubt other people

00:20:09.230 --> 00:20:12.160
 will hit it as well. I mean, it's kind of

00:20:12.160 --> 00:20:14.380
 similar to, you know, when people think about org Rome and

00:20:14.380 --> 00:20:15.760
 things like, well, you know, you're

00:20:15.760 --> 00:20:17.980
 storing everything in one database, like how many notes

00:20:17.980 --> 00:20:19.520
 could have possibly hold, like that's also

00:20:19.520 --> 00:20:25.980
 going to get slow. Right. So yeah, it's, it's I think these

00:20:25.980 --> 00:20:29.760
 limits exist, but people tend not to

00:20:29.760 --> 00:20:32.480
 hit them and it's like, yes, this is going to get slow, but

00:20:32.480 --> 00:20:34.320
 it'll certainly do better. I think that

00:20:34.320 --> 00:20:38.850
 files in the file system. What are the, here's another

00:20:38.850 --> 00:20:41.920
 question. What are your thoughts on

00:20:41.920 --> 00:20:47.130
 allowing for a true graph DB backend? Whatever the current

00:20:47.130 --> 00:20:50.480
 best free software alternative to Neo4j

00:20:50.480 --> 00:20:54.710
 is, I guess. Okay. Great question. I've actually, yeah, I

00:20:54.710 --> 00:20:57.360
 actually used graph databases and several

00:20:57.360 --> 00:21:00.580
 companies I used to work for and you know, but we always

00:21:00.580 --> 00:21:03.040
 ended up switching to SQL. I like it's,

00:21:03.040 --> 00:21:08.000
 it's I can't, it's just at least for serious applications,

00:21:08.000 --> 00:21:10.080
 they tended to be slow and

00:21:10.880 --> 00:21:14.310
 lend themselves to a use that was not, that was very iter

00:21:14.310 --> 00:21:16.480
ative and not very well thought out.

00:21:16.480 --> 00:21:23.880
 So however, I don't think it's as I said, with the last

00:21:23.880 --> 00:21:28.720
 question for the way people want to,

00:21:28.720 --> 00:21:31.090
 you know, the kind of data I think Emacs users will want, I

00:21:31.090 --> 00:21:32.480
 think a graph database would work

00:21:32.480 --> 00:21:36.610
 quite well. I don't know if there would be like, what are

00:21:36.610 --> 00:21:38.720
 the advantages over triples

00:21:38.720 --> 00:21:41.700
 aside from sort of just a more, you don't have to kind of

00:21:41.700 --> 00:21:43.440
 even deal with the SQL layer, but like,

00:21:43.440 --> 00:21:46.040
 I'm kind of, I'm kind of building, you know, with triples,

00:21:46.040 --> 00:21:47.760
 we're sort of like, don't even worry about

00:21:47.760 --> 00:21:50.220
 what the layer is, right? It's just, you don't even have to

00:21:50.220 --> 00:21:51.920
 worry about SQL if you're just using

00:21:51.920 --> 00:21:57.040
 kind of the normal functionality. So you can yeah. So, you

00:21:57.040 --> 00:22:00.160
 know, maybe there are interesting

00:22:00.160 --> 00:22:02.670
 implications for using a graph database, but I can't really

00:22:02.670 --> 00:22:03.680
 think of any right now.

00:22:03.680 --> 00:22:09.910
 It's a good question though. Thank you. - And I'll quickly

00:22:09.910 --> 00:22:10.880
 add that we have about,

00:22:10.880 --> 00:22:14.850
 I think two more minutes ish on this live stream. And then

00:22:14.850 --> 00:22:17.120
 folks are welcome to either join here for

00:22:17.120 --> 00:22:19.560
 continuing the Q and A or keep posting questions on the pad

00:22:19.560 --> 00:22:21.040
 and you can continue here in this room

00:22:21.040 --> 00:22:24.000
 after the stream moves on. - Okay. In that case, I'll,

00:22:24.000 --> 00:22:28.320
 I will stick around until I don't get any more questions

00:22:28.320 --> 00:22:30.080
 for a few minutes, then I'll probably

00:22:31.200 --> 00:22:33.440
 log off. - Sounds great. Thank you.

00:22:33.440 --> 00:22:35.440
 - Yeah.

00:22:58.960 --> 00:23:02.640
 - I'm hungry. Did I get writing and recording this? So I

00:23:02.640 --> 00:23:06.560
 actually did a month ago. So like,

00:23:06.560 --> 00:23:10.530
 I don't even, I hardly even remember what it was, what that

00:23:10.530 --> 00:23:12.160
 time was like, but yes, it's,

00:23:12.160 --> 00:23:14.480
 it took a long time. These things, you know, these

00:23:14.480 --> 00:23:16.480
 recordings are a little bit challenging. And in

00:23:16.480 --> 00:23:18.780
 fact, I only kind of screwed up in several instances of the

00:23:18.780 --> 00:23:20.240
 recording. And like, I just,

00:23:20.240 --> 00:23:22.240
 I just don't have energy to kind of keep redoing. It's like

00:23:22.240 --> 00:23:23.760
, it's a long recording. It's also,

00:23:23.760 --> 00:23:26.000
 I think I chopped it up into three bits. I'm not sure if it

00:23:26.000 --> 00:23:27.600
 was that, is that obvious, but like,

00:23:27.600 --> 00:23:31.860
 I guess, notes for people doing future sessions, it's like,

00:23:31.860 --> 00:23:35.680
 make sure you have natural pauses that

00:23:35.680 --> 00:23:39.860
 you can sort of just like record a segment because

00:23:39.860 --> 00:23:42.880
 something would inevitably go wrong. And then like,

00:23:42.880 --> 00:23:45.200
 if you're trying to repeat a 20 minute talk, it just takes

00:23:45.200 --> 00:23:48.720
 forever. Yes. Oh yeah. The recipes.

00:23:48.720 --> 00:23:54.230
 That's right. Yeah. I, well, yes, I'm glad you enjoyed the

00:23:54.230 --> 00:23:56.480
 recipe. This is great. You put the

00:23:56.480 --> 00:23:59.800
 recipes in there. Like one thing that I think is, is useful

00:23:59.800 --> 00:24:01.840
 for, you know, regardless of what

00:24:01.840 --> 00:24:06.110
 thing you're using in org-roam or EKG or whatever, you know

00:24:06.110 --> 00:24:08.240
, when you're making a recipe,

00:24:08.240 --> 00:24:11.230
 you know, record in your daily diary, like, you know, when

00:24:11.230 --> 00:24:12.800
 you, what you did it, if it worked,

00:24:12.800 --> 00:24:16.160
 like what, what, you know, what adjustments you had to make

00:24:16.160 --> 00:24:17.760
, how it turned out, how it could be

00:24:17.760 --> 00:24:21.320
 better. Then like, if it's linked to the recipe, then you

00:24:21.320 --> 00:24:23.040
 have a kind of a record of like, oh,

00:24:23.040 --> 00:24:25.720
 these are, you know, not just the recipe, but like your

00:24:25.720 --> 00:24:27.840
 experiences making the recipe. I think

00:24:27.840 --> 00:24:32.140
 it's really powerful because then you can see how, you know

00:24:32.140 --> 00:24:34.480
, you can kind of refine, refine and

00:24:34.480 --> 00:24:37.030
 refine. It's really hard to do this in other ways. Like if

00:24:37.030 --> 00:24:38.640
 just, you're just using your memory,

00:24:38.640 --> 00:24:40.730
 you're, you're kind of like, well, it's, I can't remember

00:24:40.730 --> 00:24:42.000
 what I did the last time I made this

00:24:42.000 --> 00:24:45.940
 recipe, but like, you know, it seems a little bit extreme,

00:24:45.940 --> 00:24:48.240
 but I think it's quite useful to use

00:24:48.240 --> 00:25:01.720
 these note-taking applications for this use case. Okay. I

00:25:01.720 --> 00:25:03.440
 think the stream has moved on, but again,

00:25:03.440 --> 00:25:05.620
 you're all welcome to stay here and continue to Q&A as long

00:25:05.620 --> 00:25:06.720
 as there are any questions.

00:25:06.720 --> 00:25:13.440
 Thank you for your moderation.

00:25:15.120 --> 00:25:19.920
 Cheers. Happy to. Thanks for the great talk.

00:25:21.200 --> 00:25:21.200


00:25:21.200 --> 00:25:23.200
 [end of transcript]

00:25:46.080 --> 00:25:49.120
 While I see if there's any more questions, I'm going to

00:25:49.120 --> 00:25:50.320
 fill in, I think not, not all

00:25:50.320 --> 00:25:52.710
 the replies are filled in. So I'm going to start filling in

00:25:52.710 --> 00:25:53.200
 this, you know,

00:25:53.200 --> 00:25:56.240
 the pad that's associated with this.

00:25:56.400 --> 00:25:56.400


00:25:56.400 --> 00:25:58.400
 [end of transcript]

00:26:00.160 --> 00:26:00.160


00:26:00.160 --> 00:26:00.560
 Okay.

00:26:02.560 --> 00:26:02.560


00:26:02.560 --> 00:26:04.560
 [end of transcript]

00:26:04.560 --> 00:26:14.560
 Okay.

00:26:16.560 --> 00:26:16.560


00:26:16.560 --> 00:26:18.560
 [end of transcript]

00:26:20.560 --> 00:26:20.560


00:26:20.560 --> 00:26:20.560
 Okay.

00:26:22.560 --> 00:26:22.560


00:26:22.560 --> 00:26:22.560
 Okay.

00:26:24.560 --> 00:26:24.560


00:26:24.560 --> 00:26:24.560
 Okay.

00:26:26.560 --> 00:26:26.560


00:26:26.560 --> 00:26:26.560
 Okay.

00:26:28.560 --> 00:26:28.560


00:26:28.560 --> 00:26:28.560
 Okay.

00:26:30.560 --> 00:26:30.560


00:26:30.560 --> 00:26:30.560
 Okay.

00:26:32.560 --> 00:26:32.560


00:26:32.560 --> 00:26:32.560
 Okay.

00:26:34.560 --> 00:26:34.560


00:26:34.560 --> 00:26:34.560
 Okay.

00:26:36.560 --> 00:26:36.560


00:26:36.560 --> 00:26:36.560
 Okay.

00:26:36.560 --> 00:26:46.560
 Okay.

00:26:46.560 --> 00:26:56.560
 Okay.

00:26:56.560 --> 00:27:06.560
 Okay.

00:27:06.560 --> 00:27:16.560
 Okay.

00:27:16.560 --> 00:27:26.560
 Okay.

00:27:26.560 --> 00:27:36.560
 Okay.

00:27:36.560 --> 00:27:46.560
 Okay.

00:27:46.560 --> 00:27:56.560
 Okay.

00:27:56.560 --> 00:28:06.560
 Okay.

00:28:06.560 --> 00:28:16.560
 Okay.

00:28:16.560 --> 00:28:26.560
 Okay.

00:28:26.560 --> 00:28:36.560
 Okay.

00:28:36.560 --> 00:28:46.560
 Okay.

00:28:46.560 --> 00:28:56.560
 Okay.

00:28:56.560 --> 00:29:06.560
 Okay.

00:29:06.560 --> 00:29:16.560
 Okay.

00:29:16.560 --> 00:29:26.560
 Okay.

00:29:26.560 --> 00:29:36.560
 Okay.

00:29:36.560 --> 00:29:46.560
 Okay.

00:29:46.560 --> 00:29:56.560
 Okay.

00:29:56.560 --> 00:30:06.560
 Okay.

00:30:06.560 --> 00:30:16.560
 Okay.

00:30:16.560 --> 00:30:26.560
 Okay.

00:30:26.560 --> 00:30:30.560
 All right. I, there's no one here and I don't like any

00:30:30.560 --> 00:30:35.360
 other questions. So I am going to log out. Thank you

00:30:35.360 --> 00:30:36.560
 everyone for your questions.

00:30:36.560 --> 00:30:38.560
 [end of transcript]

00:30:40.560 --> 00:30:40.560