[om-list] organising and creating textual information

[OneModel general list]

On Sat, Apr 23, 2016 at 06:24:50PM -0600, OneModel general list wrote:
> Luke writes:
> 
> On 04/23/16 15:24, OneModel general list[from hendrick] wrote:
> > I've been thinking of doing something for information capture and
> > storage in the area of fiction writing specifically, and in general as
> > an idea organizer.
> >
> > That said, I still have no idea what your system actually *does* as
> > opposed to what you'd like it to do.
> 
> Right now, OM brings up a menu and you press letters to navigate to
> the point in your data of interest.  Then you can press 1 to create
> a new entity, by typing in up to 160 characters of text as its name.
> You can add attributes to the entity (currently a quantity or number
> with type and unit like 5 meters length, or a date, boolean, file
> (actual binary content), or textattribute (like a quotation or stack
> trace or serial #).  You can use simple menu options to associate
> the entity with other entities or group them, by defining
> relationships.  The demo video you mention in your other email would
> certainly help.  The live demo at the telnet site would let you test
> out this much and ask questions.
> 
>  (1) It has to be compatible with distributed revision control (I use
> >monotone for this, the same issues arise with just about every such
> >system, including git)
> >
> >(2) It has to be able to express mathematics.  (markdown has plugins
> >that interpret Latex, though you need different plugins if you're
> >generating html or pdf).
> >
> >If you like, I could scrounge around my file system and collect the
> >relevant ideas.  (this scrounging around is exactly what I want this
> >system for, of course)
> >
> >-- hendrik
> 
> Do you use monotone to keep backups of these .md files?

The versions in the monotone repository are the only definitive copies. 
And they are replicated onto different machines automatically.

The coppies in local workspaces are all tentative until committed.

> I'm not sure
> what to say there. OM keeps its data in postresql rows and columns,
> and there isn't currently a revision control concept in it, though
> one could be considered for the future.

I do not know how replication works in a database.  I know monotone 
uses a database for its version storage, but it has its owm sync 
protocol built on top of that, and it relies on having a complete 
history of revisions.

I started this for my writing, because I had several machines to work 
on, and often did not know which one would be available.  The contents 
would sometimes diverge, and then all changes would be merged whe I got 
the chance.
 
> I'd have to have a clearer
> idea of the use cases. I was hoping to work on "distributed data"
> (or sharing between OM instances first though, but this is worth
> discussing anyway.  I make periodic backups of my data, which works
> for me, and I haven't had to restore.  I also use .git for other
> things, like the source code, where I go back in time, but the same
> need for OM data has never arisen.  I have many notes, I navigate
> among them, and it just works, as far as that goes.  I do reorganize
> them often to save off less-interesting things, or archive
> individual entities (like marking to-do items as done) so they
> disappear from view but remain in the database.
> 
> For the mathematics, at what point in your workflow do you need to
> view it as symbols?

Ideally, while I'm editing it.

In practice, I get to see it so when I convert it to html and look at 
my local files with a browser.  There is a Latex editor somewhere.  I 
believe it's a two-panel editor -- you edit Latex in one panel and it 
simultaneously shows you what it looks like in the other.

> Currently one enters data into OM by typing text
> from the keyboard, which could include some latex, but then it will
> also display it as text when viewed. The html export could be
> modified, maybe, to convert the latex to something else to view as
> html, but I'm not sure if that helps your use case, since I don't
> know enough about your use case.
> 
> Could you describe your usage more? And comment or ask questions
> about the above? Maybe that will spur ideas.  I can think more about
> it, on Monday.
> 		
> -Luke
> 
> (ps: the fact that the list can hide senders' email addresses, which
> is good for their privacy, might make it more work to see who is
> talking in these threads, over time.  Hmmm.  A habit signing one's
> name at top & bottom could help, but is fallible or more easily
> manipulable; I realize email addresses are too, but people don't
> usually, in such a forum. Maybe there's a better approach.)

It's traditional in internet mailing lists to reveal emal address, so 
people can be contacted off-list when appropriate.  This convention was 
started way back in the 70' or 80's on usenet, long before the age of 
spam.  It *is* common to allow only list subscribers to post nowadays, 
though.

-- hendrik