snipspace structure

Snipspace has structure imposed in three ways:

• magic snip names
• namespaces
• labels

The latter two should be sufficient for all purposes, even allowing for alternate snip content. Allowing creeping magic gives the illusion of structure that collapses in complex spaces.

(Victor Volle, Nov. 13. 2004): Currently neither Namespaces nor labels are consequently supported:

• Adding labels, expecially Category or Type Labels, is rather cumbersome.
• Namespaces allow multiple Snips with the same name (e.g. "wiki.css"), but the index does not yet support this: there is only one "wiki.css" in the index or one Snip called "test namespace" even if there is more than one Snip with this name.
• "Moving" Snips, i.e changing its "parent", is currently not possible. When using Namespaces, it would be necessary to change all Snips that reference the moved Snip. When using labels, you just have to change the label (see relationship-macro)
• Namespaces allow to have a hierarchy where one level might not be represented by a Snip, e.g. "start > SnipSnap > themes > SnipSnap > css > wiki.css", so what are namespaces? Snips? Names? (And it internally leads to horrible code when dealing with these levels)

That leads to the question, what is to be achieved with Namespaces/Labels? What are the "requirements"?

1. Which structure to impose (hierarchical, graph-like, brain-like)?
2. Is it desirable to have multiple Snips with the same name in different "contexts"?
3. Does it make sense to have only one parent (see the discussion in relationship-macro)?
4. Is a single hierarchy/taxonomy sufficient? I might want to list all my books in SnipSnap and organize them by topic, by author (that would make it necessary to have multiple parents/labels of the same kind).
5. (please add your own questions/answers directly here (with date and name)

See also dated snips, snip types, UsingNamespaces.