[topicmapmail] tolog: specifying the TM

[Richard Light]

In message <20060629104917.c1njyb6vbu8sc4s4 at www.altheim.com>, Murray 
Altheim <murray06 at altheim.com> writes
>
>So "which Topic Map?" really became more of a question of "which
>Topic Maps?", though really, upon merging there are no longer any
>boundaries so this is only a list of sources, identifiable via
>their source base URLs, <topicMap> IDs, or some other extra-XTM
>way of identifying a specific source document, e.g., by some
>internally- or externally-indicated metadata such as DC.identifier.
>Because there is no standardized means (apart from base URL,
>either inferred from context or explicitly stated) of identifying
>XTM documents, __which__ Topic Map can't have a standardized
>answer, it would be application-dependent.

I take your point.  However, I would have thought that it would make 
sense to be able to specify a "starting-point" Topic Map, analogous to 
HyTime's Hub Document: a "Hub TM".  Otherwise, how can you make sense of 
the results of queries, when _what_ you are querying is not 
well-defined?

In XTM, you have explicit inclusion (mergeMap), and implicit inclusion, 
as you describe above.  If I were setting up a framework to support 
Topic Map querying, I would expect to obey any mergeMap instructions in 
my Hub TM when preparing my TMDM for querying, but I wouldn't expect to 
have to expand the scope of my TMDM to include TM constructs which are 
simply referenced therein.  The fact that the _references_ are there 
means that they can be queried: you don't need to referred-to objects as 
well.

If you don't accept this argument, and assert that all TMs whose members 
are referenced should be included in the TMDM, it rather begs the 
question of what mergeMap is there to do.  Explicitly include material 
which is totally unrelated to the Hub TM?

Richard
-- 
Richard Light
SGML/XML and Museum Information Consultancy
richard at light.demon.co.uk