A bit deeper into data, a bit of a rundown of different data structures. All items should have a creation date, modified date, agent.
A blog – text blob, author
Data logging (continuous) – sensor, name, data/datum
Data logging (intermittent, bread rising, beer fermenting) – sensor, name, project, data/datum
Quote – text blob, author, text source, character if applicable, why, id (for citing and reverse citing)
Image – creator, media, xyzt dimensions
…
Stop. This is me three days later.
I want all the days to be conflated. There will be no separate tables other than to keep who can separate from whats.
Mostly.
Let’s get a bit into the weeds. I want to be able to view the data, sorted by a range of options, filtered for a range of options, and displayed by a range of options. The first two are gimmes seeing as how this is a blog, but what about the third? This isn’t just a blog, but also a data display service. I’m sure someone could come up with other descriptors, but we’ll start there. Now most days, the number of words I might type won’t have any causal relationship when the moisture content of a given planter, but there might be a correlation between hours of sunlight and rate of beer fermentation. This wouldn’t be the ideal way to look for it, but it’d be fun to graph it that way on a lark. So how do I do this? I could either join tables, which sounds like a lot of overhead or I have one* table with all the data. Now there might be other tables, such as comments or footnotes, but even those would be almost easier to do in the following format:
- User – who posted (person or device)
- Agent – what posted, web interface, app, API, web interface to the web interface (comments)
- Time stamps – created and modified
- Contents – …
- Flags or tags – TBD
This will need to be expanded fairly quickly, but I don’t see that as a major roadblock.
Now about implementing Eliza as an interactive agent, that’ll be interesting.
* Users, and other truly different projects would be separate.