[sc34wg3] Removing added scope from <mergeMap>

[Kal Ahmed]

Steve wrote:
> * Kal Ahmed
> |
> | 21, 23, 19 and 42 are mathematically concepts that are not (normally)
> | disputed 2+2 is always 4. Most topic maps consist of assertions that
> *can*
> | be disputed and there are very real requirements for being able to
> | distinguish what Party A asserts in their topic map and what Party 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.
> 

One possible scenario: 

The provider of the topic map has used a mergeMap and not done the merge
prior to sending the XTM because they have no idea (at the time of
publication) what the content of the referenced map will be. For example,
the referenced topic map might be generated by a service and updated on a
regular basis and they want the recipient to do the merge when the XTM file
is received. 

As it stands, with no added themes on the mergeMap directive, there is no
*standard* way for the publisher to express the intent that the other topic
map data needs to be scoped. As we know scoping can be used both for
tracking provenance and for preventing unwanted merges.

If publishers have no way to include third-party topic map files safely with
a record of provenance, I think that mergeMap will be pretty much restricted
to single-author use cases and drastically reduced in power.

So in a phrase: "Safe topic map aggregation".

Cheers,

Kal