Token Wildcards
From MemberWiki
Tokenized topics are not inherently hierarchical. Tokens represent conceptual units and can be independent of each other. Token N+1 is not necessarily a specialization of token N.
As a useful convention that prevents conflicts in a decentralized developer community, the first few tokens a topic should specify the defining organization (as is done in packages and domains). This part of a topic space is explicitly hierarchical.
However, the rest of a topic does *not* need to be explicitly hierarchical. Tokens in this part are frequently independent of each other. In a mash-up scenario, which by its nature involves the composition of two or more types of information and may involve very different subscribers that use the same event, topics are more likely to incorporate several independent concepts. This is up to the developer/s.
Even when only one concept model is used, many topic models incorporate several orthogonal concepts into one topic, e.g.:
- Email mash-up
Email thread, sender and priority are independent /OpenAjax/abc@xyz.com/hot
- Weather mash-up
Country, region, alert class, subclass /USA/LA/weather/storm
Other examples appear here.
As orthogonal concepts appear in the same topic space, you quickly find that if wildcards are important at all, then using tail wildcards forces you to choose one taxonomy in advance, whereas support for token wildcards allows you to adapt to changing requirements without re-designing the information hierarchy and modifying every application that uses it.
This kind of flexibility is critical where mash-ups are concerned and many developers may be relying on the defined hierarchy.
In this way, wildcards do impact taxonomy design: by making it safe for designers NOT to need to know everything up front.
