[sc34wg3] Towards TMDM 3.0

[Rani Pinchuk]

Dear Lars,

I think now we understand each other, or at least very close to that.

Lars Marius Garshol wrote:
> ...
> This is not my suggestion, Rani, but what's been the most common  
> internal model for Topic Maps engines for the past decade. Actually,  
> since the first Topic Maps engine was written. And it's been the  
> standard for a number of years now. All parts of ISO 13250, except -1  
> and -5, build on this model. As do TMCL and TMQL. And TMAPI 1.0 and  
> 2.0. Plus a number of non-ISO specifications (LTM, JTM, tolog, ...).
> 
> So changing this property is going involve a *lot* of updates. If  
> we're going to change it, we need a very good reason. Of course, we  
> could decide that changing it would be better, but not worth it. So  
> far, though, I haven't seen anything to persuade me that any of your  
> proposed changes would be for the better.

Your argumentation regarding to the history of item identifiers is a 
strong one, although I personally don't agree to it. With respect to 
data (and not software), I am not sure how much is lost (if at all) when 
a change like this is introduced. You even mention that OKS can 
optionally drop item identifiers when exporting.

> ...
>> indeed all topics have a "kind of identifier" but it is actually a  
>> subject identifier, as it is not item identifier (although it is  
>> called that way).
> 
> Actually, no. TMDM defines subject identifier as "locator that refers  
> to a subject indicator" and subject indicator as "information resource  
> that is referred to from a topic map in an attempt to unambiguously  
> identify the subject represented by a topic to a human being".
What I meant is that, as you mentioned in a previous email, the item 
identifier is used to indirectly identify a subject.

> ...
 > I really don't see any problem here. And if I *did* think this was a
> problem your suggestion would not solve it.
> 
> Imagine this CTM topic map:
> 
>    topic.
> 
> Now load it into two different TopicMap objects in the same engine.  
> That gives you two different topic items with the same item  
> identifier, even if we make the change you suggest.
> 
If you make the change I suggest, and this topic is loaded into another 
topic map, it looses its original item identifier (as it is not the same 
item anymore).

> ...
> In any case, I think you should turn your argument around. If we agree  
> that item identifiers are going to exist at all, I think you should  
> consider carefully what the benefits of making it a single-value  
> property are.
> 
> As a general rule, when two topics merge, no information is lost  
> (except the distinction between the two topics). All properties are  
> preserved. Why should item identifiers be an exception to this rule?
> 
> Remember also that XTM 1.0, XTM 2.0, and CTM all allow you to assign  
> more than one item identifier to the same topic, so this is not only  
> about merging.
> 
> Given all this, why should it be a single-value property? What are the  
> benefits of that? Yes, a single-value property requires less overhead  
> than one that's multi-value, but that's all. There are no other  
> benefits that I know of, or that you have explained. So I really don't  
> understand why you consider this change so important.

I find it that important because my colleagues and me spent hours (may 
be even days) trying to understand this. We also asked other people in 
the community for clarifications without much success.

A standard should not be that difficult to understand.

The name (and definition) of "item identifier" suggests that it 
identifies an item not a group of different items that refer to the same 
subject.

The complexity demonstrated in the last paragraph cannot be justified by 
any of the argumentations I saw so far apart from the "history" 
argumentation: the feature was included in the past and therefore must 
stay. I think that even this argument should be carefully checked and if 
it is indeed a winning argument, we have to write a clarification or a 
guideline about the issue - to facilitate the understanding of the standard.

Kind regards,

Rani

-- 
Rani Pinchuk
Project Manager
Space Applications Services
Leuvensesteenweg, 325
B-1932 Zaventem
Belgium

Tel.: + 32 2 721 54 84
Fax.: + 32 2 721 54 44

http://www.spaceapplications.com