[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /zzz/ - 1568



File: 1444839160492.png (271.67 KB, 212x300, tumblr_neungfeyzj1qzultro1_1280.jpg)

No.1568

Maybe this is a thread more suited for /lam/, but as I don't intend to extend that much on the programming side of it I'll post it here.

I thought this morning about building a Sqlite database interface in Python (ncurse or web-based), which could be a nice programming project and something useful for me or other dreamers.

So far my main concern is the database structure, and I would like suggestions about it. How would you organize it? I don't have any idea about something that would need more than a single table. I started with something very simple :

*Date
*Tags / Key-words
*Dream themes
*"Dream signs (don't remember how Laberge call this, but basically what signs that show we are experiencing a dream)
*Lucid or not (bool)
*Title
*Content
...

What can I add? What kind of functions can I implement?

  No.1569

File: 1444841047747.png (235.11 KB, 200x113, depth-2.jpg)

Schway idea.

Graphs would be pretty cool, like a column graph showing the quantity of instances of a certain dream theme. Of course just sorting them by number of appearances would work too. That helps a lot because that way you may see that you dream a lot about dolphins, and next time you see one you might get lucid. Isn't that what you call dream signs?
More info about lucidity could be useful, like how you got lucid, did it last until you decided to wake up, why did it end, etc.
An option to read a random dream, reading them helps remembering them.
Also date AND time of dreams.
I don't know about how to store it in the database, but it should be exportable to an easy to backup file, maybe encrypted.

>*title

Sounds fun.

Will it be free software?

  No.1576

>>1569

Very nice suggestions, thanks.

>Will it be free software?

Of course. I'll put it on my (for now empty) Github account as soon as I'll have something working.

  No.1577

>>1569
>Isn't that what you call dream signs?

Not quite. I don't have the book at hand right now, but it's a categorization of the kind of signs that make it clear that we're in a dream world. Those signs are related to self (ex: your gender have changed), the setting (ex: Your in the space), your action or those of others (ex : You're flying), etc. You can realize that you're dreaming if you spot recurring dream themes (like dolphin), but it's not always obvious and unrealistic (ex: dreaming about work or school if you're still a student)

  No.1579

File: 1444947958603-0.png (24.25 KB, 134x200, määh.jpg)

File: 1444947958603-1.png (1.33 MB, 200x103, ⁄cyb⁄ersleep.png)

>>1576

Sounds radical OP.
I find myself using pic related often myself.
A version for my main machine would be really nice to have.

If I may make a suggestion, it would be to support advanced data records or just multiple sets of time-data for one dream episode.

Why? Because in theory one could use a piezo element as a pick-up for any signals directly on the beds frame. Saw a TV documentary not too long ago in which scientists used one in conjunction with a Rigol DSO to pinpoint REM phases.

That being said, I might want to try and whip a similar setup up in GNU Octave sometime soon just to verify this claim and see where it goes.

To the organizing part, I would suggest something like this from the top of my head:
It's some bullsoykaf pseudocode but it gets the point across I recon


TABLE dream_data
//records basic dream data and has related a 1-n relationship to
//the n-m table meta_relations
{
id<primary int>,
title<string>,
content<text>,
meta_relations_id<int>,
created<timestamp>,
deleted<timestamp>)
};

TABLE meta_relations
//connects dream_data with meta_terms in an n_m relation
{
id<primary int>,
term_id<int>,
dream_id<int>,
created<timestamp>,
deleted<timestamp>
};

TABLE meta_terms
//holds any meta tags defined
{
id<primary>,
term<string>,
created<timestamp>,
deleted<timestamp>
};

TABLE dream_time
//records the specific timing records of dreams.
//a 1-n relation was chosen to be flexible when
//recording scenarios like continued dreams after
//a brief awake period
{
id<primary int>,
dream_id<int>,
time_begin<timestamp>,
time_end<timestamp>,
created<timestamp>,
deleted<timestamp>
};

//this table manages signs
//in combination with sign_reference
//the user can specify many signs for many
//dreams, is 1-n to sign_relations
TABLE sign_data
{
id<primary>,
title<string>,
description<string>,
created<timestamp>,
deleted<timestamp>
};

//connects signs to dream_data
//a dream can include many unique signs
//sign_relations is a n-m type table
//to relate to sign_data and dream_data
TABLE sign_relations
{
id<primary>,
dream_data_id<int>,
sign_data_id<int>,
created<timestamp>,
deleted<timestamp>
};




Godspeed Lainon, wishing the best of luck!

  No.1590

File: 1445014979608.png (771.58 KB, 142x200, lainoyellow.png)

>>1579
>It's some bullsoykaf pseudocode but it gets the point across I recon

That's way, way better than what i came up with. I suck at programming but I also still have to learn a lot of thing with databases.

I write that down, thanks you very much for this suggestion.

  No.2339

>>1590
Bumping up, anyone still pursuing this idea?

To get things rolling again,
currently cloning into OutWiker to test how usable it is for journaling dreams, among other stuff.

  No.2663

>>1568
I was thinking, maybe using M$ Access as some sort of back-end would be useful

Just shooting ideas