[sc34wg3] Towards TMDM 3.0

[Lars Marius Garshol]

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

Good. :-)

> 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.

If the change is a beneficial one it may be that not much is lost,  
apart from stability, which is important in and of itself. And then  
there is of course all the work that needs to be done...

> What I meant is that, as you mentioned in a previous email, the item
> identifier is used to indirectly identify a subject.

Sure. And nothing can change that. Even if we make [item identifier] a  
single-value property and add the rules that you propose you can still  
use them to refer to a subject.

> 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).

I'm afraid not. Imagine this:

[larsga at 217-14-5-186-dhcp-osl java]$ jython
Jython 2.2.1 on java1.5.0_16
Type "copyright", "credits" or "license" for more information.
 >>> from net.ontopia.topicmaps.utils.ctm import CTMTopicMapReader
 >>> from java.io import File
 >>> tm1 = CTMTopicMapReader(File("tst.ctm")).read()
log4j:WARN No appenders could be found for logger  
(net.ontopia.products.license.LicenseKeyManager).
log4j:WARN Please initialize the log4j system properly.
 >>> tm2 = CTMTopicMapReader(File("tst.ctm")).read()
 >>> tm1 == tm2
0

Do you see what I mean? There are two representations of the same  
topic map in the same process. Obviously there will be two different  
Topic objects. There is no merging; the two topic maps are completely  
independent.

A huge number of variations on this are possible (different processes;  
different machines; adding the identifier via the API instead of  
loading a file; etc etc etc), all of them sharing the end result: two  
different topic objects with the same item identifier, with and  
without your proposed change.

> 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.

No, I agree. If we can do something to make it easier to understand we  
should consider that.

> 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.

It seems to me that if we change the definition from:

"An item identifier is a locator assigned to an information item in  
order to allow it to be referred to."

to:

"An item identifier is a locator assigned to an information item in  
order to allow it to be referred to within a single topic map."

the problem would be solved. No?

> 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.

To be honest I'm not entirely sure what needs to be clarified. In  
general, ISO does not write clarifications, only amendments to  
standards. We could do something like the proposed change above.  
Personally, I think it just expands the definition unnecessarily, but  
your experience suggests that maybe I'm wrong.

However, it sounds like you are thinking of a separate document.  
Nothing prevents others than ISO from writing such things ...

--Lars M.
http://www.garshol.priv.no/blog/
http://www.garshol.priv.no/tmphoto/