Problem
Sometimes an application’s ontology needs to be flexible enough to accommodate changes over the lifetime of a DHT. A Symbol Anchor is unambiguous and strongly typed, but can’t adapt to changes without modifying the DNA and forking the DHT. An Anchor Tree, on the other hand, is better suited for hierarchical taxonomies such as shopping categories, rather than application-level ontologies.
Sometimes a DNA may also wants to expose its ontology to clients that are capable of ‘discovering’ ontologies they don’t know anything about. One could add a zome function to the DNA that gives this information, but this creates extra work and is vulnerable to non-standardised and incompatible implementations.
Solution
Create a simple anchor tuple that consists of two strings. With this tuple, you can create a hierarchy of anchors that is shallow but sufficient for representing your app’s ontology. All ‘base types’ of your ontology are anchors that radiate from a ‘root anchor’, and all instances (if applicable) radiate from their base type anchors.
Implement
Your anchor type should consist of two strings, the latter of which can be left blank. The first value is the ‘type’, or parent anchor, of an anchor, and the second value is the