Therefore, use a set for context. For instance, "tree as used in maths and computer science" has maths and computer science as its context, with no arbitrary ordering of the two. This creates a lattice space, as set containment is a lattice structure.
When a reference must be disambiguated, the definition chosen should be the one with the smallest context that covers as much of the context of the reference as possible. If this does not distinguish between several choices, their common root definition should be used.
But, this class of namespace is almost non-existent in computer systems to date, and its disadvantages are not known. Further, any adopter will have to educate their users; in contrast, every computer user is exposed to a hierarchic namespace on their desktop, and can be expected to understand it without explanation. Fortunately, a LatticeSpace degrades to a flat NameSpace if no contextual definitions are ever made.
In words: the disambiguated context is the intersection of all defined contexts X that satisfy a single criterion: for any defined context Y, the intersection of X and C is not a strict subset of the intersection of Y and C.
If there are no defined contexts, the original reference should be used unchanged.
PeriPeri implements a LatticeSpace in a Wiki; however, the algorithm it currently uses is incorrect in some cases of ambiguity.
I'll take a chance by commenting, if only to break the "deafening silence"...
I certainly agree that Context is critical when a word may have more than one meaning, and I appreciate that set theory can be used to select a disambiguation method. However, I can't help but feel that the more familiar Key Word In Context algorithms I've come across before might be a bit easier to implement.
I'd be happy to try to say more, but I'm not at all sure where this is headed so I am reluctant to divert it. --HansWobbe.
Syntax. I had the necessity to invent a syntax of context. After some experimentation it seems best to add a context tag after the word, so one could write "gift~en equals Geschenk~de" meaning "the word 'gift' in English means the same as the word 'Geschenk' in german". One could also write about tree~el (common everyday language), tree~biology, tree~math, tree~cs or even tree~math~cs. Alternative syntactical forms like "math:tree" or "tree.math" turned out to have disadvantages. -- HelmutLeitner
(1) It collides with wiki namespace syntax. (2) It seems less readable. (3) The plus '+' is an especially bad character in the Browser/HTML/regex context. -- HelmutLeitner
I even have a wiki cluster in use where the namespace syntax is/was used for multilingual work. If you use it that way, its fine. But if you don't have such corresponding namespaces, the namespace syntax will get in the way (collide with InterWiki names, costing performance looking up potential links, ...). Just try it in practice. The '+' character is used as a replacement for the space character in URLs. -- HelmutLeitner
In this [experimental dictionary setting] namespaces exist for natural languages and for a semantic minimal language. You can see how they link, exactly in the syntax you suggest. The namespaces are implemented as separate wikis using InterWiki links. So the "context syntax" and the "automatic link generation" correspond. But if you use the syntax En:house or De:Haus here at meatball or in most other wikis, no link is generated, but the interwiki regex pattern will be triggered ineffectively, so this is costing performance. There is also an overlap of the "namespace of languages" and the "namespace of interwiki abbreviations", so if you need a "MathCs?:tree" as a language context you couldn't have MathCs? as a interwiki abbreviation (that's what I call a potential collision). -- HelmutLeitner
See also: Some IBM folks have come up with a faceted search, although I'm sure this is not a new idea. See  for a beta demonstration. Click on the 'Search' tab. You can narrow your search by predetermined categories.