-
Notifications
You must be signed in to change notification settings - Fork 188
Naming Topics
Name usage is always contextual, in natural language a noun binds to something in the context, a person in the room, the one mentioned in the last sentence. In programming languages we have concepts of nested naming contexts in which variable names are bound to language objects.
The design goal here is simple and easy to understand, so looking to natural language patterns will be important, but we will also want precision and consistency in the face of potential ambiguity.
Probably the client tools should help automatically supply or guess the context and resolve ambiguity with user interactions if necessary.
In Wagn, a name is a sequence of simple names, which is similar to a file system path. In a file system each node is either a directory (set of other nodes) or a file (data, or a blob in git terms), but in Wagn each name identifies both of these options. Some Wagn cards are like files, just having content and no sub-nodes, and some are like directories in having no content (Wagn actually creates these nodes with blank content, but it wouldn't have to).
In today's (2/29/12) call there was some talk of permanent identifiers. Any method to assign an id that is unlikely to collide will do, Wagn just uses the Rails ActiveRecord model id's for the Card objects, and we have a notation (I think it is /#999, but I'd have to check), or you could use the Purple Number of the first item in the page, anything that you won't change later.
A Purple Number could track it through movement in the federation and through modifications by multiple authors. If you created a "context free identity" for the entire wiki instance (maybe the Identity of the initial page?), then that plus a page identifier from the instance context would work similarly. I think Engelbart thought it was important that these identifiers be universal and not bound to and site.
Having these identifies allows for the names to be changed without breaking references. In Wagn it actually updates all the references that are stored as names such as links and transclusions. Obviously in a federated system, the original name cannot be relied on for external, permanent references unless you can track names changes at the source.
One more concept that we have found useful in Wagn is the idea of a "codename", that is a name that is used to reference a card (page) in the code. These are separately bound to the instance identifiers for specific pages.
I think this wiki with it's base JSON representation for a page could benefit by stealing these two concepts from Wagn. In Wagn we say, "Everything is a card." So similarly, we would have "Everything is a page" So just as with Wagn where a Card has a Cardtype which is another Card. Here, a Page has a Type which is a Page (JSON) and a Type Type Page is where you define a new type.
We have a "Basic" cardtype which is some limited markup plus Wiki links and inclusions, and this wiki can have something similarly simple for the default page type. It is here is defining page behavior and style that you will find segmented names of interest as well. Wagn defines searches based on types and name patters, and then more recent enhancements use these search defined sets as the basis for defining behavior(permissions, views, actions and more) selectively.