Thursday, April 4, 2013

Protometa

Protometa - my username on Github and the beta invite code for Thinker. It's short for prototype metadata, the virtual metadata nodes that stores default values that are otherwise undefined. If a node does not have a certain property defined in it's metadata nodes, it would inherent this default prototype metadata. Whenever a property of a node is initially set, a metadata child node is added that overwrites the protometa.

Metadata nodes within metadata nodes...

Why would you want the properties of nodes to be stored as nodes within nodes? Ideally, this fractal, recursive structure makes nodes more editable and extensible.

Metadata can as complex as any other data, and since Thinker nodes are meant to be a way to navigate and edit such data, it only makes sense to use such nodes to explore the metadata as well. In this way, nested node metadata allows for manual editing of properties. E.g. you can edit the radius of a node by dragging the edge and resizing it, or you can open the radius metadata and set it to some specific value.

Also, it potentially allows for the use of data to drive the appearance of nodes, which would be a way to create custom data visualization. E.g. the radius of a node could be driven by a value which would allow you visualize it relative to others. Creating formulas to drive values is itself done with metadata nodes. It's sort of like visual scripting.

Working out formula/function syntax in nodes

But it has some major downsides. It overcomplicates many things that would otherwise be very simple, and the nested metadata nodes are difficult to query and update in the database.

In considering the new linked data structure for Thinker, specifically the idea of link node metadata, I had a happy realization. Nested metadata nodes should not be created by default every time a property is adjusted. According to the new paradigm, metadata links could be an optional addition to allow for plugging node values into node properties. This would let nodes store their own properties in a compact fashion by default while still allowing for advanced functionality such as manual override of properties, custom data visualization, and function nodes.

Furthermore, adding these metadata links could simply be a matter of adding a child node and changing the type of link that connects it. So there would be normal links with any arbitrary labels and meta links with special keyword labels that could alter various properties or provide other advanced functionality based on the values to which they linked.

Bottom line: things will be much simpler for the developer and the user without sacrificing any potential functionality.




No comments:

Post a Comment