[om-list] OneModel

[Luke A. Call]

(Quoting with permission.)

On 06-17 16:36, Nicholas White wrote:
> Hi Luke - I raised PR #2 to document my attempts to get OM running. I'm
> evaluating systems that store notes as graphs of connected text, as my
> current approach (big or many markdown files and `grep`) makes it hard to
> follow a single theme. I like OM's keyboard based approach to quick data
> entry (important when taking notes!), and am willing to spend time bolting
> on a visualization website (e.g. using http://js.cytoscape.org, to get
> something like
> https://metacademy.org/graphs/concepts/deep_belief_networks#mode=explore)
> to share my notes with others.

Hi Nick, thanks for the pull request and the chance to discuss OM.  If OM is useful to you, I'm very glad.  Sorry I'm sometimes slow to respond.  Don't let me block you.

Does it work better for you (or anyone) if lines are limited to 72 chars, as is true on some lists?

I've not yet become a fan of javascript, maybe due to its abuses, but some people and features would certainly benefit from a graphical and web-based UI.  There is an html export OM feature, but of course nothing at all like what cytoscape does.  I much prefer technologies with staying power, and of course openness and other virtues, which maybe cytoscape has judging only by wikipedia and those links.  (Looks impressive.)

Are you thinking of making that a separate project, or like a module inside OM?

> OM is a good foundation for this, although your vision for the future is a
> bit different (you seem to focus more on making the resulting graph
> computable), whereas I'd care more about making linking information easier
> (e.g. if I want to reference an Entity in a TextAttribute), and making
> connections between Entities I'm reading about more obvious.

Could you describe use cases to help me understand that?

> With that in mind, I was hoping you could talk a bit about some of the
> design choices you've made with OM:
> - Why do Groups exist as a first-class concept, instead of organically
> arising from Entities and is-member-of relationships?  Do you think of
> groups as a way of tagging information (e.g. a group for
> People-I-Should-Call-On-Monday), or did you concieve them as a way of
> representing an existing organisation (e.g. a company's org chart).

Currently, my use of OM is better when they organically arise from relationships as you describe.  I thought I would use groups more, much sooner.  Possible YAGNI..?  But an example use-case I have in mind is to-do lists or anything homogeneous:  by putting them in a group some uniformity can be enforced (internal class), and code can be, I'm guessing, more usefully-associated with them, such as to move an entry forward one week, or "display me" logic specific to internal OM classes (someday).  I use OM internal classes now to quickly create an entry for a person or organization (like a company whose phone # I want to remember), and I can go back later and use OM to add standard attributes to flesh it out more consistently.  Plus some things just make seem to be groups--an attribute sometimes is, in real life, a group of things. Like, stair steps.  Or documents, or feathers on a wing.  And to link each one individually seems potentially very cluttering.  But more importantly, I hope that by trying both over time, especially with more future features, it can emerge which is more useful for what.  Best practice might turn out to be what you describe (and I hope best practices can becomes shared via OM itself someday.) 

> - In OM's object model, links are lightweight (i.e. can't have their own
> attributes, apart from the built in valid-on, type & observation-date
> ones). Why is this (in particular, how would you represent a knowledge
> graph of: Entity: "Me", Entity: "Very Cold Sea", Link Type: "Swam In",
> TextAttribute: "thought it was a good idea at the time")?

(Yes, Oregon...)

Maybe I'll remember more about verbs later, but in the above spirit of "what works and is like reality", I could see either creating a relation type, or if it needs attributes, an Entity for the event and link both other entities to it.  Events could be an internal class, with standard attributes that do whatever is useful for them, and can then be used in internal code.  To me, if it needs attributes, it is an entity, and can be related in any way.  Otherwise seems like conceptual duplication.  Always open to better ways, with integrity.

> - More of an implementation question: why is "relationtoremoteentity" a
> separate table, rather than just tagging each Entity, Relationship, &c.
> with a home-instance foreign key?

If I were going to redo that part or refactor it now, I might make a separate table for each of relationtolocalentity and relationtoremoteentity, instead of tying them closely with Entity in the code.  

But I think I didn't add such a key because most data at the time was local, and wouldn't have need of such a key.  So, wasted space?  Everything could be done better.  If I spend some time pondering the data structure and commit comments from that time I might remember more, if it is important.  :) 

> - Why does the idea of a class' "defining_entity_id" (and associated
> template Entities) exist?

See above description of filling in things from a class.  Like, for an organization, there are many things I use (kinds of contact info, interaction log, interaction ideas, etc), but not always.  And it's easier if they can be consistent when I want, and partly ignored the rest of the time.  And when the internal code features are in place, I have imagined that that template could have default values for instances that haven't filled them in for themselves.  But again there are always better ways, goals including to model reality very well, be maintainable and useful.

> Thanks for your work on OM -

Again, if it is useful (and even better, if it can live and become more useful), I am very, very glad.