TMRM Exegesis: Taxonometrics
In our series about TMRM we have covered so far:
- how they can be simply organized into subject maps, and what merging of proxies means and what views on maps one can produce.
Apart from the bottom proxy (remember, the one with no properties at all), there was so far no need to predefine any proxies. As soon as we want TMRM to honor subclassing of concepts and also to understand a type-instance relationship, then we are tempted to define these.
Earlier versions of TMRM did just that: they hardcoded proxies such as type, instance, supertype and subtype and then they also prescribed a way how a type-instance relationship is to be expressed as proxy. Same for a type-subtype relationship.
It turned out later that that detail was not necessary. Actually, it was then considered as even harmful as it preempts how a particular TMRM implementation would have to represent these two special relationships.
So, instead of hardcoding everything TMRM became more reticent and only defined its (formal, mathematical) expectations on the above relationships in the context of a subject map. And these expectations can be quickly summarized:
- First, the supertype-subtype relationship must be implemented in a transitive manner. So, if A is a subtype of B and that is a subtype of C, then also A is always in a subtype relationship with C. Nothing peculiar here.
- What is slightly odd, though, is that the subtyping relationship is always reflexive, so that every proxy is a subtype of itself, regardless whether that proxy is ever used as type or not. This has absolutely no impact on anything, but it makes the formalism for navigation and then later for path expression more concise.
- A similar expectation is spelled out for the type-instance relationship. That uses the above transitivity to achieve the usual if a is an instance of A and A is a subtype of B (direct or indirect), then a is also an instance of B mantra.
An implementation may choose to represent one such relationship between two particular proxies, say person and patrick as
type => person,
instance => patrick
with type and instance predefined proxies.
But again, TMRM does not actually say anything how an implementation is supposed to represent these special two relationships as proxies; or whether it does it at all.