Generalize SmSn graph elements

[joshsh]

Currently in SmSn, everything is an Atom, or a set of Atoms. An Atom has a (possibly empty) list of children, a title, and a number of other properties. It is untyped. Children are ordered. These were very deliberate design decisions 12 years ago, before it was clear how SmSn might incorporate strong schemas without compromising rapid, stream-of-consciousness editing. I specifically did not want to force users to choose between creating a Person atom, a Book atom, a Dog atom, etc., then to be constrained to selecting properties supplied in a predefined ontology. However, APG and now LambdaGraph offer a reasonable middle ground in which a user can define graphs which combine strongly typed elements with untyped ones -- or rather, with elements of one particular, distinguished type which would be equivalent to the current Atom (only without ordering on children) and others such as a wikitext type (embedding untyped links into Markdown or another language).

This change, on its own, will require a major rewrite of SmSn -- which is why it hasn't been done yet, despite obvious advantages.

cc @jmatsushita

[JeffreyBenjaminBrown]

What will you do about note order in SmSn v2? Do you not need it? A lot of my notes are ordered -- by preference, or as instructions, or by recency or priority.

Hode doesn't use ordered types either, and the solution I implemented there was to let the user create transitive relationships like "should be done before" or "is more important than", and let them sort a collection of nodes accordingly. (In fact they could sort by multiple criteria.) In that case, though, the user needs to tell the system that a relationship is transitive before they start using it, so that it can prevent them from creating cycles.

It was damn hard.

[joshsh]

Perhaps I should not have been so quick to say that ordering on children will be dropped. Ordered children will likely be retained as a legacy feature because we already have these graphs which use them, but I would like to de-emphasize ordered children in the future, replacing them with one of: 1) wikitext, which is naturally ordered, and 2) typed elements, which may contain list-valued fields. Those atoms in which the ordering of children is not relevant, I would rather express through child->parent relationships, rather than parent->child ones. The parent->child relationships can then be inferred, and also ordered if necessary using a total order on atoms which the user specifies. E.g. if you are ordering events, it is natural to do so based on a timestamp or time range.