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
