As an editor of the TMRM (Topic Maps Reference Model) I feel compelled to point out the TMRM is not a universal information space.
I bring up the universal issue because someone mentioned lately, mapping to the TMRM.
There is a lot to say about the TMRM but let’s start with the mapping issue.
There is no mapping to the TMRM. (full stop) The reason is that the TMRM is also not a data model. (full stop)
There is a simple reason why the TMRM was not, is not, nor ever will be a data model or universal information space.
There is no universal information space or data model.
Data models are an absolute necessity and more will be invented tomorrow.
But, to be a data model is to govern some larger or smaller slice of data.
We want to meaningfully access information across past, present and future data models in different information spaces.
Enter the TMRM, a model for disclosure of the subjects represented by a data model. Any data model, in any information space.
A model for disclosure, not a methodology, not a target, etc.
We used key and value because a key/value pair is the simplest expression of a property class.
The representative of the definition of a class (the key) and an instance of that class (the value).
That does not constrain or mandate any particular data model or information space.
Rather than mapping to the TMRM, we should say mapping using the principles of the TMRM.
I will say more in a later post, but for example, what subject does a topic represent?
With disclosure for the TMDM and RDF, we might not agree on the mapping, but it would be transparent. And useful.
Regarding the “data model”: TMRM defines proxies consisting of key/value pairs and it defines legends. That’s a data model, imo. Without the data model the query (path) language wouldn’t be possible.
> Rather than mapping to the TMRM, we should say mapping using the principles of the TMRM.
Okay, if this is seems to be a wording issue. A mapping could also be a TMRMish view on an RDBMS to use the path language defined by TMRM. The creation of the “view” would be the mapping acc. to my understanding. I don’t mean with “mapping” a “physical” translation from one data structure to another data structure.
Comment by Lars Heuer — November 25, 2010 @ 5:00 am
I think we seriously disagree about what “data model” means.
If key/value pair can be everything from ‘name=”patrick”‘ to ‘topic map=”dataForTopicMap”‘ I don’t see how the TMRM has defined a data model.
To my mind, a data model has to define at least one key, which then constrains the value that may appear with that key.
The TMRM has not defined any such keys.
Yes?
Nor does it define any legends.
You may be right that the path language is based on an implied assumption of of a data model. But it isn’t an explicit data model.
Not a wording issue, goes to the crux of the TMRM.
I really don’t understand the seeming obsession with having a “data model.”
Understanding what subjects are represented in a data model, which enables mapping between data models seems more important to me.
But as I may have said elsewhere, to paraphrase Nietzsche, “I am not bigoted enough for a data model. Not even my own.”
Comment by Patrick Durusau — November 25, 2010 @ 5:22 am
This is a much-needed clarifying conversation. Sometimes, whatever seems most obvious is in fact a major source of confusion. At the risk of adding to the confusion, I now belabor the obvious:
We see in a thing exactly what we’re looking for.
An implementer looks at TMDM and sees “information items”, with the all the traditions and implementation guidance that the term “information item” carries, as well as the details about each of TMDM’s classes of information items. She says to herself, “Hmmm, OK, that’s nice. I wonder what TMRM says.”
Then she looks at TMRM, STILL LOOKING FOR IMPLEMENTATION GUIDANCE, because, remember, she’s an implementer, and that’s what she’s looking for. And while she finds much less implementation guidance than she found in TMDM, she still finds some. She finds, as Lars Heuer points out, ‘key/value pairs’, sets of which can comprise ‘subject proxies’. Although the term ‘subject proxy’ is not defined as an “information item”, or even as an “object” — terms that *would*, if used in TMRM, unarguably constitute implementation guidance — she nevertheless sees these terms as implementation guidance. Where she sees ‘subject proxy’, she reads “object”, because that’s what she’s looking for.
It doesn’t matter to her that ‘subject proxy’ is emphatically NOT intended to be read as “object”.
Precisely because she thinks of herself as an implementer, it may be very difficult for her to understand the TMRM in the spirit in which it is written.
She can be rescued from her buttoned-down thinking when someone demonstrates for her an implementation in which no object classes correspond to the notions of ‘key/value pair’ and/or ‘subject proxy’. But she will likely then ask, “What use is the TMRM?” Her indignation is normal and natural, because, in general, human beings have difficulty understanding the answers to questions they have not asked. Implementers don’t often ask questions of the kind to which TMRM is an answer, because such questions have no obvious connection (at least in their own minds) to the profession of implementing information systems.
If TMRM is the answer to a question that she didn’t ask, what, then, is that question?
There are many ways to formulate the question to which the TMRM is designed to be an answer. Here’s a formulation that I hope will lead open-minded, curious, humanistic implementers to be more sensitive to the nuances and profundities of TMRM:
“What can be done to systematically ameliorate the negative impacts of the Curse of Babel?”
Here’s another formulation, adapted from an early draft of Yuri Rubinsky’s “SGML: The Movie”:
“If I send a message to an alien culture, how can I reduce the possibility that they will think it’s toast and mistakenly eat it for breakfast?”
Comment by Steve Newcomb — November 25, 2010 @ 8:58 am
Whups, I omitted something important about:
“What can be done to systematically ameliorate the negative impacts of the Curse of Babel?”
The Curse of Babel is inherent in the miraculous ability of human beings to communicate with each other symbolically.
The Miracle is that we invent ways of saying things. We *must* do this every time we have to say something that hasn’t been said before. And we do it on many other occasions, too. The people who do it exceptionally well are called “poets”.
The Curse is that the number of ways of saying the same thing is always increasing, and this increase has been going on throughout recorded history. One of the many dreadful side-effects of the Curse is religious warfare. Another is the recent loss of a Mars probe. Airplanes have run out of fuel for the same reason.
Every human being “knows” the answer to the problem. The answer is always to invent another language, and to get everyone else in the world to adopt it. We have a name for the class of all instances of this widespread conviction: they are all “Esperanto fantasies”. (In very rare cases, they actually take hold for a while, but such cases are both exceptional and temporary; the Babel Curse guarantees constant degradation of their “universality” and their ultimate demise.)
With all that in mind, let me clarify the question that’s at the heart of TMRM as follows:
“If inventing yet another language only increases the number of languages and therefore only amplifies the Curse, what’s the alternative? What can we do to increase human understanding *without* inventing yet another way to say the same things? What can we do to *reduce* the number of languages we need to know in order to communicate accurately with everyone else?”
TMRM attempts to show a way. And that’s why Patrick and I both bristle whenever someone implies that TMRM is yet another language. That’s the exact opposite of its intent and purpose.
Every data model, after all, is nothing more or less than yet another language.
Comment by Steve Newcomb — November 25, 2010 @ 9:26 am