* For me, the primary reason for having a single
namespace is not technical; it's human.  Having a
single namespace is a significant advantage for human
beings who are trying to talk with each other about
TM Models.  With a single namespace within which
every aspect of a given TM Model has a unique name,
we can speak to each other unambiguously, without
having to be painfully precise every time we open our
mouths.  We can say only "zorp", instead of having to
say "the zorp assertion type", or "the zorp role
type", or "the zorp SIDP", since "zorp" can mean only
one thing (whichever it is).  (As a standards
developer yourself, you know how hard it is to
establish an unambiguous universe of discourse.
Considering the vanishingly small price of this
"single namespace" idea, and the potentially enormous
cost of misunderstandings regarding TMs and what they
mean, doesn't the single namespace idea make sense to
you, too?)

Seriously, though. It's quite obvious that the IAM is a metamodel - a model
for defining other models - just as XML is a metalanguage - a language for
defining other languages.

What we were looking for was a word that: (1) Did suggest that the "RM"
[sic] was a member of the set of things that we call internally
consistent. "Principles" did this. (2) Did not suggest that the substance
of the "RM" [sic] was a model, because it isn't. It enables models, but is
not itself (we feel) a model, certainly as the architects of the (S)AMs
woudl think of one.
An additional advantage of principles is that they can be enumerated --
Principle of A, Principle of B, so the word enables some useful language.
"MetaModel" is noted -- but my feeling is that it suggests the "more meta
than thou" wars, and I don't want to go there.

I think there's something to be said for Steve's suggestion below of "Topic
Maps Information Aggregation Metamodel". There's more than one way to get to
that: we should remember that the full title of a standard actually has
three parts, which are normally the name of JTC1, the same of the SC, then
the name of the standard. So ISO/IEC 13250 is actually "Information
Technology - Document Description and Processing Languages - Topic Maps"
(and SGML is "Information Processing - Text and Office Systems - Standard
Generalized Markup Language"). But we can play games with that pattern: TR
9573 was "Information Technology - SGML Support Facilities - Techniques for
Using SGML", skipping the name of SC18.
So likewise, we could name the model "Information Technology - Topic Maps -
Information Aggregation Metamodel". That would get both the long name and
the short name.

Move to TM Application definition (parid0269). Question: Do we really want to get into syntax issues, such as the fields and field separators? Could simply say it must be distinguishable and let it go at that.

Extracting requirement of properties having names.

Fixing distinguishable name requirement for nodes. Perhaps should
be made more general for nodes, roles, etc.