Written in scala (java platform; see below about style), using PostgreSQL. *BUT*: As of 2020, I plan to move OM to Rust, to simplify installation and for a better tool set going forward. (And considering sqlite.) The intent in OneModel is to program in a style mostly guessable by programmers with intermediate programming knowledge. Exceptions to that should be clearly commented, with the reasoning. If this does not prove to be true, let's discuss the problem and possible improvements, on the mailing list.
It is run from a script, but essentially it's "java -jar <jarname>". It's best run from a terminal window where you can expand the window size, scroll back easily, copy/paste, control the font, etc. See the Download link in the Navigation bar above for platform-specific or detailed & generalized installation instructions.
About the data internals:
Everything starts with the idea of "entity", represented by the entity
table. An entity has a name (or in the future I hope, any number of names,
with one chosen for display based on context or user preference).
(In the future names might not be required, if you can help us
understand the specific needs for that.) Names can be 160 characters
long (it just "felt" right as the length for making & rearranging rough
individual notes, without the note becoming a paragraph which goes in
a TextAttribute). In addition to attributes, entities have a creation
date, (i'm thinking of adding an edited date,) an "archived date" (which
makes them hidden from most use, which I currently use to mark off done
tasks or past calendar items: calendar items, BTW, I just write like a
to-do entry, with a quick date in a list, and sort them, then check it
each day -- which isn't ideal yet but works better than the other stuff
I've tried). Entities also can be marked as public, non-public, or null
(not specified), and data exports (to text outline or html) can filter
on those public/non.. values.
Entities have attributes, including:
- QuantityAttribute (per a Martin Fowler book), with number,
unit and type: for example, 5 meters length. Meters and Length
have to be defined as entities (not done automatically yet,
nor made sharable...maybe should be as part of sharing, or user
feedback). QuantityAttrs also have a date on which they are known
valid, and a date on which they were observed. The UI lets you use
the valid/observed dates, or ignore them by just hitting Enter for
default values.
- DateAttributes have date and type, for example
2010-1-1 and "birth", where "birth" is an entity.
- BooleanAttribute similarly has a boolean and a type, and valid & observed dates.
- FileAttribute (lets you add blobs/whatever to entities) has file
content and metadata, such as the original path and md5sum.
- TextAttribute lets you put in arbitrary text, including very long,
and I use it for paragraphs, quotes, or stack traces, but the
original intent was more to put in something like a serial #. It
also has valid/observed dates.
- RelationToEntity: link entities to each other. One can be specific and
make types (...is child of, lives next to, owns, whatever kind of
relationship...), or use the UI
quick option which is just "has" (and comes predefined in the system).
- RelationToGroup: of debatable use now, but might become more useful
when code is associated with classes. Today, groups of entities are
created when importing data from a text outline. Groups can also
have class uniformity optionally enforced.
Many conveniences are there, others could be added (sharing/distributed
instances, and better UIs are obviously big), but with some thought
when using OM, it should let you "model" just about any knowledge, at
least any that you might ever personally want to enter in an organizer
or exchange with others.
Copyright 2015-2024 Luke A. Call | OM Home
Contact (won't put you on a mailing list): comments@onemodel.org (but for replies see the mailing lists)
(Content generated selectively from a OneModel instance.)