SoylentNews is people
SoylentNews
Emacs org-mode is very powerful tool for personal knowledge management, but can be hard to learn, makes it hard to have the same content (notes) referenced in more than one place, and can be awkward for the hands. Finding other tools inadequate for various reasons, I wrote OneModel to meet my own needs, and made it available. If you touch-type, it is extremely fast for to-do lists and notes of all kinds, and I generate the project web site from part of its data. It is much easier to learn and faster to navigate than emacs, and you can have the same content in as many places as desired, without duplication.
But it wants to be more: It uses an internal structure that has big future ideas for knowledge management, like embedding code within groups of entities, or linking across OneModel instances, so you can choose to share data from your personal organizer, or subscribe to (or copy) data from other instances: like a wikipedia but where the internal knowledge is structured so can be used for computation, rich queries etc. Imagine asking a system: what villages in history had economic improvements in a 4-year period, all external conditions being equal, and what do those cases all have in common?--that is the long-term vision of the system. The vision and internal structure are intended as be a prototype of a platform to manage all mankind's knowledge as a usefully computable whole.
The web site has a few screen shots (remember it's an ugly prototype but works well! -- I have my calendar/life notes/todos/contacts etc in it now) and a demo system to play with without installing anything.
(It is written in scala, using a simple/approachable coding style that should be readable by most programmers with just minutes of scala knowledge--I hope--and uses postgresql for the data.)
I frankly don't mind if someone else takes the ideas and does a better job with them: we can do better than managing mankind's knowledge in the form of huge sophisticated piles of words: words are not the real knowledge but a superstrate over it, and they are hard to compute well. Feedback welcome.
(Score: 2) by hendrikboom on Saturday April 23 2016, @05:43PM
Just getting a tech writer isn't enough if the tech writer doesn't know what to write. The skill of a tech writer is in organising and presenting information clearly, not in figuring out what the information is.
Wandering around your website, it looks like a mind-map listing the things you'd like an information-organizing system to do. The kind of things a marketing manager would want customers to believe, not the kind of thing a technologically-inclined person would want to understand in depth.
It doesn't explain its architecture or its engineering except to mumble something vague about objects and relationships.
I did sign up for the mailing list, by the way, hoping I might end up learning something definite.
-- hendrik
(Score: 2, Informative) by lcall on Saturday April 23 2016, @06:14PM
Thanks, especially for your candor. I accept your comments about the site. Your being on the regular list (not just announcements) would let me ask if my later improvement efforts help enough. Feedback is something the project has really needed.
How is this for an initial description of the architecture (beyond the "About" page then "what it is today" link, which mentions simplified scala and postgres):
- everything is an "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). 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 entity, with a quick date in a list, and sort them, then ck 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 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, which the UI lets you use or ignore by just hitting Enter.
- 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, including the original path and md5sum, and other metadata.
- 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.
Not many conveniences are there yet (sharing/distributed instances, and better UIs are obviously big), but I think with some thought when using OM, that should let one "model" just about any knowledge, at least as much as what one might ever personally enter into a system.
Details on the data are in this file: https://github.com/onemodel/onemodel/blob/master/src/main/scala/org/onemodel/database/PostgreSQLDatabase.scala [github.com]
What else about the architecture would help?
Do you think I should put material like in the "About" / "what it is today" / "internals" page, or refactor those & put it somewhere else, or neither?
(Score: 2) by hendrikboom on Sunday April 24 2016, @12:36PM
Yes, this presentation helps. It should be in the "about" page. It says what the conceptual model is. It could even be what everyone here is asking for. The demo version gives me not a clue what's going on. I think I need this information just to understand what the screenful of instructions mean.
-- hendrik
(Score: 0) by Anonymous Coward on Monday April 25 2016, @02:47AM
Personal pet peeve for information management systems like this:
Why must everything be named? Anonymous entities/content can sometimes be a godsend, especially when dealing with "indexed data" which only really differs by the index value.
(Score: 1) by lcall on Monday April 25 2016, @06:10PM
I agree. This probably should be accounted for in OM when there are use cases (with users) driving the priority.
Because all the conveniences aren't in OM yet, sometimes I cheat just by putting whatever is the info, in the entity name. But that doesn't lend itself to computability long-term and isn't a good practice once the ability to use code or have object templates is in place.