Donate | Contact | Search
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-2021 Luke A. Call | OM Home
Contact (won't put you on a mailing list): firstname.lastname@example.org (but for replies see the mailing lists)
(Content generated selectively from a OneModel instance.)