Nicknames, alternate names, synonyms, abbreviations, and other shortcuts

The formal names for concepts such as objects, people, places, streets, etc. can be rather inconvenient or in some cases a matter of dispute. In the real world, in natural language we use a variety of shortcuts:

• Nicknames
• Alternate names
• Synonyms
• Abbreviations
• Full names that require context (e.g., city or town names that occur in more than one state or country)

In theory, with the Semantic Web we can have a single concept URI for each thing and then state axioms to equate the various shortcuts with their equivalent specific concept. Unfortunately, a given shortcut might be used for more than one concept. Some form of context or other form of additional detail must be supplied to disambiguate ambiguous shortcuts.

In the case of a user interface, a popup list of the choices can be provided and the user can make an explicit choice of the specific concept.

But in the case of a computational agent, the agent must supply the disambiguating data.

This also begs the question of how to store the graph that would describe what facts need to be detailed in order for a computational agent to choose between competing alternatives for a given shortcut. Sure, that could be application specific, but it would be a shame if each application was forced to invent its own mechanism. Possible a generic context lookup mechanism (e.g., the PostScript dictionary stack metaphor) could be defined to satisfy this need.

Then there is the question of when a shortcut should be substituted with its equivalent umambiguous concept URI. Early has some advantages, but late binding also has some appeal. Another approach would be to carry around both, possibly in the form of a special shortcut mapping which gives the disambiguated concept for direct access but also provides the orginal shortcut for porting to other contexts or display, debugging, or other forms of convenience.

-- Jack Krupansky