[sc34wg3] The role of the RM [was: Let's revert to N323!]

[Patrick Durusau]

Steve,

Steve Pepper wrote:

> At 06:39 04.02.2003 -0500, Patrick Durusau wrote:

<snip>

>
>> The RM should be part of this multipart standard.
>>
>> ...
>>
>> Reasons:
>>
>> The RM is designed to define the essence of what it means to be a 
>> topic map and provides a heuristic device for evaluating topic map 
>> models and topic maps separate and apart from any particular data 
>> model or implementation or instance of a topic map. (If anyone 
>> disagrees with this assessment, it would be helpful if you could 
>> point to the parts of the RM that you read as supporting some 
>> contrary view. I am aware that contrary views exist, but they do not 
>> appear to be based on reading of the RM but on other grounds. That 
>> appearance could be resolved by citations to the RM.)
>
>
> I disagree with the assessment because:
>
> (1) I don't see how the RM can define the "essence of what it means to 
> be a topic map" when it doesn't concern itself with *any* of the 
> things that are central to ISO 13250, such as topics, associations, 
> occurrences, etc. ISO 13250 defines the essence of topic maps. All 
> that is missing is a formal data model, i.e. the SAM.

ISO 13250 defines interchange syntaxes, which should not be confused 
with "the essence of topic maps."  That the RM does not use names 
incorporated in an interchange syntax is not much of a basis for 
claiming it is about something other than topic maps.

The question of the missing formal data model presumes that a single 
data model is sufficient. That is a position that I noted several posts 
ago is simply unsupportable and cited historical cases in computing 
where that view has caused problems.

>
> (2) It cannot provide a "heuristic device for evaluating topic map 
> models" because there is only one "topic map model" - the SAM. SC34 
> has no intention of standardizing other models and should be promoting 
> its own rather than indirectly encouraging other, non-standard models.

Some people might like to think there is only one "topic map model" and 
they are entitled to that view. Whether such a limiting view of topic 
maps should be enshrined in ISO 13250 is another matter. I don't think 
anyone can speak for the intention of SC34 so I will leave the balance 
of this paragraph unanswered.

>
> (3) No real business requirement or industry demand has been put 
> forward for the RM.

Well, I would think drafting good standards would be a requirement. 
Perhaps not as commercially appealing as promoting a particular brand 
but still an important consideration. Both HyTM and XTM were 
successfully drafted because the original principals were still involved 
in the effort. Having a good description of all the aspects of what 
constitutes a topic map would be a useful thing for topic map models.

As far as business or industry requirements, I have yet to see any proof 
that the limited range of experience by topic map implementors is 
representative of the requirements of any business or industry. It is 
one thing to imagine that a one size fits all solution exists, it is 
quite another to make it a normative standard.

Just because we cannot see the future (or even all of the present), 
doesn't mean that it does not exist.

>
> That is the basis for my belief that the RM should not be part of the 
> Topic Maps standard. It is an interesting academic exercise that may 
> lead us beyond topic maps at some point in the future and could 
> therefore be a project and work item in its own right. But it will 
> take time to mature and it should not be allowed to delay finalization 
> of the data model that is required in order to move forward with topic 
> maps in the real world.

Despite our obvious disagreement on the issues mentioned above, the 
final one is where I am the most puzzled. How will the RM delay the data 
model? The reason I ask can be illustrated as follows:

***Artificial universe follows***

RM here consist of:

Definition of integers

Definition of addtion of integers

SAM here consists of:

The data model of the Jave programming language

Topic Map consists of:

int numWGs = 2;

int numSCs = 4;

numWGsSCs = numWGs + numSCs;

***End Artifical Universe***

As you can see, a formal definition of integers is not really necessary 
for the Java programming language to be built. As a matter of fact, that 
two interchange syntaxes were built in the absence of both the SAM and 
the RM, casts more than a little doubt on why one has been seized upon 
as more important than the other.

It has often been the case that systems have been built without a firm 
theoretical basis, steam engines for example, but better steam engines 
were build after a firmer foundation in thermodynamics was esablished.

It would be helpful if you could say "why" the RM would delay the data 
model rather than simply making the statement. All I have seen so far, 
and there may have been posts that I have missed, have simply had that 
statement and no more.

I appreciate your candor as it sets the stage for at least addressing 
this issue and the placement of other parts of the standard, when we 
reach London. I will respond if anyone has any substantive points to 
advance but prefer to use the time between now and May to help insure 
there is a visible answer to Steve's concerns and not a theoretical one.

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps