[sc34wg3] RM4TM 2 roleplayers and merging

[Steven R. Newcomb]

Marc makes an astute observation.

"Marc de Graauw" <marc@marcdegraauw.com> writes:

> RM4TM requires at least two r-nodes in an
> assertion. The r-nodes can be x-endpoints in Cx arcs
> too. And TM Applications can confer SIDP values on
> these nodes based on their situations. Couldn't this
> lead to well-formedness violations when merging?
> 
> Example:

> When we have an association with two r-nodes, R1 and
> R2, each of which have have two SIDP's which I shall
> call S1 and S1, and they have the following values
> conferred on their SIDP's because of their
> situatedness and the rules of the governing TM
> Application:
> 
> R1
>     S1: 1
>     S2: 1
> 
> R2
>     S1: 2
>     S2: 2
> 
> If the governing TM Application would require nodes
> with the same S1 or S2 to be merged, this would
> constitute a well-formed and fully merged TM graph
> (assuming nodes and arcs not mentioned are also
> well-formed and fully merged).
> 
> Now when we merge with a second Topic Map with a node
> y which serves as the x endpoint in one or more Cx
> arcs, and which has the following SIDP values:
> 
> y
>     S1: 1
>     S2: 2
> 
> The merging process would require R1 and R2 to be
> merged, yielding an assertion with only one r-node,
> and thus the resulting TM graph would not be
> well-formed.

> So is it possible that two Topic Maps which each are
> well-formed and fully merged merge to a Topic Map
> which is no longer well-formed? 

Yes, you're quite right.

In the most general case, it is possible for merging to
cause pathological situations to exist in the graph.
It's the responsibility of the topic map author (in
this case, for example, the author of the XTM instance
that contained the <mergeMap>s that caused the two
topic maps to be merged) to fix things up so that
pathological conditions don't result.

The case you're discussing, Marc, is pretty bizarre,
but it's still undeniably possible for a Topic Map
Application to be so carelessly designed that two of
the role types of one of its assertion types may merge.
The good thing about this particular kind of error is
that it *will* be detected and it *must* be fixed.  So,
in this case, the draft RM4TM really shines, because it
helps maintain the integrity of the information.

> Or should TM Applications forbid this, and if so,
> how?

TM Applications that allow users to define their own
assertion types, as (I hope and believe) the Standard
Application does, cannot forbid this from happening
except by saying, "For pity's sake, don't make this
mistake!"

Well-engineered TM Applications that limit users to a
list of predefined assertion types and role types, and
that require all of them to be built into each topic
map graph, cannot suffer from the problem you describe.

BUT:

In the case of topic maps that are governed by a
TM Application that borrows this well-engineered TM
Application, property values may be added to those
r-nodes and, on the basis of those property values,
they may still be forced to merge.  

SO:

There is no substitute for careful thought.  It
requires careful thought to define a TM Application,
even if you borrow other TM Applications that are known
to work well in their own contexts.

-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

Coolheads Consulting
http://www.coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA