parid0235 | 31 Dec 2002 09:15:27
* 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?)
parid0235 | Tue, 31 Dec 2002 17:24:00
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.
parid0235 | Tue, 31 Dec 2002 11:27:43
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.
parid0235 | Tue, 31 Dec 2002 13:02:23
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.
parid0235 | Wed, 26 Feb 2003 09:49:00
Each property has a name that is unique, within the TM Application, among all the names of the properties, assertion types, and role types defined by the TM Application. In a topic map graph, however, property names may be defined by multiple TM Applications, so different TM Applications may define the same property name. Therefore, each property name consists of two fields, separated by the field separator symbol defined in parid0442 Ed.Note 55 The first field is the name of the TM Application itself, and the second field is the property name which is unique within the TM Application.
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.
parid0235 | Wed, 26 Feb 2003 09:49:00
Every property of a node is required to have a name.
Extracting requirement of properties having names.
parid0235 | Wed, 26 Feb 2003 09:49:00
The name of a property must be distinguishable from all other property, assertion type, role and node names.
Fixing distinguishable name requirement for nodes. Perhaps should
be made more general for nodes, roles, etc.