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.
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.
Every property of a node is required to have a name.
Extracting requirement of properties having names.