[om-list] OneModel

[Luke Call]

Nick,
A few more thoughts about TextAttributes (TAs):

It seems like the content of a TA can and sometimes ideally should be modeled instead of just using text.  Depends on the use and what works best, of course.  In other words, TAs are convenient (I use them for things that originated as text but which I need to store and not take the time to model) but I think they can over-used (as viewed from ideal/theory).

Specifically for the example you gave: 
> .... (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")?

...I think the TA could be done that way informally, but if the data is to be computable, it might be expressed as an entity for "thought" (or think), with attributes (including other relations as needed) for what was thought, and the validOn and observedOn dates, and/or other date attributes to suit the need, which in turn could be associated with an internal class for verbs, or a class for thoughts, whose instances express someone's own internal mental model at any given time.  Maybe this "thought" Entity (internal class instance) is an OM representation of a mental model, where OM records the expectation, or expressed/modeled future, in which there is some benefit like "pleasure" on a numeric scale.  The "thinking" instance entity also could have a numeric attribute for confidence level, which could change over time.  In other words, broken down into a full object model as an engineer might do if this were an application dedicated to that domain, to the extent that is useful.   By using internal code and classes (in the future), there can be mechanisms to automate or limit values, like a SQL database could do with constraints on columns.

All of that seems impractical for general note-taking, and I'm not sure I've ever yet used OM that way, but long-term, that is the intent of the structure, to support richer and more automatable data types, with ease of use for the non-engineer, but capability (headroom) for the engineer.

Maybe verbs could also be expressed in some other ways using the internal code, which cause or show changes in state, like some kind of mini-simulation.

-Luke

----- Forwarded message from "Luke A. Call" <luke350 at onemodel.org> -----

Date: Mon, 9 Jul 2018 16:35:35 -0600
From: "Luke A. Call" <luke350 at onemodel.org>
To: om-list at onemodel.org
Cc: Nicholas White <n.j.white at gmail.com>
Subject: Re: OneModel

(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.

----- End forwarded message -----