[sc34wg3] Analysis of TMRM Use Cases

[Mason, James David (MXM)]

See below, snipped from Steve P's comments on Robert's message.

Jim Mason

 
> 
> Again, there is a certain intellectual satisfaction in this, 
> but it begs further important questions:
> 
> * What other "instantiations" already exist or might exist?

I think I've mentioned TMs in databases in another message, just for a
starter. From the end-user's prespective, TMs should be a black box: if it
acts like a TM, it is a TM. We may think a real TM engine offers better
performance, but if you can fake it (even a static set of generated HTML
pages, for a collection that't static), why not call it one?
 
> 
> * Do we want to call those "instantiations" Topic Maps?

Yes. That was part of the intent of the original 13250, which is what is
still in force.

> 
> * If so, to what extent does it serve or damage the interests
>   of Topic Maps users for there to be multiple models, all of
>   which can legitimately be called Topic Maps?

I believe it helps us immensely in that we can point to other things (maybe
even in RDF, horror of horrors), and say, this, too, is a TM. This helps us
make our case for TMs being a widespread phenomenon, not just a SC34 niche.

> 
> * To what extent should multiple "instantiations" of the
>   generic model be interoperable?

Most likely we want import to things we think of now as TMs.. The RM,
combined with a DM, might show us how to transform the odd representations
to something we're more comfortable with (i.e., XTM). It might be that the
transformations will not be fully reversable, it might be that some must be
assembled on a case-by-case basis, but it would help to be able to say we
have an understanding of how to create them, based on the RM.