Ingredients:
The notion of fluid roles than can be resolved to specific items can be applied across a surprisingly broad range of domains. The resolution process generally involves using contextual constraints to pin down the exact item filling a given role. Here are some examples: the role of head-of-state in any democracy can always be resolved to a specific person but usually changes every few years after an election; the 49ers home stadium is currently Candlestick Park (or whatever its being called these days) but if they were to move to another city then that role would start being filled by different stadium; noon is a time of day whose absolute position in time depends upon the timezone in which it is resolved; independence day is a holiday that falls on a different day in every country that celebrates it and doesn't even exist in some;
The process of disambiguating roles seems to involve the application of constraints in a recursive manner. For a given role, we can know in advance the constraints required to resolve it. However, some of those constraints may themselves be defined by other roles, which would have to be resolved first. As long as we can define a dependency tree for this purpose, resolution should be straightforward. Sometimes this may not be possible because a pair of roles may have mutually dependent constraints. Usually this can be avoided when constructing the tree if some of the problem roles have multiple options for their constraint set. Sometimes, however, resolution may have to be performed iteratively.
The advantage of using fluid roles instead of fixed values is that you don't need to manually update anything when the value assigned to a particular role changes because it can be dynamically resolved as needed. This is the same principle behind the use of DNS to resolve unchanging domain names to potentially volatile IP addresses.
| ← Previous day | (Calendar) | Next day → |