[sc34wg3] Removing added scope from <mergeMap>

[Mason, James David (MXM)]

I'm with Kal and Steve on this.=20

There are times when I use <mergemap> as a simple file include like the =
troff
".so" directive, when I am trying to do something with my file
modularization. Then the results of merging probably don't need to know =
where
they came from.

But one of the original goals of developing TMs was merging indices. =
Then
it's of critical importance to know where things came from. It's all =
part of
scholarly accountability to know the provenance of concepts. So if =
merging
destroys that, it destroys one of the main reasons for having TMs in the
first place.

(If you don't think knowing the sources for things is important, go look =
at
the recent controversy over the lies inserted into the Wikipedia article =
on
John Siegenthaler. I've known John since back in the '60s, and I knew =
those
things were wrong, but lots of people couldn't have known that someone =
had
been messing with his bio.)

Jim Mason



Steve Pepper in reply to Kal:
* Kal Ahmed
|
| 21, 23, 19 and 42 are mathematically concepts that are not (normally)=20
| disputed 2+2 is always 4. Most topic maps consist of assertions that=20
| *can* be disputed and there are very real requirements for being able=20
| to distinguish what Party A asserts in their topic map and what Party=20
| B asserts in their topic map both pre- and post-merge.

I'm with you all the way on this.

| IMO this cannot be ignored by the topic map merging process and has to =

| be supported both in the definition of the merging process...

I agree fully.

| ...and in the representation of a merge directive in XTM.

Here I would like you to explain why. It was Lars Marius and Graham, =
editors
and implementers, who came up with the idea that added scope on =
<mergeMap>
should be done away with. It was a bit "last minute", so I would be
interested to hear from one of their peers, *why* you think this might =
not be
such a good idea.

Steve